Check IBAN: a guide to manual and automated checking
2026-07-16
When you are checking a payment list, standing just before the export to the bank format, and suddenly several records report “invalid IBAN”, you are in a typical situation. The error almost never surfaces during typing. It surfaces when the remittance needs to go out, approvals have already been obtained, and no one has time left for rework.
That is exactly when IBAN checking turns from an annoying formality into an operational issue. Anyone who checks IBANs only at the last step produces follow-up questions, delays and unnecessary loops between accounting, purchasing, sales and sometimes the tax office too.
Introduction to the importance of IBAN checking
In finance teams, the same error happens again and again. Master data is taken from emails, PDFs, Excel lists or old ERP screens. The IBAN looks plausible at first glance, so it is saved. Only at the point of payment does it turn out that a character is missing, the country code does not fit, or the check digit is formally wrong.

Since 1 February 2014, the IBAN has been the official and exclusively permitted standard for payment instructions in the SEPA area in Germany. The German IBAN consists of 22 characters and, for electronic transfers and direct debits, replaces the former combination of account number and bank code. Banks can automatically reject German SEPA transactions in the absence of a valid IBAN, which triggers direct additional effort and delayed payment flows for companies, as the IBAN calculator from Vercalc summarizes for German SEPA logic.
Where teams fail in practice
The real difficulty is rarely mathematics. What is problematic are handovers between systems and people:
- Copy-paste from documents leads to hidden spaces or transposed characters.
- Legacy stock from old systems often still contains logic based on account number and bank code.
- Manual entry under time pressure produces formal errors that only become visible shortly before submission.
- Missing upfront checking shifts the error from the master data process into the payment process. There it is more expensive.
Practical rule: IBANs should be checked at capture, not only at export to the bank.
Anyone who sets up their processes cleanly saves above all returns and rework. A good complement is a clearly defined bank account verification process in the payment workflow, so that entry, checking and approval do not get stuck in different corners of the organization.
Understanding the IBAN structure
Anyone who wants to check a German IBAN should know its structure by heart. Not theoretically, but well enough that inconsistencies stand out just from reading. For Germany, the structure is fixed: 2 letters for the country code, 2 digits for the check number, 8 digits for the bank code, and 10 digits for the account number. That is exactly how the Germany calculator on the composition of the German IBAN describes it.

The four building blocks
| Component | Meaning | What to watch for |
|---|---|---|
| DE | Country code for Germany | If the code is wrong, the structure is already questionable for German payments |
| Check digits | Formal safeguarding of the string | Do not guess, but calculate or validate |
| BLZ with 8 digits | Assignment to the credit institution | Must be numeric and complete |
| Account number with 10 digits | Individual account | Shorter numbers are padded with leading zeros |
That last position often leads to misunderstandings. Many historical account numbers had fewer digits. For IBAN formation in Germany, they are padded to exactly 10 digits. Anyone unaware of this logic sometimes mistakenly considers a correctly padded IBAN to be wrong.
What the check digit really does
The formal IBAN check in Germany follows the international mod-97 method. The first four characters are moved to the end, letters are converted to numbers, that is A=10 to Z=35, and the remainder of the division by 97 must be 1. For a German IBAN, the fixed length of 22 characters is checked at the same time, as the German IBAN checker from Kalcify explains.
A formally valid IBAN is cleanly structured. This step says nothing more than that, at first.
Anomalies you can spot immediately
If you see a lot of master data in daily life, a quick visual check is worthwhile before any deeper IBAN check:
- Strings that are too short or too long are an immediate warning sign for German IBANs.
- Mixed formats of old account-number logic and modern IBAN entry frequently appear in Excel lists.
- Non-numeric positions in the bank or account part should be checked.
- Unusual separators often arise when exporting from third-party systems.
Anyone who internalizes this structure no longer needs a validator for many errors, but recognizes them at first glance.
Manual checking with the mod-97 method
Manual IBAN checking is not for every payment run. But it is the best way to understand why a tool reports “valid” or “invalid”. For spot checks, troubleshooting and conversations with IT or the bank, it is very useful.
As an example, let’s take DE44500105175407324931.

