01 — Why it matters
The one error the bank will never catch for you
Most mistakes in a payment file are caught by somebody. A malformed file is rejected at upload. A control sum that does not add up is rejected before anything moves. Those are annoying, and they are safe.
Paying the same invoice twice is neither. In the file, the second payment looks exactly like the first one: valid IBAN, valid amount, valid structure. The bank has no reason to refuse it, so it does not. You find out when the supplier mentions it, or when somebody reconciles the account — and getting the money back depends on their goodwill.
It happens the ordinary way: a batch exported twice, a payment added by hand while the original was still in the run, an approval loop that produced two files. Nothing dramatic, which is exactly why nobody is looking for it.
02 — And the expensive typo
An IBAN carries its own check digit
Characters three and four of an IBAN are a checksum over the rest of it (ISO 13616, mod 97-10). One wrong digit anywhere in the number and the arithmetic stops working — which means a typo can be caught here, offline, with no lookup and nobody asked.
If the number happens to be wrong and valid, the money reaches a real account that is not your supplier's. If it is wrong and invalid, the payment bounces days later and the invoice quietly goes overdue. Both are worth two seconds of arithmetic.
What is checked
- IBAN check digits, on both the debtor account and every creditor account.
- Control sum and transaction count, at file level and per batch — recomputed from the transactions rather than trusted. A file whose header disagrees with its contents is rejected by the bank as a whole.
- The same payment twice: same creditor IBAN, same amount, same remittance information. Reported as a warning, not a verdict — two identical invoices from one supplier on one day do exist, and only you know which case this is.
- Duplicate end-to-end identifiers, which have to be unique and which banks use to recognise a resubmitted batch.
- Characters SEPA does not carry. The permitted set is narrow: letters, digits,
space, and
/ - ? : ( ) . , ' +. Anö, anéor a Chinese character in a creditor name is either rejected or silently rewritten — and the silent rewrite is worse, because the money moves and the name no longer matches anything. - Amounts that are negative, zero, or carry more than two decimals.
- An execution date in the past, which different banks handle differently and none of them handle the way you meant.
What is deliberately not checked: whether your bank has extra requirements of its own — those differ per bank and guessing would produce false alarms — and whether a payment should be made at all, which is a person's judgement, not a file's.
The one this browser can answer and the file cannot
A duplicate inside one file is visible by opening the file. The expensive one is across months: a payment that already went out in August turns up again in the September run. Both files are clean on their own, and the bank has no reason to refuse either of them.
So every file checked here leaves a trace on this machine, and the next one is compared against it: the same IBAN, amount and remittance were already in a file checked here on 14 August. It is a warning, not a verdict — a monthly invoice of the same amount to the same supplier is a perfectly normal thing.
What is stored is a fingerprint, not a supplier list. The account number, the amount and the reference are hashed together into sixteen characters; the originals are not written anywhere. A payment file holds every supplier a company has and what it pays them — that is not something to leave lying in browser storage. It also never leaves this machine, so a different computer will not know about last month's run.
Drop the invoices in as well
Everything above is the file checking itself: does the header match the contents, do the check digits add up, is anything in here twice. There is one question the file cannot answer on its own — is this the amount the invoice actually asks for?
An extra zero typed into an ERP produces a perfectly valid payment. 12,000 and 1,200 are both well-formed amounts, both pass every format check, and the bank carries out whichever one is in the file. It surfaces when someone reconciles the account, by which time the money is sitting in somebody else's account.
So drop the invoices in along with the payment file. Payments are matched to invoices by
the invoice number written in the remittance — which is how the other side clears
it too — and the amounts are held against each other. Separators do not matter:
RE-2026/0417 and RE20260417 are the same number.
Rather than risk matching the wrong pair, it declines to match: invoice numbers shorter than five characters are skipped (they hit inside any text), and a remittance that names two invoices is left alone. Different currencies are reported as such rather than converted — guessing an exchange rate to accuse someone of an error is not a trade worth making.
Collecting, not paying
A direct debit run (pain.008) goes through the same checks, because the same things go wrong in it — only the person who suffers changes. A wrong IBAN means that collection comes back days later while the invoice has already gone out. And charging the same customer twice is not simply one amount too many: it is a complaint, a chargeback, and under SEPA the customer can demand the money back for eight weeks with no reason given. The money goes back. The bank's fee does not.
Two things are deliberately not judged here: the mandate dates, and whether the sequence type (FRST / RCUR / FNAL) is the right one. Both depend on whether this customer has been charged before, and that is not in the file. Saying nothing beats guessing.
Nothing is uploaded
A payment run contains every supplier you have, what you pay them, and their account numbers. That is not a file to hand to a web form. It is read in the browser: open the developer tools, the Network tab, and drop a file in — no request goes out. Or load the page, disconnect the network, and drop the file anyway. It still works.
The same is true of the rest of this site: reading invoices into a spreadsheet, checking one invoice against EN 16931, and the full list of rules.