Compliance — tax, data rights, appeals, retention
ENGINE — compliance (MAV-owned map, 2026-08-09): one console, both products mount it — Folo’s /admin/compliance is the fuller live seed; FG’s converges. Its VAT tab carries the house pattern for money truth: state the ruling, then show the math that bounds it as a RANGE — never a false-precision single number. Anything fee-related stays out of this page entirely — canonical is docs/PRICING-CANONICAL.md. Per-tab scope: Tax/VAT is per-LEGAL-ENTITY (pick whose books) · DSAR is person-scoped and genuinely cross-platform (one subject, data on all three) · appeals are per-platform queues · retention is per-store schedules. folo.link answer: this page COMPOSES those per-entity, per-person and per-store truths; it changes nothing directly except external lookups (VIES / HMRC) that mutate no record.

Four obligations, one console — and a house rule: a number you cannot attribute row-by-row renders as a bounded range, never a guess.

Demo dataPartial

VAT / GST collected

$153,071

all-time · FG entity · per-entity books, never blended

DEMO DATA · window: all-time · source: FG entity’s settled ledger

DSARs open

30-day statutory clock starts at intake

DEMO DATA · window: now · source: DSAR queue

Appeals awaiting

content decisions challenged by their creator

DEMO DATA · window: now · source: appeals queue

Deletions scheduled

1,307

grace period · real census, not an estimate

DEMO DATA · window: now · source: deletion census

Legal entity:FG entityFolo entityReceipt entity

Whose VAT am I looking at? VAT is owed by a LEGAL ENTITY, not by the family — each platform’s entity keeps its own books and files its own return, so the chip picks whose rows render below. A blended family total would be a category error. Demo shows the FG entity; Folo’s entity files separately (its own OSS registration); Receipt runs plain Stripe under its own entity — Stripe handles its tax lines, nothing to consolidate here.

showing: FG entity

Region	Collected	Rate basis	Filing status
EU · aggregate	$118,904	OSS destination rates	awaiting source — filing feed not wired
United Kingdom	$29,441	UK VAT standard rate	awaiting source — filing feed not wired
Unknown region	$4,726	unattributable — see the ruling below	held pending attribution

Founder ruling · 2026-08-06 — then the math that bounds it

“The credit was never a real transaction, so no sales tax or VAT is due on it.”

$32,646 – $33,532 not due · a RANGE, never a point

①Sales funded wholly or partly by migrated platform credit are identifiable by funding method, but the credit share inside a mixed wallet payment is not recorded per row.why no point value

②Lower bound — count only the credit portion proven by pure-credit funding rows.$32,646

③Upper bound — assume every mixed wallet row was credit-first up to its credit balance.$33,532

④The truth is inside the bounds; anything narrower would be invented precision. The range is re-derived on every settlement run.house pattern

Structure over figures: state the ruling, show the math, publish the bounds. Demo numbers — the pattern, not the books. Fees and packages never appear on this page; canonical lives in docs/PRICING-CANONICAL.md.

Funding methods · can they carry credit?

Wallet

can

iDEAL

never

Card

never

Bancontact

never

Only wallet rows can hide credit — which is exactly why the ruling resolves to a range.

VAT-number validation queue VIES · HMRC

WRITE PATH · Re-run = VIES / HMRC lookup only — reads an external register, mutates no record · EFFECT · a failing number flags the agency for human review

Queue emptyagency VAT numbers re-validate on change + quarterly

HMRC lookups pausedHMRC’s API needs credentials that are not yet set — honest, not silent

Awaiting source

No action mutates a real record yet. Every control on this console records intent only (the live seed says the same, honestly). When wired, each write goes through the owning product API with an audit row — one write path, one trail.

folo.link Folo skin FG skin Receipt skin