Feb 23, 2026
Arnon Shimoni
Every company that expands into a second geography discovers the same thing: their billing system assumes they're one company.
When you launch a European subsidiary and you need a second Stripe account, and now you have two sets of API keys, two dashboards, two reconciliation processes. Your engineering team builds a "billing orchestrator" to unify them. Your finance team builds a spreadsheet to reconcile them. Six months of work just to invoice from Brussels.
This is the multi-entity billing problem. And it gets worse from here.
What multi-entity billing actually means
Multi-entity billing is the ability to operate billing across multiple legal entities from a single system, with entity-specific currencies, tax rules, invoice templates, and compliance settings, while maintaining a consolidated view for finance.
Read that last line again - because most companies end up with multi-entity billing by accident: one Stripe account per country, separate configurations per subsidiary, manual consolidation in spreadsheets.
I call that a multi-account billing held together with duct tape.
True multi-entity means:
Each legal entity has its own currency, tax jurisdiction, and invoice formatting
All entities share a single product catalog and customer view
Revenue rolls up into a consolidated report without manual reconciliation
New entities launch without new API integrations or billing code
The difference shows up at month-end. Companies with real multi-entity billing close books in days. Companies with multi-account workarounds close in weeks.
Why multi-entity duct-taping breaks at scale
With usage-based pricing gone mainstream, some 85% of surveyed software companies now incorporating some form of consumption billing. These two trends collide in multi-entity environments.
When you're running seats plus usage plus credits across three legal entities, the math gets really complicated, really quickly,
As each entity may have different pricing for the same product, currency conversion happens at different rates on different days, VAT rules differ by country - and all of this needs to reconcile into a single set of financials for your board and your auditors.
Research shows a typical 1,000-person company spends 100,000 person-hours annually on account reconciliation. That is insanely high. Manual reconciliation takes around 8 days compared with 3 days for automated systems. In multi-entity structures, each subsidiary multiplies that time.
The direct labour cost can reach $3–5M annually for large organizations.
For SaaS companies between $15M and $100M ARR, the numbers are smaller but the pain is proportional. We've seen finance teams spending 2 full weeks on monthly close, with the bulk of that time spent reconciling revenue across entities and currencies.
The billing platform landscape for multi-entity
Not every billing platform handles multi-entity the same way. The differences matter, and they're often buried in implementation details rather than marketing pages.
True in-tenant multi-entity
These platforms treat legal entities as a first-class concept. You configure multiple entities within a single environment, each with its own currency, tax, and compliance rules, and get consolidated reporting without external tools.
Solvimon was built by the team that scaled Adyen's internal billing engine to handle €970B+ in annual payment volume across dozens of entities and currencies. Multi-entity isn't a feature we added. It's how the system was designed from the start. One product catalog. Infinite entities. Launch in India, Brazil, or Germany without new API keys or billing code. Combined with native support for usage-based pricing, credits, and hybrid models, it handles the full complexity of modern SaaS billing across geographies.
Zuora offers mature multi-entity support with entity hierarchies and global workflows. It's a proven enterprise option, though implementation timelines and administration overhead reflect its complexity. Usually the right fit for large global organizations with dedicated billing teams.
Chargebee provides "Multi-Business Entity" configuration within a single environment, with entity-specific addresses, taxation, and catalogs. Solid for mid-market SaaS with 2–10 entities, though the feature typically requires higher-tier plans.
Multi-entity through workarounds
These platforms can achieve multi-entity outcomes, but the entity separation lives outside the billing system itself.
Stripe Billing requires a separate Stripe account per legal entity. You can stitch them together using Organizations or Connect, but reporting, tax, and revenue recognition remain fragmented across accounts. For companies with two entities, this is manageable. At five or more, you're maintaining a custom orchestration layer.
Metronome handles multi-entity by mapping to multiple Stripe accounts, letting you choose which account bills which customer. The entity separation still happens at the Stripe-account layer, which means legal-entity accounting and tax compliance live in Stripe and your ERP rather than in Metronome itself.
Orb has a rich customer hierarchy with parent/child accounts and consolidated invoicing across business units. But the accounts are structured as test/live environments rather than true legal entities. If your multi-entity needs are primarily about customer hierarchy and credit pooling, Orb works. If you need entity-specific tax, compliance, and statutory reporting, that still lives in your ERP.
Single-entity platforms
Many billing platforms, including Lago, Maxio, and others, don't offer a native multi-entity feature. The workaround is typically running a separate instance per entity and consolidating in your data warehouse or ERP. This works until it doesn't, usually around entity three or four, when the maintenance burden of multiple instances exceeds the cost of migrating to a multi-entity platform.
What to look for in a multi-entity billing platform
When evaluating options, these are the capabilities that separate real multi-entity support from marketing claims:
Capability | Why it matters (examples) |
|---|---|
Entity-level configuration | Each legal entity needs its own currency, tax rules, invoice templates, and bank details without maintaining separate environments |
Single product catalog | Define products and pricing once, localize per entity. Avoids catalog drift and conflicting setups |
Consolidated reporting | Revenue, usage, and subscription metrics should roll up across entities without manual aggregation |
Inter-company automation | When one entity sells and another delivers, revenue and cost allocation should happen at the contract level, not in month-end journal entries |
Multi-currency with real-time FX | Currency conversion at invoice time using current rates, with FX impact visible in reporting |
Usage-based billing across entities | Usage metering that works per-entity while respecting entity-specific rate cards and pricing |
Role-based access by entity | Finance teams in Germany shouldn't see or need to modify billing for the US entity |
The last point is often overlooked. As companies add entities, they also add finance staff in each region. Without entity-scoped permissions, you're choosing between giving everyone access to everything or building manual gatekeeping processes.
The architectural decision you should make
Multi-entity billing is an architectural decision, not simply a feature checkbox to cross off in an RFP.
If you're a single-entity company today with plans to expand, the choice you make now determines whether launching a second entity takes a week or six months. Companies that start with a platform designed for multi-entity from the ground up avoid the painful migration later, when the billing system that worked fine for one entity becomes the bottleneck for the business.
We've seen how companies do this before: launch with Stripe for entity one. Add a second Stripe account for entity two. Build custom code to unify them. Add usage-based pricing. Build more custom code. Add a third entity.
You should now realize that you are maintaining a billing orchestration layer that three to five engineers work on full-time and nobody fully understands how it breaks.
That's billing v1 breaking - and that's not because Stripe is bad - but because you succeeded! Congrats!
Billing v2 is a single system that handles the entire lifecycle across entities, currencies, and pricing models. One ledger. One catalog. One source of truth.
Getting started
If you're evaluating multi-entity billing platforms, start here:
Count your entities (current and planned for 24 months). If you're at one today and expect three within two years, choose a platform with native multi-entity now. Migrating later is always more expensive than building right the first time.
Map your pricing complexity. Pure subscriptions across entities is a solved problem. Hybrid pricing (seats + usage + credits) across entities with different currencies and tax regimes is where most platforms break.
Talk to your finance team. The real cost of multi-entity billing isn't the platform fee. It's the engineering hours maintaining billing code, the finance hours reconciling across systems, and the close cycle days that compound every month.
Solvimon handles multi-entity, multi-currency, and hybrid pricing in a single system, built by the team that managed this complexity at Adyen for €970B+ in annual volume. If you're scaling beyond your first entity and your current billing setup is starting to strain, we should talk.