This section is for the platform's own operators; tenants read §15.8. Erasure is super-admin only, end to end — no delegated platform permission includes it, and the register page does not exist for anyone else.
- Open a request from Platform → Tenants ("Request erasure" on the tenant's row), or work a request the tenant's own administrator opened from their Subscription page.
- Work the register on Platform → Tenant erasures. Each record shows its stage, the export offer and its recorded outcome, the grace dates, the dry-run manifest (row and file counts plus its hash — generated from the live schema each time, never a hand list), and any gate failure by name: a legal hold, an unpaid platform invoice, a mirrored balance still open, a migration run still in flight. Gates are checked when grace starts and again at execution; a failed gate is a stop, not a warning.
- Builds run in the background. Build export and Dry-run manifest start background jobs rather than doing the work inside the click — a large tenant's export can take minutes, and the page never waits for it. The row shows Building… / Generating… with the time the build was queued, names a failure on the row when one happens, and names a build no worker is processing so you can send it again — never a build quietly pending forever. The export download appears on the row when the bundle is ready.
- The bundle covers line-level records too. Every sheet in the export is read through the same company-scope classification the dry-run manifest uses, so records that belong to the tenant through a parent document — bank statement lines through their statement, invoice and order lines through their documents — are in the tenant's bundle exactly as the census counts them. If a build ever meets a table it cannot scope to the tenant, it fails by name on the row rather than producing a bundle with silent gaps.
- Execute only from grace, only after the purge date, and only by typing the tenant's code into the row. The purge then runs as a queued job — the register shows its progress, and if no worker is processing it the page says so and offers Resume. Execution extracts the billing records to the register first (kept six years), deletes in dependency order, sweeps the file stores and the analysis warehouse, and issues the certificate (downloadable from the row) only when the independent verification count reads zero everywhere. A purge that cannot prove zero stops as failed, naming what remains — it never certifies on faith.
- Onboarding rounds are erased through the same register: an archived round of a closed case can be opened as an erasure of its snapshot company (the 90-day retention runs from the case's close). The case record itself — what was agreed and signed — is kept; the rehearsal company's data is what goes.
- Cancelling an erasure leaves the tenant's data untouched and its subscription cancelled; reactivate the subscription from Platform → Tenants when the tenant resumes.
- The grace length is a platform setting — Platform → Billing → Erasure grace (days), 30 by default, and distinct from the billing grace on the same card (that one drives the past-due → suspension clock). The value is read when an erasure's grace starts — and when a never-paid trial is captured — so erasures already in grace keep the purge date they were given. Setting it to 0 lets a purge execute as soon as grace starts; use that only when the tenant's window has genuinely already been served by other means.