3757771 - Post-Migration Clearing of Initial Offset Accounts in SAP S/4HANA Cloud Public Edition

After completing data migration using the SAP S/4HANA Migration Cockpit, the Initial Offset Accounts (e.g., 39914000, 39915000, 39916000, 39917000, or customer-defined equivalents) carry individual non-zero balances, even though their combined total nets to zero.

The customer expects the offset accounts to automatically clear to zero after all migration objects have been executed.

"Image/data in this KBA is from SAP internal systems, sample data, or demo systems. Any resemblance to real data is purely coincidental."

• SAP S/4HANA Cloud Public Edition (all releases from 2508 onward)

1.  Migrate AR open items using "FI - Accounts receivable open item" → system posts to the Initial FI-AR offset account (e.g., 39914000)
2.  Migrate AP open items using "FI - Accounts payable open item" → system posts to the Initial FI-AP offset account (e.g., 39915000)
3. Migrate remaining G/L account balances using "FI - G/L account balance and open/line item" → system posts to the Initial other GL offset account (e.g., 39916000)
4. Attempt to include AR/AP reconciliation account balances in the G/L balance migration → error F5354 "Account & in company code & cannot be directly posted to"
5. After all migrations complete, each offset account carries a non-zero balance, but the total across all offset accounts is zero

This is expected behavior, not a defect. The root cause is architectural:

• Each migration object posts its offsetting entry to its own dedicated offset account. The sub-ledger migration objects (AR open item, AP open item) post to the AR and AP offset accounts respectively, while the G/L balance migration object posts to the GL offset account.
• The "FI - G/L account balance and open/line item" migration object does not allow direct posting to G/L accounts marked as reconciliation accounts or flagged as "Post Automatically Only" (documented in the "Out of Scope" section, item 7, of this migration object on the SAP Help Portal). This restriction ensures the GL-to-subledger reconciliation is maintained. See KBA 3091350.
• Since the sub-ledger migration objects already post to the reconciliation G/L accounts as part of the sub-ledger entry, a separate G/L balance posting to the same account is neither needed nor permitted.
• There is no automatic cross-reconciliation mechanism between the separate migration objects. Each migration object operates independently.
• The documentation states these offset accounts are used "to get a zero balance of the actual posting and to sum the total amount of the transactional data to be migrated in order to achieve a simpler comparison of totals between the source and target system" (SAP Help Portal, FI - G/L account balance and open/line item, Mapping Instructions section). Their purpose is reconciliation and verification during migration — not a permanent ledger function.
• The combination of these factors — each migration object posting to its own offset account, reconciliation accounts being excluded from the G/L balance migration object (Error F5354), and no cross-clearing mechanism between independent migration objects — means the only available path to zero the offset accounts is a manual journal entry. The documentation's Post-Processing section lists the "Post General Journal Entries" app (F0718) as a validation tool for this migration object.

After completing all migrations, the customer must perform a **manual journal entry** to clear the offset account balances against each other. This is the standard and expected post-migration cleanup step.

**Procedure:**

1. **Verify the net total.** Open the "Display G/L Account Balances" app (F0707A) and check the balances of all Initial Offset Accounts. The combined total across all offset accounts must be exactly zero. If it is not zero, investigate for missing migration data or an imbalanced legacy trial balance before proceeding.

2. **Post a clearing journal entry.** Use the "Post General Journal Entries" app (F0718) to post a single journal entry that offsets the balances across all offset accounts, bringing each to zero. Example:

   (Amounts are illustrative. The actual amounts depend on the customer's migration data. Adjust debit/credit sides based on actual balance signs.)

   If the migration also includes open/line items for non-AR/AP open-item-managed G/L accounts, an additional offset account (e.g., 39917000 – Initial other Open Item GL offset) may carry a balance and must be included in the clearing entry.

3. **Verify all offset accounts are zero.** Re-check the balances using the "Display G/L Account Balances" app.

**Note on custom offset accounts:** The documentation explicitly allows customers to use self-created offset accounts instead of the predefined standard accounts (39914000, 39915000, 39916000, 39917000). The same clearing procedure applies regardless of which accounts are used.

FAQ:

Q: Should the offset accounts be zero automatically after migration without any manual clearing?
A: No. Each migration object posts to its own dedicated offset account. There is no automatic cross-clearing mechanism between them. The manual journal entry is the designed cleanup step.

Q: Is the manual journal entry a workaround or a best practice?
A: It is the standard procedure. The offset accounts serve a temporary reconciliation and verification purpose during migration. Once the customer has verified that the net total is zero (confirming a balanced migration), clearing them via journal entry is the expected final step.

Q: We could do this differently in a previous project / in a previous release. Has the logic changed?
A: The "Out of Scope" restriction for reconciliation accounts in the G/L balance migration object is documented consistently since at least release 2508. If a previous project was able to post to reconciliation accounts via this migration object, it may have used a different account configuration (accounts not flagged as reconciliation accounts) or a different migration strategy.

Q: KBA 2699296 says the offset accounts should auto-clear. Why doesn't this work?
A: KBA 2699296 applies to SAP Business ByDesign, which uses a different migration architecture with a "Cross-Check Balances" mechanism that can auto-clear offsets within a single migration unit. SAP S/4HANA Cloud Public Edition uses separate, independent migration objects and does not have this mechanism. 

3091350 - Direct postings to reconciliation accounts are not allowed - error F5354 
2853964 - Migration Cockpit: Collective KBA for G/L Open Item or G/L Balance or FI AP/AR Open Item 
2699296  Migration of Accounting Transaction Data Cross-Check Balances (CAUTION: Business ByDesign only, not applicable to S/4HANA Cloud Public Edition) 
SAP Help Portal | FI - G/L account balance and open/line item — Out of Scope section, item 7: 
2Q2 Test Script | Data Migration to SAP S/4HANA from Staging — offset account definitions and "total balances must be ZERO" instruction (available via SAP Signavio Process Navigator, Accelerators section -  Process Navigator - SAP for Me  -> Solution Scenario: SAP Best Practices for SAP S/4HANA Cloud Public Edition )

Migration Cockpit ("Migrate Your Data" app)

Migration objects: FI - G/L account balance and open/line item, FI - Accounts receivable open item, FI - Accounts payable open item, and related sub-ledger migration objects

migration, offset account, clearing, initial offset, 39914000, 39915000, 39916000, 39917000, F5354, reconciliation account, post automatically only, manual journal entry, zero balance, data migration, migration cockpit, FI - G/L account balance, FI - Accounts receivable open item, FI - Accounts payable open item, SAKOMIG, initial FI-AR offset, initial FI-AP offset, initial other GL offset , KBA , FI-GL-GL-A-2CL , Posting/Clearing (Public Cloud) , How To