Validation methods: counts, totals and samples

Business validation answers two questions. Is the data complete: did everything that should arrive actually arrive, and nothing extra? Is it accurate: does each record mean the same thing in SAP S/4HANA as it did in the legacy system? Three methods answer those questions together: counts, control totals and samples.

Counts

A count compares the number of records in the extract (after agreed exclusions) with the number in the target. Count at a useful level of detail: customers by account group, products by plant and product type, open items by company code and currency. A total count of 1,842 that matches can hide 40 missing fleet customers offset by 40 duplicates elsewhere; counts by group expose that.

Always agree the source count with the migration team before the load. If the extract was filtered (for example, customers with no activity in three years were excluded by a business decision), the expected count is the filtered one, and the exclusion rule is part of the evidence.

Control totals

For anything with an amount or quantity, compare totals. Finance validation is mostly control totals:

• AR and AP open items: total by company code, document currency and reconciliation account, compared with the legacy aged receivables and payables at the migration key date.
• G/L balances: the Trial Balance app in SAP S/4HANA compared account by account with the legacy trial balance at the same date, after mapping legacy accounts to new ones.
• Inventory: quantity and value by plant, storage location and product, compared with the legacy stock valuation. In SAP S/4HANA, MB52 lists warehouse stock and values.
• Tie-out: AR, AP and inventory sub-ledger totals must agree with their G/L reconciliation accounts, and the migration offset accounts must net to zero.

Getting the figures out of SAP

Use standard reports and apps with saved variants so the same selection runs in every mock. List reports such as Manage Customer Line Items, Trial Balance and MB52 can export to a spreadsheet, where the comparison with the legacy extract is a matter of lookups and sums. Agree the selection with the migration team: same company code, same key date, same currencies, same exclusions. Avoid reading raw database tables for business validation; the point is to see the data the way users will see it.

Field profiles

A field profile counts records by the value of a key field in both systems: customers by payment term, products by valuation class, suppliers by payment method. Profiles catch mapping errors fast. If 1,100 legacy customers had 30-day terms and only 700 SAP customers do, a mapping rule is wrong somewhere, even though counts and totals match.

Samples

A sample compares individual records field by field. It is the only way to see that the street address, the bank account, the tax number and the credit limit came through correctly on a real record. Basic sampling rules keep it honest:

• Pick some records at random so the sample represents the whole population.
• Add targeted records: the biggest customers, records with unusual characters, foreign addresses, multiple bank accounts, partner functions, or anything that broke in a previous mock.
• Size the sample to the risk. A common practical rule is 20 to 30 random records per object plus targeted ones; critical objects such as supplier bank details may justify more, or a full comparison where a tool allows it.
• Compare against the legacy source, not against the load file, so transformation errors are caught.
• Record every field compared, the expected and actual value, and the result.