A group with four entities almost always ends up with four sets of spend rules, and usually ends up with four places to look them up. The second part is optional and expensive.
Why the instinct is to separate
Because the requirement is real. A newly acquired subsidiary with its own controller and its own risk profile genuinely needs a lower card ceiling and a shorter approval chain than the parent. Separate workspaces deliver that on day one with no design work.
What they also deliver is a consolidation that has to be assembled by hand, four policy documents that drift, and no way to answer “what can anyone in this group spend without approval?” without opening four screens.
Inheritance instead
Set the policy at the group and let each entity tighten it. Three rules make that work:
- An entity may lower a threshold, never raise it. The group ceiling is a ceiling.
- Inherited values are visible as inherited, not copied. A copied value stops tracking the parent silently, which is the whole failure mode.
- A change at the group level shows what it will do to each entity before it applies.
The third is the one most systems skip, and it is why administrators stop making group-level changes at all — an edit whose blast radius you cannot see is an edit nobody makes twice.
The consolidation payoff
Reporting stops being a merge. Every transaction already carries its entity — see policy that ships with the card — so group and entity views are the same query with a different filter rather than two pipelines that have to be shown to agree.
When separation really is right
Different regulators, different auditors, or an entity being prepared for sale. Those are cases where you want the isolation, including its costs, because the isolation is the point. Everything else is an inheritance problem wearing a separation costume.
