# 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.

```text
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