glossary Recurring + delayed revenue Automation & AI Agent Systems · CRM, Lifecycle & Follow-Up Systems

Dunning Sequence

A dunning sequence is what a recurring-billing system does after a charge fails. It has an entry rule that decides which decline classes enter it, a schedule of retry attempts, a notice track that messages the customer, an optional grace period during which access continues, and a terminal state that defines what the subscription becomes when the sequence ends. Its behaviour differs by billing platform and payment processor, so the sequence in any given business has to be read from that business's own configuration rather than assumed.

Definition

Dunning is the process of pursuing payment on an invoice that did not clear. In a recurring business it is automated and lives inside the billing platform, which makes it a configured state machine rather than a human collections activity. The sequence has a defined beginning — a decline response from the issuer, classified by the processor — and a defined end, after which the subscription is left in whatever status the platform was configured to write. Between those points sit the retry schedule, the customer notices, and any grace behaviour governing whether the customer keeps access while attempts continue. The same shape appears wherever recurring charges are made against stored credentials, not only in digital subscriptions.

Why it matters

Revenue lost inside a dunning sequence never involved a customer decision, which makes it structurally different from churn caused by a customer choosing to leave, and it is handled by a different part of the stack. Because the sequence is configured rather than observed, its behaviour is knowable from settings and logs rather than inferred from outcomes: the entry rule, the schedule, the notice track and the terminal state can each be read directly. That makes it a revenue mechanic an operator can audit from configuration rather than from results.

Explore related entities

[CLAIM BOUNDARY] Dunning behaviour, decline taxonomies and retry limits are set by the specific billing platform and payment processor in use and are not generalisable across them. No recovery rate is asserted here; none was verified. This is a definition, not configuration advice for any business.