The count of cross-Business-Unit journals that fail Oracle Fusion’s intercompany balance check. Unbalanced intercompany lines block consolidation in Oracle Cloud EPM and delay the close.
At a glance
Intercompany Business Unit Imbalances counts the cross-Business-Unit transactions in Oracle Fusion whose intercompany lines do not balance. In a multi-Business-Unit Oracle Fusion environment, every intercompany transaction should have an equal and opposite leg in the counterparty Business Unit: when one unit books an intercompany receivable, the other must book the matching payable. When those legs do not tie out, the intercompany balance check fails, eliminations cannot run, and consolidation in Oracle Cloud EPM (the Financial Consolidation Hub) is blocked. An unbalanced intercompany position is one of the most common reasons a Fortune 500 group close slips. A reading of zero is the healthy state; anything above zero is exceptions a human must clear before the books can consolidate.
| What it counts | The number of cross-Business-Unit journals or intercompany transactions that fail the intercompany balance check in Oracle Fusion, where the originating leg and the counterparty leg do not net to zero across the trading Business Units. |
| Why it blocks the close | Consolidation eliminates intercompany balances against each other. If the two sides do not match, the elimination leaves a residual and the Financial Consolidation Hub cannot produce a clean consolidated reporting ledger. The close waits on resolution. |
| Common causes | A counterparty leg never posted, the two legs used different amounts or FX rates, one side posted in the wrong period, or an intercompany transaction type was mis-mapped so only one Business Unit recorded it. |
| Business Unit scope | Respects the dashboard’s selected Business Unit and Ledger filter. By default rolls up every trading Business Unit pair the connected role can see. |
| Time window | RT (real-time, re-evaluated each sync) |
| Alert trigger | >0 - any unbalanced intercompany journal is an exception that needs a human |
| Roles | owner, finance |
Calculation
Calculated automatically from your Oracle ERP Cloud data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A US Fortune 500 group runs Oracle ERP Cloud with three trading Business Units: US Retail Inc, UK Retail Plc, and EU DTC NV. During the Mar 26 close on 09 Apr 26, the intercompany balance check flags four unbalanced positions.| Trading pair | Originating leg | Counterparty leg | Residual | Cause |
|---|---|---|---|---|
| US Retail Inc → UK Retail Plc | $1,840,000 IC receivable | $1,792,000 IC payable | $48,000 | FX rate mismatch between the two legs |
| US Retail Inc → EU DTC NV | $620,000 IC receivable | none | $620,000 | Counterparty leg never posted |
| UK Retail Plc → EU DTC NV | $310,000 IC payable | $310,000 IC receivable, wrong period | n/a (period) | One leg posted to Feb-26, the other to Mar-26 |
| EU DTC NV → US Retail Inc | $95,000 IC receivable | $95,000 IC payable | $0 in value, type mismatch | Mis-mapped intercompany transaction type |
- The count is 4, not the dollar value. This card counts unbalanced positions, not the residual amount. Each of the four trading-pair exceptions is one row blocking the elimination, regardless of size. The 620,000 missing leg each count as one.
- The $620,000 missing leg is the dangerous one. US Retail Inc booked an intercompany receivable but EU DTC NV never recorded the payable, so consolidated equity is overstated until the counterparty posts. This is the classic one-sided intercompany error.
- A period mismatch counts even when the values agree. UK Retail Plc and EU DTC NV both booked $310,000, but in different periods, so the check still fails for the period being closed. Timing breaks intercompany just as surely as amount breaks do.
- Consolidation is blocked until all four clear. The Financial Consolidation Hub will not produce a clean consolidated reporting ledger while any intercompany position is unbalanced. This is why the card sits in the Period Close category and why owner is on the role list with finance: a stuck intercompany position is a stuck group close. Pair it with GL Period Close Past Deadline.
Sibling cards merchants should reference together
Intercompany imbalances are a close-blocker. Pair this card with the rest of the close and consolidation picture.| Card | Why pair it with Intercompany Business Unit Imbalances |
|---|---|
| Intercompany Balance | The net intercompany position. This card is the count of unbalanced legs behind it. |
| GL Period Close Past Deadline | Unbalanced intercompany is a frequent reason the group close runs late. |
| GL Period Close Status | The live close status that intercompany resolution gates. |
| Revenue by Subsidiary | Intercompany revenue is what eliminates; this shows the per-unit revenue before elimination. |
| Open (Unposted) Journals | A missing counterparty leg often sits as an unposted journal. |
| Period Close On-Time Rate (12mo) | The trend that recurring intercompany breaks erode. |
| Oracle Fusion Health Score | The composite that unbalanced intercompany drags down. |
Reconciling against Oracle ERP Cloud
Where to look in Oracle ERP Cloud: The closest native equivalents in the Oracle Fusion UI are:Navigator → Intercompany → Transactions → Manage Intercompany Transactions (status and balance of each intercompany transaction) General Accounting → Period Close → Close Monitor (intercompany as a close prerequisite) Reports and Analytics → OTBI → Financials → Intercompany Transactions Real TimeManage Intercompany Transactions shows each cross-Business-Unit transaction and whether its legs balance. Transactions in an unbalanced or incomplete status, for the period being closed, are what this card counts. The count there, scoped to the same Business Units and period, should match this card. The detail names the trading pair and the residual, which is what finance needs to resolve each one. Common mistakes when comparing against Oracle’s own reports:
- Counting value instead of transactions. Oracle’s intercompany reports can show a net residual amount. This card counts the number of unbalanced positions, not the dollar residual.
- Ignoring period mismatches. Two legs with equal amounts in different periods still fail the check for the period being closed. Filter to the close period, not to all-time.
- Wrong Business Unit pairing. A residual belongs to a specific trading pair. Querying a single Business Unit misses the counterparty side of the imbalance.
| Reason | Direction | Why |
|---|---|---|
| Count vs value | Card different | The card counts unbalanced positions; an Oracle report showing residual value will not reconcile to a count. |
| Period scope | Either | The card scopes to the close period in the dashboard filter; an all-period Oracle query shows more. |
| Business Unit scope | Either | The card spans every trading pair in the filter; a single-Business-Unit view shows fewer. |
| Resolved since sync | Card higher | If a counterparty leg posts right after the last sync, the card still counts the imbalance until the next refresh. |