Skip to main content

The bank-details check: what it compares, and what it can't

How DocuBite notices a supplier's bank account changing on an invoice, local account numbers and IBANs alike, why it fails rather than warns, and where the check stops.

Paying a real invoice into the wrong account is the costliest mistake in accounts payable, and the hardest to undo. This check exists for one moment: when an invoice asks to be paid somewhere new.

What it compares

DocuBite reads the account an invoice asks to be paid into and compares it with the account on file for that supplier. Lesotho and South African invoices usually print a local account number and branch code, read as Payment account number and Payment branch code; suppliers abroad print an IBAN, read as Payment IBAN. Each is compared with its own kind on file. There are three outcomes.

  1. First sight. The supplier has no bank details on file yet. The check passes, says "First bank details on file for" the supplier, and remembers the account. The learning is recorded in the audit trail.
  2. Same account. The check passes: "Payment details match the supplier's bank details on file."
  3. Changed account. The check fails, naming both accounts, masked, and the next step: "Payment account changed for" the supplier, the account on file, the one this document gives, then "Verify with the supplier through a known channel before paying." A branch code counts as a change only when both the invoice and the details on file carry one.
In DocuBite: a changed bank account fails the check, naming both accounts and the next step. On Leribe Hardware & Supplies LH-3096, DocuBite shows: Bank details: Payment account changed for Leribe Hardware & Supplies: 9081…7713 on file, this document says 6203…0526. Verify with the supplier through a known channel before paying.

Why it fails instead of warning

Most checks warn: a VAT figure that looks off, an amount unusual for this supplier. A changed account fails, because the cost of being wrong is the whole payment. A failed bank-details check means the invoice can never go through touchless processing, whatever the company's other settings.

A changed account is never learned automatically. The check stays failed until a person updates the supplier's bank details on file, which is the point: someone has to have confirmed the change.

What you still do

DocuBite compares; it does not verify. It cannot know whether the new account is genuine. Confirm with the supplier through a channel you already had, such as a phone number from an earlier contract or a call to someone you know there, never the email that carried the invoice. Then update the supplier's details, and the invoice moves on.

Where it stops today

If a supplier is paid to an IBAN on file and an invoice gives a local account number instead, the check doesn't learn the new number beside it: it warns, so a person looks before anything on file changes.

The check only sees what the invoice prints. An instruction to change accounts that arrives by email, with no invoice, never reaches it.

Where it sits among the other checks

The bank-details check is one of the checks that run on every invoice before anyone approves it: duplicates, arithmetic, VAT, purchase-order lines, split invoices, a new supplier's red flags. Each says its reason at the field it concerns.

Every check DocuBite runs

Keep reading. More from the library.

Try it on one messy month.

For businesses and accounting firms in South Africa and Lesotho.

Add a month of supplier invoices and see every check, with its reason, before anything is approved or paid.

Questions first? Email support@docubite.com.

Held at the line, with the reason beside it.