← All SAP articles

Do not repeat a G/L balance upload simply because the first totals differ. First define exactly what should reconcile, then isolate whether the variance comes from scope, source preparation, rejected records, accounting treatment or the target posting. A reload without that diagnosis can duplicate valid records or hide the original cause.

The companion lesson demonstrates G/L account balances and open/line items in the SAP S/4HANA Migration Cockpit and explains year-end versus mid-year treatment. Migration objects and restrictions change by release; verify the object available in your target system before turning this sequence into a cutover procedure.

1. Fix the reconciliation frame

Write the control header before comparing numbers:

A source total in local currency cannot be compared fairly with a target total in group currency. Nor can an extract taken after late postings be compared with a target loaded from the earlier file.

2. Use a small reconciliation worksheet

Here is an illustrative mid-year extract for fictional company code A100:

ScopeSource EURAccepted for migration EURTarget EURVariance
Balance-sheet accounts480,000480,000480,0000
P&L accounts-72,000-70,000-70,0000
Rejected P&L records-2,00000-2,000

The target is not mysteriously EUR 2,000 wrong. One source record never entered the accepted population. Correct that record, simulate it again, and update the worksheet. Do not reload the already accepted records.

3. Check the transfer date and P&L treatment

In the demonstrated accounting model, a year-end transfer can focus on balance-sheet balances after the normal close has moved the net P&L result to retained earnings. A transfer within the fiscal year can require current-year P&L balances as well. That is an accounting and cutover decision, not a generic setting to copy. Confirm the fiscal-year variant, closing status and retained-earnings design with the finance owner.

4. Separate migration errors from reconciliation differences

A failed record is a processing problem: inspect the message, source key and field values. A posted amount that differs from the signed-off source is a reconciliation problem: trace its mapping, sign, currency and account. Keep two lists so that a configuration error does not get buried inside an unexplained financial variance.

Also review duplicate detection and earlier test loads. SAP documents key-field combinations used for duplicate checks for the G/L balance and open/line-item object. Never assume that “overwrite” means a previously migrated financial record will be harmlessly replaced.

5. Verify the clearing result and documents

Financial migration uses offsetting or migration-clearing accounts. SAP's posting-logic guidance states that the total balance of each migration clearing account must be zero after the required migration postings are complete. Investigate a remaining balance by migration stream—G/L, receivables, payables, inventory or assets—rather than posting a manual plug. Then compare the target trial balance and financial statements with the approved source control totals.

Common mistakes

Continue learning

If the account foundation is uncertain, review the G/L account master-data demonstration before repeating any financial load.

FAQ

Should I reload everything after correcting one row? Usually not. Determine what the cockpit accepted and follow the supported correction approach for that object and project.

Is a zero clearing-account total enough? No. It is an important control, but account-by-account, currency and financial-statement checks still matter.

What official guidance is relevant? Review SAP Help on posting logic during financial migration and the G/L balance and open/line-item object for your release.

Watch the G/L balance migration demonstration — free lesson
Did this guide help you understand the topic?

Feedback measurement requires analytics consent.