Lesson 3 of 5
Reconciliation design
13 min
Listen to this lesson
Reconciliation proves completeness and correctness in bulk: what left the source arrived in the target, with the same counts and values, except for differences that are explained and approved. It is the migration equivalent of an accountant tying out a ledger, and finance owners will not sign without it.
Three kinds of checks
| Check | What it compares | Alternadores del Norte example | Catches |
|---|---|---|---|
| Count | Number of records per object and key dimension | Customers per sales area; open PO items per plant | Missing or duplicated records |
| Sum | Totals of amounts and quantities per dimension | Open AR by company code and currency; stock quantity and value by plant and storage location | Wrong amounts, signs, currencies |
| Key attribute and sample | Field values for important attributes, for all records or a sample | Payment terms, bank details, tax numbers, product valuation class | Wrong values that totals hide |
Where to reconcile
Reconcile at each hand-off, so that a difference points directly at the stage that caused it: source to extract (did we extract what the selection rule says?), extract to staging (did transformation keep or explain every record?) and staging to target (did the load post everything?). A single source-to-target comparison tells you that something is wrong but not where.
- Source (legacy ERP)Counts and totals from the source as of the cutover key date
- ExtractReconcile to source; differences = selection rules
- StagingReconcile to extract; differences = transformations, merges, exclusions
- Target (SAP S/4HANA)Reconcile to staging; differences = load rejects
- ExplainedEvery difference listed with reason and owner approval
Designing the financial reconciliation
Finance objects need the most precise design, agreed with Dan before Mock 1. For the Alternadores del Norte load:
- Open receivables and payables: count of open items and sum of open amounts per company code, currency and customer or supplier, source against target. Display the target with customer and supplier line item reports (for example
FBL5NandFBL1Nin SAP GUI, or the Manage Customer Line Items and Manage Supplier Line Items apps). - Inventory: quantity and value per product, plant and storage location (for example with
MB52, or the stock apps in Fiori), compared with source stock on the key date. - G/L balances: the trial balance by G/L account for company code 1910, mapped from the legacy ERP's accounts to Contoso's chart of accounts, so that the opening balances in company code 1910 equal the legacy ledger's.
- Migration clearing accounts: zero after all financial objects are loaded. Any residual means a gap or a double count.
Tolerances and explained differences
Agree up front what difference is acceptable per check. For financial values the usual tolerance is zero, after explained items. For counts, differences are normal when selection rules exclude records or duplicates are merged; the requirement is that every difference is listed with its reason. Record each reconciliation as: check, source figure, target figure, difference, explanation, owner approval. That table is the core of the migration evidence.
| Check (Mock 3) | Source | Target | Difference | Explanation |
|---|---|---|---|---|
| Customers, sales area 1910 / 10 / 00 | 1,946 | 1,943 | −3 | 3 merged duplicates per approved rule |
| Open AR, company code 1910, MXN | MXN 48,615,320.40 | MXN 48,615,320.40 | 0 | – |
| Stock ADN-200, plant 1910 | 2,300 pc / MXN 6,210,000.00 | 2,300 pc / MXN 6,210,000.00 | 0 | – |
| Open PO items, plant 1910 | 612 | 610 | −2 | 2 items fully received before key date; source extract timing; approved |
Extract from the Alternadores del Norte reconciliation log. Numbers are fictional.
What would you do?
In Mock 3 of the Alternadores del Norte load, open AR for company code 1910 matches in total, but a per-customer comparison shows Flotillas Monterrey S.A. de C.V. MXN 12,400 higher in the target and another customer MXN 12,400 lower. What should Priya do?
Make reconciliation repeatable
Reconciliation runs in every mock and again on go-live weekend, at three in the morning, under time pressure. Build it once and reuse it. Prepare source and target reports with the same dimensions (company code, currency, plant, customer, supplier, G/L account), in the same layout, so that comparison is mechanical. Keep the queries or report variants under version control with the mapping specification, and test them in Mock 1 alongside the data. On the weekend, the job should be to run the prepared reports and read the differences, not to design checks.
Also agree with Luis where reconciliation sits in the cutover plan. Some checks, such as counts after each object load, run immediately; financial reconciliation runs after all finance objects are loaded. Each check gets a time slot, an owner and a decision point, because a difference found late in the sequence can force earlier objects to be reloaded.
- Use count, sum and key-attribute checks; each catches different errors.
- Reconcile at every hand-off: source to extract, extract to staging, staging to target.
- Financial objects: open items per customer and supplier, stock per product and location, G/L by account, clearing accounts to zero.
- Agree tolerances in advance; list every difference with an explanation and owner approval.
Check your understanding · not graded
Lesson check
1. Which reconciliation check proves open AR balances migrated correctly in total?
2. Why reconcile at each hand-off rather than only source to target?
3. Why reconcile per customer as well as in total?
4. What should migration clearing accounts show once all financial objects are loaded?