How a direct debit mandate is collected, what has to be stored alongside the charge itself, what proves the mandate exists, and the procedure when a row comes back refused.
Key takeaways
- A mandate is documented consent, not merely a row in the billing system.
- What proves a mandate is its documentation - the setup route, the date, and what was shown to the customer.
- Mandates usually carry limits, and a business that does not store them next to the charge is working blind.
- A refusal is not only a technical fault; each return code calls for different handling.
- The mandate belongs to the customer - they can cancel it, and that must be a defined state in the system.
A direct debit mandate is the customer's consent for the business to charge their bank account the agreed amounts. Documenting it matters no less than having it: the moment a customer says they never authorised anything, what decides the matter is what you hold and when it was recorded.
The three ways a mandate comes into being
From the business's side the difference between routes is not only convenience - it decides what documentation stays in your hands:
| Route | Who sets it up | What you are left holding |
|---|---|---|
| Form at the bank | The customer, at their bank | A notice that a mandate exists, not the form |
| Digital setup through the bank | The customer, identified by the bank | A setup confirmation with an identifier |
| A form the business collects and forwards | The business | The signed form itself |
The third route leaves the fullest documentation and the greatest responsibility; the first two push identification to the bank but leave you holding only a confirmation. Which of them is open to you is settled during setup with the bank and Masav, so it belongs to the Masav onboarding stage and not to later.
What has to be stored alongside the charge
A common mistake is storing only the customer code and the amount. What is actually needed to answer a question from a customer or a bank:
- The mandate identifier or the reference it was opened under.
- The setup date, to the day at least.
- The route through which it was created.
- The limits set - amount ceiling, frequency, and an expiry if one was set.
- What exactly was shown to the customer at the moment of consent - which service, which amount, which frequency.
- The change history: every amount update, hold or cancellation, with its date.
The fifth item is the one that gets forgotten, and the only one that answers the question actually being asked. "The customer authorised a mandate" is not enough when they ask why they were charged an amount different from the one they remember; "the customer authorised a monthly subscription of X on this date" is an answer.
Mandate limits and what happens when you exceed them
A mandate can carry limits: an amount ceiling per charge, a frequency, and a validity period. They are not decoration - a charge exceeding them may simply not go through, and that surfaces only in the rejection report.
The operational problem is not the excess itself but that the business's system usually does not know about the limits. The amount rises after a plan upgrade, the charge is sent, and it is refused - and the customer is certain they paid. So the ceiling field belongs in the billing system itself, with a check before the file is built, not only in a document filed in a folder.
What to do when a row comes back refused
A refusal is not one event. There is a material difference between a closed account, insufficient funds, and a cancelled mandate - and each calls for a different action:
- Read the return code, not only the fact that the row was rejected.
- Classify it: a one-off problem, an account problem, or a cancelled mandate.
- Update the customer's state in the system according to that classification, immediately.
- Contact the customer on a channel they actually use, with what is needed from them.
- Decide on a retry - whether, and when, rather than automatically by default.
- Record what was done, so the next charge does not repeat the same mistake.
Step three is what prevents the real damage. A business that files a cancelled mandate as "a payment that did not come in" will keep sending charges to an account that will not accept them, accumulating rejections instead of opening a conversation. There is depth on updating customer state from the return file in return files and updating customer debt.
What you tell the customer at the request stage
Most billing disputes are not about whether a mandate exists but about what the customer understood they were agreeing to. So the wording of the request is part of the control rather than marketing copy: it has to say plainly what is charged, how often, and what changes when a plan changes.
The three sentences that save most enquiries are what the amount is, when in the month it leaves, and how to stop it. The last one sounds like handing the customer an exit and in practice it raises the consent rate - what deters people about a mandate is the sense that there is no way out, not the amount.
What is worth keeping from the request is the wording itself, not merely the fact that it was sent. When the wording changes - a price change, a plan change - keep a new version with a date, so it is possible to know what exactly was shown to a customer who signed up a year ago.
What happens when the customer cancels?
A customer can cancel a mandate at their own bank, and it happens without you knowing in advance. Operationally that means two things. First, cancellation has to be a represented state in the system - not "a failed charge" but a standalone state that stops further attempts. Second, cancelling a mandate is not the same as cancelling your service.
That gap is a source of arguments. A customer who cancels a mandate usually means to end the service too, but not always - sometimes they only switched banks. So the right response to a cancellation is an enquiry, not an automatic service stop and not continued charging on another channel without consent.
How long should the documentation be kept?
Retention is driven by two different systems: the accounting record-keeping requirements of the business, and the data minimisation rules in privacy law. Both are settled with the relevant professionals - the accountant and legal counsel - and are not a subject for an improvised policy.
What is purely operational: that a written decision exists, that it is identical for all customers, and that the system can actually carry it out. Mapping what is kept and where is covered in a personal data map for a small business.
Sources
Frequently asked questions
Is a customer's approval over the phone enough?
The question is not whether it is "enough" but what remains as documentation. A phone approval that is not recorded cannot be produced at any later stage, which is why businesses working that way send a written confirmation immediately after the call so that a document exists.
What is the difference between a cancelled mandate and a refused charge?
A refusal is the failure of a single charge, which may succeed on retry. A cancellation ends the mandate itself, and every future charge will fail until a new one is set up. A system that does not distinguish between them will keep trying in vain.
Can you raise the amount on an existing mandate?
It depends on the limits set on the mandate and on the route it was created through. Operationally, the safe rule is to check the stored ceiling before building the file, and to tell the customer about an amount change in advance - because a charge that differs from expectation is the most common reason for enquiries.
Where should mandates be stored?
In one place accessible to whoever handles collection, linked from the customer's record. An email folder is not a place - it cannot tell you whether a given customer has a valid mandate without a search, and that is precisely the question that gets asked.
Keep reading
Related service
Business Automation
I build custom automations that remove repetitive work end to end.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build and I'll tell you the fastest reliable way to ship it.