Finance — one ledger, separate lanes OWNER: ENGINE — payments (Mav's map, 2026-08-09). This is the money merge group: seven live FG routes (Finance Overview · Settlement · Transactions · Chargebacks · Ledger · Payouts + Fees) collapse into this ONE common surface; Folo’s /admin/finance mounts the same page. Per brand: FG adds third-party platform filters + recording/CRM lane; Folo is consumption-side of the same ledger (fan pays, wallet shows — it records nothing sale-side); Receipt is excluded from blended rollups — own metric id, plain Stripe. Fees are never quoted here — canonical is docs/PRICING-CANONICAL.md. folo.link scope (§17 + §17e): this page READS the one Folo↔FG ledger plus Receipt’s separate Stripe store; the payout Approve works in place on every skin — the write routes via the owning product’s admin API (one write path, audited in its log) and “open in FG admin ↗” is only the quiet secondary. Everything else here is a read.
The shared payments engine — every product mounts this page; money renders in separate lanes, never summed.
Demo dataPartial
Folo · GTV
$798,083
gross transaction value · consumption side of the one ledger
Fanogram · net revenue
$154,807
recording + CRM side of the same ledger · never re-counted with Folo GTV
Receipt · tracked revenue
$0.00
own metric id · plain Stripe · excluded from blended rollups by rule
≠
Never summed. Standing rule (Mav-adopted 2026-08-09): three lanes, three metric ids, three formulas — a total across them would double-count the one Folo↔FG ledger and blend Receipt’s incompatible metric.
ReadingComposed read: the one Folo↔FG ledger (two lanes of the same store) + Receipt’s separate Stripe store. Every row below carries its store chip; a lane pick filters rows — totals never blend lanes.
Net revenue · FG lane shown — pick a skin for its lane
$154,807
Jul 11Jul 26Aug 10
Demo data
$
One ledger, locked (Mav ③, 2026-08-09): Folo = consumption (fan pays, wallet shows) · FG = recording + CRM. This chart shows ONE lane at a time — pick the skin in the devbar to see each brand’s read of the same page.
Revenue by type · 30dDemo data
100%
PPV unlocks · 51.8%Subscriptions · 39.6%Tips · 8.3%Custom & services · 0.2%
Attribution honesty
UNLABELLED stays unlabelled — we never guess. A sale without a platform or sold-by attribution renders as UNLABELLED in every table and chart split; it is never reassigned to the biggest bucket. (Live FG convention, kept as the house rule.)
Payout approvals View + approve only Demo data Honest scope from both live admins: payouts here are view + approve only — refunds and exports are role-gated and audited; on live Folo the Approve button is still stubbed (“Not wired — no handler”). Owner + write path (§17-2 + §17e): the payouts queue is FG’s — Approve routes via the FG admin API and is audited there; the button works in place on every skin (the architecture constrains the WRITE, not the operator) and “open in FG admin ↗” is a quiet secondary, never the only path. Effect (§17-3): the payout moves to processing and funds leave on the next settlement run; the creator sees “processing” in their earnings view. Fail-safe: a blocked KYC/KYB state disables the button — it never queues a payout that compliance would unwind.
→
Delisha@delisha · balance on-platform · requested 2d ago
→
Little Miss Aria@missaria · balance on-platform · requested 1d ago
→
Sophia Jansen@sophiajansen · KYC pending — approval blocked
→
Velvet Studioagency settlement · KYB in review
≡
$116,429 pending across 12 creators (demo) — full queue lives on the Payouts tab; every approve is audited with actor + reason.
→
Write path: Approve acts in place on this skin too — the write routes via FG’s admin API · one write path · audited in FG’s log · your grant: super admin; “open in FG admin ↗” is the quiet secondary, never the only path. Effect: payout → processing; funds leave on the next settlement run; the creator’s earnings view shows “processing”. Blocked rows stay blocked until KYC/KYB clears — the button can never queue a payout compliance would unwind.