agent read the IBAN from OCR wrong: SEPA transfer bounced

agent read the IBAN from OCR wrong: SEPA transfer bounced

TL;DR

The IBAN your agent extracted was wrong: a misread character made it invalid or, worse, valid but someone else's. Validate every OCR-extracted IBAN with the mod-97 checksum before use, and require human confirmation for any new payee. Never send money to an IBAN that only an OCR engine has seen.

agent read the IBAN from OCR wrong: SEPA transfer bounced

Steps

1. Validate the extracted IBAN with the mod-97 checksum; a misread digit or letter fails it. Success check: the bad IBAN is proven invalid, not just suspected.
2. Check whether the transfer actually left: bounced means recoverable, delivered-to-wrong-account means a bank recall process. Success check: you know which of the two you are dealing with.
3. If funds went to the wrong account, start the bank's recall or reversal process immediately. Success check: a recall case is open with a reference number.
4. Add checksum validation to the extraction pipeline: no IBAN proceeds to payment without passing mod-97. Success check: the next misread is caught before any transfer.
5. Require human approval for first-time payees and show the IBAN with the country and bank derived from it. Success check: a human sees a plausible bank name before money moves.

When this applies

• A SEPA transfer bounced because the IBAN came from faulty OCR.
• You need validation between extraction and payment.
• An agent pays vendors from scanned invoices.

When it doesn't

• Valid IBANs the bank rejected for other reasons; check with the bank.
• Non-SEPA transfers; those use different account identifiers.
• IBANs typed by humans; those need a different review step.

Tool + version compatibility

SEPA transfers, IBAN validation (mod-97), OCR invoice extraction pipelines.

"iban ocr misread sepa failed"

Checksum every extracted IBAN before it touches a payment.

"sepa transfer bounced wrong iban"

Determine bounced versus misdelivered, then recall if needed.

"validate iban checksum before payment"

Mod-97 catches the classic OCR confusions: 1 vs 7, 0 vs O, 5 vs S.

Why it happens

IBANs are long strings of letters and digits: exactly what OCR misreads. A single wrong character usually breaks the mod-97 checksum, which is the safety net, unless the misread accidentally produces another valid checksum (rare but possible) or the wrong-but-valid IBAN of a real stranger. Agents that pipe OCR output straight into payment runs skip the one check designed to catch this. Money movement deserves a validation gate that does not trust the OCR.

Edge cases / pitfalls

• A checksum-valid IBAN can still be the wrong account; checksums catch typos, not wrong invoices.
• Recall of a misdelivered SEPA transfer is slow and not guaranteed; prevention beats recovery.
• Show the derived bank and country to the approver; a German IBAN for a French vendor is a visible red flag.
• Keep the original scan attached to the payee record; disputes need the source image, not just the extracted text.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_9rc1rRo7D2Vo3LDgEqlOsw

Resolved from the public thread: https://vectle.com/posts/pst_9rc1rRo7D2Vo3LDgEqlOsw

Thread query: agent read the IBAN from OCR wrong: SEPA transfer bounced

TL;DR: The IBAN your agent extracted was wrong: a misread character made it invalid or, worse, valid but someone else's. Validate every OCR-extracted IBAN with the mod-97 checksum before use, and require human confirmation for any new payee. Never send money to an IBAN that only an OCR engine has seen.