Intercompany elimination matching
Agent matches intercompany entries across entities and currencies and posts eliminations.
Finance processPlanBudgetInvoiceCollectPayCloseReportAudit
By Don, DoneThat’s AI coach · updated
What a matched elimination looks like
A usable elimination is a proposed consolidation journal that cites both entity entries. If one side is missing, the proposal stays empty. The agent does not invent a counterparty. The controller still posts.
Read the proposal the way you would read an audit pack. You need entity, account, local-currency amount, presentation-currency amount, document or journal ID, posting date, and the same fields for the counterparty. Missing any of those on one side means you do not have a match. You have an open item.
Treating a proposal as posted is how groups wipe a real third-party balance or double-count equity. Until the controller (or the consolidations owner with posting rights) posts, entity books and group books still show the intercompany.
Load both entity books before you match
Matching starts with two complete ledgers for the same close period, not with an extract from one legal entity. Load trial balances and intercompany subledgers from both entities: receivables, payables, loans, dividends, inventory in transit, and management-fee revenue and expense. If the group books sit in Workday, SAP, Oracle, or BlackLine, those systems are the books of record. Do not match against a worksheet that already nets IC.
Entity A may post on the last day of the month while entity B posts on day two of the next month. Load a window that includes the close cutoff plus the group's documented lag, and keep that lag visible on the proposal so the controller can see why dates differ.
If one entity's book is incomplete, stop. A match against a partial extract is how one-sided eliminations enter the pack. Finish the entity close, or at least the intercompany subledger, before the matching pass. The same rule an account reconciliation agent follows on a balance-sheet account applies here: reconcile from source balances, not from a hoped-for net.
Cite both sides; do not invent the counterparty
The matching rule is citation, not proximity. Two amounts that look like they should cancel are not a pair until you can point to both entries. Typical keys are counterparty entity ID, IC account pair, invoice or reference number, amount in transaction currency, and event type (sale, loan interest, dividend, management fee). When those keys agree, the proposal lists both cites and the suggested elimination lines in the consolidation chart of accounts.
When they do not agree, do not fill in the missing entity. Inventing a counterparty creates a fake payable and a real P&L wipe. If entity A billed entity B and entity B has nothing, the proposal is blank for that item and the open item goes to the IC rec list.
Currencies complicate the cite. They do not replace it. Entity A may hold a USD receivable while entity B holds the EUR payable on the same invoice. Show both local amounts, the invoice's transaction currency, and the rate each entity used in its own books. Then show the group elimination in presentation currency using the documented group rate, not a rate chosen to make the residual zero.
HoldCo (USD functional) invoices OpCo (EUR functional) for a quarterly management fee. HoldCo books IC revenue and IC receivable against document MF-093. OpCo books IC expense and IC payable against the same invoice number, in euros, at the rate already in OpCo's AP file. The agent loads both books, finds MF-093 on both sides, cites both journal IDs, and proposes a consolidation elimination that reverses HoldCo revenue against OpCo expense and reverses the receivable against the payable in presentation currency. Any residual is the translation difference the group already parks in CTA or in the IC FX clearing account. The agent does not pick a rate so the residual disappears.
If OpCo has not booked MF-093, there is no elimination for that invoice. HoldCo's receivable stays on the rec.
Leave unpaired items empty
Unpaired does not mean eliminate half, and it does not mean eliminate the side you can see. Eliminating a one-sided entry removes a real balance from the group without removing the corresponding income or expense on the other side, or it removes income that still sits with the counterparty. The consolidation is wrong either way, and the error is hard to see because the IC accounts look cleaner.
Park one-sided items on an unmatched IC schedule with the cite you do have: entity, document, amount, expected counterparty, and why there is no match (not booked, wrong period, wrong entity code, amount break). That schedule is the consolidations worklist. It is also where journal entry anomaly detection belongs. A large IC journal with no counterparty code, a round-dollar late entry, or a reclass that breaks the invoice trail should be flagged before anyone proposes an elimination.
Timing breaks are the usual unpaired class. Goods in transit, fees accrued on one side only, and dividends declared but not recorded all look like broken pairs. If the missing side is an accrual the entity should have booked, that is an entity-level posting question, not a consolidation invention. An accrual auto-suggestion can draft the entity entry. Until that entry exists in the entity book, the elimination proposal stays empty.
Intercompany leases follow the same rule. Lessor and lessee entries have to exist, with their right-of-use and lease-liability (or receivable and deferred inflow) cites, before you eliminate. A lease accounting agent does not stand in for the second book.
Convert only with a documented rate
Multi-currency matching fails when someone invents an FX rate to force a zero residual. The rate hierarchy is group policy, not convenience: the rate already attached to each entity's posting, then the group's published close rate (average or closing, per the account type), then stop. If the group rate table has no row for that currency pair and date, do not convert. Leave the item unmatched, or matched in transaction currency only, with a visible exception.
Do not back into a rate from the residual. A small difference may be a true translation plug. It may also be a mis-keyed invoice, a VAT line one entity booked and the other did not, or a partial payment. Forcing FX to absorb it hides the break.
When both entities used different rates in their own books, show both. The elimination uses the group rate. The difference stays in the translation accounts the policy names. The proposal should state which rate source it used (entity posting or group close table) so the controller can reject a silent override.
The controller posts the elimination
The last step is human posting in the consolidation ledger. The agent prepares the journal with both cites, the FX source, and the unmatched list. The consolidations accountant, usually the controller or a designee with posting rights, reviews and posts.
Do not treat the proposal as posted because the match looked clean. Downstream reports (equity, NCI, cash flow, IC aging) will assume the elimination is in. If it is only a draft, you will spend the next cycle explaining a variance that is a workflow miss.
Review before post: both cites present, amounts agree in transaction currency, the group rate is the documented one, one-sided items remain on the unmatched list, and the elimination accounts are consolidation-only accounts, not entity P&L. If a cite is wrong, reject. Do not edit the counterparty into existence.
After posting, the entity books still hold the IC. That is expected. The group pack should show those balances eliminated, with a trail from each entity document to the consolidation journal. If a later entity reversal arrives, the posted elimination needs a reversing proposal that again cites both sides, not an automatic unwind without review.
The working loop is short: load both books, match only with cites, leave unpaired empty, convert only with a documented rate, and let the controller post.
Is this worth automating for you?
Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other. This one is rated high effort to implement, so the baseline matters more than usual.
DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.
Measure the baseline first