Lesson 1 of 6
Reconciliation layers for a consolidation
8 min
Listen to this lesson
This course discusses ACCELQ by name. Matt Angerer, who runs The Sign-Off Table, works at ACCELQ. Disclosure
A system consolidation changes data in two places at once. The incoming business must arrive complete and correct, and the business already in the system must come out unchanged. Most migration reconciliation, including course sap-dmg-302, focuses on the first half. This course is about proving both halves, plus the extra checks that mergers and carve-outs add: intercompany positions that change meaning, mappings that merge accounts and org units, and data that must not be there.
The running example is Contoso's Wave 2: loading Alternadores del Norte from its non-SAP legacy ERP into Contoso's live SAP S/4HANA as company code 1910 (MXN), plant 1910 Monterrey, sales area 1910 / 10 / 00. The W2 mock loads run into client 100 in CMQ from October 2026, and the go-live weekend is planned for February 5 to 7, 2027. Lessons 2 and 4 add clearly labeled what-ifs for SAP-to-SAP merges and carve-outs.
Nine layers
The first four layers are standard migration reconciliation. Layers 5 to 9 are what make consolidation different. Mapping checks that the design was applied, not just that totals match: a balance can tie while landing on the wrong account. Document flow matters when documents are moved or renumbered; SAP Help says a DMLT company code merge does not affect document flow, but that is a claim to test, not an assumption to sign. Intercompany changes meaning in a deal: Alternadores' receivables from Contoso were third-party items in its legacy ERP and are intercompany items in 1910. And the negative layer covers both carve-out leakage and the quiet risk of an absorption: that loading 1910 changed something in 1710 or 1810.
Two directions: incoming and untouched
The untouched check is cheap and often skipped. Before each W2 mock load, capture the trial balance of 1710 and 1810 for every ledger, open AR and AP totals, stock values and a few document counts in CMQ, using report variants saved for the purpose. After the load, run the same variants again. Any difference must be explained by a deliberate posting during the mock; an unexplained one means the load or a configuration transport touched a company code it should not have. In CMQ other testing continues during a mock, so freeze posting in 1710 and 1810 for the hours between the two snapshots or agree a list of expected test postings.
| Check ID | Layer | Object and company code | Target report | Tolerance | Owner |
|---|---|---|---|---|---|
| W2-R01 | Volume | Business partners with 1910 sales data | Count by sales area 1910 / 10 / 00 (SE16H on the customer sales data) | 1,946 exactly | Hannah |
| W2-R04 | Open items | Open AR 1910, MXN | FBL5N or Manage Customer Line Items (F0711) | 0.00; per customer | Dan |
| W2-R07 | Balances | Trial balance 1910, ledgers 0L and 2L | FAGLB03 or Trial Balance (F0996) | 0.00 per account | Dan |
| W2-R11 | Intercompany | 1910 AR from 1710 against 1710 AP to 1910 | FBL5N in 1910, FBL1N in 1710, trading partner set | 0.00 at agreed rate | Dan |
| W2-R14 | Negative | Trial balance 1710 and 1810, before and after load | Same saved variants, both snapshots | No unexplained change | Priya |
An extract from the Wave 2 reconciliation plan (illustrative course data); check IDs link each check to the mapping workbook.
Merge arithmetic
When two company codes become one, the target balance is not simply the sum of the sources. Consider a what-if: after Wave 2, Contoso decides to merge the Toledo distribution entity 1810 into 1710 with a DMLT company code merge, which is possible because both are in the same client. For each account, the merged 1710 balance must equal 1710 plus 1810 before the merge, adjusted for intercompany: 1710's receivable from 1810 and 1810's payable to 1710 for CMC-ALT-100 shipments at the $200 internal price must be settled or eliminated, or the merged company owes itself money. Agree the rule per account with finance before the first mock, and write the expected result into the check.
What would you do?
After W2 Mock 1, 1910 ties to the legacy source on every layer. The untouched check shows that 1710's trial balance in ledger 2L changed by USD 12,480 on one revenue account between the two snapshots. No one posted in 1710 during the mock. What should Priya do?
- Consolidations need nine layers: volume, balances, open items, subledger, mapping, document flow, intercompany, field level and negative.
- Reconcile both directions: the incoming company code against its source and the untouched company codes against themselves.
- Merged balances equal the sum of the sources adjusted for intercompany; write the expected result per account.
- Every difference is fixed and retested or explained and accepted by a named owner.
Check your understanding · not graded
Lesson check
1. What does the untouched check in Wave 2 prove?
2. A trial balance ties, but revenue landed on the wrong G/L account. Which layer catches it?
3. In a what-if merger of 1810 into 1710, what must be adjusted when comparing merged balances to the sources?
4. SAP Help says a company code merge does not affect document flow. How should the test team treat that?