> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Intercompany Business Unit Imbalances, Oracle ERP Cloud > Intercompany Business Unit Imbalances counts cross-Business-Unit journals in Oracle Fusion that fail the intercompany balance check, blocking consolidation and delaying the close. **Card class:** [Hero](/nerve-centre/overview#card-classes-explained) • **Category:** [Ecommerce Platform](/nerve-centre/connectors#connectors-by-type) > 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 | Four things to notice: 1. **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 $48,000 FX residual and the $620,000 missing leg each count as one. 2. **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. 3. **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. 4. **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](/nerve-centre/kpi-cards/oracle-erp/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](/nerve-centre/kpi-cards/oracle-erp/oerp-intercompany-balance) | The net intercompany position. This card is the count of unbalanced legs behind it. | | [GL Period Close Past Deadline](/nerve-centre/kpi-cards/oracle-erp/gl-period-close-past-deadline) | Unbalanced intercompany is a frequent reason the group close runs late. | | [GL Period Close Status](/nerve-centre/kpi-cards/oracle-erp/gl-period-close-status) | The live close status that intercompany resolution gates. | | [Revenue by Subsidiary](/nerve-centre/kpi-cards/oracle-erp/oerp-revenue-by-subsidiary) | Intercompany revenue is what eliminates; this shows the per-unit revenue before elimination. | | [Open (Unposted) Journals](/nerve-centre/kpi-cards/oracle-erp/open-unposted-journals) | A missing counterparty leg often sits as an unposted journal. | | [Period Close On-Time Rate (12mo)](/nerve-centre/kpi-cards/oracle-erp/period-close-on-time-rate-12mo) | The trend that recurring intercompany breaks erode. | | [Oracle Fusion Health Score](/nerve-centre/kpi-cards/oracle-erp/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 Time** Manage 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. **Why our number may legitimately differ from Oracle's reports:** | 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. | ## Known limitations / merchant FAQs **What exactly is an intercompany imbalance in Oracle Fusion?** A cross-Business-Unit transaction whose two legs do not net to zero. Every intercompany trade should have an originating leg in one Business Unit and an equal, opposite counterparty leg in the other. When the amounts, FX rates, periods, or transaction types do not match, the intercompany balance check fails and that position counts here. **Why does an imbalance block the close?** Consolidation eliminates intercompany balances against each other so the group does not double-count internal trade. If the two sides do not match, the elimination leaves a residual and the Financial Consolidation Hub in Oracle Cloud EPM cannot produce a clean consolidated reporting ledger. The close waits until every intercompany position balances. **Does the card count the dollar residual or the number of breaks?** The number of unbalanced positions. A $48,000 FX residual and a $620,000 missing leg each count as one. To see the net intercompany value, pair this card with [Intercompany Balance](/nerve-centre/kpi-cards/oracle-erp/oerp-intercompany-balance). **What are the most common causes?** A counterparty leg that never posted, the two legs booked at different FX rates, one leg posted to the wrong period, or a mis-mapped intercompany transaction type so only one Business Unit recorded the trade. The first, a one-sided posting, is the most frequent and the most material because it distorts consolidated equity. **Why is the threshold zero?** Because a clean group close requires every intercompany position to balance. Any unbalanced leg is an exception that a human must resolve before consolidation can run, so the right people need to hear about it immediately rather than discovering it at the consolidation step. **Can Vortex IQ post the missing counterparty leg?** No. Posting intercompany journals and resolving imbalances are controlled accounting actions inside Oracle Fusion, under your change controls. Vortex IQ detects the imbalance, names the trading pair and the residual, and notifies owner and finance. Your team posts the correction in Oracle and re-runs the balance check. *** ### Tracked live in Vortex IQ Nerve Centre *Intercompany Business Unit Imbalances* is one of hundreds of KPI pulses Vortex IQ tracks across Oracle ERP Cloud and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.