← All guides

IBAN mod-97 check digits, explained simply

How the two check digits inside every IBAN work, why a single typo always gets caught, and how to verify an IBAN by hand or by tool — with a worked example.

Every IBAN carries a built-in lie detector. Two of its digits — the third and fourth characters — are not part of your account number at all. They are check digits, computed from all the other characters, and they let any bank verify in a fraction of a second that the IBAN was copied correctly. Type one digit wrong, swap two digits, drop a character: the check fails, and the bank knows the number is broken before it looks at anything else. This is why IBAN typos are one of the most common causes of rejected payment files, and also why they are the easiest cause to prevent. This guide explains the mod-97 check in plain language, works a real example all the way through, and shows what to do when the check fails.

What an IBAN is made of

An IBAN has up to 34 characters and three ingredients. The first two letters are the country code, such as DE for Germany or FR for France. The next two digits are the check digits — the stars of this guide. Everything after that is the national account number, called the BBAN, whose format each country defines for itself: bank codes, branch codes and account numbers in whatever order that country prefers. Because the BBAN differs by country, IBANs have a fixed length per country: 22 characters in Germany, 27 in France, 24 in Spain, 18 in the Netherlands, 15 in Norway. Length is the zeroth check, before any maths: a German IBAN with 21 or 23 characters is wrong, full stop, no calculator needed.

When people write an IBAN on paper, they group it in blocks of four characters to make it readable: DE75 5121 0800 1245 1261 99. In a payment file the spaces disappear and the IBAN is one continuous string. Most copying errors happen in the paper-to-system step, when someone reads those blocks aloud or retypes them into a supplier form. The check digits were designed for exactly that moment. The system that defined them, the ISO 13616 standard, uses the same mod-97 arithmetic that older national account systems used, scaled up to work for every country at once. If you validate payment files regularly, IBANs will be the check you meet most often — it is one of the core rules in our validation walkthrough.

The mod-97 trick, in plain words

Mod-97 means: divide a number by 97 and keep only the remainder. The IBAN check works like this. Move the first four characters (country code and check digits) to the end of the IBAN. Turn every letter into digits — A becomes 10, B becomes 11, and so on up to Z as 35. Now you have a very long number, sometimes more than 30 digits. Divide it by 97 and look at the remainder. For a correct IBAN, the remainder is always exactly 1. Not close to 1, not usually 1: exactly 1, every time, for every valid IBAN in the world. If the remainder is anything else, the IBAN contains an error. That is the whole test. Banks run it on every account number in every file, and it never gets tired or distracted.

Why 97? Because it is the largest prime number below 100, and dividing by a prime close to 100 gives the check two useful properties. First, the remainder carries two digits of information, matching the two check digit positions. Second, the maths catches the mistakes humans actually make: it detects every single-digit error and every swap of two neighbouring digits, which between them account for the overwhelming majority of typos. A simpler check, like adding the digits, would miss swaps. Mod-97 was chosen so that the errors people really type are the errors the check really catches. It is a small, elegant piece of defensive design, and it has quietly prevented billions of misdirected payments.

A worked example

Take the well-known German example IBAN DE75 5121 0800 1245 1261 99. Step one: move the first four characters, DE75, to the end, giving 512108001245126199DE75. Step two: convert the letters — D is the fourth letter, so it becomes 13; E is the fifth, so it becomes 14. The number string is now 512108001245126199131475. Step three: divide by 97. Nobody does this with pencil and paper in one go; you work through the digits in chunks, carrying the remainder forward, which is exactly what software does. The remainder of this division is 1. The IBAN is sound. If you change even one digit — say the account number’s final 9 becomes an 8 — the remainder jumps to something else entirely, and the check fails. There is no partial credit: the remainder is 1 or the IBAN is wrong.

Creating check digits uses the same machine in reverse. When a bank opens an account, it assembles the country code and BBAN with placeholder check digits of 00, runs the rearrangement and conversion, divides by 97, and subtracts the remainder from 98. The result is the two check digits, padded with a leading zero if needed. For our example, that calculation produces 75, which is why the example IBAN carries 75 in positions three and four. This also tells you something important about fixing errors: if an IBAN fails the check, the problem is almost never the check digits themselves. The check digits are computed by the bank’s own system. The problem is that some other character — in the bank code or the account number — was copied wrongly, and the honest check digits are reporting the crime.

