IBAN Validator: Check Any IBAN Number Free | Cash Book

This validator runs entirely in your browser: the IBAN you type is never uploaded, never stored and never sent anywhere, and the page keeps working with the connection off. It does three things in order. It reads the first two letters as a country code and looks that country up. It compares the total length against the length that country registered. Then it runs the mod-97 calculation defined in ISO 13616, the arithmetic that the two digits after the country code exist to satisfy. If all three pass, the number is well formed.

That is a smaller claim than most people want it to be. A well-formed IBAN is not a confirmed account, a confirmed recipient or a confirmed payment. The rest of this page is about that gap, because the gap is where money goes missing.

A note on the input field, since it caused most of the work. People paste from PDFs, and PDFs hand over things that look like nothing: non-breaking spaces, soft hyphens, zero-width characters between the groups of four. The field strips all of it before the country code is even read, which is why an IBAN that failed on some other site may pass here without you changing a thing. Nothing was fixed. It was only ever the invisible characters.

How to use it

1. Paste the number exactly as you received it. Spaces, lower case, dots and the odd line break all get stripped before anything is checked, so there is no need to tidy it up first. Paste rather than retype wherever you can, because retyping is the step that introduces the very error you came here to find.
2. Read the verdict. Valid means the country code is in the registry, the length matches that country, and the mod-97 remainder is 1. Not valid means one of those three failed, and the note says which. A failed length and a failed checksum are different problems with different fixes.
3. Then read the breakdown, not just the verdict. The table shows the IBAN regrouped in blocks of four, the country in full, the two check digits, the account part and the length. Compare the country against the country you were expecting. An invoice that should be paid to a supplier in Portugal and produces a valid IBAN in Cyprus is worth a phone call.
4. If something failed, fix what the note points at. A length error is nearly always a missing or duplicated character, usually at the end where a long string is easy to truncate. A checksum error is nearly always one character read wrong or two swapped. Either way, re-read the source document. Do not guess at the digit.
5. Verify the name separately. The checker has no idea whose account this is. Before money moves, confirm the account holder's name with the payee through a channel you chose yourself, and use your bank's own payee verification screen if it offers one.

What the check actually proves

An IBAN is defined by ISO 13616. The structure is fixed: two letters for the country, two check digits, then the domestic account number, called the BBAN, padded and formatted to a length that each country registered once. The maximum total is 34 characters.

The two check digits are not part of the account number. They are a checksum computed from everything else, using the mod-97-10 scheme from ISO 7064. The calculation is short enough to do by hand:

1. Move the first four characters, country code and check digits, to the end of the string.
2. Replace every letter with a number, where A is 10, B is 11, and so on up to Z as 35.
3. Treat the result as one long decimal integer and take the remainder after dividing by 97.
4. The remainder must be 1.

When the account was created, the bank picked the two check digits that make step four come out at 1. So a remainder of 1 means the check digits still agree with the country code and the account part. If any character has changed since, the remainder changes with it.

This is a good error detector. Every single mistyped character and every swap of two adjacent digits shifts the remainder away from 1, which is the whole reason mod-97 was chosen over a simpler scheme. What it cannot do is look outside the string. The checker does not know whether the bank code inside the BBAN belongs to a real bank, whether the account is open, whether it is in credit, whether it accepts euro transfers, or who owns it.

So the honest reading of a green result is narrow. It proves the number is internally consistent, which means it was probably transcribed correctly. It does not prove the account exists, does not prove it belongs to the person or company named on the invoice, and does not prove a payment will arrive. Those are three separate questions, and none of them can be answered by arithmetic on the number itself.

Where the check stops working

Start with the limit people get wrong most often: fraudsters use valid IBANs. Invoice fraud, where a supplier's real invoice is intercepted and the bank details swapped, does not depend on a broken number. The account in the fake invoice is a real account, opened for the purpose or borrowed from a money mule, and it validates perfectly on this page. Think about it from the other side. A criminal has no reason to send you a number that fails a checksum anyone can run in a browser. So treat a green result as evidence about typing accuracy and nothing more. Payment details that changed since the last invoice deserve a call to a number you already had, never the number printed in the email.

The layer this page cannot provide is name checking, and that gap is being closed in regulation rather than in arithmetic. Under Regulation (EU) 2024/886, the instant payments regulation, payment service providers offering credit transfers in euro must offer a verification of payee service: before you confirm, the bank compares the name you entered against the name on the account behind the IBAN and tells you whether it matches, closely matches or does not match at all. The obligation was phased in through 2025 for providers in the euro area, with later dates elsewhere, and similar services have run in the Netherlands and the United Kingdom for years. If your bank shows you that warning, it knows something this page cannot. Let it win the argument.

Then there are the typos that pass anyway. Mod-97 catches every single-character error, but it is a 97-way check, so roughly one random multi-character corruption in 97 lands back on a remainder of 1. More common in practice: two different real accounts one character apart, both valid. The German test number DE89 3704 0044 0532 0130 00 validates, and so does DE89 3704 0044 0532 0100 90, which differs inside the last four characters. Nothing here could tell you which of those you meant. Several countries add their own check digits inside the account part, which catches more, but this validator does not implement the national rules and does not pretend to.

Lengths are their own small trap. Because each country wrapped its existing domestic format, the totals run from 15 characters in Norway to 31 in Malta and 32 in Saint Lucia. A number copied one character short is often still a plausible IBAN for some other country, and a number that is the right length for its own country tells you nothing about the country you were expecting. The registry also gains members, which is why a code the checker does not recognise is reported as unknown rather than wrong.

