Verify IBAN: how to check any account number correctly

A transfer is prepared, the remittance is about to be exported, and yet the run fails because of a single string of characters. Not the amount. Not the mandate. But an IBAN with a small input error or a formally valid but practically unusable bank connection.

This is exactly where a misunderstanding arises in many companies. Anyone who checks an IBAN online often assumes that this also ensures the payment will actually go through later. That is not the case. With IBAN verification, there is a difference between formal correctness and operational usability. For private one-off transfers, the first level is often enough. For SEPA direct debits, recurring supplier payments and bulk runs, it is not.

Why a correct IBAN check is decisive

Since 2014, the IBAN has been mandatory for all transfers in the SEPA area, and old account numbers and bank codes without IBAN conversion are no longer accepted for payment services in Germany, as the overview on the IBAN checker and the SEPA obligation describes. In practice, this means the IBAN is no longer just an additional field, but the central identifier for executing payments.

The problem begins where companies confuse an online check with real payment certainty. Many tools only answer the question of whether the string is formally plausible. They do not automatically answer whether the bank connection is really usable in business operations, whether the bank details are current, or whether the target account is suitable for the desired procedure.

The most common thinking error

A typical sequence looks like this: an employee takes an IBAN from an email, a customer types it into a form, or a supplier list is imported from Excel. The number passes the standard check. After that, everyone assumes everything is clean. The error only appears at execution. By then, the work has already flowed into the payment process.

Practical rule: A passed IBAN check digit is not yet a release signal for a business-critical payment run.

For business owners, this has direct consequences. Payments are delayed. Direct debits are returned. The team has to clarify follow-up questions, correct records and recreate payment files. On top of that come possible fees and, above all, unnecessary friction with customers, suppliers and your own accounting.

Formal validity is not the same as payment capability

Free checkers in particular are useful when you want to quickly check the format of a single number. There is nothing wrong with that. What is often missing is the second level: checking whether the stored bank identifier still matches the current bank directory and whether the connection is suitable for the planned SEPA process.

From a professional perspective, the decisive question is therefore not whether an IBAN “looks valid”. What is decisive is which type of validation is needed for the respective business process. For a one-off manual check, a basic tool is often enough. For remittances, ERP imports or automated payment flows, more is needed.

The structure of a German IBAN and the check digit

Anyone who wants to check a German IBAN correctly should first understand its structure. That demystifies the number immediately. A German IBAN is not a random block of characters, but follows a fixed structure.

The German IBAN is mandatorily 22 digits long and consists of the country code DE, a two-digit check digit, eight digits for the bank code (BLZ) and ten digits for the account number. The BLZ occupies positions 5 to 12 and allows assignment to more than 1,500 German credit institutions, as the explanation on the structure of the German IBAN at Finanzen.net summarizes.

What the individual parts mean

Component	Function
DE	Identifies Germany per ISO standard
Check digit	Detects input errors across the entire number
BLZ	Assigns the IBAN to a credit institution
Account number	Identifies the specific account within the bank

The account number may contain leading zeros. That in particular is a common source of error in daily life when data is taken over from legacy formats, from paper documents or from ERP exports.

Anyone who wants to dive deeper into the derivation and calculation will find a clean technical explanation of how to calculate an IBAN.

How the check digit works

The actual logic lies in the modulo-97 method per ISO 13616. The principle is sober but very effective. The first four characters are moved to the end, letters are converted to numbers, and the overall result must give a remainder of 1 when divided by 97.

At first glance, this seems mathematical, but in daily life it is above all a safety mechanism against typical input errors. Transposed digits, forgotten positions or incorrectly copied characters are often caught before the payment is even submitted.

A check digit is not decoration. It is the built-in error brake of the account number.

Why the BLZ remains so important for business

Many teams treat the IBAN as a complete black box. For operational processes, that is impractical. In Germany, the bank code is still clearly visible within the IBAN. That is valuable, because it lets you recognize which institution the connection belongs to and whether a further check is sensible.

For companies with recurring payments, this is especially relevant when legacy data is migrated or when bank connections have been in the system for years. The IBAN may look formally stable, but the bank identifier contained in it is a practical checkpoint that many simple checkers do not consistently reconcile against current directories.

Manual and programmatic IBAN checking