What a failed check does — and does not — mean

A failed mod-97 check means the IBAN, as written, cannot be a real IBAN. Some character is wrong. It does not tell you which character, and it does not mean the intended account does not exist — it means the directions to the account are garbled. A passed check means the IBAN is internally consistent: right length, right shape, check digits match. It does not prove the account exists, that it belongs to the person you intend to pay, or that it is open. Existence and ownership are different questions, answered by other means such as confirmation-of-payee services where they exist. Treat mod-97 as a typo detector, not an identity check, and it will never disappoint you.

How to check IBANs without doing long division

In practice, nobody validates IBANs by hand, and nobody should: the arithmetic is long and the whole point of the check is that machines do it perfectly. What you need is a habit, not a skill. When a new supplier or employee account is entered, run the IBAN through a checker at entry time, not at payment time. When a payment file is exported, validate every IBAN in the file — debtor and creditors — as part of the pre-flight routine, because master data rots: banks merge, accounts migrate, and a number that was right last year can be wrong today. Our validator runs mod-97, country length and BBAN shape checks on every account in the file and names the exact payment that carries a bad IBAN; you can try it free on the home page. On paid plans the same check runs across batches of files at once — see pricing — which is how a month of supplier payments gets swept in seconds.

Where IBANs break in real organisations

Ask a room of finance staff where bad IBANs come from and they will blame typing, and they will be half right. The other half is plumbing. IBANs arrive by email and get copied out of a PDF, where a proportional font makes 1, l and I nearly twins and 0 and O identical. They are dictated over the phone. They are stored in a CRM field that silently truncates at 30 characters, two short of the longest IBANs. They are exported through a spreadsheet that helpfully reorders the groups of four. They survive a bank merger in which the beneficiary’s account was migrated to a new IBAN and only some of your records were updated. And they are printed on invoices in the paper format — groups of four with spaces — which a well-meaning colleague pastes into a system that counts the spaces as characters, inflating a 22-character German IBAN into a 27-character monster that fails the length check. None of these failures is carelessness in any useful sense; they are what happens when a precise string travels through tools designed for prose. The fix is systemic: capture IBANs electronically where you can, validate at the moment of entry, and re-validate in the payment file, because each hop is a fresh chance to break them.

A related trap deserves a name: the almost-IBAN. Some suppliers, especially outside the SEPA area or from older banking relationships, send a national account number and a BIC and expect you to construct the IBAN. For many countries the construction is deterministic — country code, computed check digits, then the national parts in a defined order — and bank websites offer converters. But converting by hand, or with a random web tool, and then never validating the result, manufactures risk: if any national part was itself copied wrong, the computed check digits will faithfully certify the wrong account, because they are computed from the error. A self-built IBAN that passes mod-97 proves only that it is consistent with its ingredients. Where the money matters, ask the beneficiary for the IBAN as issued by their bank, in writing, and file it. The check digits then go back to their proper job: proving that what you received is what you stored.

One last distinction completes the picture: the debtor IBAN deserves the same care as the creditors’. Teams obsess over supplier IBANs and forget that the file also names the account being debited — their own. A wrong debtor IBAN usually fails instantly and loudly, which is a mercy, but a subtler failure exists: the file names a real company account that is not the account the bank expects for this channel or mandate, and the rejection speaks of permissions rather than numbers. Keep the debtor account details in the same master-data discipline as everything else in this guide: captured from the bank’s own documents, validated on entry, and re-validated in every exported file, because the one account in the file you are most sure of is the one nobody ever checks.

And when a check fails an hour before a deadline, resist the two tempting shortcuts. Do not adjust the check digits until the number passes: that manufactures a formally valid IBAN that points at a wrong or nonexistent account, converting a safe rejection into a dangerous misdirected payment. And do not drop the payment and forget it: the supplier still needs paying, and the bad IBAN is still sitting in your master data waiting for the next run. Get the correct IBAN from the beneficiary, in writing, fix the record, and note the incident. Mod-97 is the cheapest fraud and error control in the whole payment chain — two digits, doing their job, as long as nobody overrides them.