Generate Random IBAN

IBAN vs routing number: what US teams need to know before paying a European supplier

The US identifies a bank account with a routing number and an account number. Europe and about 90 other countries use the IBAN. This guide covers the differences, what to request from a supplier abroad, and the validation rules for each field.

By the Generate Random IBAN editorial team · · 8 min read

If you run accounts payable, build a payouts product or maintain a vendor onboarding form in the US, the first European supplier you pay will send you something that looks like DE89 3704 0044 0532 0130 00 and call it their bank details. There is no routing number in it, and no separate account number. The IBAN vs routing number question comes up at that point, usually with a deadline attached.

A US account is identified by two numbers, a 9-digit ABA routing number for the bank and an account number of up to 17 characters for the account. In Europe and most of the Middle East, one string does both jobs: the IBAN (International Bank Account Number) contains the country, two check digits, the bank code and the account number. The United States does not use IBANs, so a US company never has one and never needs to produce one. For an international wire, the US bank is identified by its BIC (the "SWIFT code") instead.

The rest of this post goes through each identifier, what to request from a supplier, and how to store and validate the fields without the usual mistakes.

The two systems side by side

United States IBAN countries
Bank identifier ABA routing number, 9 digits Inside the IBAN (bank code at a fixed position), plus a BIC for cross-border payments
Account identifier Account number, up to 17 characters in ACH files Inside the IBAN
One string or two? Two One
Checksum Routing number: weighted MOD 10 check digit. Account number: none in general Two MOD-97 check digits over the whole IBAN; some countries add national check digits
Length 9 + up to 17 15 to 34 characters, fixed per country
Standard ABA, Nacha Operating Rules for ACH ISO 13616, SWIFT IBAN Registry

How a US bank account is identified

A US account is addressed with two separate fields.

The ABA routing number (also "routing transit number", RTN, or "ABA number") is a 9-digit code that identifies the financial institution. The American Bankers Association created it in 1910 for cheque clearing, and it is still assigned by the ABA's registrar, LexisNexis Risk Solutions. The first four digits are the Federal Reserve routing symbol, the next four identify the institution and the ninth is a check digit.

The check digit uses weights 3, 7 and 1 across the nine positions, and the weighted sum has to be divisible by 10:

3·d1 + 7·d2 + 1·d3 + 3·d4 + 7·d5 + 1·d6 + 3·d7 + 7·d8 + 1·d9 ≡ 0 (mod 10)

For 021000021 that gives 3·0 + 7·2 + 1·1 + 3·0 + 7·0 + 1·0 + 3·0 + 7·2 + 1·1 = 30, which is divisible by 10, so the number is well formed. Routing numbers can start with 0 (011000015 is one), so the field is a string, never an integer.

The account number is whatever the bank assigned. There is no national format and no national check digit. In an ACH file the Nacha record format gives it 17 positions (the "DFI Account Number" field), which is why many payment systems cap US account numbers at 17 characters. When a US counterparty gives you a routing number, ask whether it is the one their bank wants for the payment type you will use (ACH or wire); banks publish them separately.

How a European bank account is identified

An IBAN is a single string of 15 to 34 characters with a layout that is fixed per country:

  1. Two letters: the ISO country code (DE, FR, GB).
  2. Two digits: check digits computed over the whole IBAN with the MOD 97-10 algorithm from ISO/IEC 7064.
  3. The BBAN (Basic Bank Account Number): the domestic bank code, branch code where the country has one, and account number, in positions the SWIFT IBAN Registry defines for each country.

Three examples from the registry:

Country Length Example Inside the BBAN
Germany 22 DE89 3704 0044 0532 0130 00 8-digit Bankleitzahl, 10-digit account
France 27 FR14 2004 1010 0505 0001 3M02 606 5-digit bank, 5-digit branch, 11-character account, 2-digit national key
United Kingdom 22 GB29 NWBK 6016 1331 9268 19 4-letter bank code, 6-digit sort code, 8-digit account

So the German IBAN above already contains the bank code 37040044 and the account 0532013000. There is nothing else to ask for to identify the account. What is an IBAN covers the structure in more detail, and IBAN formats by country lists the length and layout of every country.

The BIC (Business Identifier Code, ISO 9362, often called the SWIFT code) is a separate 8- or 11-character code that identifies a bank, and optionally a branch, on the SWIFT network: DEUTDEFF is Deutsche Bank in Frankfurt. Inside the euro area the BIC is no longer required for SEPA payments, but a wire from a US bank is not a SEPA payment, so for your purposes the BIC is still part of the supplier's bank details. IBAN vs BIC explains how the two relate.

Does the United States use IBANs?

