Lesson 3 of 6
Reconciliation methods
10 min
Listen to this lesson
Reconciliation proves completeness and accuracy with three families of evidence: totals (counts and amounts that must agree), comparisons (record-by-record matching of source and target) and samples (detailed checks of selected items). A strong reconciliation uses all three, chosen per object by risk and volume.
Three points of comparison
For a load, compare at three points, not two. The legacy source at cut-off, the extract that went into the Migration Cockpit, and the target in SAP S/4HANA. Comparing only extract and target proves the load worked, but not that the extract was complete. Comparing only legacy and target finds a difference but not where it arose.
- Legacy at cut-offTrial balance, AR and AP agings, asset register, stock valuation, frozen and signed
- ExtractControl totals per file: record count, sum of amounts, hash total of keys
- LoadCockpit log: records created, errors, warnings
- TargetSame reports run in SAP S/4HANA with the same selection
- Three-way matchLegacy = extract = target, per object and per currency
Totals
| Total | Proves | Contoso example |
|---|---|---|
| Record count | Nothing was lost or duplicated | 1,946 customers in scope, 1,946 created; open AR items 8,412 in legacy, extract and target |
| Amount total by key dimension | Values arrived in aggregate | Open AR by customer, currency and reconciliation account |
| Hash total | The same set of records moved, even when amounts net out | Sum of legacy customer numbers in the extract equals the sum in the mapping file |
| Debit and credit totals separately | Offsetting errors do not hide in a net total | Debit and credit balances per G/L account group |
Totals and what each proves. Totals by key dimension beat one grand total.
One grand total is weak evidence: a MXN 10,000 error on one customer and a MXN -10,000 error on another cancel out. Totals by key dimension, such as by customer and currency, or by G/L account and ledger, make offsetting errors visible.
Reports in SAP S/4HANA
Use the reports finance will use after go-live, with selections that match the legacy reports. Typical choices: the Trial Balance app or the G/L balance reports for G/L accounts by ledger; Manage Customer Line Items and Manage Supplier Line Items (or FBL5N and FBL1N) for open items, plus customer and supplier balance lists; the Asset History Sheet for assets by depreciation area; and stock value lists such as MB5L, which compares stock values with the inventory G/L accounts. For a conversion, run the same set in ECC immediately before downtime and in SAP S/4HANA immediately after the finance migration steps, with identical selections, and keep both outputs.
For conversions, SAP also provides consistency checks to run before the conversion, and the finance migration steps in Customizing produce their own logs and reconciliation output. Check the current SAP conversion guide and notes for your release to see which checks and reports apply; run them in every mock so cleanup is finished before the production weekend.
Samples for attributes and large volumes
Totals cannot prove that due dates, payment terms or depreciation keys are right. For that, sample. The international auditing standard on audit sampling (ISA 530) describes useful ideas you can borrow: define the population clearly, give every item a chance of selection for a statistical sample, consider stratification so large items are covered, and use value-weighted selection when the risk is in the amounts. Items that are individually significant are usually tested 100% and the rest sampled.
What would you do?
The migration lead suggests reconciling the 1910 open AR with one grand total: legacy MXN 48,615,320.40 versus SAP MXN 48,615,320.40. It matches. What should Dan add before accepting?
- Reconcile at three points: legacy at cut-off, extract and target.
- Use counts, totals by key dimension and hash totals; avoid relying on one grand total.
- Run the same finance reports before and after, with identical selections, and keep the outputs.
- Sample attributes: check high-value items in full, stratify, and compare with the legacy source.
Check your understanding · not graded
Lesson check
1. What does a three-way match add over comparing only extract and target?
2. Why are totals by key dimension better than one grand total?
3. Which items should normally be checked in full rather than sampled?
4. A sampled due date is checked against the load file and matches. What is missing?