Once you understand the mechanism, an IBAN can be traced even without a tool. This is not intended for daily operations, but it helps avoid implementation errors. That is exactly where many in-house developments fail.

German IBAN validation follows the modulo-97 algorithm strictly, and a critical technical error lies in the missing normalization of the input. According to the description at the IBAN validator from mdle.de, this error occurs in 15–20% of all incorrect IBANs in Germany. What is meant are cases such as spaces that were not removed or inconsistent spelling, which lead to an abort even before the actual calculation.

How the manual check works

Let’s take a German IBAN as an example, without fixating on a specific number. The manual process is always the same:

1. Clean up the input Remove spaces, bring everything into a uniform spelling.

2. Move the first four characters DEpp... becomes ...DEpp.

3. Convert letters to numbers D becomes 13, E becomes 14.

4. Check the resulting number against 97 Only if the remainder at the end is 1 is the IBAN formally valid.

The point about cleaning up is more important than it looks. Anyone taking inputs directly from forms, CSV files or copy-paste from emails must pay particular attention to spaces, invisible separators and special characters accidentally copied along.

A practice-oriented check process for developers

For systems, regex alone is not enough. A regex only checks the basic format. The actual validation always also needs the mod-97 calculation.

import re

def validate_german_iban(iban):
    iban = iban.replace(" ", "").upper()

    if not re.fullmatch(r"DE\d{20}", iban):
        return False

    rearranged = iban[4:] + iban[:4]
    converted = ""

    for ch in rearranged:
        if ch.isalpha():
            converted += str(ord(ch) - 55)
        else:
            converted += ch

    remainder = 0
    for digit in converted:
        remainder = (remainder * 10 + int(digit)) % 97

    return remainder == 1

JavaScript works on the same pattern:

function validateGermanIBAN(iban) {
  iban = iban.replace(/\s+/g, '').toUpperCase();

  if (!/^DE\d{20}$/.test(iban)) {
    return false;
  }

  const rearranged = iban.slice(4) + iban.slice(0, 4);

  let converted = '';
  for (const ch of rearranged) {
    if (/[A-Z]/.test(ch)) {
      converted += (ch.charCodeAt(0) - 55).toString();
    } else {
      converted += ch;
    }
  }

  let remainder = 0;
  for (const digit of converted) {
    remainder = (remainder * 10 + parseInt(digit, 10)) % 97;
  }

  return remainder === 1;
}

What often goes wrong in in-house developments

Most errors are unspectacular. That is precisely why they are so expensive in operation.

• Missing normalization If spaces or separators are not removed, the check fails unnecessarily early.

• Only format, no check digit A regex like DE plus 20 digits is not enough. It accepts values that look formal but are mathematically wrong.

• Wrong letter conversion The mapping A=10 to Z=35 must be implemented correctly.

Anyone checking an IBAN in code should never rely only on the visible pattern. The pattern recognizes the form. The check digit recognizes the error.

For internal tools, a simple principle therefore applies: if the volume is small, a solid in-house function can suffice. As soon as payment data comes from several sources or is processed automatically, the risk of edge cases rises quickly.

Online tools and the limits of free checking

Free IBAN checkers on the web have their place. For individual queries in day-to-day business, they are practical. An employee quickly checks a customer number, accounting verifies a detail from an email, or a sales team wants to see whether a bank connection is formally plausible.

Review the tools listed on the SEPA utilities page and choose deliberately according to your purpose. For a simple individual check, the IBAN validator or Check IBAN tools show the check digit, bank reference and basic IBAN data—not just “valid/invalid”.

What such tools are good for

Use	Suitable?	Why
Single manual check	Yes	Fast, without setup
Control before data entry	Yes, with limits	Good as a first hurdle
Bulk check from Excel or ERP	Rather no	Too manual and not scalable
Risk minimization in the payment process	Not on its own	Formal checking is not enough

The real catch lies not in the quality of these tools, but in the scope of their checking. A free checker usually only answers the syntactic question. For companies, however, the operational question is often decisive: can the planned SEPA process be carried out reliably with this bank connection?

The business gap

In German practice, checking only length and check digit without reconciling the bank code against the current Bundesbank directory leads to an error rate of around 3–5% in the actual feasibility of SEPA transactions, as the guide on IBAN checking at Smart-Rechner explains.

