E-Invoicing Architecture for Multi-Entity Groups

Most e-invoicing guidance is written for a single company with a single tax registration. Corporate groups are not that. A holding company with a trading arm, a logistics subsidiary and a manufacturing entity is four taxpayers, four sets of registrations, and — critically for anyone designing the system — four separate identities on the network. They also trade with each other, which means a large share of their invoice traffic has the group on both ends.

This paper describes the architecture that follows from those two facts: per-entity identity, and intercompany documents that must tie out.

A group is not one taxpayer

The instinct when onboarding a group is to create one account and treat the entities as departments. It does not survive contact with the tax rules. Each legal entity has its own registration, issues invoices under its own name, and is separately liable. Consolidating them into a single sender produces documents that name the wrong seller, and no amount of downstream reporting repairs that.

The consequence for design is that the legal entity, not the group, is the unit of identity. Everything else — shared users, shared configuration, group-level reporting — is layered on top of that boundary rather than replacing it.

Each entity is its own participant on the network

On a four-corner or five-corner network, an entity is addressable because it is registered against an identifier that the network can resolve. In practice that means each entity in the group gets its own participant registration, published so that senders can discover where to deliver.

• Registration is per entity. A subsidiary is discoverable in its own right, not as an attribute of the parent.
• Identifier schemes are jurisdictional. A group spanning several countries will hold different identifier types per entity, and the correct scheme is a property of where the entity is registered.
• Capability is per entity too. What document types an entity can receive is published alongside its address, and entities in the same group frequently differ.

Where a group operates across borders, the practical effect is that one customer relationship becomes several network relationships. Our SMP service covers the publication mechanics; the ERP integration whitepaper covers how documents reach it.

Intercompany traffic: one transaction, two documents

When a group's logistics arm invoices its trading arm, the network sees an ordinary supplier-to-buyer exchange. The group sees something quite different: a single economic event that must appear as a payable in one set of books and a receivable in another, for the same amount, in the same period.

That gives the architecture a job that a single-entity design never has — pairing the two legs of an intercompany exchange and proving they agree. It is worth being precise about why this is not automatic:

1. The sending and receiving entities may run different ERP systems, on different close calendars.
2. The document may be delivered successfully and still fail to post on the receiving side.
3. Where a jurisdiction also requires reporting to a tax authority, that is a third leg which can fail independently of the delivery.
4. Credit notes and corrections arrive later and must re-pair with the original.

A group that cannot see all three legs of an intercompany exchange discovers the mismatches at close, by hand.

Reconciliation at group level

The useful design goal is that someone in group finance can ask a single question — does everything we sent to ourselves tie out? — and get an answer without opening four ERPs.

Pairing works on evidence rather than convention. The strongest signal is a shared document identity carried through the exchange; where that is absent, legs can be matched on counterparties, document type and a bounded time window. What matters more than the matching rule is that the exceptions are enumerated rather than silently dropped. The classes worth surfacing are consistent across groups:

• Unmatched leg — one side of an intercompany exchange exists and the other does not. Either the document never arrived, or it arrived and was never posted.
• Duplicate document number — the same number issued twice within an entity, which usually means two systems are allocating from the same range.
• Failed delivery — the network rejected or could not deliver, so the receivable has no counterpart.
• Held document — stopped by validation or a manual hold and still sitting in the queue at period end.
• Failed regulatory leg — delivery succeeded but a required report to a tax authority did not.

Each of these is a finding a controller can act on. A reconciliation that returns only a number is not actionable; one that returns the specific exchanges that failed to pair is.

Isolation is a security boundary, not a filter

Group reporting requires reading across entities, which is exactly the capability that must not leak. Two entities in the same group may have different owners, different minority shareholders, and staff who are contractually not permitted to see each other's ledgers.

The durable pattern is that isolation is enforced in the data layer rather than in application code, so that a missing filter in a query is a failure to return rows rather than a disclosure. Group-level reads then become an explicit, audited elevation across a defined subtree — not the absence of a restriction.

This distinction is worth insisting on during procurement. "Our application filters by organisation" and "the database will not return another organisation's rows" are very different assurances, and only the second survives a bug.

What group finance actually needs to see

Consolidated e-invoicing reporting tends to be specified as a dashboard and used as an exception queue. In practice three views carry most of the value:

• Traffic by entity — volumes sent and received per legal entity per period, which is how anyone notices that a subsidiary stopped transmitting.
• Intercompany tie-out — matched pairs, with unmatched legs listed individually.
• Compliance state by jurisdiction — for a cross-border group, which entities are current against which national profile, since these move independently.

A rollout sequence that works

Groups are usually tempted to onboard every entity at once because the commercial agreement covers all of them. The sequence that carries less risk is narrower:

1. One entity, external traffic only. Prove registration, delivery and validation against real counterparties.
2. A second entity in the same jurisdiction. This is where the identity model is genuinely tested — two participants, one tenant boundary.
3. The first intercompany pair. Turn on reconciliation between exactly two entities and confirm both legs pair before adding a third.
4. Remaining domestic entities, then cross-border. Each new jurisdiction brings its own profile and identifier scheme and should be treated as a new integration, not a copy.

Where to go next

For the mechanics of getting documents out of the underlying systems, see the Oracle and SAP integration whitepaper. For a high-volume retail lane inside a group, see e-invoicing for fuel retail networks. Country-by-country requirements are collected under global e-invoicing compliance.

Published by GoRoute.ai Engineering. Last reviewed 28 August 2026.