Published 2026-09-21 · LuckyMDM Blog
A returned debit is a result, not a reason. The reason lives in the return code the network sends back, and that code decides what you are allowed to do next. Group the codes into three buckets and the workflow writes itself: one bucket is worth retrying, one bucket needs the subscriber to act, and one bucket must never be retried at all. Treat all three the same and you will lock the wrong handsets, inflate your return rate, and hand the subscriber a defensible complaint.
A debit travels from your billing system through an originating institution and a network to the receiving bank. Any one of those can decline, and every decline lands in your console as the same word: failed. At the symptom layer there is one state. At the cause layer there are at least three. That compression is where every downstream mistake starts.
A debit succeeds only when four conditions are true simultaneously: a valid authorisation is on file, the account is in good standing, sufficient funds or available credit exist, and the routing between originator and receiving bank is working. Those four belong to different parties. The authorisation belongs to the subscriber and to you. Account standing belongs to the receiving bank. Funds belong to the subscriber. Routing belongs to the network. Because the owners differ, the repair actions differ, and no single agent on a phone call can repair all four.
The ACH network returns a three-character reason code with each returned entry. That code is the only objective field capable of separating the three paths, and in most subscription operations it never leaves the payment processor's dashboard. It does not reach the device ledger, it does not reach the collections queue, and so the people who need it most are guessing. The mechanism fixes the order of work: get the code into your own record first, then design the retry policy, then define the delinquency date. Reverse that order and you will rebuild it twice.
| Bucket | Representative codes | What actually happened | The right action | The wrong action |
|---|---|---|---|---|
| A, funds | R01 Insufficient Funds; R09 Uncollected Funds | Money was not there on the day | Re-present on a schedule, three attempts, avoid overnight and month-edge windows | Counting it as delinquency and locking the device |
| B, authorisation and account | R03 No Account or Unable to Locate; R04 Invalid Account Number; R13 Invalid Routing Number; R07 Authorisation Revoked; R10 Customer Advises Not Authorised | The authorisation or the account reference is broken | Send a re-authorisation link the same day; escalate if not repaired in 48 hours | Retrying at all. R07 and R10 in particular must not be re-initiated without fresh authorisation |
| C, stop and dispute | R08 Payment Stopped; R05 Unauthorised Consumer Debit Under a Corporate Code; R29 Corporate Customer Advises Not Authorised | The payment was blocked or is being contested | Zero retries, route to a human, open a risk review on the subscription | Retrying, auto-locking, auto-assessing late fees |
Read the table right to left. The "wrong action" column matters more, because a wrong action costs more than a missed one.
Two rules sit behind bucket B and bucket C. Under the Nacha Operating Rules, certain returns may be re-initiated a limited number of times within a defined window after the original settlement date, commonly cited as up to two times within 180 days for R01 and R09. Returns that turn on authorisation, such as R07 and R10, are a different matter: re-initiating without a new authorisation is not a policy question, it is a compliance one. Confirm both against the current Nacha Operating Rules and your originating institution before you encode anything.
Bucket A timing is not arbitrary. First, avoid the overnight window, roughly 00:00 to 06:00 in the receiving bank's timezone: declines cluster there and the failures land in the same business day's figures. Second, avoid the first three and last three days of the calendar month, when competing debits concentrate and the insufficient-funds rate is artificially inflated. Third, place the three attempts at 17:00 on the day after the original presentment, then 09:00 on day three, then 09:00 on day five. The 17:00 slot is the one that most often lands after pay has cleared.
Bucket B has no retry, only repair. Once a subscriber has changed bank accounts, the stored authorisation no longer describes anything real. One re-presentment and ten re-presentments return the identical code; the difference is that ten of them multiply your failure count by ten.
Bucket C is the only zero-retry bucket. A stop payment or a contested debit will not convert on a second attempt, and repeated attempts against a blocked account are exactly the pattern risk models look for.
This is the part that decides whether the rest of your process holds up. If the delinquency clock starts on the day of the first return, then every action you schedule against "day 3, day 7, day 15 of delinquency" runs three to five days early. A subscriber who can show they paid inside the retry window has a straightforward answer to all of it.
The sturdier construction has three clauses. The day of the first return is not delinquency; the entry enters the retry queue. The delinquency start date is the day after the retry schedule is exhausted. Any grace period runs from the delinquency start date, not from the first return.
Two regulatory clocks run alongside and should be designed for rather than discovered. Under Regulation E at 12 CFR 1005.17, a consumer who asserts an error in an electronic fund transfer triggers an investigation duty with defined deadlines and provisional-credit timing; confirm the current text, because the timelines differ for new accounts. Separately, the Nacha WEB Debit Account Validation Rule requires validation of a consumer account the first time it is used for a WEB-originated debit. Both are reasons to treat bucket B as an authorisation problem rather than a collections problem.
There is also a ceiling on how hard you can push. Late fees and default charges that look punitive invite challenge, and in the United States the surrounding framework includes state usury caps, the FTC Holder Rule at 16 CFR Part 433 where a credit contract is involved, and the Fair Debt Collection Practices Act at 15 U.S.C. 1692g once an account is with a third-party collector. Whether each applies to a given device subscription depends on structure and on local law, which is a question for counsel, not for a billing script.
Take a fleet of 1,000 active subscriptions at USD 49 per month, presented on the first of the month. First presentment returns 62 entries, a 6.2 per cent first-return rate. Split by bucket: 38 in bucket A, 15 in bucket B, 9 in bucket C.
Approach one, no classification, three retries for everything. That generates 186 re-presentments, of which 45 from bucket B and 27 from bucket C are pointless, so 72 wasted attempts. Those 72 lift the month's failures from 62 to 134, a 13.4 per cent return rate. For context, the Nacha Operating Rules set return-rate thresholds for originating institutions, including an overall return rate and a materially lower unauthorized-return rate, with 0.5 per cent commonly cited for unauthorized debits; confirm the current figures with your ODFI, because exceeding them has consequences that have nothing to do with collections.
Approach two, classify first. Bucket A is re-presented on day one, day three and day five, recovering 26 of 38, a 68.4 per cent recovery rate. Bucket B gets a re-authorisation link and 9 of 15 repair within 48 hours. Bucket C is escalated with zero retries and recovers nothing by design. Final unresolved count is 27, a 2.7 per cent rate, with zero wasted attempts.
Approach three, classification plus a corrected delinquency date. Recovery is identical to approach two, but 12 of the 27 pay inside the grace period, so only 15 ever reach a collections workflow, a 44.4 per cent reduction in collections volume.
Now the cost side. A USD 1,399 device carried at an 8 per cent annual cost of capital is about USD 0.31 per day. One monthly payment arriving three days late costs about USD 0.92 in carry. Compare that with a bucket A return that is misread as delinquency and locked: if the subscription ends early, the unrecovered position is USD 1,399 less a USD 420 deposit less USD 147 collected across three payments, which is USD 832. The ratio is roughly 900 to one. That is the whole argument for classification in one line.
The first: a returned debit is not an event of default; the lessor will make up to three re-presentments within five days and the delinquency start date is the day after the third one fails. The second: where the subscriber changes the designated account and the stored authorisation ceases to be valid, the subscriber will complete re-authorisation within forty-eight hours of notice, failing which the account is treated as delinquent. Both sentences do the same job, which is to convert an internal workflow into a contractual one that survives a dispute.
LuckyMDM (Sichuan Starlight Network LLC) is a device asset management platform for rental and instalment operators, and its contribution here is narrow and specific: it cannot tell you why a payment failed, but it can carry the return code on the unit record next to enrolment state, so the queue that touches the device is filtered by bucket rather than by a single failed flag.
LuckyMDM writes the returned reason code onto the unit record alongside last-known check-in and enrolment state, and a bucket C return moves the unit into a manual-review queue rather than an automated lock queue.
First, export every returned entry from the last three months out of your processor's dashboard, tag each one to a bucket, and compute the three proportions. A healthy book is mostly bucket A. Bucket C above 2 per cent is not a collections problem, it is an underwriting or channel problem, and no amount of calling will fix it.
Second, sample ten returned entries and read the attempt log. Bucket A should show exactly three attempts at the scheduled times. Bucket B should show none, because retrying it is a configuration error. Bucket C should show none. Ten records will tell you whether the policy exists on paper or in production.
Third, open your own agreement and search for the term delinquency. If the only definition ties it to a failed payment, then everything you did during the retry window lacks a contractual basis. Fixing that one clause outranks any amount of message tuning.
Misconception one: a returned debit means the subscriber decided not to pay. In most books bucket A dominates, and bucket A subscribers have the highest completion rate inside the retry window. Treating them like bucket C means applying your most expensive and most damaging action to your best customers.
Misconception two: try again a few more times and it will clear. That is true only for bucket A. Bucket B returns the same code on attempt one hundred. Bucket C is worse than neutral, because the attempt count itself is an input to the risk models that watch your merchant profile.
Misconception three: watch the return rate as a single number. Watch its composition and its trend. A 6.2 per cent rate that is 5.8 points of bucket A is a cash-timing artefact. A 6.2 per cent rate with 4 points of bucket C rising month over month is a structural problem in the channel or the applicant mix. The two require opposite responses.
First boundary: the buckets, the codes and the timing here follow United States ACH practice. Card-on-file rails, SEPA in the euro area, Bacs in the United Kingdom and open-banking rails each use different reason codes, different re-presentation windows and different thresholds. Do not map this table onto them directly.
Second boundary: classification answers what to do first, not whether you are entitled to the money. Contract formation, interest and fee caps, disclosure duties and ownership on default are separate questions with separate tests. A clean bucket assignment does not make an unlawful collection step lawful. This is workflow hygiene, not a defence.
Yes, and you should, but send the right kind. A notice says the payment did not go through and will be attempted again on a named date. A collections demand asserts a breach. The first requires no delinquency; the second does. Writing a notice in the register of a demand is where a large share of avoidable disputes begin.
No rule fixes the number. It is a compromise between processor limits and subscriber tolerance: processors cap attempts on the same entry, density triggers risk review, and subscribers notice repeated attempts. Start from your processor's agreement, then tune against your own recovery rate by bucket. Do not copy another operator's number.
No. A stop payment tells you something happened at the bank. It does not tell you where the device is, and it does not tell you the subscriber has disappeared. The order is contact first, verify, then decide. Locking first converts a fixable account problem into a terminated subscription and a complaint.
Only if the agreement says so. A deposit exists to cover end-of-term exposure, and consuming it mid-term removes the cover you will need later. If you want the option, draft it as a specific clause: after two consecutive failed presentments, the lessor may apply the deposit to arrears and the subscriber shall restore it within a stated period.
Align it with the retry window. The schedule above finishes on day five, so three to five further days keeps total tolerance under ten. Beyond ten days, carrying cost and loss probability both move against you. Set the number from your own cost of capital and cohort quality rather than from someone else's template.
LuckyMDM is a brand of Sichuan Starlight Network LLC, focused on device asset management for the phone rental and instalment sector, covering device control, pre-lease risk screening and post-lease performance.