No. The SWIFT IBAN Registry, the official list of countries that have adopted ISO 13616, has 89 entries as of Release 102 (June 2026) and the United States is not one of them. Neither are Canada, Australia, China, India or Japan. Countries without IBAN lists what they use instead.

In practice this means:

  • A US company cannot fill in an "IBAN" field on a European supplier's or marketplace's form. The right answer is the BIC of the US bank plus the routing number and account number, and a form that handles non-IBAN countries has to accept that. If it does not, ask the counterparty how their bank wants a US account entered.
  • A European supplier cannot give you a routing number. Their bank details are an IBAN and a BIC.
  • Anything presented as a "US IBAN" is either a mislabelled account number or a made-up string. A correct validator rejects US as the country code.

What to ask a European supplier for

For a USD or EUR wire from the US to an account in an IBAN country, request these fields and nothing else:

  1. The IBAN, exactly as the bank prints it. Spaces are fine; you will remove them when you store it.
  2. The BIC of the bank that holds the account.
  3. The account holder name as the bank has it. Since 9 October 2025, payment service providers in the euro area have to check the payee name against the IBAN before a euro credit transfer (Verification of Payee, Regulation (EU) 2024/886). A wire from the US falls outside that rule, but the receiving bank can still hold a payment whose beneficiary name does not match the account, so use the legal name, not a trading name.
  4. The currency of the account, if you plan to pay in USD. A euro account can receive dollars, but the receiving bank will convert at its rate.

You do not need a routing number, a sort code, a branch address or a "bank code" as separate fields: all of that is inside the IBAN. If the supplier's invoice template lists a sort code or Bankleitzahl separately, it is the same information shown twice.

How to store and validate each field

Treat every identifier as a string. Store the IBAN in electronic format (uppercase, no spaces), and format it in groups of four only for display.

Field Column type Validation
IBAN VARCHAR(34) Characters A-Z0-9 only; first two letters are a registry country; length matches that country; MOD-97 remainder is 1
BIC CHAR(8) or CHAR(11) 6 letters, then 2 alphanumeric, then optional 3 alphanumeric
ABA routing number CHAR(9) 9 digits; weighted 3-7-1 sum divisible by 10
US account number VARCHAR(17) Non-empty; no universal checksum, so rely on the bank's confirmation or a pre-note

The routing check fits in a few lines of JavaScript:

function isValidRoutingNumber(rtn) {
  if (!/^\d{9}$/.test(rtn)) return false;
  const d = [...rtn].map(Number);
  const sum = 3 * (d[0] + d[3] + d[6]) + 7 * (d[1] + d[4] + d[7]) + (d[2] + d[5] + d[8]);
  return sum % 10 === 0;
}

isValidRoutingNumber("021000021"); // true
isValidRoutingNumber("021000022"); // false

The IBAN check is the MOD-97 calculation described in IBAN check digits, together with the per-country length table. To check one by hand, paste it into the IBAN validator; it runs in the browser and shows which rule fails. For test fixtures, do not copy a real supplier's IBAN into your QA database. Generate structurally valid ones for the countries you support instead:

Each generated IBAN passes the length and MOD-97 checks and, in realistic mode, carries a real bank code, so your validation code and your payout flow can be tested end to end without touching a real account.

Common mistakes

  1. Storing a routing number as an integer. 011000015 becomes 11000015, and every payment to that bank fails. The same goes for account numbers with leading zeros.
  2. Putting an IBAN in the account-number field. A 27-character French IBAN in a 17-character ACH field is silently truncated, and the payment leaves with an invalid beneficiary.
  3. Asking a European supplier for a routing number. They will send the BIC, a sort code or a Bankleitzahl, and whichever it is, your form will mislabel it. Ask for IBAN and BIC.
  4. Validating the IBAN with a regular expression only. A regex checks the shape, not the check digits. A transposition such as DE89 3704 0044 0532 0310 00 passes the pattern and fails MOD-97.
  5. Treating a valid IBAN as proof that the account exists. Check digits catch typos. Only the receiving bank knows whether the account is open and belongs to the payee; why a valid IBAN can still be rejected lists the usual reasons.
  6. Keeping spaces in the stored value. DE89 3704… and DE893704… are the same IBAN, and a duplicate check that compares the raw strings will not see that.
  7. Using production bank details in test environments. A real IBAN tied to a named supplier is personal data. Generated IBANs give you the same formats without the exposure.

Sources

Need test IBANs?

Generate structurally valid IBANs for 91 countries, with correct check digits, ready to copy or download as CSV, JSON or SQL. They are not issued by any bank.

Open the IBAN generator
All articles