Single Tenant or Multi-Tenant? How to Architect Expense Management for 100+ Legal Entities

Introduction

Energy and utilities groups are among the most entity-heavy organisations in any industry. A mid-sized power group in Southeast Asia routinely operates 50 to 150 legal entities: generation assets held in separate project companies for financing reasons, distribution utilities operating under franchise licences, retail electricity suppliers, holding companies, and one or more shared-services companies that provide finance, HR and IT to everyone else. Each of those entities has its own board, its own statutory accounts and its own tax filing.

Useful architectural context appears in Oracle’s ERP overview, PwC’s energy and utilities research and Deloitte’s strategy insights.

What Does Single Tenant vs Multi-Tenant Actually Mean in Expense Management?

In expense management, a single tenant means one logical instance of the platform containing every legal entity as a subsidiary record, sharing one user directory, one policy library and one reporting layer. Multi-tenant, in the enterprise buyer’s sense of the phrase, means several separate instances — each with its own configuration, its own users and its own database — that cannot natively query each other.

The three architectures you are actually choosing between

• Single tenant, multi-entity. One instance, 100 entity records, entity as a dimension on every transaction, user and policy object.
• Federated tenants. Two to four instances split along a hard boundary such as jurisdiction, with a downstream warehouse stitching them together for group reporting.
• Fragmented tenants. One instance per business unit or per country. Common in groups that grew by acquisition and never consolidated. This is almost always an accident rather than a decision.

When Is a Single Tenant Right, and When Are Separate Tenants Unavoidable?

A single tenant with subsidiary entities is the correct default for most multi-entity groups, and separate tenants are only justified by a small set of hard constraints. If you cannot name a specific legal, regulatory or transactional reason that two entities must not share a database, they should share one.

Separate tenants become genuinely unavoidable in four situations:

• Data residency law. A jurisdiction requires employee personal data and receipt images to remain physically inside its borders, and your platform cannot pin storage at entity level.
• Legal ring-fencing. A regulated distribution utility or a joint venture with external shareholders is contractually barred from sharing operational systems with affiliates.
• Imminent divestment. An entity or cluster is under active sale process and the acquirer will need a clean, separable dataset within 12 months.
• Radically divergent policy. A business unit’s expense policy, approval model and category structure share almost nothing with the group, so shared configuration produces more exceptions than it removes.

The trade-offs are worth laying out explicitly, because most groups only discover the multi-tenant costs after go-live.

How Do You Model Shared-Services Users Who File and Approve Across Many Entities?

Model each person as one user record with a home entity plus an entitlement set that lists every additional entity they may act in and the role they hold there. The mistake to avoid is creating one user per entity, which inflates licence counts, splinters audit trails and makes delegation impossible.

Entitlement design that scales

• Home entity drives payroll, default cost centre and default currency on a new claim.
• Transaction entitlements list the entities a user may file against; the entity picker on a claim shows only these.
• Role entitlements are separate and per entity, so a person can be a submitter in ten entities and an approver in three.
• Profiles bundle entitlements into reusable sets such as “Shared Services AP — Region North”, so onboarding a new analyst is one assignment rather than 40.
• Attribute-driven assignment derives entitlements from HR fields (department, region, cost centre) so leavers and movers are handled automatically.

Which Master Data Should Be Global and Which Should Be Entity-Local?

Master data should be global when you want to report on it consistently across the group, and entity-local when it is bound to a specific legal ledger or statutory obligation. Get this split wrong in either direction and you pay: too global and entities cannot meet local tax rules, too local and group reporting becomes impossible.

How Do You Design an Expense Platform That Survives a Group Reorganisation?

Design for reorganisation by treating the entity as a first-class object whose group membership is a mutable, effective-dated attribute — not part of the entity’s identifier and not a fixed hierarchy that reporting and security read directly. This single decision is what separates a two-week reorganisation from a two-quarter one.

The four rules that make reorganisation cheap

1. Entity codes are meaningless identifiers. Never encode region, technology or group into the code. ENT-0042, not HYDRO-LUZON-04.
2. Group membership is an attribute with valid-from and valid-to dates. An entity belongs to the “Thermal” group until 31 December and the “Region North” group from 1 January, and both facts remain true for their respective periods.
3. Support multiple concurrent grouping dimensions. Technology, region, regulatory status and reporting segment should all exist simultaneously as separate attributes, not as competing hierarchies.
4. Reporting reads groups as of a date. Prior-period reports use the old structure, current-period reports use the new one, and nobody restates a single transaction.

Use the following triggers to decide when an entity genuinely warrants its own tenant.

How to Architect Multi-Entity Expense Management: A Step-by-Step Implementation Guide

Follow these eight steps in order. Steps 1 to 4 are design decisions that are expensive to reverse; steps 5 to 8 are build and rollout.

