Lesson 1 of 5
Reconciliation levels
10 min
A migration load that finishes without errors has proved one thing: SAP S/4HANA accepted the records it was given. It has not proved that every record that should have arrived did arrive, that the amounts are right, or that the important fields hold the right values. Reconciliation closes that gap by comparing what left the source with what arrived in the target, at agreed levels of detail, and explaining every difference.
This course builds on the testing course for data migration, which introduced counts, sums and samples. Here we design reconciliation as an engineered deliverable: levels, specifications, automation and the evidence that data owners sign.
Three levels of reconciliation
Each level catches different errors. Counts catch missing and duplicated records. Values catch wrong amounts, signs, currencies and units. Attributes catch records that arrived complete but carry the wrong payment terms, the wrong bank account or the wrong valuation. A count can match while values differ, and values can match in total while two customers have swapped balances. You need all three, designed per object.
| Level | Typical measure | Catches | Misses |
|---|---|---|---|
| Count | Records per object and dimension | Missing, extra and duplicated records | Wrong amounts and wrong field values |
| Value | Sums of amounts and quantities per dimension | Wrong amounts, signs, currencies, units | Swapped values that cancel out; wrong non-numeric fields |
| Attribute | Field-by-field comparison, full or sampled | Wrong codes, texts, bank details, settings | Nothing in the fields compared, but costs more |
Reconciliation points
Reconcile at every hand-off, so that a difference points at the stage that caused it: source to extract, extract to transformed staging data, and staging to target. Each hand-off has expected differences, and those must be explained by rules: selection rules explain source-to-extract differences, cleansing and merge rules explain extract-to-staging differences, and load rejects explain staging-to-target differences.
- Source snapshotCounts, sums and attribute extracts at the key date
- ExtractReconcile to source; differences explained by selection rules
- StagingReconcile to extract; differences explained by cleansing, merges and exclusions
- TargetReconcile to staging; differences explained by load rejects
- Explained listEvery difference with reason, rule reference and owner approval
The reconciliation specification
Write a reconciliation specification for each object, next to its mapping specification. It makes reconciliation repeatable and reviewable before anyone runs it.
| Element | Wave 2 example: open receivables of company code 1910 |
|---|---|
| Key | Company code, customer, document number, line item |
| Dimensions | Company code, customer, currency, reconciliation account |
| Measures | Count of open items; sum of open amount in document currency and in MXN |
| Source query | Legacy ERP open items at the key date, from a saved, versioned extract query |
| Target query | Customer line items in SAP S/4HANA, for example FBL5N or the Manage Customer Line Items app, with the same layout |
| Tolerance | Zero after explained items |
| Owner | Dan, finance process owner |
Elements of a reconciliation specification, with the Wave 2 open receivables example.
What would you do?
After Wave 2 Mock 2, the count of migrated open sales order items matches the staging data exactly, and the migration specialist proposes to mark sales orders as reconciled. What should Priya ask for?
- Reconcile at three levels: count, value and attribute; each catches different errors.
- Reconcile at each hand-off so a difference points at the stage that caused it.
- Write a reconciliation specification per object: key, dimensions, measures, queries, tolerance, owner.
- Automate full-population attribute comparisons where possible; sample the rest.
Check your understanding · not graded
Lesson check
1. Counts match but total open amounts differ. Which level found the problem?
2. Why reconcile at each hand-off instead of only source to target?
3. Which difference is explained by a selection rule?
4. Which element belongs in a reconciliation specification?