This is the point many companies underestimate. An IBAN can be formally clean and still fail in the process, because the stored BLZ no longer matches the current directory situation, or because the connection is not operationally usable the way the team assumes.

A free web check is a filter. It is not a substitute for a robust payment process.

When free tools are enough and when they are not

In my view, a web checker is enough in three situations: for individual checks, for internal queries and for the first plausibility check of new master data. It is not enough when remittances are created automatically, when direct debits run in series, or when the company wants to systematically reduce fees, returns and operational rework.

As soon as payment data is no longer checked individually by hand, the difference between “formally correct” and “reliably usable in the process” becomes economically relevant.

Automation with an API for maximum security

Companies that regularly generate SEPA files or take payment data from ERP, shop, CRM or Excel should automate the check. Not for convenience, but because it catches the most common errors exactly where they arise: before export and before submission to the bank channel.

IBAN validation APIs check not only the check digits, but also whether an IBAN has a valid domestic bank code and account number, and what SEPA support the bank offers for modes such as B2B, COR1, SCC, SCT and SDD, as the description of the validation API from iban.com explains.

What an API does better

The biggest advantage is not speed. It is consistency. Every incoming IBAN runs through the same rules. This reduces manual exceptions, interpretation errors and silent data problems that would otherwise only surface in the remittance.

For technical teams, API documentation that fits directly into existing processes is also worthwhile. A practical reference for this is the technical API documentation from GenerateSEPA, when payment files and IBAN checking are to be integrated into an automated workflow.

Important criteria when choosing

• Does the solution only check mod-97 or also bank data? This separates simple checkers from production-ready services.

• Does it provide additional information for SEPA procedures? This is especially relevant for direct debit processes and bank-dependent workflows.

• Can the check be triggered before the XML export or import? Only then do you stop errors early enough.

Anyone who wants to see how such processes are built in practice around SEPA files can also watch this short example:

The operational benefit is clear. The API does not replace the professional decision in the finance team. But it takes the recurring technical check off the team’s hands and turns individual case controls into a reproducible standard.

Best practices for error-free SEPA payments in 2026

Anyone who checks IBANs cleanly reduces not only error risks. They build a more stable payment process. For 2026, the same basic rule remains valid: not every formally correct IBAN is automatically a commercially secure bank connection.

The checklist for daily use

• Check the IBAN at input Errors should become visible in the form, at import or during the master data update. Not only at the bank run.

• Combine two levels First the formal check, then the reconciliation with bank data and the requirements of the planned SEPA procedure.

• Do not secure bulk processes manually As soon as lists from Excel, CSV or ERP are processed, manual checking is too error-prone.

• Question legacy data regularly Historically grown master data often looks clean, even though it was never checked against current references.

• Distinguish between valid and active An IBAN check primarily confirms formal correctness. It is not automatically proof that an account is active or remains smoothly usable in the desired business context.

What works in practice

Companies do best with a staged model. At the front of the process stands an immediate plausibility check. Behind it, for business-critical payments, follows a deeper technical validation. And at the very end, the export to the SEPA format should work only with data that has already been checked.

Anyone who lets payments be “tested” only at submission shifts quality control to the most expensive point of the process.

For small teams, a clear separation between individual-case checking and productive bulk processing is often enough. For growing organizations, a consistent workflow is worthwhile, in which master data, validation and file generation are thought of together. That is exactly where the greatest benefit of clean IBAN verification arises.

---

If you generate SEPA files from Excel, CSV, JSON or AEB formats and want to build IBAN checking directly into the process, GenerateSEPA is a matter-of-fact option. The platform converts payment data into SEPA XML, supports automated workflows via API, and integrates validations so that faulty bank connections do not only surface when sending to the bank.

---

Frequently Asked Questions

Does an online IBAN check mean the payment will succeed?

Not necessarily. Online checkers usually answer formal correctness only. Whether the account is active and suitable for your SEPA process may require additional business and bank-side checks.

What are the parts of a German IBAN?

DE plus two check digits, eight-digit bank code and ten-digit account number. Leading zeros in the account part are valid and common in legacy data.

What error affects many invalid German IBANs?

A large share fails because normalisation was skipped — spaces or inconsistent casing — before modulo 97 is applied.

How should companies secure bulk payments?

Combine validation at entry, automated list checks and exports that only use already verified records. That moves quality control away from the most expensive step.

---

Related posts