For CFOs
The CFO’s guide to Stripe Connect leakage
Leakage never appears as a line item. It appears as margin slightly below plan, attributed to pricing pressure, mix shift, or "market conditions" — until someone measures it directly and discovers the denominator was wrong all along. For a CFO, Stripe Connect leakage is a governance question disguised as an engineering detail: which controls exist over money movements nobody booked, who can see them, and how quickly would you know if they stopped working?
Materiality is measured against gross profit
A leak framed against revenue reads trivial; the same leak against contribution margin reads urgent. A platform netting 15% margins that loses 2% of refund value to unreversed transfers loses 13% of its profit on those transactions — the denominator change is the entire argument. Model the exposure bands for your GMV with the published ranges, label them estimates, then replace them with a measured baseline from the free scan before budget season.
- Annual refund volume
- $2,000,000
- Typical stranding band
- 1–3% → $20–60k
- Against revenue ($40M)
- 0.05–0.15% — looks trivial
- Against gross profit ($6M)
- 0.33–1.0% — board material
The question to ask engineering
"Show me every code path that creates a refund, and confirm reverse_transfer and refund_application_fee are set on each." The answer reveals everything: whether an inventory of paths exists at all, whether the main checkout path is the only audited one, and whether admin tools, support macros, retry queues and cron jobs got the same treatment. Silence or hand-waving is itself the finding.
Controls, evidence, and the audit posture
What satisfies a control environment here is specific: detection running continuously rather than annually; findings carrying evidence chains (charge, transfer, expected versus actual, timestamps); actions recorded in append-only logs; recovery authority separated from detection authority. None of this claims to deliver compliance — it gives auditors and boards something verifiable to examine, which is what governance actually requires.
What this becomes in the board deck
One slide: exposure modelled, baseline measured, recovery run-rate since monitoring began, causes ranked by dollars closed. The narrative writes itself once numbers exist — "we found a control gap affecting X% of refunds, instrumented it, recovered $Y, and eliminated the top cause" is a governance story, not an embarrassment.
What FeeGuard does about it
Read-only restricted scopes mean no payment-path risk; findings export as CSV matching journal structures; every action lands in an append-only trail; and detection stays free forever so the baseline costs nothing but ten minutes. Monitoring tiers exist for when the queue needs daily operation rather than quarterly measurement.
Common questions
Is this a finance tool or an engineering tool?
Detection runs automatically against events; recovery is governed by finance policy. Both departments touch it; neither owns the whole problem.
What access does FeeGuard need?
Read-only restricted scopes by default. Write scopes are optional and only requested if you enable automated clawback — detection never needs them.
Does this deliver SOC 2 or SOX compliance?
No tool delivers certification. FeeGuard provides the evidence layer — continuous detection, immutable trails — your auditors map into their control framework.