1. Build a complete entity register. List every legal entity with its base currency, fiscal calendar, ERP company code, tax regime, statutory reporting obligation, expected annual claim volume and divestment likelihood. Expect to find 5 to 15 percent more entities than the org chart shows.
2. Apply the tenancy decision test. Default to a single tenant with subsidiary entity records. Split into a separate tenant only where data residency law, legal ring-fencing, imminent divestment or radically divergent policy makes shared configuration impossible.
3. Split master data into global and entity-local objects. Define categories, policy templates, currencies and audit rules once at group level. Keep GL accounts, tax codes, cost centres, approvers and per diem rates entity-local, joined by a category-to-GL mapping table.
4. Model entity and group as separate, mutable objects. Store group membership as an effective-dated attribute on the entity record. Support several concurrent grouping dimensions and make reporting read group as of a date.
5. Design user entitlement for shared services. One user record per person with a home entity plus an entitlement set. Bundle entitlements into profiles and drive them from HR attributes.
6. Separate currency conversion for routing from posting to the ERP. Convert to the entity base currency only to select the approval tier; post in original currency and let the ERP revalue and translate.
7. Build cross-entity work queues and reporting. One first-in-first-out queue per administrator spanning their entitlement set, with entity as a column. Expose entity, group and region as standing analytics dimensions, and wire in real-time budget validation against the ERP at request time.
8. Pilot one entity group, then roll out in waves. Go live with three to five entities that span the hardest variations, stabilise for four to six weeks, then roll out in waves of ten to twenty entities at four-week intervals.

A realistic sequence for a 100-entity group looks like this.

How Peakflo Handles Multi-Entity Expense Estates

Peakflo’s travel and expense module models legal entities as subsidiaries inside a single tenant, so entity-local data stays separated while group-level reporting remains possible.

Entity data stays aligned with the financial core through Peakflo’s ERP integrations, including NetSuite, SAP and SFTP file transfer. Review the architecture on the product tour or request a demo.

Our Verdict: Single Tenant With Subsidiaries Is the Default, and Entity Modelling Matters More Than Tenancy

Single tenant with subsidiary entities is the right architecture for the large majority of multi-entity groups, but the tenancy choice is not where most programmes fail. They fail on entity modelling — specifically on hard-coding group hierarchy — and that failure is invisible until the first reorganisation. For sector and reporting context see the IEA’s electricity system analysis and AICPA management accounting guidance.

Best for:

• Groups of 20 to 300 legal entities sharing one dominant base currency with a handful of foreign-currency ledgers
• Organisations with shared-services finance centres serving many entities at once
• Groups that reorganise regularly as assets are acquired, divested or regrouped
• Enterprises standardising on a single ERP core with an expense layer integrating back to it

Not recommended if:

• A material share of your entities sit in jurisdictions with strict data residency requirements your platform cannot satisfy at entity level
• A regulated or joint-venture entity is contractually barred from sharing operational systems
• More than half the group is under active sale process
• Your entities genuinely share no common expense categories, which in practice is rare

Conclusion

The headline question — single tenant or multi-tenant — has a clear answer for most energy and utilities groups: one tenant, many entities. Separate tenants solve a narrow set of legal and regulatory problems and create a broad set of reporting, administration and cost problems in exchange.

The harder question is how you represent entities inside that tenant. Groups that treat entity as a first-class object with mutable, effective-dated group membership absorb restructures and divestments as routine configuration. Groups that bake hierarchy into entity codes discover, usually mid-reorganisation, that their expense platform has become the constraint on how the business can be organised.

Design for the reorganisation you have not announced yet. It is the cheapest insurance in the entire programme.

Frequently Asked Questions

What is multi entity expense management?

Multi entity expense management is the practice of processing travel, cash advance, corporate card and reimbursement claims for many legal entities inside one expense platform, while keeping each entity’s chart of accounts, tax treatment.

Is single tenant or multi-tenant better for a group with 100 legal entities?

For roughly 85 to 90 percent of groups, a single tenant with 100 entity records is the better architecture. It gives native cross-entity reporting, one user directory, one policy library and a single integration.

How many separate tenants should a large group actually run?

Most groups that genuinely need more than one tenant need two or three, not ten. A typical pattern is one primary tenant covering all domestic entities, plus one secondary tenant for a jurisdiction with data residency rules or for a ring-fenced joint venture.

How do you model a shared services employee who files expenses for many entities?

Create one user record with a home entity for payroll and default costing, then grant a separate entitlement set listing every entity the user may transact against and the role held in each.

Which expense master data should be global and which should be entity-local?

Global objects are those you want reported consistently across the group: expense categories, policy templates, currency and FX rate sources, receipt rules, merchant taxonomy and audit rules.

Why can’t legacy expense systems move an entity between groups?

Legacy systems typically encode group membership inside the entity’s identifier or inside a fixed hierarchy table that reporting, approval routing and security all read directly.

What is effective-dated group membership and why does it matter?

Effective-dated group membership stores each entity’s group assignment with a valid-from and valid-to date, so an entity can belong to a technology group until 31 December and a regional group from 1 January.

How should multi-currency work across entities with different base currencies?

The expense platform should convert claim amounts into the entity’s base currency purely to decide which approval threshold tier applies, then hand the transaction to the ERP in the original transaction currency with the original amount, date and rate reference.

How do travel administrators manage approval queues spanning many entities?

Give the administrator one cross-entity work queue that unions every entity in their entitlement set and orders items first-in-first-out by the date the item entered the approval step, not by entity name or claim.

What does a consolidated reporting layer cost if you run multiple tenants?

Building and running a separate consolidation layer for multi-tenant expense data typically costs 250 to 600 engineering hours to build and 20 to 40 hours a month to maintain, plus warehouse and pipeline costs.

How do you onboard an acquired entity into an existing expense tenant?

Create the entity record with its base currency, fiscal calendar and ERP company code, clone a policy template from the closest existing entity, load its GL accounts, tax codes and cost centres, then load.

How do you offboard a divested entity without losing audit history?

Set the entity to a closing state that blocks new submissions but allows existing claims to complete, run a final settlement window of 30 to 60 days, export a complete transaction and receipt archive.