Multi-Entity Without the Mess: How Intercompany Transactions Should Actually Work

Multi-entity accounting in most ERPs means running separate books and periodically trying to reconcile and consolidate them. Intercompany eliminations happen at month-end, done by hand or by a consolidation module that runs after the fact. We describe what it looks like when intercompany transactions are architecturally enforced — and eliminations happen as a property of the data, not as a step in the close.

Multi-entity is one of those ERP capabilities that sounds straightforward until you have to actually implement it. The concept is simple: a company has multiple legal entities, each with its own books, and there’s a parent entity that needs to see consolidated financials. The execution is complicated in ways that reveal the architectural limits of most ERP platforms.

What multi-entity typically looks like

In most ERP systems, each entity has its own chart of accounts, its own GL, its own set of subledgers. The entities are linked through an organizational hierarchy in the software, and the system provides tools to roll up the individual entity balances into consolidated reports. This is the suite model: one platform, multiple instances of the financial structure.

The problem is intercompany transactions. When Entity A provides a service to Entity B, the transaction needs to appear as revenue in Entity A’s books and as an expense in Entity B’s books. When the entities are consolidated, that intercompany revenue and expense need to be eliminated — otherwise the consolidated financials double-count an internal transaction as both income and expenditure.

Managing these eliminations is one of the most manual, error-prone parts of the financial close at companies with more than one entity. Someone — usually a controller or a consolidations specialist — has to identify all intercompany transactions, create elimination entries, and verify that the eliminated amounts agree on both sides. If Entity A booked $100,000 of intercompany revenue but Entity B only booked $95,000 of corresponding expense (perhaps because the invoice timing differs across entities), the elimination doesn’t balance and someone has to investigate.¹

The volume problem

At small scale — two entities, a handful of intercompany transactions per month — this is manageable, if tedious. At larger scale — five entities, dozens of intercompany service agreements, shared service cost allocations, transfer pricing — it becomes a substantial piece of the close process. Deloitte’s research on consolidation practices found that intercompany reconciliation is one of the top three contributors to extended close timelines at multi-entity companies.²

The tools available to help are real: dedicated consolidation modules, intercompany matching tools, and financial close platforms that track intercompany agreements and flag mismatches. These tools are improvements on fully manual processes. They’re still treating the symptom.

An architectural alternative

The core issue is that intercompany transactions create entries in two separate books that need to agree. If the two books are genuinely separate — different instances of the financial data model — then making them agree requires a reconciliation process that runs between them.

If the books are not genuinely separate — if entity-level financials are views of a single underlying ledger, scoped to the transactions tagged with a particular entity — then intercompany transactions don’t create entries in two separate places. They create one entry tagged with two entities: the originating entity and the receiving entity. Elimination isn’t a step in the close; it’s a filter applied when generating consolidated reports. Transactions tagged as intercompany are excluded when the view is set to “consolidated.”

This requires that the ledger design include the concept of entity and intercompany classification at the transaction level — that every journal entry knows which entity it belongs to, whether it has a corresponding intercompany party, and what the elimination treatment should be at consolidation. It requires enforcing at the database layer that intercompany transactions balance across entities, not just within them.

The result is a consolidation process that produces the right answer automatically, not one that runs a month-end reconciliation and then adjusts until it ties.

The internal party concept

One underappreciated architectural requirement for this to work: every entity in the system needs a corresponding internal party record — a first-class representation of the entity as a counterparty in transactions. Without this, the system can’t distinguish between a transaction with an external customer and a transaction with a related entity. With it, intercompany transactions can be marked automatically, eliminated automatically, and reported correctly at both the entity level and the consolidated level.

This design decision — the internal party as a required element of entity configuration — is the kind of foundational choice that either gets made at the beginning or requires a painful migration later.

Sources