The Intercompany Matching report, where both sides meet

Two entities, one trade, and each swears its number is right. This report puts the receivable against the payable, pair by pair, and the out-of-balance column is the close's daily to-do list.

Third page on the reports shelf of the FCCS reference. The tagging machinery beneath it lives on the Intercompany dimension, the posting mechanics on Consolidation, and the whole reference is mapped on the FCCS index.

RuleRun matching days before close, with thresholds and cutoffs agreed in advance, while the counterparty can still fix the source system.

Neverjournal a plug to zero to make the report go quiet. The plug is the indicator, not the problem; fix the source and it clears itself.

◆ The report in the application— where it lives, what drives it, and the 2025 change that ended the monthly edit.

Piece	What to know
Where it lives	Its own corner of the application, intercompany reports beside the management reports, driven by a point of view of scenario, year, period, view, consolidation, and currency, plus the entities and accounts you scope in.
How it groups	By plug account. Accounts sharing a plug appear together, which is what lets the report lay a receivable against its payable and net the pair. The grouping is the matching.
Substitution variables, since late 2025	Period and year in the point of view can now be variables, the current-period and current-year kind, maintained once under the application's variables. Before this, someone edited every matching report every month; teams that have not switched still do.

◆ Reading an out of balance— the recurring patterns, each with its signature on the report.

Pattern	The signature
Matched	The pair nets to zero and disappears from the exception view. The goal state, and the only row that needs no meeting.
Wrong account	One side books the intercompany receivable, the other books a different intercompany account carrying a different plug. The pair splits across two report groupings, each showing the same amount out of balance with opposite signs. The fix is a reclass on the side that strayed.
Wrong partner	One entity tags the wrong counterparty, and the report shows two separate one-sided imbalances, one against a partner who never traded, one missing where the trade was real. The audit trio, entity, account, partner, finds it in minutes.
Timing	Goods shipped in the seller's period, received in the buyer's next. Both sides are right and the pair still gapes. This is what the agreed thresholds and cutoffs exist for.
Rates	The same trade booked at two rates creates a small, real difference, and its cousin, FX on an intercompany loan in a third currency, never matches at all. The cases live on the Intercompany page.

The plug never gets deleted. In a perfect period every plug is zero, and in a real one the balance is the report pointing at something upstream. Fix the booking and the plug clears on the next run, which is the entire discipline in one sentence.

◆ Two questions from the field— asked on the forums, answered by people who run this report for a living.

Question	The answer
Can we match in one currency without running translation?	Out of the box, no comfortable way: leave the point of view at entity currency and every entity compares in its own money, which proves nothing, or pick a reporting currency and the translation step becomes mandatory. A veteran consolidation consultant published the working trick, a calculated member outside the hierarchies that surfaces parent-currency amounts while the point of view stays at entity currency, letting the matching run before translation does. Worth knowing it exists before close week does.
We loaded both sides. Why did nothing eliminate?	Asked live this May by a team with one parent and three children: eliminations do not happen at load. They post during consolidation, at the first common parent of the trading pair, which in a flat structure is simply the one parent. Load, then consolidate, then read the matching report, in that order.

Question

The answer

Can we match in one currency without running translation?

Out of the box, no comfortable way: leave the point of view at entity currency and every entity compares in its own money, which proves nothing, or pick a reporting currency and the translation step becomes mandatory. A veteran consolidation consultant published the working trick, a calculated member outside the hierarchies that surfaces parent-currency amounts while the point of view stays at entity currency, letting the matching run before translation does. Worth knowing it exists before close week does.

We loaded both sides. Why did nothing eliminate?

Asked live this May by a team with one parent and three children: eliminations do not happen at load. They post during consolidation, at the first common parent of the trading pair, which in a flat structure is simply the one parent. Load, then consolidate, then read the matching report, in that order.

In the owned warehouse, the star schema we recommend building beside FCCS on your own cloud, mapped here, matching is a standing query, receivables against payables by entity pair, any morning, with the plug balances trended so chronic offenders are visible by name. Report behavior, the variables change, and both field cases verified against Oracle's documentation, practitioner writing, and Customer Connect, July 2026.

The same pairs out of balance every month?

We trend the plugs by entity pair, name the chronic offenders, and move matching from close week to every morning.

Talk to us

Terms on this page

the pair: A receivable and its payable, one trade seen from both ends.
plug account: Where the unmatched remainder shows. The report's grouping key.
threshold: The variance agreed in advance, so small gaps close themselves.
first common parent: Where the elimination posts, at consolidation, never at load.