Complex structures
Multiple Stripe platform accounts, one recovery surface
Multi-account Stripe estates arise innocently: regional entities for local acquiring, acquired platforms kept separate during transitions, risk segregation demanded by marketplaces. Each account then runs its own Connect rails, its own refund paths, its own silent leaks — while one finance team inherits the consolidation problem with none of the tooling. Detection has to span accounts; policy has to respect their differences; leadership needs one view that does not lie by aggregation.
Why estates fragment — and why it persists
Regional acquiring optimises conversion and compliance locally. Acquisitions keep targets separate until integration earns trust. Risk teams segregate high-volume categories. Fragmentation persists because unification is always next-quarter’s project — meanwhile each account accumulates independent leakage with independent blind spots, and group finance sees only consolidated summaries averaging the problems away.
The consolidation problem, stated precisely
Four dashboards, four export formats, four sets of webhook configurations drifting independently — and one controller trying to explain group margin. The failure mode is not any single account misbehaving; it is nobody holding the cross-account view where patterns surface (one entity’s support-team behaviour, another’s currency config) because tools stop at account boundaries.
Per-entity policy, deliberately different
Entities legitimately differ: German subsidiaries carry different seller-term norms than US siblings; acquired platforms run legacy refund code; currencies vary. Policy templates should propagate defaults while values stay per-entity — floors, thresholds, notice periods — because false uniformity breeds workarounds, and workarounds breed shadow spreadsheets where visibility dies.
The aggregate view leadership actually wants
One screen answering: total exposure across entities, recovered-to-date, causes ranked group-wide, entities ranked by leak-rate-per-GMV. Rate-normalised ranking matters — absolute dollars just crown the biggest entity, while rates reveal which teams need help. That view is what turns multi-account chaos into an operating rhythm.
Enterprise shape, and FeeGuard
SSO/SCIM, multiple connected platform accounts per customer, signed DPA and dedicated success — configured under Enterprise agreements rather than promised generically. Findings consolidate across accounts with entity attribution preserved, so the group view and the entity view derive from the same evidence instead of parallel spreadsheets.
Common questions
Do findings consolidate across accounts?
Under Enterprise configuration, yes — with entity attribution intact so group views roll up honestly and entity views stay actionable.
Do policies sync across entities?
Templates propagate; values remain per-entity by design. Uniformity imposed falsely creates the shadow-spreadsheet problem visibility was meant to solve.