Multi-entity operation

As a SaaS company expands internationally it usually establishes local legal entities: a US Inc., an EU entity, an APAC entity. Each becomes the contracting party and merchant of record for customers in its region.

Each entity needs its own invoice numbering, its own tax registrations and treatment, its own functional currency, its own accounting system connection, and its own statutory reporting — while the group needs consolidated revenue, consolidated ARR and consolidated retention.

The instance-per-entity trap

Many billing platforms handle this by requiring a separate instance per entity. That produces:

• A duplicated product catalog in each instance, drifting apart from the day it is copied.
• Duplicated integrations to maintain — CRM, tax, accounting, payments — multiplied by the entity count.
• No consolidated reporting without exporting from each and merging by hand.
• Customers with entities in several regions who cannot be seen as one relationship.

The cost is not the licence; it is that every pricing change, every integration update and every reporting question is now an N-times problem.

What the alternative looks like

The structure that scales is a single instance where entity is an attribute of the contract rather than a boundary of the system: one shared catalog, per-entity price books and currencies, per-entity invoice sequences and tax rules, per-entity accounting integrations — and group-level reporting that simply does not need consolidation because the data was never split.

Worth evaluating before the second entity is incorporated. Retrofitting an entity model onto duplicated instances means migrating live subscriptions, which nobody enjoys.