Step sequence without a tool
-
Clean up the IBAN Remove spaces and special characters. For the check, you need a continuous string.
-
Move the first four characters to the end
DE44500105175407324931becomes the sequence with the remainder first andDE44at the end. -
Convert letters to numbers D becomes 13, E becomes 14. This mapping is standard.
-
Check the resulting number modulo 97 The result is formally correct if the remainder is 1.
-
Consider plausibility separately Even if the check digit fits, the structure and origin of the data should be examined further.
For illustration, a video explanation is embedded here:
Where calculation errors often happen
It is not the formula that is the problem, but the preparation. To calculate the check number in Germany, the account number must be padded to exactly 10 digits if it is originally shorter. The bank code always comprises 8 digits, as the guide to the German IBAN check digit at IBANTest describes.
In practice, errors usually arise at these points:
- Leading zeros are missing in the account number.
- Letter substitution is transposed or noted incompletely.
- A long digit sequence is transferred incorrectly when intermediate steps are not documented.
- The result is over-interpreted. Mod-97 confirms formality, not account existence.
A clean manual way of working
I always recommend a small check note with three lines for manual checking:
| Note field | Content |
|---|---|
| Original value | Submitted IBAN without change |
| Cleaned value | IBAN without spaces and formatting characters |
| Calculation step | Shifted string and letter substitution |
If you do not note the calculation path traceably, an error can hardly be cleanly clarified later.
For individual problems, this method is strong. For lists from ERP, CRM or Excel, it is too slow. That is exactly where online validators, batch checks and APIs begin to show their value.
Using online tools and API solutions
Manual checking helps understanding. In day-to-day business, however, what counts is speed, repeatability and clean logging. That is why I always look at IBAN checking on three levels: individual checking in the browser, batch checking for files, and API integration for systems.