Plenty of places never adopted IBANs at all. The United States, Canada, Australia, Japan and many others route payments with domestic account numbers and a BIC, so an unknown country code usually means the thing you pasted is not an IBAN.

One last non-problem: the spaces. Groups of four are a printing convention for humans, not stored, not transmitted, not part of the number. Neither is lower case. If a payment form rejects something that validates here, suspect the form's own field rules first.

Five numbers, checked

The German test number is the one to do by hand, at least once. Take DE89 3704 0044 0532 0130 00 and strip the spaces to get DE89370400440532013000, which is 22 characters, the registered length for Germany.

Move the first four characters to the end: 370400440532013000DE89. Replace the letters: D is 13, E is 14, so the string becomes 370400440532013000131489.

That number is too long for most calculators, so take it in pieces, carrying the remainder forward. First nine digits, 370400440, divided by 97, leaves 23. Put that in front of the next seven digits to get 235320130, which leaves 70. Carry on: 700013148 leaves 38, and the last piece, 389, leaves 1. The remainder is 1, so the check digits 89 are correct for this account.

Now change one character. Turn the last 0 into a 1, giving DE89370400440532013001. The length is still 22 and the country is still known, so the first two tests pass. Run the arithmetic again and the remainder comes out at 28 instead of 1, so the result is Not valid with a checksum error. One wrong digit, always caught. That is exactly what mod-97 was chosen for.

Length failures look different. Paste NO93 8601 1117 947 and the checker reports 15 characters and a valid number, because 15 is precisely what Norway registered. Add a digit to the end and the length test fails before the arithmetic even runs, with a note naming Norway and the expected 15. The table still shows the country and the expected length, so you can count what is missing.

The case worth memorising is the fourth. DE89 3704 0044 0532 0130 00 and DE89 3704 0044 0532 0100 90 both come back Valid. The checker is a spell-checker for numbers, and a correctly spelled wrong word sails through a spell-checker.

One more. GB33 BUKB 2020 1555 5555 55 validates as a United Kingdom IBAN, 22 characters, BUKB as the bank identifier. If you were expecting an Irish supplier, the number is well formed and still wrong. Read the country row, every time.

What each part of an IBAN means

Take the breakdown table apart from left to right.

The first two characters are the country code, two letters from ISO 3166-1. They identify the country of the account, not the currency and not the nationality of the holder. That code fixes the expected length and tells the routing system which national format comes next.

Characters three and four are the check digits. Always digits, never letters. They belong to the IBAN rather than to the account, which is why the domestic account number on your bank statement does not contain them. Their only job is the mod-97 test above.

Everything from character five onwards is the BBAN, the basic bank account number in its national format, padded to a fixed length with zeros where the domestic number is shorter. Its internal layout changes from country to country, and the two things worth knowing about live inside it.

The first is the bank identifier at the front. In Germany that is the eight-digit Bankleitzahl, so 37040044 in the example above is Commerzbank in Cologne. In the United Kingdom it is four letters, BUKB, followed by the six-digit sort code. In France it is a five-digit bank code and a five-digit branch code. This validator checks none of them against any bank list.

The second is the national check digits several countries keep inside the BBAN: the two-digit clé RIB in France, the CIN in Italy, the last two digits of a Spanish account number. Those catch errors the IBAN-level check misses. Each one is a different algorithm, though, so a general validator that skips them will happily accept a number a domestic system would throw out.

One consequence is worth spelling out: an IBAN is not a secret. It appears on every invoice its owner issues. Knowing one lets someone send money to that account, not take money from it. Direct debits are a different mechanism with their own authorisation and refund rules, so treat an IBAN as you would a postal address rather than as a credential. More on the vocabulary in the IBAN and SEPA glossary entries.

What this has to do with tracking money

An IBAN identifies an account at a bank. Cash Book tracks what happens to your money, on the phone, and the two never meet.

Cash Book never connects to a bank. There is no bank sync, no aggregator, no IBAN field and no place to enter a bank credential of any kind. Transactions live on the iPhone, with optional sync to your own iCloud account, and the app needs no sign-up and no email address. That rules out a category of features some apps have, and it also rules out the risk that comes with them.

What it does have is Accounts: cash, cards and savings, each with its own balance, transfers between them, and one net-worth number across all of them on the Accounts screen. The account you would pay an IBAN from is represented there as a name and a balance you keep true, which is enough for budgeting and carries none of the bank's data. Insights then shows where the month went, by tag and against last month.

Keeping those balances true is a logging problem, which is the part the app is built around. A transfer typed on the keypad takes three taps, and voice logging handles the rest of the day in one sentence. If most of your outgoing money is bank transfers rather than card taps, how to track expenses on iPhone covers the routine, how to track cash spending covers the part no bank sees at all, and how to track subscriptions and recurring bills is for the standing orders that leave the same account every month.

Nothing here is advice about a specific payment. If you are deciding whether to send a large or unusual transfer, or you think you have already sent one to the wrong account, your bank's fraud line and a qualified adviser are the right people to talk to, and speed matters more than certainty.

The other tools

The VAT calculator handles the number on the same invoice as the IBAN. The bill split calculator divides a payment several people owe before one of them makes the transfer. The net worth calculator adds up the accounts those IBANs point at, and the savings goal calculator turns one of those balances into a date.

Where to go next

Paste the IBAN, read the country row rather than only the verdict, and then do the thing the arithmetic cannot do: confirm the name with the payee through a channel you picked. The checksum is a filter for mistakes. Everything after it is a filter for people, and that one still runs on your own attention.

Get Cash Book on the App StoreFree for 7 days. $19.99 once for lifetime.

Get Cash Book on the App StoreFree for 7 days. $19.99 once for lifetime.