Intercompany Eliminations

Your consolidated P&L shows $2.3M in revenue that your CFO knows should have been eliminated. It is the same transaction recognized by two different entities in the group, and it has been in the consolidated financials for two quarters. Intercompany eliminations are the accounting adjustments that remove transactions between entities in the same corporate group from the consolidated financial statements. When Entity A sells services to Entity B and both are part of the same consolidated group, Entity A's revenue and Entity B's expense are an internal transfer: money moving from one pocket to another inside the organization. Viewed as one group, no revenue was earned from an outside party and no expense was paid to one. The revenue and matching expense have to be eliminated so the consolidated statements show only transactions with third parties. Finance teams understand the concept and know eliminations are required. The hard part is doing them accurately and consistently at every close, especially when entities run different accounting systems, currencies, and close calendars. The $2.3M that has sat in consolidated revenue for two quarters means one of those problems has gone unresolved since before the last audit.

Why intercompany eliminations exist

GAAP consolidation accounting requires eliminating four types of intercompany transactions: revenue and expense (services sold between entities), accounts receivable and payable (balances owed between entities), intercompany loans and related interest, and unrealized profit in inventory or assets transferred between entities. Each type needs a matching pair of eliminations. The revenue recognized by the selling entity is eliminated against the expense in the purchasing entity, and the receivable on the seller's balance sheet is eliminated against the payable on the buyer's. In spreadsheet-based multi-entity consolidation, someone has to identify every intercompany transaction each period, confirm both entities recorded their side in consistent amounts, and post elimination journal entries before the consolidated statements are produced. The failure modes are predictable. Transactions get missed because the person doing consolidation can't see all intercompany activity. Amounts don't agree between entities because of timing differences or currency treatment. And the same transaction gets partially eliminated in one quarter and fully eliminated in the next, which leaves the comparative financials inconsistent.

Transaction type mismatches, timing differences

As a company adds entities through acquisition, geographic expansion, or reorganization, intercompany transaction volume compounds. Each new entity is a potential counterparty for every existing entity. A group with 10 entities has 45 possible intercompany pairs. With 20 entities, it is 190. Volume grows quadratically with entity count, which is why teams that handle intercompany consolidation easily at 3 entities are overwhelmed at 12. Timing differences between entities create a recurring elimination problem. Entity A in the US closes on the last calendar day of the month; Entity B in Germany closes on the last business day. A service transaction that Entity A recognizes in November may not be recognized by Entity B until December because B's close hasn't run yet. The elimination needs both sides in the same period, so either Entity A's recognition moves to December or an intercompany receivable/payable absorbs the timing difference until both entities have closed. Intercompany policies should settle which entity's close date governs, how timing differences are handled, and how disputes over transaction amounts get escalated, before the first close that involves two entities, not after.

How automated elimination matching works

Automated intercompany elimination only works if the consolidation engine can identify both sides of a transaction, usually through intercompany account coding and transaction reference matching. When Entity A books a sale to Entity B, the revenue posts to a designated intercompany revenue account tagged with Entity B's identifier. When Entity B books the matching expense, it posts to an intercompany expense account tagged with Entity A's identifier. The consolidation system matches the two by counterparty and amount, eliminates the pair, and produces an exception report for any transaction where the match fails. Exceptions fall into three categories: missing counterpart (one entity posted, the other hasn't), amount mismatch (both posted, but for different amounts, often because of currency translation), and timing mismatch (both posted, but in different periods). When entities run different ERPs, SAP and NetSuite for example, the intercompany reference codes may not be structured the same way, and the consolidation engine may not match automatically without a translation layer. Companies that acquire often inherit this problem: the acquired entity runs a different ERP with different coding conventions, and the intercompany matching logic has to be rebuilt for each new entity pair.

Questions to ask

• Do we have intercompany account coding standards that all entities follow, and are they enforced in each entity's ERP when transactions are posted, or only during consolidation?
• How does our consolidation system handle transactions where both entities have posted but the amounts don't agree? Is there an automated matching tolerance, and who resolves exceptions above it?
• When entities close on different dates, what is our policy for intercompany transactions that cross a period boundary, and which entity's period governs recognition?
• If one or more entities run a different ERP, how does the consolidation engine receive and match intercompany data from each system? What is the integration architecture?
• Who owns the intercompany reconciliation process (the group consolidation team, the individual entity controllers, or a shared service), and is that ownership documented and enforced?

Common mistakes

The first is not setting intercompany policies before rollout. Organizations that add a second entity without defining account coding standards, close date policies, and reconciliation ownership end up doing policy work retroactively, after transactions have already piled up under inconsistent practices. The cleanup is expensive: you have to find every intercompany transaction posted under the old practices, recode it to the new standard, and verify that eliminations are complete before the audited period can close. The second mistake is relying on manual elimination at every close. Manual elimination works for two entities with a handful of intercompany transactions a month. It doesn't work for five or more entities with service charges, management fees, licensing arrangements, and cash pooling, all of which generate intercompany entries that need matching and elimination. Once elimination takes more than 30 minutes of manual work per close, it is time to automate it, whether in your ERP or in dedicated consolidation and accounting software. Waiting until it takes 3 days sets up exactly the kind of error described above: $2.3M in revenue that should have been eliminated and wasn't.

Comparing accounting software

The dividing line in this category is whether a tool owns the ledger or sits beside it running reconciliations and the close checklist. Once intercompany eliminations is settled as a requirement, read the Accounting Software category guide for how the market splits, then weigh the BlackLine profile against the FloQast profile on that requirement rather than on the feature list. Our BlackLine pricing breakdown records what the vendor publishes and what is quote-based. The BlackLine against FloQast comparison sets two of them side by side on the same criteria. Before you book demos, put your own numbers through the accounting software ROI calculator so the business case is written down before a vendor writes it for you.

Intercompany Eliminations questions

Related terms

Account Reconciliation, Accrual Accounting, and Audit Trail come up in the same workflow as intercompany eliminations, and the rest of the accounting software cluster is indexed in the finance operations glossary.