BlogSeptember 15, 202612 min read

What integration approach works for multi-entity and multi-subsidiary finance

Multi-entity finance needs routing by subsidiary, currency, and intercompany rules. The integration patterns that hold up across entities and at audit.

By Zuny Fester, Head of Operations and Marketing

Reviewed by Zuny Fester

Published September 15, 2026Editorial policy

Part of the finance integrations guide.

What integration approach works for multi-entity and multi-subsidiary finance

The integration approach that works for multi-entity and multi-subsidiary finance is one where every record is routed to an entity by an explicit rule before it's written anywhere. Subsidiary, currency, and intercompany treatment should be decided at the front of the integration, from data on the source record, not patched in the ERP after the fact. In practice that means a routing table (which field decides the entity), entity-aware master data (which customer, vendor, and bank account belong to which subsidiary), and paired intercompany transactions that eliminate cleanly at close.

Single-entity integrations fail in predictable ways when a second entity arrives. The CRM has one account where the ERP needs three customers. Stripe pays out in EUR to a UK entity. An intercompany recharge is booked on one side only. This guide lays out the patterns that hold up across entities and at audit.

Key takeaways

• Route before you write. Every inbound record needs a deterministic entity assignment from a routing rule, such as contracting entity on the contract or the processor account it came from.

• Master data must be entity-aware. One CRM account often maps to one ERP customer per subsidiary, or to a multi-subsidiary customer with a primary subsidiary, and the choice has consequences.

• Intercompany is two transactions, not one. Both sides must post with a shared reference so elimination works; NetSuite OneWorld's Automated Intercompany Management generates elimination entries from lines marked for elimination.

• Currency decisions belong in the routing layer: transaction currency, the entity's functional currency, and which rate source applies.

• Controls scale per entity: approvers, period locks, and bank accounts are set by subsidiary, not globally.

• Loopfour, the deterministic finance workflow automation platform, runs entity-routed workflows across NetSuite, Sage Intacct, QuickBooks, and Xero with rules set in advance and exceptions held for approval.

Why single-entity integrations break in a multi-entity setup

They break because they assume one customer, one currency, one bank account, and one ledger, and every one of those assumptions fails with a second entity. The integration still runs. It just writes records to the wrong subsidiary, in the wrong currency, or without the other half of an intercompany pair.

Assumption	What breaks with more entities	Where it shows up
One customer per CRM account	Invoices for the UK contract land on the US customer	Wrong subsidiary AR, wrong tax, wrong currency
One default subsidiary	Every synced record goes to the parent	Entity P&Ls that don't match reality
One payment processor account	Payouts for two entities land in one bank account	Cash that belongs to one entity booked in another
Intercompany is a journal entry	Only one side gets booked	Intercompany accounts that won't eliminate
One currency	Amounts sync without currency or rate	FX differences no one can explain at consolidation

Every one of these is a routing decision that never got made. The fix is to make it explicitly, once, in the integration.

The routing table: how records find their entity

A routing table states, for each record type, which source field determines the subsidiary and what happens when that field is missing. It's the multi-entity equivalent of a field-ownership table, and it should be signed off by the controller.

Record	Routing field	Example rule	If missing or ambiguous
Customer	Contracting entity on the order form	"Acme Holdings Ltd" → UK subsidiary	Hold for approval
Sales order and invoice	Contracting entity plus billing country	UK entity, GBP billing → UK subsidiary	Hold for approval
Customer payment	Processor account or bank account received into	Stripe UK account → UK subsidiary	Hold; never default to parent
Vendor bill	Bill-to entity on the invoice	Bill addressed to US Inc. → US subsidiary	Route to AP lead
Expense	Employee's home entity and cost center	Employee in Germany → DE subsidiary	Route to approver
Intercompany charge	Agreement between entities	Monthly management fee US → UK	Both sides generated or neither

The rule that matters most: no record defaults to the parent entity. A default is a silent guess. A hold is a visible decision.

The routing flow:

Source record → read routing field → look up entity rule → assign subsidiary, currency, and accounts → validate entity-specific master data exists → write → exceptions to a named approver.

Entity-aware master data

Master data must say which entities each customer, vendor, item, and bank account belongs to, because the routing rule is only as good as the records it routes to. This is where most multi-entity integrations need a design decision.

For customers in NetSuite OneWorld, there are two common models:

Model	How it works	Trade-off
One customer per subsidiary	Separate customer records for US and UK, linked by a master ID	Clean AR and tax per entity; more records to keep in sync
Multi-subsidiary customer	One customer with a primary subsidiary and secondary subsidiaries	Fewer records; NetSuite documents limitations, including tax defaults that apply only to the primary subsidiary

NetSuite's Multi-Subsidiary Customer limitations are worth reading before you choose: tax information defaults only to the primary subsidiary and is ignored when a secondary subsidiary is selected, and credit limit per subsidiary is not supported. If entities have different tax treatment or separate credit decisions, one customer per subsidiary is often the safer model.

Either way, the link back to the CRM has to be a master key rather than a name, the approach laid out in how to map fields between finance systems that don't share an identifier. Vendors, items, and bank accounts follow the same logic: each record is either assigned to specific subsidiaries or explicitly shared.

How to handle intercompany transactions in an integration

Generate both sides of every intercompany transaction from one source event, with a shared reference, so they post together and eliminate together. An integration that books a US management fee to the UK entity without booking the matching payable in the UK creates an intercompany balance that won't eliminate at close.

NetSuite OneWorld's Automated Intercompany Management generates elimination journal entries from intercompany transaction lines and intercompany journal lines marked for elimination, evaluating intercompany account activity as part of period close. The feature works only if both sides were recorded correctly. That's the integration's job.

A worked example, amounts illustrative:

The US parent charges the UK subsidiary a monthly management fee of $20,000, invoiced in USD. The UK subsidiary's functional currency is GBP.

Entity	Account	Debit	Credit
US parent	Intercompany receivable, UK	$20,000
US parent	Intercompany management fee income		$20,000
UK subsidiary	Intercompany management fee expense	$20,000 (booked in GBP at the transaction rate)
UK subsidiary	Intercompany payable, US		$20,000 (booked in GBP at the transaction rate)

Both sides carry the same intercompany reference, and both are marked for elimination. When the rate used on each side differs, or the UK side revalues before settlement, the pair won't eliminate to zero, and a currency difference remains. That residual is a known problem with a specific fix, covered in how to run intercompany elimination in NetSuite and fix the currency delta that won't eliminate.

Currency: decide it in the routing layer

Every record should arrive at the ERP with its transaction currency, the target entity, and the rate source already determined. When an integration sends an amount without its currency, the ERP applies a default, and the error surfaces at consolidation.

• Transaction currency comes from the source: the invoice currency, the processor payout currency, the vendor bill currency.

• Functional currency comes from the entity the record is routed to.

• Rate source is a policy decision, applied consistently. Mixing rate sources across integrations creates differences that look like errors.

Consolidation adds a separate layer of rates. If consolidated numbers look wrong even when entity books are right, why your consolidated exchange rate is wrong in a NetSuite OneWorld close walks through the causes.

Book a workflow review to see your own entity routing rules written down and running, with every unroutable record held for approval.

Which architecture: one ERP with subsidiaries, or one ledger per entity?

Both work, and the integration pattern differs. Companies on NetSuite OneWorld or Sage Intacct typically run one ERP with subsidiaries or entities inside it. Fractional CFO firms and smaller groups often run a separate QuickBooks or Xero file per entity. The routing table is the same idea in both; what changes is where it points.

Architecture	Routing target	Intercompany handled by	Consolidation
One ERP, many subsidiaries	Subsidiary field on each record	ERP intercompany features, fed by paired transactions	Inside the ERP
One ledger per entity	A different company file per entity	The integration, which posts both sides in two files	Outside the ledgers, often a spreadsheet or consolidation tool

The one-ledger-per-entity model puts more weight on the integration. It has to post both sides of every intercompany transaction in two separate files and keep them paired. If consolidation happens in spreadsheets, the risks compound with every entity you add.

Controls that scale across entities

Controls must be scoped by entity: who approves, which periods are open, and which accounts can receive postings. A global approver list or a single period lock doesn't match how a multi-entity group actually closes.

• Entity-scoped approvals. The UK controller approves UK exceptions; the US controller approves US exceptions.

• Entity-scoped period locks. An integration shouldn't post to a subsidiary whose period is closed, even if other subsidiaries are open.

• Entity-scoped bank and processor accounts. Each Stripe or PayPal account and each bank account maps to exactly one entity.

• Paired-posting checks. An intercompany transaction with only one side posted is an exception, not a warning.

How to choose an integration approach for multi-entity finance

Choose the approach that makes routing rules explicit, holds anything it can't route, and posts intercompany pairs atomically. Connectivity is rarely the constraint. Every major iPaaS can reach NetSuite, Sage Intacct, QuickBooks, and Xero.

Horizontal platforms and packaged connectors are flexible, and teams with integration engineers can build all of the above on them. The question is who owns the routing logic, and what the tool does when a record has no clear entity. Many connectors default to a subsidiary. A default is convenient until it's wrong.

Loopfour builds and maintains the routing table as part of the workflow. Each record gets its entity from a rule you approved, intercompany pairs post together or not at all, and anything unroutable goes to the named approver for that entity in Slack. For a fractional CFO firm running a dozen client entities on different ledgers, that's the difference between one reviewable exception queue and twelve sets of manual checks. Every run leaves an execution tree showing the routing rule applied, the entity chosen, and who approved each exception.

Frequently asked questions

What integration approach works for multi-entity or multi-subsidiary finance? Route every record to an entity by an explicit rule before it's written, keep master data entity-aware, post intercompany transactions as linked pairs, and decide currency and rate source in the integration layer. Records that can't be routed should be held for a named approver, never defaulted to the parent.

Should I use one customer per subsidiary or NetSuite's multi-subsidiary customer? It depends on tax and credit needs. NetSuite documents that tax defaults apply only to the primary subsidiary for multi-subsidiary customers and that credit limit per subsidiary isn't supported, so entities with different tax or credit treatment often work better with one customer per subsidiary linked by a master ID.

How do I make intercompany transactions eliminate cleanly? Generate both sides from one source event with a shared intercompany reference, mark both for elimination, and use a consistent rate policy. In NetSuite OneWorld, Automated Intercompany Management generates elimination entries from correctly marked intercompany lines at period close.

What field should determine the subsidiary for an invoice? Usually the contracting entity on the signed contract, combined with billing country and currency. Whatever you choose, write it into a routing table, and hold any invoice where the field is missing or conflicting.

Can I automate multi-entity finance on QuickBooks or Xero? Yes, with one company file per entity and an integration that routes each record to the right file. The integration also has to post both sides of intercompany transactions in two files, which makes pairing checks essential.

How do I stop payments landing in the wrong entity? Map each processor account and bank account to exactly one entity and route payments by the account they arrived in. Never let a payment default to the parent entity when its source account isn't recognized.

Conclusion

Multi-entity finance integration works when routing is explicit: a rule for every record type, entity-aware master data, intercompany pairs that post together, and currency decided before the ERP sees the amount. Build those four pieces first, and adding the next entity becomes a configuration change rather than a rebuild.

Tell us the one workflow your team dreads. We will show it running — deterministic, permissioned, and auditable.

Book a demo.