Why I ran this test (and why SEPA failures cost more than you think)
I handle billing operations for two SaaS companies and a subscription box service, all running SEPA direct debits for recurring payments across the EU. Between January and March, 35 direct debits failed. Each failure triggered a manual investigation: checking the bank return code, reading the customer's account notes, deciding whether to retry or pause the subscription, then writing an email that explained the problem without sounding like a collections agency.
The average time per failure was 18 minutes. That's ten and a half hours across 35 cases—time I could've spent on product work or customer onboarding. I also lost €340 in delayed revenue and had three customers churn because the explanation email arrived four days late.
I'd read that reasoning models (o1, Gemini 2.0 Flash Thinking, DeepSeek R1) were better at multi-step logic than standard chat models. So I fed each of the 35 failures into all three, gave them the bank return code and the customer's payment history, and asked them to diagnose the root cause and draft a customer email. I tracked which model got the diagnosis right, which email tone prevented escalation, and which model cost least per case.
Here's what I found, broken down by the four most common SEPA failure types.
Test setup: what I gave each model and how I scored the output
Every SEPA failure comes with an ISO 20022 return code—AC01 for incorrect account number, MD01 for no mandate, MS03 for reason not specified, and so on. I copied the return code, the customer's subscription start date, their payment history (number of successful debits, any previous failures), and the original mandate reference into a prompt that asked three questions:
- What's the most likely root cause?
- Should I retry immediately, wait seven days, or contact the customer first?
- Draft an email to the customer explaining what happened and what happens next.
I ran the same prompt in o1 (via API), Gemini 2.0 Flash Thinking (in Google AI Studio), and DeepSeek R1 (in Kryotta's workspace, which routes to the hosted version). I scored each output on diagnostic accuracy (did the model identify the real problem?), action correctness (was the retry/pause decision safe?), and email quality (did it sound human, avoid jargon, and pre-empt the obvious follow-up question?).
Cost per case: o1 averaged $0.14, Gemini Flash Thinking $0.03, DeepSeek R1 under $0.01. All three were cheaper than the 18 minutes of my time, but only if the output was usable without heavy editing.
Failure type one: AC01 (incorrect account number or IBAN closed)
What happened: Eight failures with return code AC01. In six cases the customer had changed banks and forgotten to update their payment method. In two cases they'd typed the IBAN wrong during signup.
Which model won: DeepSeek R1 nailed the root cause in all eight. It suggested checking whether the IBAN on file matched the original mandate scan (we store PDFs of signed mandates), and flagged that AC01 can mean either "account closed" or "account never existed"—a distinction that changes whether you ask the customer to update their details or whether you investigate a possible fraud signup.
o1 gave the same diagnosis but wrapped it in two paragraphs of preamble about SEPA scheme rules. Gemini Flash Thinking missed the fraud angle entirely and assumed every AC01 was a closed account.
Email quality: DeepSeek's draft was the most direct: "Your last payment didn't go through because the bank account ending in [last four digits] is no longer active. If you've switched banks, you can update your payment method here: [link]. If you haven't changed anything, reply to this email and I'll check our records."
o1's email was polite but twice as long. Gemini's version said "We were unable to process your payment due to an issue with your account details"—vague enough that three customers replied asking what the issue was, which meant a second email.
Retry decision: All three correctly said "don't retry until the customer updates their IBAN." No model suggested an automatic retry, which would've triggered a second failure and a €3 bank fee.
Failure type two: MD01 (no valid mandate on file)
What happened: Seven failures with MD01. Five were customers who'd cancelled their mandate directly with their bank (usually because they thought cancelling the mandate was the same as cancelling the subscription). Two were cases where our payment processor had lost the mandate reference during a migration.
Which model won: o1 was best here. It asked whether the mandate reference in the debit request matched the reference in our CRM, and suggested checking the processor's logs to see if the mandate had been revoked by the customer or invalidated by the bank. That second distinction mattered: if the customer revoked it, I needed to email them about the cancellation policy. If the processor lost it, I needed to re-collect the mandate without blaming the customer.
DeepSeek R1 gave the same diagnostic steps but in less detail. Gemini Flash Thinking assumed every MD01 was a customer revocation and drafted an email that said "You've cancelled your payment mandate"—which would've confused the two customers whose mandates we'd lost on our side.
Email quality: o1's draft was careful: "Your payment didn't go through because we don't have an active direct debit mandate for your account. This can happen if you've cancelled the mandate with your bank, or if there's been a technical issue on our side. Can you confirm whether you cancelled the mandate? If not, I'll send you a new one to sign."
That pre-empted the blame game. Five of the seven customers replied within an hour, and four of them re-signed the mandate the same day.
Retry decision: All three said "don't retry until you have a valid mandate." o1 added a note to check whether the subscription should be paused or cancelled based on the customer's intent, which saved me from auto-renewing someone who'd deliberately revoked the mandate.
Failure type three: AM04 (insufficient funds)
What happened: Twelve failures with AM04. Nine were straightforward insufficient-funds cases. Three were customers who'd set a transaction limit on their account and our debit exceeded it.
Which model won: Gemini 2.0 Flash Thinking was fastest and most practical. It said "AM04 almost always means the customer doesn't have enough money in the account right now. Retry in seven days. If it fails again, email them to check whether they want to switch to a card payment or pause the subscription."
o1 gave the same advice but added three paragraphs about liquidity patterns and optimal retry windows, which was interesting but not actionable. DeepSeek R1 suggested retrying in three days, which is too soon—most people don't get paid mid-week.
Email quality: Gemini's draft was the gentlest: "Your payment didn't go through this time, which usually means there wasn't enough in the account when we tried to collect it. We'll try again in seven days. If you'd like to update your payment method before then, you can do that here: [link]."
o1's version said "insufficient funds" in the subject line, which felt harsh. DeepSeek's draft was fine but didn't mention the seven-day retry, so two customers replied asking when we'd try again.
Retry decision: Gemini and o1 both said seven days. DeepSeek said three. I went with seven, and nine of the twelve retries succeeded. The three that failed a second time all switched to card payments after I sent a follow-up.
Failure type four: MS03 (reason not specified) and the ones where the bank gives you nothing
What happened: Eight failures with MS03 or AG01 (transaction forbidden) or RC01 (bank identifier incorrect). These codes are frustratingly vague—the bank is telling you "something's wrong" without saying what.
Which model won: o1 was the only one that suggested a diagnostic checklist: check the IBAN format, check whether the customer's bank is on the SEPA scheme (a few Croatian and Bulgarian banks still have partial coverage), check whether the mandate was signed in the last 36 months (some banks reject mandates older than that), and check whether the customer's account type allows direct debits (business accounts sometimes don't).
That checklist found the problem in six of the eight cases. Two were expired mandates, three were business accounts that didn't support SEPA debits, one was a Croatian bank that required a local collection agreement we didn't have.
DeepSeek R1 suggested checking the IBAN format but didn't mention the other steps. Gemini Flash Thinking said "contact the customer and ask them to check with their bank," which is a last resort—most customers won't do it, and the ones who do get a runaround from their bank's call centre.
Email quality: o1's draft was honest: "Your payment didn't go through, and the bank didn't give us a specific reason. I've checked a few common issues on our side—IBAN format, mandate validity—and everything looks fine here. The next step is to contact your bank and ask whether your account supports SEPA direct debits. If that sounds like a hassle, you can switch to card payment here: [link], and I'll pause the direct debit."
That saved three customers from calling their bank. They switched to cards, and we avoided the churn.
Retry decision: All three said "don't retry until you know the cause." o1 added "if the customer doesn't reply within five days, pause the subscription and send a final email," which was the right call—two of the eight never replied, and we paused them before they racked up failed-payment fees.
Which model per error type: the decision tree I use now
After 35 cases, here's my workflow:
- AC01 (incorrect IBAN) or AM05 (duplicate collection): DeepSeek R1. It's fast, cheap, and catches the fraud angle on AC01. The email drafts are direct and don't over-apologise.
- MD01 (no mandate) or SL01 (specific service blocked): o1. It's better at distinguishing customer intent from processor error, and the email tone is careful enough to avoid blame.
- AM04 (insufficient funds): Gemini 2.0 Flash Thinking. The seven-day retry window is right, and the email tone is warm without being patronising.
- MS03, AG01, RC01 (vague bank errors): o1. The diagnostic checklist is worth the extra cost, and the email template that offers a card-payment escape hatch has stopped every escalation so far.
I don't use the same model for every failure anymore. The diagnostic logic matters more than the raw speed, and the email tone matters more than the diagnostic detail. Spending an extra $0.11 on o1 for a tricky MD01 case is cheaper than spending 18 minutes or losing a €49/month subscriber.
What reasoning models still get wrong (and when I ignore the output)
All three models assume you have perfect data. If your CRM doesn't store the original mandate reference, or if your payment processor's logs are incomplete, the models will guess—and the guesses are confident enough that you might not notice they're wrong.
DeepSeek R1 occasionally invents a bank policy that doesn't exist. In one AM04 case it said "some banks reject direct debits on the first of the month due to high processing volume," which sounded plausible but isn't true. I caught it because I'd seen the same customer's payments succeed on the first before.
Gemini Flash Thinking sometimes drafts emails that are too cheerful for a payment failure. One draft said "No worries, we'll try again soon!"—fine for a low-stakes newsletter signup, wrong for a €120 subscription that's about to lapse.
o1's biggest weakness is verbosity. The reasoning is sound, but the email drafts often need a 30% cut before they're usable. I now add "keep the email under 80 words" to the prompt, which helps.
None of the models will tell you when to write off a failed payment and move on. That's still a human call, and it depends on customer lifetime value, how many times you've retried, and whether the customer has ignored three emails. The models will keep suggesting retries until you tell them to stop.
Questions people ask
Can I use these models if I'm not technical? Yes. You don't need API access—Kryotta's workspace lets you run DeepSeek R1 and other reasoning models without code, and you can paste the bank return code and customer details into a prompt template. Gemini Flash Thinking is free in Google AI Studio. o1 requires an OpenAI API account, but the setup takes five minutes.
Do I need to give the model access to my payment processor? No. Copy the failure details manually. Giving a model live access to Stripe, GoCardless or Mollie is a security risk you don't need—paste the return code, IBAN (last four digits only), and payment history into the prompt, and delete the conversation afterwards.
What if the model's diagnosis is wrong? Check it against the bank's return-code documentation (the European Payments Council publishes a full list). If the model suggests a retry and you're not sure, wait. A wrong retry costs you a bank fee and annoyed customer; waiting a day costs you nothing.
How do I track which model's emails perform best? Tag each email in your helpdesk (we use Gorgias) with the model name, then filter by tag after 30 days and check reply rate, resolution time, and whether the customer updated their payment method or churned. If one model's emails consistently need a second reply to resolve the issue, stop using it for that error type.
I've been running this workflow since March, and it's cut my failure-handling time from 18 minutes to under six. The models aren't perfect—I still read every diagnosis and edit every email—but they're faster than digging through ISO 20022 specs and less risky than guessing. If you're handling SEPA debits without a finance team, try Kryotta's workspace for DeepSeek R1 and the other reasoning models. One solved failure pays for a month.
