Sub-company journals that do not balance across the CompanyCode group. The single number that decides whether SAP Group Reporting consolidation can run tonight or stalls until someone fixes a mismatched intercompany pair.
At a glance
The count of intercompany postings that do not balance across the Company Code group. When one Company Code books an intercompany transaction (a sale, a loan, a recharge, a dividend) the matching Company Code must book the mirror side at the same value. When the two sides disagree, the pair fails to net to zero on elimination, and SAP Group Reporting cannot consolidate the group until it is fixed. This is a hero card because a non-zero value here is not a “watch this”, it is a “consolidation is blocked right now”. The CFO’s group close stops here.
Calculation
Calculated automatically from your SAP 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 group running SAP S/4HANA Cloud Public Edition with three Company Codes: 1000 UK Holdings Ltd (GBP), 2000 US Trading Inc (USD), and 3000 EU Trading BV (EUR). Group currency is GBP. The group close for the period ending 31 May 26 is being prepared on 04 Jun 26. The card reads the live intercompany position.
Five things to notice:
- The count is 3, and the
>0alert fires immediately. As a hero card with a zero-tolerance threshold, any non-zero value stops the group close. Consolidation cannot run clean until all three are resolved. - The biggest residual is an FX mismatch, not a value error. The £120,000 management recharge was booked as a fixed sterling figure in the UK but the US side recorded the dollar equivalent and translated it back at a different rate, leaving a £26,160 residual. This is the classic intercompany FX trap: both sides agree on the economics, but the two ledgers translated independently. The fix is a Group Reporting reclassification or a harmonised intercompany FX rate, not a re-posting.
- One pair is purely a timing problem. The $310,000 inventory transfer was booked in US Trading Inc but the EU side has not posted its mirror yet. This is the most common blocker at close: one entity is faster than the other. The fix is simply to get the lagging side posted before the elimination task runs.
- A £138 rounding residual still counts. Even a tiny mismatch blocks a clean elimination. SAP Group Reporting can be configured with a rounding tolerance, but absent that, the card faithfully reports that the pair does not net to zero. Small residuals are usually rounding or sub-unit currency differences.
- The balanced royalty pair is correctly excluded. The £85,000 royalty matched exactly on both sides, eliminated cleanly, and does not appear in the count. The card only surfaces the pairs that will actually break consolidation.
Sibling cards merchants should reference together
An intercompany imbalance is a group-close blocker. Read it with the wider intercompany and period-close family to find and fix the cause fast.Reconciling against SAP
Where to look in S/4HANA Cloud: The closest native equivalents inside the SAP Fiori launchpad are:Intercompany Reconciliation Fiori apps (Manage / Monitor Intercompany Reconciliation) to match trading-partner balances pair by pair Group Reporting apps (Consolidation Monitor, Data Monitor) where the elimination tasks run and fail on residuals Display Journal Entries filtered to the trading-partner / partner Company Code field to inspect each side of a pair Embedded Analytics: intercompany CDS views that expose trading-partner balances by Company CodeTo match this card, run the Intercompany Reconciliation app for the period and list the pairs whose trading-partner balances do not net to zero (within any configured tolerance). Each unmatched pair the app shows should correspond to one count on this card. The Consolidation Monitor will independently fail its elimination task on the same pairs. Common mistakes when comparing against SAP’s own reports:
- Comparing per-Company-Code balances without translation. Each side is in its own Company Code currency. An apparent imbalance can vanish once both sides are translated to group currency at the consolidation rate, and vice versa. Always reconcile at the group-currency layer that elimination uses.
- Missing the trading-partner code. A posting that should be flagged intercompany but lacks the partner Company Code field will not be picked up by the reconciliation app as intercompany at all. The card relies on the same flag, so an unflagged one-sided posting shows up as a different finding, not as an imbalance.
- Ignoring tolerance settings. Group Reporting can be configured with a rounding tolerance. If your tolerance nets a tiny residual to zero in the Consolidation Monitor but the card reports it, the difference is the tolerance, not an error.
Known limitations / merchant FAQs
Why is the alert threshold zero? Because any unbalanced intercompany pair blocks a clean elimination, and a blocked elimination stops group consolidation. There is no “acceptable” non-zero level: one mismatched pair is enough to halt the group close. That is why this is a hero card with a>0 trigger.
Most of my imbalances are tiny FX or rounding residuals. Are they really a problem?
They are a real blocker unless Group Reporting is configured with a rounding tolerance that nets them out. If you have a tolerance, those sub-threshold residuals will pass the Consolidation Monitor even though the card flags that the pair is not exactly zero. If you do not have a tolerance, even a small residual breaks the elimination task and must be cleared.
The most common cause for me is timing, one side posts before the other. How should I read that?
As a genuine real-time blocker that will self-resolve once the lagging Company Code posts its mirror. The card is real time, so the count drops the moment the missing side is booked. Pair with the period-close status cards to find which entity is behind.
Does an intercompany imbalance always mean someone made an error?
No. The most frequent causes are timing (one side not yet posted) and independent FX translation, neither of which is a data-entry mistake. Value mismatches and missing trading-partner codes are the ones that usually need a correction posting.
How does the card handle multi-currency intercompany pairs?
It reconciles at the group-currency layer that elimination uses, because that is where consolidation actually nets the pair. An imbalance that exists only in Company Code currency, or only after translation, is reported as the elimination layer sees it.
Can a balanced pair still block consolidation?
A pair that nets to zero on elimination will not block on this metric. Other things can still block a group close (a Company Code not yet closed, an unposted journal, an IDoc error), which is why this card is best read alongside the period-close family rather than alone.
How fresh is the number?
It is real time. S/4HANA Cloud exposes trading-partner balances through live APIs, and Vortex IQ’s connector refreshes frequently, so the count reflects the current intercompany position. The moment a mismatched side is corrected or a missing mirror is posted, the count updates. For pair-by-pair detail, pivot into the Intercompany Reconciliation Fiori app.