An important trend is the growing expectation of API and mass validation instead of individual checking. Some IBAN checkers already offer API access or bulk validation, as the FAQ from IBAN.com on API and bulk validation shows. This fits the reality in finance departments. Hardly anyone checks just one IBAN. Usually it is about master data lists, supplier imports or remittances from Excel.
Which web tools I find useful for individual checks
When it comes to a single record, browser tools are often enough. What matters is not only the result, but also whether the tool explains the structure in a traceable way.
For a quick individual check, I would rely above all on traceable validators, such as:
- Kalcify for a clear explanation of the mod-97 process
- MDLE for the structure-related view of length, country code and check digit
- de.iban.com when API and bulk topics are additionally relevant
If you just want to quickly check whether a single entry is formally correct, the IBAN validator is often enough.
When batch validation is the better choice
As soon as Excel or CSV files are involved, no one should work by browser line anymore. Then it is about repeatability and about recognizing error types in aggregate.
Batch procedures make sense for:
- Supplier migrations from an old ERP
- Stock clean-ups before a large SEPA file
- Regular imports from CRM, shop system or payroll software
- Check logs for internal approvals
A practical difference is the question of whether the result delivers only “valid/invalid” or also cleanly marks the faulty record. For operational teams, the second variant is significantly more valuable.
API instead of manual work
APIs are worthwhile when IBANs are to be checked already at data entry. That is the cleanest point in the process, because errors do not only surface in the payment module.
Here is a brief comparison:
| Method | Well suited for | Weakness |
|---|---|---|
| Online tool | Individual checks | Not scalable |
| Batch validation | Excel and CSV lists | Usually a separate work step |
| API | ERP, forms, portals, workflows | Needs technical integration |
Among the available services, GenerateSEPA is also worth a look. The service can convert Excel, CSV, JSON and older AEB formats into SEPA XML and includes IBAN validations in the process. For technical teams, a JSON API is additionally available, which is useful above all for recurring imports or automated payment pipelines.
For finance teams, a simple selection rule applies: browser for individual cases, batch for clean-up, API for permanent process control.
In terms of content, the market clearly shows where practice is heading. Away from individual screens, toward validation where data is created or processed in aggregate.
SEPA specifics and typical sources of error
Many guides on IBAN checking end at the check digit. That is not enough in daily life. In the SEPA context, payments often fail on things that seem formally small but become operationally expensive.
For German payment data, the practical source of error is less the calculation rule than the structure validation. Besides the check-digit check, the IBAN must match the national length and the country code. A single wrong character already makes the IBAN formally invalid, as the technical description of a German IBAN validator at MDLE explains.
What is often overlooked in German SEPA practice
An important point is left out of many search results. In Germany, since 1 February 2017, the IBAN alone is enough for SEPA transfers; the BIC is no longer required. At the same time, a clean distinction is often not made between format checking and real account checking, as the consumer advice center on the Europe-wide SEPA rules explains.
This is decisive in practice:
- Formal validity means the IBAN is correctly structured.
- Account existence is not confirmed by this.
- Payability additionally depends on whether the target account really exists and is usable.
Typical errors I see again and again in lists
Not every error needs a mathematical analysis. Many fail already at data hygiene.
-
Wrong country code Especially with international suppliers, a foreign IBAN is wrongly processed as a German one or vice versa.
-
Shortened or lengthened entries Export errors, truncated fields and wrong cell formats destroy the fixed structure.
-
Spaces and special characters People read better with them. Systems often do not.
-
Legacy data from AEB or old formats Old stock does not automatically fit into current SEPA processes.
Anyone who looks only at “check digit correct” often overlooks the actual error in the data flow.
Do not ignore data protection and public-authority processes
As soon as IBANs are stored, transmitted or changed, it is not only about technology, but also about data protection and responsibilities. Anyone documenting internal policies for processing such data can orient themselves on well-prepared examples, such as Find Your Seat’s privacy policy, to understand how payment and personal data can be described transparently.
For Germany, there is also an often-overlooked special case in the public-authority context. The Federal Central Tax Office (BZSt) names concrete ways in which an IBAN can be transmitted, changed or deleted. Transmission is done via the bank, the BZSt IBAN+ app or the ELSTER portal, not in writing or by phone. Changes run via renewed transmission, and for deletion there is a separate online process, as the BZSt notes on IBAN transmission and deletion set out.
At first glance, this seems far from IBAN checking. But for the self-employed, payroll offices and tax advisors, it is part of the same data quality. A formally correct IBAN helps little if it is stuck in the wrong authority process or stored in an outdated form.
Best practices for finance teams and conclusion
Finance teams do not need a theoretically perfect check routine. They need a workflow that holds up in daily life. The most effective approach combines early data-entry checking, automated batch control and targeted manual spot checks in unclear cases.
This sequence makes sense:
- Check at capture. Errors belong in the form or in the import, not in the last payment step.
- Validate batches before the run. Especially with Excel and CSV processes, this saves follow-up questions.
- Trace special cases manually. This is especially important for supplier changes, migrations and legacy stock.
- Train staff on structure errors. Many problems are not bank problems, but entry problems.
Anyone who wants to make payment processes more reliable overall will find a useful perspective in the guide to digitalization for SMEs on how manual administrative workflows can be digitalized more systematically. That is exactly where IBAN checking belongs. Not as an individual tool on the side, but as a fixed checkpoint in the process.
For teams working with remittances, the combination of file conversion and integrated IBAN checking is usually more practical than loose individual solutions. Especially when Excel, CSV or older AEB formats are still in circulation, an end-to-end workflow noticeably saves time and rework.
If you create SEPA files from Excel, CSV, JSON or old AEB formats and want to check IBANs directly in the process, GenerateSEPA is a practical option. The service converts files into SEPA XML, supports automated workflows via the GenerateSEPA API, and helps catch formal errors before sending to the bank.
Frequently Asked Questions
- How long is a German IBAN?
- A German IBAN is always 22 characters: country code DE, two check digits, an eight-digit bank code and a ten-digit account number. Any other length is an immediate warning sign.
- What does the modulo-97 check validate?
- It validates the formal check digits of the full string. The first four characters move to the end, letters become numbers, and the remainder modulo 97 must be 1.
- Is a passed check digit enough for SEPA payments?
- No. A formally valid IBAN does not prove the account exists or is active. For bulk payments, master data should be checked early and again before export.
- When should IBAN checking happen in the process?
- Ideally at data entry, again before batch export, and with spot checks when migrating legacy formats. That keeps Excel and CSV errors out of the bank run.