Intercompany Postings Out Of Balance Between Company Codes

The controller for one entity reports that the intercompany balance shown in their books does not match what the counterparty entity is carrying for the same relationship, usually surfaced during month end close reconciliation between two company codes that trade goods, services, or cost allocations with each other. The complaint is phrased as a number mismatch: company code 1000 shows a receivable of a certain amount from company code 2000, but 2000's payable to 1000 is a different figure, sometimes by a small rounding amount, sometimes by the full value of a missing document. Consolidation or group reporting flags the difference as an unresolved intercompany elimination item. Nobody has touched the accounts manually as far as anyone admits, and the individual documents, viewed one at a time, appear to balance.

Pull FBL3N line items for the intercompany clearing accounts in both company codes for the period, filter on the cross-company document number or the trading partner field, and lay the two lists side by side. A document present on one side and absent on the other confirms a missing leg. A document present on both sides with a difference confined to the local currency amount, not the document currency amount, confirms an exchange translation cause rather than a posting error.

If the cause is missing OBYA configuration, the fix is a customizing change transported through the normal path, not a data correction, and it must be tested with a fresh cross-company posting before the transport is released to confirm both legs now generate correctly. If the cause is a currency translation residual, the fix is usually accepting the exchange difference as legitimate and reclassifying it out of the clearing account into the exchange rate difference account it belongs in, which is a data correction posted with the appropriate document type. If the cause is a manual one-sided correction, the fix is to post the missing mirror entry in the counterparty company code, referencing the original document, and this is a data fix that should go through the same approval as the original transaction since it touches two entities' books. If the cause is inconsistent document splitting or tax configuration between the company codes, that is a customizing alignment requiring change management sign-off from both entities' finance leads before transport, because it changes how future documents post, not just the current imbalance.

The reflex fix is a manual journal entry that debits one clearing account and credits the other to force both balances to zero for the close. This clears the reconciliation report for the current period but leaves no link to the original transaction, so the underlying configuration or process gap that caused the split is never found. The same imbalance reappears the following month, usually larger, because the manual entry has itself broken the pairing between the two company codes' ledgers and made a later proper reversal impossible without unwinding the correction first.

The FI general ledger team owns the intercompany clearing configuration and the reconciliation process, but correcting the imbalance touches two company codes' books, so both controllers or their delegates need to sign off on any correcting entry. The handover note should state the affected company code pair, the clearing account numbers, the cross-company document number involved, and whether the fix applied is a data posting or a configuration change awaiting transport.