Dunning & Payment Enforcement

When Stripe emits invoice.payment_failed for a tenant, the dunning engine opens a DunningCase tied to the failing Invoice and starts the involuntary lifecycle at banner_only. A persistent payment-overdue banner is rendered to every authenticated tenant user — not only admins — so the consequences are visible to the entire organisation. As scheduled offsets elapse, the case escalates through final_warning, read_only (the tenant can read but cannot mutate billable data), pre_deletion and finally deleted.

Each transition triggers an email cascade to all tenant admins, with template, channel and offset taken from the BillingProfile dunning configuration. Contract billing has a separate trigger: 30 days overdue on a signed services contract opens a dunning case directly without a Stripe failure. Stripe webhook integration closes the loop at invoice.paid: if the case is at or below final_warning the case is closed cleanly, banners disappear and read access is restored; once read_only has been entered, automatic reactivation is explicitly disabled and a platform admin must manually waive.

The waive endpoint requires a mandatory reason that is written to the governance audit log so every override is traceable to an operator and a justification. Voluntary cancellation during an active case closes the dunning cleanly and prevents post-cancellation escalation. The PL-T047 implementation is documented in specs/api/endpoints/dunning.md and the policy ladder in docs/domain/dunning-policy.md, both linked from the feature inventory.