Lesson 5 of 6
Reconciliation and testing
9 min
Listen to this lesson
The central ledger is only useful if finance trusts it, and trust in Central Finance means one thing: for every source, the central system holds the same accounting, translated through the mappings, with every difference explained. That is a reconciliation design, and it is this course's main deliverable.
Three levels of reconciliation
| Level | Question | How |
|---|---|---|
| Technical | Did every source document arrive and post? | Document counts per source, company code, period and status; SAP's comparison reports such as FINS_CFIN_DFV_FI_NUM for FI document numbers |
| Financial | Do amounts match, through the mappings? | Balances per company code, account and period, source versus central, with source accounts translated through key mappings |
| Business | Do the reports make sense to finance? | Trial balance, P&L by profit center and open items reviewed by owners |
Reconciliation levels in Central Finance.
SAP delivers comparison reports in the central system for FI and CO documents and balances, run against one source system at a time. The document-number comparison is the first check: which source documents have no central counterpart, and in which status are they. The balance comparisons follow. Because the central system re-keys everything, every financial comparison has to translate source keys through the mapping tables first, otherwise it compares apples with differently labeled apples.
Explaining differences
| Difference source | Example | Expected? |
|---|---|---|
| Open AIF errors | 1,240 documents awaiting a new account mapping | Temporary; must be zero or accepted before close |
| Mapping many-to-one | Three source accounts map to one central account | Expected; compare at central account level |
| Derivation in the central system | Central profit center derived differently from source | Expected by design; test the rule separately |
| Initial load granularity | Summarized history versus line items | Expected for loaded periods; agree the basis |
| Postings outside replication | Document types excluded from replication by configuration | Expected only if documented |
Why source and central figures differ, and which differences are acceptable.
The test plan
- Unit tests per mappingOne document per mapping rule, checked field by field in the central document
- Initial load mockFull initial load into a test central system; technical and financial reconciliation
- Process testsSource processes (invoice, payment, goods receipt, settlement) end to end into the central ledger
- Error testsInjected errors fixed and restarted
- Period-end parallelA full period closed in the sources and reconciled centrally
- Volume testPeak posting volume with latency and error rate measured
Process tests are where testers add the most value. Post a supplier invoice in EP1 for 1710, for 500 rotors CMC-RTR-200 at USD 42.00 from Lakeside Components, and follow it: the source document, the replicated central document with mapped supplier and account, and its effect on the central trial balance. Then pay it in the source (or centrally, if Central Payments is active for 1710) and follow the clearing. Each step has an expected central result written before the test.
What would you do?
The balance comparison for 1710 shows the central G/L account for freight costs USD 18,300 higher than the sum of the three EP1 freight accounts mapped to it. AIF is empty for the period. What is the likely next step?
A worked count reconciliation
| Count for 1710, period 06 (illustrative) | Documents |
|---|---|
| FI documents posted in EP1 | 48,250 |
| Excluded by configuration (documented document types) | 310 |
| Expected in the central system | 47,940 |
| Posted centrally | 47,902 |
| Open in AIF (missing mapping, one new account) | 38 |
| Unexplained | 0 |
A technical reconciliation that closes: every source document is posted, excluded by design or waiting in AIF.
The count closes when the unexplained line is zero. The 38 documents in AIF are not a problem as long as they are fixed and restarted before the close, after which the posted count becomes 47,940. Only then does the balance comparison make sense, because comparing balances while documents are missing guarantees differences.
Auditors will ask how the central ledger is known to be complete. The answer is this pack, period after period, with the reports run the same way each time and the mapping tables versioned. Keep reconciliation evidence for as long as the central ledger is used for statutory reporting.
Tolerances
Unlike a consolidation parallel run, Central Finance reconciliation has almost no room for tolerance. Amounts are never mapped, so balances translated through mappings must match exactly once AIF is empty. The only tolerances that make sense are for currency rounding when the central system recalculates amounts in additional currencies (for example a different group currency setting) and for documented exclusions. Write those down per company code and currency, and treat any other difference as a defect until it is explained.
- Reconcile at three levels: technical counts, financial balances, business review.
- Translate source keys through the mappings before comparing balances.
- Classify every difference: errors, mapping design, derivation, load granularity, exclusions.
- Test with process flows whose central results are written down in advance.
Check your understanding · not graded
Lesson check
1. What is the first reconciliation level after replication?
2. Why must source accounts be translated through key mappings before comparing balances?
3. Three source accounts map to one central account. How do you compare?
4. Which difference must be zero or explicitly accepted before the central close?