IBAN vs SWIFT: What Each Code Does and When You Need It
Learn the difference between IBAN vs SWIFT codes, how each is structured, which countries need them, and how to avoid rejected transfers.
An IBAN identifies the recipient's account, and a SWIFT/BIC identifies the bank or branch that routes the payment, so the two are usually used together rather than swapped.
The familiar advice to get both codes is incomplete. You can enter both correctly and still have a transfer held or returned because the beneficiary name, currency, intermediary instructions, or payment message is wrong. The practical question isn't which acronym is better. It's which field needs checking, who can correct it, and what evidence you should keep.
IBAN and SWIFT at a Glance
An IBAN and a SWIFT/BIC belong in separate fields because they identify different parts of the payment. SWIFT's bank-directory FAQ distinguishes the account identifier from the institution identifier and describes a BIC as 8 characters, or 11 characters when a branch or business line is specified.
Neither code is a delivery receipt. Correct identifiers don't promise a particular exchange rate, fee, settlement time, or successful completion, as the Congressional Research Service's explanation of international payment infrastructure makes clear.
IBAN vs SWIFT/BIC side by side
Feature | IBAN | SWIFT/BIC |
What it identifies | A specific bank account | A bank or branch that routes the payment |
Governing standard | ISO 13616 | ISO 9362 (BIC) |
Length | Up to 34 characters, set by country | 8 characters, or 11 with a branch code |
Example | German format beginning DE, followed by check digits and domestic bank/account fields | DEUTDEFF |
Question it answers | Which account receives the money? | Which institution carries the payment? |
Used in US domestic transfers | No | No |
Confirms delivery or speed | No | No |
The distinction also applies to the terminology. SWIFT is the messaging network; BIC is the institution identifier commonly called a SWIFT code. An IBAN is an account-number format, not a competing messaging network.
For context on the messaging process behind the identifier, Zaro's guide to SWIFT payments explains how a SWIFT payment works. That background helps when a bank says it has sent an instruction but the recipient hasn't yet received the money.
For freelancers receiving foreign payments, staff paying suppliers abroad, and employees claiming international reimbursements, the useful distinction is operational: copy each identifier into its designated field and keep the complete payment instruction.
How an IBAN Is Built, Country by Country
An IBAN is not just a domestic account number with a country prefix attached. Each participating country defines a fixed national format within the international structure.
Under SWIFT's IBAN registration procedures, the sequence begins with a two-letter country code, followed by two check digits and a Basic Bank Account Number, or BBAN, of up to 30 alphanumeric characters, giving a maximum total of 34 characters. The BBAN contains the country-specific bank and account information.
Read the national fields, not just the prefix
Germany provides a useful example. The Bundesbank's technical standard specifies 22 characters: DE, two check digits, an eight-digit bank sort code, and a ten-digit account-number field. Shorter underlying account numbers are padded with leading zeros.
That padding matters when someone copies payment details into a spreadsheet. If the spreadsheet treats the account field as a number, it can remove zeros that the bank needs. Store bank identifiers as text, not quantities.
IBAN lengths for common countries
Country | Code | Total IBAN length |
Germany | DE | 22 |
United Kingdom | GB | 22 |
France | FR | 27 |
Italy | IT | 27 |
Spain | ES | 24 |
Switzerland | CH | 21 |
Netherlands | NL | 18 |
Belgium | BE | 16 |
Use the country's prescribed length as an initial check, not as final approval. A copied IBAN can have the right length while containing the wrong account details.
Validate without silently repairing
A payment system should check the national format and run the mod-97 check-digit test before submission. Printed spaces are for readability; payment systems remove them when processing the identifier.
Don't manually change a digit to make an error message disappear. Re-copy the complete IBAN from a current bank statement or authenticated account-details page, then validate it again.
For a supplier setup, retain the original document alongside the normalized identifier. That gives finance staff something concrete to compare if a later invoice presents different bank details.
How a SWIFT/BIC Code Is Structured
A BIC is shorter and more uniform than an IBAN. It identifies a financial institution under ISO 9362 and is assigned through SWIFT's registration process.
Read DEUTDEFF as separate fields rather than an opaque string. The institution field comes first, followed by the country and location fields; an optional branch suffix makes the identifier more specific.
Read the code field by field
Field | Example component | What to check |
Institution | DEUT | Matches the receiving institution's published instructions |
Country | DE | Matches the institution's stated country |
Location | FF | Matches the location specified by the bank |
Optional branch | 500 in DEUTDEFF500 | Appears in the beneficiary bank's instructions when needed |
The institution-only form and the branch-specific form aren't interchangeable merely because they share a prefix. If the recipient supplies DEUTDEFF500, don't shorten it because your last payment used DEUTDEFF. Equally, don't invent a suffix when the bank gives you the institution-level code.
SWIFT's global recognition comes from its messaging infrastructure. SWIFT's account of its history reports more than 8.4 billion messages in 2019, illustrating the scale at which institutions exchange standardized instructions.
Find the receiving code, not any code for the bank
Look in the recipient's online banking account details, statement header, bank website, or international transfer instructions. Prefer instructions specific to the account and receiving currency over a general search result.
A bank can publish different instructions for different services. The code on a corporate contact page might not be the instruction the beneficiary should use for that particular incoming payment.
- Start with account-specific instructions. Ask the recipient to obtain incoming international payment details from their bank.
- Resolve conflicting codes before sending. Have the recipient confirm which instruction applies to the account and currency.
- Keep the account identifier separate. A correct BIC never supplies the customer's personal account number.
The useful check is whether the BIC matches the intended route, not whether the code merely looks plausible.
Where Each Code Is Required and Where It Is Not
Start with the payment case, not the sender's nationality. A US business paying a European supplier may need the supplier's IBAN even though its own US account doesn't have one.
IBANs are used across most of Europe and in parts of the Middle East, Africa, and Latin America. The United States, Canada, Australia, and Japan use local account formats instead, so an international instruction to those destinations normally combines local account information with the receiving institution's BIC.
Match the identifiers to the payment route
The SWIFT IBAN Registry publishes national IBAN specifications, including country-specific lengths and account structures. Its distinction between account identification and institution identification is why finance systems should retain IBAN and BIC in separate normalized fields.
IBAN and BIC requirements by payment case
Payment case | IBAN needed | BIC/SWIFT needed | Notes |
Euro payment inside SEPA | Yes | Often not required | Some banks still ask for it on their form |
Europe to UK or Switzerland | Yes | Usually yes for an international wire | IBAN countries outside the euro zone; a SEPA euro payment can follow different requirements |
US company wire to a European account | Yes, if recipient is in an IBAN country | Yes | US routing numbers don't replace the European recipient's bank details |
US domestic payment | No | No | Uses routing and account numbers |
Payment to Japan, Australia or Canada | No | Yes for an international SWIFT wire | Local account number paired with BIC and any required domestic bank code |
Reimbursement to an employee abroad | Required for an IBAN destination account | As required by the payer's bank and selected route | Confirm with payroll or treasury |
A payment to the UK or Switzerland doesn't automatically mean a foreign-currency wire. The currency and payment rail matter, so don't infer the requirements solely from whether the destination uses the euro domestically.
Similarly, an employee's residence isn't enough to determine reimbursement details. Confirm the country and currency of the account receiving the reimbursement, which may differ from where the employee traveled or currently lives.
Follow the bank's actual instruction
If the sending bank's form asks for a BIC, provide the confirmed BIC even when the general corridor rule doesn't require the customer to supply one. The form reflects that bank's routing process. If its requirements conflict with the beneficiary's instructions, ask the bank to resolve the conflict rather than entering a guessed value.
For overseas reimbursements, collect payment instructions separately from the travel claim. A consistent routine for managing travel expenses helps finance staff connect the approved expense to the payment without treating an itinerary or receipt as bank-account evidence.
Transfer Failures and Which Code to Check
Check the IBAN format first, then the BIC, beneficiary name, intermediary instructions, and currency. If the bank provides a specific rejection reason, start with that field instead of repeating every check.
A structurally valid IBAN can still identify the wrong person's account. Validation catches many transcription mistakes, but it doesn't establish ownership, authenticate an invoice, or rule out payment-detail fraud.
Diagnose the symptom before resending
Transfer rejection symptoms, causes and fixes
Symptom | Likely cause | Fix |
Account number rejected as invalid | IBAN has the wrong length or fails the mod-97 check | Re-copy from a current statement and match the country length |
Bank code not recognized | Wrong BIC or required branch suffix missing | Confirm the institution or branch-specific form with the recipient's bank |
Funds held or returned by an intermediary | Missing intermediary bank details | Request the intermediary BIC and complete routing instructions from the recipient's bank |
Returned for name mismatch | Beneficiary name differs from the account holder | Use the legal name on the account exactly |
Rejected for currency | Receiving account does not accept that currency | Confirm the accepted currency before sending |
Rejected as invalid format | An in-scope legacy instruction wasn't accepted after the payments-format transition | Ask the provider to confirm ISO 20022 support and the correct resubmission process |
These are likely causes, not conclusive diagnoses. An intermediary hold can also involve compliance review, and a delayed transfer isn't automatically a rejected transfer. Ask the sending bank whether the instruction was rejected, accepted but pending, returned, or credited.
Say a consultant's reimbursement is returned for a beneficiary-name mismatch. Replacing the BIC won't fix the problem if the account is held under a registered business name rather than the consultant's trading name. Obtain the account holder's confirmed legal name and correct that field.
Check the message format with the sending bank
SWIFT's ISO 20022 transition notice states that the MT/ISO coexistence period ended on 22 November 2025, after which in-scope financial-institution payment instructions had to use ISO 20022; non-compliant MT instructions could be negatively acknowledged, left unprocessed, or incur contingency-processing costs.
That's a bank or provider issue, not something a freelancer fixes by editing an IBAN. Ask the sender's bank to identify the rejected message, confirm the supported format, and explain whether it will repair or resubmit the instruction.
Give each correction an owner
The sending bank should explain an IBAN length or format rejection and identify the field its system refused. The recipient should confirm the account information against current banking records and obtain intermediary instructions from the receiving bank.
Keep the rejection text, payment reference, original instruction, correction, and resubmission confirmation together. Don't overwrite the failed instruction without preserving what changed, because finance staff may need to explain both the returned payment and its replacement.
Saving Transfer Details for Expense Reports
A reconcilable transfer record needs more than a screenshot showing that money left an account. Keep the payment instruction, bank confirmation, matching invoice, and shared reference together.
The instruction should preserve the beneficiary name, IBAN or local account number, BIC, amount, currency, and value date. The bank confirmation records what the bank accepted or processed; the invoice explains what the business paid for.
File the evidence when the payment goes out
- Save the bank confirmation as a PDF. Download it on the day you send, including the transaction reference and payment status. Don't label an accepted instruction as proof of final receipt.
- Capture the invoice the payment settles. Keep the original invoice legible, including the supplier identity, invoice reference, and currency.
- Put the payment reference in the receipt notes. Use the same reference across the confirmation, invoice, and expense entry so finance staff can match them without guessing.
- Mask the IBAN in shared reports. Show only its ending characters where identification is necessary, while retaining the full instruction in an access-controlled finance record.
- Group documents by trip or client. Export the relevant report as PDF or CSV for finance, and retain the supporting files with the expense entry.
This is especially useful when a reimbursement settles several expenses. The bank confirmation establishes the payment amount, but the expense report needs to explain how that amount relates to the approved claims.
Keep payment status separate from expense approval
An approved expense isn't necessarily paid, and a submitted transfer isn't necessarily received. Use clear status notes such as submitted, returned, replaced, or receipt confirmed rather than a single ambiguous paid label.
SWIFT's explanation of structured payment data describes ISO 20022 as a richer messaging format, not a replacement for IBANs or BICs or a guarantee of cheaper settlement. Structured remittance information helps only if the business preserves the reference needed to match the payment to its documents.
For a consistent filing approach, understanding what an expense report should contain helps separate the business purpose from the banking evidence.
Keep records for as long as your tax authority requires, and follow your organization's retention and access rules. A shared reimbursement report shouldn't expose complete bank details merely because the restricted finance record contains them.
Confirm Both Codes Before You Send Money
Use the final review to confirm the whole instruction, not just whether the form accepts the identifiers. Automated acceptance doesn't resolve a conflicting beneficiary name, an unsupported receiving currency, or a suspicious change of bank details.
The visual check is a starting point; the payment route and recipient confirmation still matter.
Run the pre-send check
- Validate the IBAN. Match its length and structure to the destination country and confirm that its check digits pass validation.
- Confirm the BIC. Use the institution or branch-specific form supplied by the receiving bank. Investigate a country mismatch with the IBAN rather than automatically changing either code, because routing arrangements can require clarification.
- Match the beneficiary name. Use the account holder's confirmed legal name, not an informal contact name or an assumed trading name.
- Check the receiving currency. Confirm what the account accepts and whether conversion is intended.
- Ask about intermediaries. Obtain complete intermediary instructions when the recipient's bank requires them.
- Verify changed details independently. Call a number you already hold, not a new number in the message requesting the change.
Use the IBAN to identify the account, add the BIC when the cross-border route or bank requires it, and investigate a rejected payment as a field-level problem rather than assuming you used the wrong kind of code.
Save the verified instruction in the supplier or expense record for controlled reuse. Once a field has failed, use the rejection symptom to assign the correction instead of changing unrelated details or sending the same instruction again.
Smart Receipts uses OCR to extract dates and totals from captured documents and helps you organize receipts with payment references and supporting records. Visit Smart Receipts to keep your transfer documentation together and export PDF, CSV, or ZIP reports for reimbursement and reconciliation.