The autopay mandate exists, and it has quietly stopped collecting

A recurring mandate that has stopped collecting does not fail. It is absent — no debit attempt, no decline code, no gateway webhook, nothing for a dunning ladder to react to. That is why it goes unnoticed for cycles: every alerting system a club owns is built to react to a failure, and this is a silence.

There are 4 states behind that silence, and the fix is different for each. The member revoked the mandate through their bank or payment app. The mandate reached its own end date. The debit exceeded the maximum amount authorised at registration and was refused before it became a transaction. Or the mandate was never activated in the first place, and the member has believed since sign-up that they are paying you.

The three-way join that names the state

This is a reconciliation, not a report you already have. It starts from what you were owed rather than from what was collected, because everything else in your stack starts from collections and the whole problem is a collection that never happened.

1. List every membership that should have been debited in the cycle, from the membership schedule. Not from the payment provider, and not from the invoices raised — both of those are downstream of the thing that failed.
2. List every successful debit in the same window from the provider, keyed on the mandate reference rather than on the member id. Members hold multiple mandates more often than anyone expects, especially after a card change.
3. Left join the first onto the second. The unmatched rows are your population, and it will be larger than the arrears figure your billing screen shows.
4. For every unmatched row, fetch the mandate's current status and the date of its last status change from the provider, and store the rail's own code verbatim. Do not map it to your internal vocabulary at this stage; the mapping is where the 4 states get flattened into one.
5. Bucket the population by that status-change date. A cluster on a single date is a systemic event on your side. An even spread across the cycle is member-side revocation, which behaves like churn and should be read as churn.
6. Only now compare against your arrears list. Anything in the join that is not in arrears is a member the system believes is paid up.

Registered, active and collecting are three different claims

Most club systems record 1 boolean: the member has autopay, or does not. That boolean is set when the registration flow returns and is never touched again, which is exactly why the failure is invisible. Registration is an intent, activation is a confirmation from the member's bank, and collecting is an observed debit in the current cycle. A member can be registered and not active, active and not collecting, and your screen will show a green tick in all 3 cases.

• Store the mandate as its own record: status, status-change timestamp, validity end date, maximum amount authorised. A flag on the member row cannot represent any of these states.
• Record the last successful debit date there and surface it wherever staff look at a member. A mandate last debited 2 cycles ago is a fact a receptionist can act on; a green tick is not.
• Treat activation as an event you receive, not a value you assume, and keep the rail's own status code alongside yours. When you call the provider about 40 members, their team works from their vocabulary.

The four states, and why one recovery path does not fit them

The last row is there because it is common and it is the cheapest to eliminate. A freeze that suspends collection without an agreed resume date produces exactly this pattern, and what a freeze is supposed to do to the schedule is set out in what a membership freeze does to the billing schedule.

A failed payment is an event you can retry. A dead mandate is a permission you no longer hold, and no retry ladder in the world converts one into the other.

The version of this that clubs cause themselves

The systemic signature — dozens of mandates going quiet on the same date — is almost always an amount change. A mandate authorises a maximum per debit, fixed when the member approved it. Raise the fee above that ceiling and every member registered under the old one stops collecting simultaneously, with no decline anyone sees.

• Register with headroom, as a written policy. Set the authorised maximum meaningfully above today's fee so an ordinary annual increase does not require re-authorisation of the whole base.
• Treat a fee rise as a mandate migration, planned before the price is announced. The staged approach with an abort point in raising membership fees without a cancellation spike has to include the mandates that cannot carry the new amount.
• Watch cycle 1 on any joining charge. A joining fee collected alongside the first monthly debit can exceed a ceiling sized for the monthly amount alone — the modelling for that is in charging a joining fee and a monthly fee on one mandate.
• Model every one-off uplift before it is debited. A mid-cycle upgrade or a pro-rata catch-up is a larger-than-usual debit, and the arithmetic that produces it is in computing pro-rata for mid-cycle joins, freezes and upgrades. If the result exceeds the ceiling, the whole charge fails, not the excess.
• Check family accounts when membership composition changes. Adding a sibling to a mandate sized for 2 children silently breaks it — one of several edge cases traced through billing one academy term with siblings, freezes and joiners.

Pre-debit notification is part of the collection, not a courtesy

Recurring rails generally require the payer to be notified before a debit is taken, with a defined lead time. Treat that notification as a step in the collection rather than as marketing: if your provider sends it and you do not know, your member is being told about a charge in wording you did not write. If you send it and the timing does not satisfy the rail, the debit can be refused.

• Establish which party sends it — you, the provider, or the member's bank — and store a record either way. When a member disputes a charge, the notification is the evidence.
• Give the member a real window to act. A notice arriving with the debit is a receipt, and a receipt does not prevent a dispute.
• Confirm the current lead time with your provider rather than encoding one from a blog post, and treat a notification the provider could not send as an early warning that the mandate underneath is gone.

Re-authorise or amend: the fork that decides the member experience

Two of the 4 states end in a member action, and the difference between them is worth engineering for. Amendment, where the rail supports it, changes the authorised amount or the end date on an existing mandate and is usually a lighter interaction. Re-authorisation is a fresh approval, which means the member reopens their banking app, and every one of those is an opportunity to reconsider the membership.

1. Determine which operations your rail and provider support on a live mandate. Amend and pause are not universal, and assuming they exist produces a recovery flow that fails in production.
2. Batch the systemic cohort and message it as a change to the arrangement, not a failure. Members whose mandate broke because you raised a fee did nothing wrong, and a dunning email tells them otherwise.
3. Handle member-side revocations individually. That population is a retention signal, and the argument in put the cancel button in the app applies: they cancelled somewhere you cannot see.
4. Stop the retry ladder for both, and set a stated deadline with a stated consequence. Retrying a revoked mandate produces only noise — the distinction drawn in which payment declines are worth retrying.

Making this visible in cycle two, not month five

The reconciliation above is a query. Turned into a scheduled job that runs the day after each collection run and writes a queue with names on it, the entire class of failure moves from invisible to routine. Nobody notices a missing debit; everybody notices a list of 12 members labelled mandate inactive.

This is usually the last thing a club commissions and it should be among the first. Software attention goes to the visible half of the operation — scheduling, attendance, and coach-facing tooling like encoding progression so the coach stops retyping loads — while the collection side is assumed to work because it worked in month 1. The related failure, where a decline genuinely happened but never reached a human, is failed dues only surfacing when the term ends; this page is its mirror image, where there was no decline to notice.

Which rail to build on is a separate argument, weighed in card mandate or UPI AutoPay for recurring club dues. Whichever you choose, the mandate record, the reconciliation job and the re-authorisation flow decide whether dues arrive — ordinary MVP and product build work across memberships, session packs and dues in our sports, fitness and athletics practice.

• recurring payments
• mandates
• membership dues
• reconciliation