Architecture·Reference·6 min·Updated 2026-10-05
Several legal entities
One org, several selling entities, and tax rules that must not leak between them.
Business requirement
A group sells through several legal entities in different jurisdictions. Each has its own tax rules, its own accounting periods, and must never apply another's rate.
Why it is not trivial
With several entities the treatment can be selected by entity. With one, that selection mechanism has nothing to discriminate on and silently does nothing — so an architecture that works in a multi-entity org is not transferable to a single-entity one, and the reverse.
Recommended architecture
Entity-scoped treatments and rates, with the policy selecting by legal entity. Accounting periods are per entity too.
Salesforce components
Select one to open its detail.
Flow
Scroll the diagram sideways
Two things decide everything here. First, it is the country of the billing profile that commands the rate, not the address on the order — verified in both directions on two orders with different addresses and the same profile. Second, no native mechanism varies the tax code by country: TaxTreatmentItem has no geographic field, and the standard decision table takes a code as input and returns a rate, so it can never produce one.
Implementation
- One treatment per entity, with the policy selecting on entity.
- Rates scoped to the entity, so a rate cannot leak across.
- Periods per entity — and remember a period cannot exceed one year.
Watch out
- With a single entity, entity-based selection is inoperative. Resolve on the rate instead, or place the treatment on the line.
- An accounting period cannot exceed one year, so “one open period” means one per financial year.
Alternatives
Separate orgs give absolute isolation and cost you cross-entity reporting and a second of everything. Worth it only when the entities genuinely share no customers.