The Masav Returns File: Reading It Automatically and Updating Customer Debt

The Masav returns file consolidates the return notices received from every bank for debits that were not honoured, transmitted to the organisation as one uniform file - daily, or on several fixed dates each month. It carries the details of the original transaction that was returned and a coded reason for the return. Until it is read, the debt still looks paid in your system.

Why the debt does not reappear when a debit fails

Because in many systems "charge sent" is recorded as "collected". The moment the charges file is submitted the invoice is marked paid, and if the bank did not honour the debit, nothing goes back to correct it.

The result is familiar: a customer who stopped paying keeps receiving service for months, because on the books they are fine. Repairing that retroactively is hard work, because it means cross-checking months of submitted charges against what actually landed in the account. The daily habit that prevents the gap is described in the daily bank reconciliation process for a small business.

What the returns file actually carries

For each return the file identifies the original transaction that was returned and the reason for it. Three kinds of value your process needs to extract:

• The original transaction identifier - the reference you sent the charge with. It is the only matching key you can rely on.
• The coded return reason - what decides the next action, rather than merely recording that something failed.
• The charge details - amount and date, used to confirm the match is correct.

That is why the reference must be generated in your system, be unique, and be stored on the charge row. A reference regenerated on every run, or built from a customer number alone, makes automatic matching impossible.

What do you do with each type of return reason?

The correct response differs sharply between reasons. An automatic retry is right for some and actively harmful for others:

The simple rule: an automatic retry is allowed only when the reason is temporary in nature. Re-submitting a charge against a cancelled mandate produces another return and another cost, not money.

What a dependable ingestion process looks like

1. Collect. Pull the file from the secure channel it is transmitted through, on a fixed schedule.
2. Store raw. Keep the file exactly as received, before any parsing. That is what lets you investigate a dispute six months later.
3. Parse. Read records against the official returns specification, failing loudly on an unrecognised record rather than skipping it silently.
4. Match. Link each return to its charge row by reference. Anything unmatched goes to a manual queue.
5. Update. Clear the paid flag, reopen the debt, and write an event into the customer's history.
6. Respond. Apply the response rule for that return reason.

Step 2 is the one teams skip, and the only one that cannot be reconstructed after the fact.

Step 4 decides how much manual work survives. A good matcher returns exactly three outcomes: matched, not found, or more than one candidate. That third outcome is the clearest sign your reference is not genuinely unique, and it should be treated as a bug in the charges file rather than an edge case in ingestion. The manual queue should be a list with a stated reason per row, not a pile of files that failed to load.

How do you avoid double debt when a file is read twice?

Define a unique key per return - reference, return date and amount together - and enforce it as a database uniqueness constraint, not as a check in application code. Re-ingesting the same file then fails on the constraint instead of creating a second row.

This matters in practice because a repeat read happens in every one of these cases: a run that died halfway and was restarted, a file received twice, or a transmission that includes an overlapping period. A process assuming each file is read exactly once will create duplicate debts on the first day that assumption breaks.

What to measure once the process works

Once ingestion is automatic, the returns file becomes a measurement source rather than only an incident queue. Four metrics surface a problem before it becomes written-off debt:

• Return rate by reason, over time. A rise in insufficient funds tells a completely different story from a rise in cancelled mandates: the first points at customer distress, the second at churn.
• Age of the unmatched queue. Returns never linked to a charge row are debt that was never recorded. A growing queue means your reference key is not stable.
• Time from return to debt creation. If it is measured in days rather than hours, the problem is your collection frequency, not your code.
• Retry success rate by reason. This is the number that decides whether your retry rule earns its keep or merely generates fees.

Keep one operational metric alongside them: how many returns were handled manually. A figure that does not fall over time means the automation only covers the easy case.

What the customer should see

A return is a sensitive moment. The customer usually does not know the charge failed, and a generic "payment failed" message produces a support call instead of a resolution.

What works: a message stating the amount, the date of the failed charge, and the action required - and where the reason is a cancelled mandate or a closed account, a direct route to fixing it. The scheduling and follow-up of those messages is the same mechanism described in automating invoicing and payment reminders, and the collection side that produced the charge is covered in Masav direct debits versus card payments.

Sources

• Charge returns service - Masav
• File specifications and further information - Masav