SAP ECC Data Validation — Cent-Exact, Audit-Signed

Sap ecc data validation is the post-load reconciliation discipline that proves the Fusion tenant matches the ECC source to the cent, line by line, across every dimension the auditor cares about. That means: GL trial balance reconciliation per company code, per ledger (leading + non-leading), per period, in local currency + group currency + hard currency; AP/AR aging reconciliation (bucketed aging in Fusion matches bucketed aging in ECC to the cent); fixed-asset register reconciliation (asset count, gross-block, accumulated depreciation, NBV match per asset class); inventory reconciliation (on-hand quantity and value per item per warehouse); open PO and SO reconciliation (count + committed value); HR headcount reconciliation. Every reconciliation report is signed, timestamped, hash-anchored and lands in the cutover evidence binder.

Every record extracted from ECC is hashed at source — BKPF documents get a header hash, BSEG line items get individual line hashes that roll up to the document, KNA1/LFA1 master records get a row hash, MARA materials get a row hash per organisation context. After Fusion load, the equivalent record is re-hashed using the same algorithm. Sap ecc data validation compares: row counts (documents, lines, master records, items) per business unit per period; sum totals (GL debits and credits per ledger per period in every reporting currency, AP open balance per supplier per BU, AR open balance per customer per BU); hash signatures per partition. Discrepancies surface immediately with the exact field-level cause — a missing posting key translation, a misrouted Z-* field, a UoM conversion divergence. No silent loss.

ECC supports up to three local currencies per company code (DMBTR / DMBE2 / DMBE3 in BSEG) plus the document currency (WRBTR), and may run multiple non-leading ledgers (IFRS, HGB, US GAAP) parallel to the leading ledger 0L. Sap ecc data validation reconciles every currency on every ledger. Trial balance in Fusion primary ledger matches ECC leading ledger 0L in local currency to the cent. Trial balance in Fusion secondary ledger (IFRS or HGB) matches the corresponding ECC non-leading ledger. Group-currency reporting matches across the consolidation reporting currency. Hard-currency (for high-inflation entities) matches via DMBE2 alignment. Translation rates are validated row-by-row — the rate used in ECC on the posting date is the rate used in Fusion. No FX gaps.

The GL trial balance pack is the signature deliverable. Per company code, per ledger, per period: a side-by-side report listing every account at the leaf level — ECC SKB1 account number, ECC closing balance in local currency, group currency, hard currency; Fusion GL account (post-crosswalk), Fusion closing balance in primary ledger currency, secondary ledger currency, reporting currency; variance per column. The pack is acceptable only at zero variance. Roll-ups show net debit/credit per account class (Asset, Liability, Equity, Revenue, Expense) and per FS category to confirm the COA crosswalk preserved the balance sheet and P&L structure. Cutover sign-off blocks until the pack ships clean. External audit and Wirtschaftsprüfer receive the pack directly.

Open AP (BSIK) and open AR (BSID) need exact open-balance reconciliation per supplier per company code (AP) and per customer per company code (AR), in document currency and in all reporting currencies. Sap ecc data validation produces: an open-item count match (Fusion open invoice count = ECC BSIK row count per supplier per BU), an open-balance match (sum of unapplied amounts), an aging bucket match (0–30 / 31–60 / 61–90 / 91+ days bucket totals match), a partial-payment match (any ECC invoice with a partial cash application has the same unapplied balance in Fusion), and a credit-memo match (open credit memos applied or unapplied match). The German Wirtschaftsprüfer signs off on the aging match before cutover — discrepancy means an open item was lost or mis-applied during load.

Fixed assets (ANLA master + ANLC value-segment) require asset-by-asset reconciliation. Sap ecc data validation produces: asset count match per asset class per company code; gross-block match per asset class per company code (sum of original cost); accumulated depreciation match per asset class per company code per depreciation area (ECC depreciation areas 01/02/03 etc. map to Fusion books primary/secondary/tertiary); NBV match per asset (gross minus accumulated); year-to-date depreciation match per period. Additions and retirements within the migration period reconcile as movement journals. The asset register is the most error-prone domain in any ECC migration — sap ecc data validation catches misrouted asset classes, missed sub-numbers (ANLA-ANLN2 sub-asset numbering), and depreciation-area gaps before cutover.

Z-* fields routed to Fusion COA segments are reconciled as part of the GL trial balance pack — a balance pivot by Z-* dimension in ECC has to match the same pivot by COA segment value in Fusion. Z-* fields routed to Fusion DFFs are reconciled by row sampling: for every BSEG row with a non-NULL Z-* value, the DFF on the corresponding Fusion GL Journal Line has the equivalent value. Z-* fields routed to the long-term ECC archive are excluded from Fusion-side reconciliation but verified in the archive's data integrity check (hash anchored at archive-write time). Z-* fields explicitly retired during classification are confirmed retired with a zero-coverage report. Every Z-* routing class has a corresponding reconciliation check — nothing slips through silently.

After the bulk load completes, the sap ecc data validation cycle runs over 1–2 weeks per parallel-run cycle. The engine produces all reconciliation packs automatically — the labour-intensive part is human review and exception remediation: identifying a misrouted Z-* field, fixing the mapping, re-loading the affected partition, re-running the pack. Two parallel cycles of full reconciliation are typical: cycle 1 surfaces the systematic exceptions (90% of total exceptions caught), cycle 2 surfaces the long-tail (rare doc types, edge cases). Cutover is blocked until: (a) every GL trial balance reconciles to the cent in every currency on every ledger, (b) AP/AR aging reconciles per supplier/customer per BU, (c) FA register reconciles per asset, (d) the inventory value matches per item per warehouse, (e) external audit and Wirtschaftsprüfer have signed the evidence binder. No silent overrides, no 'we'll fix it post-cutover'.