Intercompany elimination is the accounting step that keeps a group's financial statements from double-counting money that never actually left the group. If multi-entity accounting is part of why you're evaluating an ERP migration, it's worth understanding precisely before you sign anything. I'm Patrick, and del.ai helps companies migrate from NetSuite to Odoo, so read what follows knowing I have a commercial stake in how you answer that question, and judge the argument on whether it holds up on its own.
You don't struggle to close an individual entity's books. Entity A closes clean. Entity B closes clean. Entity C closes clean. Each set of books survives its own audit, on its own terms, on schedule. The struggle starts one step later, when three (or six, or a dozen) correct sets of books have to become one number the board can look at.
That step is intercompany elimination, and in most finance stacks it still runs in a spreadsheet. Someone exports trial balances from every entity, finds the line items that describe one entity's arrangement with another, and manually strips them out before the group total means anything. It happens every month, on schedule, whether or not the ERP underneath the entities has "consolidation" printed on the box.
One thing worth being direct about before this goes any further: this article will not claim that step is fully automated anywhere, including in what del.ai builds. That isn't a hedge. It's the honest state of the category. Full statutory consolidation, the kind that handles transfer pricing and per-jurisdiction reporting across a genuinely complex multi-entity group, is a hard exclusion from what we take on today. If that's your actual entity structure, nothing below is going to argue you out of that fact, and neither will a call with us.
What this article is for is the more common case. A handful of related entities trade with each other, each entity's books are fine, and the join between them is the part eating a day of your month. That's worth defining precisely, because "intercompany elimination" gets used loosely enough that most people who need it couldn't tell you exactly what it does, and doesn't do, to their numbers.
An intercompany transaction is any transaction where both parties sit under the same corporate ownership: one subsidiary selling to another, one entity lending to another, or a shared cost allocated across related companies. Each side records it the normal way. The selling entity books revenue and a receivable; the buying entity books a cost and a payable. Both entries are correct on their own, and both would survive an audit of that single entity's books without question.
The complication starts one level up. At the group level, an intercompany transaction describes money that moved between entities the same owner controls, not money that came in from a customer or went out to a supplier. Left alone, it inflates group revenue and group balances by however much the entities trade with each other. That's why intercompany transactions have to be tagged and identified before anyone can trust a consolidated number.
Source: IFRS Foundation, "IFRS 10 Consolidated Financial Statements," ↗, 2026.
Here's the mechanism, worked through on a simple, entirely illustrative example, not a real company. A three-entity group: Entity A manufactures a component and sells it to Entity B for $200,000. Entity B assembles it into a finished product and sells the result to an actual outside customer for $350,000. Entity A's books are correct: $200,000 in revenue, a $200,000 receivable from Entity B. Entity B's books are also correct: $200,000 in cost of goods sold, a $200,000 payable to Entity A, and $350,000 in revenue from the real sale.
Add the revenue lines together without adjustment, and the group appears to have generated $550,000 in revenue against a single outside customer payment of $350,000. The $200,000 never left the group. It moved from one pocket to another pocket the same owner controls. Leave it in the group total and revenue is overstated by exactly that amount. The receivable and payable on both sides of the transaction are overstated the same way.
The same logic applies past trade invoices. An intercompany loan between two entities creates interest income on one side and interest expense on the other, both real at entity level, both needing to disappear at group level. A shared-cost allocation, one entity paying a vendor and billing the others their share, creates the same wash requirement. None of this shows up as a problem at the entity level. That's exactly why it survives so long unnoticed: entity-level books are where the audit happens and where the statutory filing happens. The group view is a separate exercise, built on top of them, and it's the one nobody's local audit is checking.
Intercompany elimination is the consolidation-layer step that removes intercompany transactions from a group's combined financial statements, so revenue one entity billed another isn't counted twice and a balance one entity owes another isn't counted as a real asset. Without it, a group of entities trading with each other reports revenue larger than anything any customer actually paid, and a receivable nobody outside the group will ever collect. The mechanism is a set of wash entries: intercompany revenue against intercompany cost of sales, intercompany receivable against intercompany payable. These entries never touch any entity's own ledger. They exist only on a consolidation worksheet, or inside consolidation software, built on top of the entity-level books rather than inside them. That separation is exactly why elimination is usually the last thing to get automated in a finance stack, and the first thing done in a spreadsheet: the entries live above the system boundary most software is built around.
Source: IFRS Foundation, "IFRS 10 Consolidated Financial Statements," ↗, 2026 (Appendix B requires intragroup balances, transactions, income and expenses to be eliminated in full).
An elimination entry is a wash, and once you see the mechanics, it isn't a complicated one. Take the $200,000 sale from the example above. At the group level, you debit intercompany revenue $200,000 and credit intercompany cost of sales $200,000, cancelling the mark-up that moved between entities. Separately, you debit intercompany payable $200,000 and credit intercompany receivable $200,000, cancelling the balance sheet entries describing the same internal transaction. Neither side of either entry touches Entity A's or Entity B's own ledger. They exist purely on the consolidation worksheet, a layer sitting above the entity-level books rather than inside them.
That location is the whole reason these entries are easy to describe and hard to templatize. A single three-entity group with one product moving in one direction is simple enough to whiteboard. A group with cross-selling in both directions, shared-service cost allocations, and intercompany loans at different rates looks nothing like it. The worksheet has to be built to match the actual structure, not borrowed from somewhere else. That's the practical reason most finance teams rebuild their elimination worksheet instead of buying a templated one off the shelf. Every group's intercompany structure is shaped differently enough that a generic template covers the mechanics but not the specifics. The specifics are the part that takes the time.
The difference is control, not ownership percentage. Consolidated financial statements combine a parent and every entity it controls into one economic unit: intercompany transactions between them are eliminated, and any non-controlling interest is broken out separately on its own line. Combined financial statements cover entities under common ownership without a parent-subsidiary control relationship between them, sister companies owned by the same person or holding entity, for example, where no single entity directs another's financial and operating decisions. The test that decides which framework applies is whether one entity controls another's policies, not what percentage of equity sits on a cap table. Both frameworks eliminate intercompany transactions between the entities they cover; the difference is which entities get pulled into the reporting unit in the first place, and whether a non-controlling interest line appears in the result.
Source: IFRS Foundation, "IFRS 10 Consolidated Financial Statements," ↗, 2026 (governs the control test and elimination requirement for consolidated statements; "combined financial statements" describes common practice for commonly-owned entities without a parent-subsidiary relationship, not a separate numbered standard).
Here's what's actually automated today, stated plainly instead of folded into a features list. Each legal entity in Odoo keeps its own chart of accounts, its own tax rules, and its own fiscal localisation, inside one database rather than one instance per entity. Automatic pairing of intercompany invoices and bills is not in stock Community — Odoo's own version is Enterprise — but OCA publishes a free AGPL-3 module for it, maintained on the 18.0 branch. An invoice raised on one company creates the matching bill on the other automatically, without anyone re-keying it. Multi-currency is handled natively at the entity level. We rate all three of those full today.
Consolidation, the elimination step this whole article has been describing, we rate partial. Not because it's undersold or waiting on a roadmap date we can quote, but because that's the honest state of it: multi-currency and multi-company work is there; consolidation is limited. We aren't claiming it's automated, and we're saying so here, before any statement of work gets signed, not after.
That distinction has a practical consequence for who this actually fits. If your intercompany structure is a handful of related entities trading with each other, the kind described earlier, the automation above covers the part of your month that currently eats a day. That means invoice and bill matching, and entity-level books staying clean and separate. The elimination step itself still needs a person building the worksheet, same as it does on most ERPs today. If what you actually need is full statutory consolidation across multiple jurisdictions, with transfer pricing and per-entity statutory reporting layered on top, that's a different and considerably harder problem. It's also the existing reason NetSuite OneWorld accounts sit outside what del.ai takes on right now. It's the same capability gap, named directly, with a review date attached (next review 2027-05-07) rather than a promise to have closed it by then.
Ask any vendor, us included, to show you which of these two categories your setup falls into before you sign anything. It's a question with a checkable answer, not a matter of taking someone's word for it.
Before you sign anything with any ERP vendor, not just us, ask to see the capability rating in writing, not a verbal reassurance on a call. "We handle multi-entity" is a sentence that covers two very different products. The difference matters more than almost anything else on the checklist if intercompany accounting is part of why you're evaluating a migration at all.
If your consolidation need looks like the group described throughout this article, a handful of related entities trading with each other, sharing costs, maybe an intercompany loan or two, the entity-level automation above is likely what's eating a day of your Controller's month right now. That part is real, and it's rated full for a reason.
If your consolidation need is full statutory, multi-jurisdiction reporting with transfer pricing built in, the kind of complexity NetSuite OneWorld accounts usually carry, say so at the start. Don't wait until partway through a migration. That's the case this article, and del.ai's current product, isn't built for. It's an existing exclusion, reviewed on a fixed date rather than left open-ended, and treating it otherwise to close a deal would cost both sides more than it saved either one.
The honest version of this topic is short: entity-level books get easier. The join between entities still needs a person, here and almost everywhere else. Knowing that going in is worth more than a features list that quietly steps over it.
This isn't built for every NetSuite account. It's built for Controllers and CFOs running NetSuite (not OneWorld) who want the honest capability list for their specific entity structure before they sign anything, not a feature-parity checklist that quietly steps over the gap.
30 minutes. Bring your actual entity structure and we'll walk through what's automated today and what still needs a person, for your setup specifically. No pitch. You'll leave knowing whether this is a fit before either of us spends more time on it.
See how this works in the product