UK Payments: No Bank Routing Numbers
2026-05-23
Your AP team is ready to pay a new supplier in London. The supplier sends over bank details promptly, but the fields don’t line up with what your system expects. There’s no ABA number. No domestic routing field that makes sense. Instead, you get a sort code, an IBAN, maybe a BIC, and someone on the supplier side says, “Please use these for the remittance.”
That’s where many US finance teams stall. They know how bank routing numbers work in the United States, but UK and European payment identifiers sit in a different framework. If you’re building payment files, collecting vendor onboarding data, or preparing remesas for cross-border payouts, the biggest risk isn’t theory. It’s entering the right data into the wrong field and creating avoidable payment repairs.
Table of Contents
- The Cross-Atlantic Payment Puzzle
- Understanding the US Bank Routing Number
- The UK’s Answer to Routing Numbers The Sort Code
- Going Global with IBAN and BIC for International Transfers
- Common Payment Pitfalls and How to Avoid Them
- How to Validate and Map Bank Data for Payment Files
- Frequently Asked Questions About UK Bank Identifiers
- Do UK banks have routing numbers
- Is a sort code the same as a routing number
- Can I use only a sort code to pay a UK supplier from the US
- Do I always need a BIC for UK or European payments
- Why did my payment file fail even though the bank details looked correct
- What should I store in the vendor master
The Cross-Atlantic Payment Puzzle
A US company paying a UK supplier often runs into the same friction point. The payer asks for a routing number because that’s the normal language of domestic US banking. The supplier replies with details that look unfamiliar, and suddenly a simple vendor payment turns into a back-and-forth between procurement, AP, treasury, and the bank.
This is especially common when a team is used to ACH workflows and then has to step into international payments without changing its assumptions. A supplier form might ask for domestic bank details in one country, while your ERP or payment platform still labels the field as if every destination were using US rails. That mismatch creates unnecessary repair work before the payment even leaves your account.
### Where the confusion starts
In the US, teams are trained to think in terms of bank routing numbers and account numbers. In the UK, domestic payments use a different pair: sort code and account number. For international transfers, the expected identifiers usually shift again to IBAN and BIC.
If you already understand what ACH payments mean in day-to-day finance operations, the key adjustment is this: ACH logic doesn’t travel well across borders. The field names may look similar inside software, but the underlying payment rails are different.
Practical rule: If the beneficiary bank is in the UK or Europe, stop asking first for a routing number. Ask which identifier is required for that payment rail.
### What finance teams actually need
Most errors come from treating all bank identifiers as interchangeable. They aren’t. A routing number belongs to a US domestic framework. A sort code belongs to UK domestic payments. An IBAN is built for international and European account identification. A BIC identifies the bank in the SWIFT context.
That distinction matters most when you’re preparing payment batches, not just one-off transfers. Once you move from a single manual payment to a spreadsheet or remesa file, one wrong assumption gets repeated across every row.
## Understanding the US Bank Routing Number
A US routing number is the bank identifier used on domestic US payment rails. It tells the system which institution should receive the payment. The account number then points to the specific customer account.
For a finance team building payment files, that distinction matters because the routing number belongs to a US framework. It does not map cleanly into UK domestic payments or SEPA transfers, even if your ERP or treasury platform puts all bank identifiers into the same set of fields.
Bank routing numbers in the United States were formalized by the American Bankers Association in 1910 to help sort, bundle, and deliver paper checks. The modern format is a nine-digit code, where the first four digits identify the Federal Reserve routing symbol, the next four identify the financial institution, and the final digit is a check digit, as described in the routing transit number reference.
That legacy still shows up in daily operations. Routing numbers are used across ACH, domestic wires, direct deposit instructions, bill payments, and check processing. US teams see them so often that they become the default answer to any request for “bank details.”
That habit causes problems in cross-border work.
Inside the US, the routing number works as the institution-level address for domestic payment processing. Pair it with the account number and you have the standard data needed for many US payment types.
A US finance manager is used to asking for those two fields first because that request is usually correct for payroll, vendor payments, and treasury transfers sent through US rails. The trouble starts when the beneficiary is in London, Dublin, Madrid, or Frankfurt and your team still tries to force the payment into a routing-number model.
If the beneficiary bank is outside the US, a routing number is often irrelevant to the payment you are trying to send.
That is the practical translation issue behind many failed remesas. The file may be technically complete by US standards and still be unusable for the destination rail.
### Where teams make the wrong leap
The common error is not misunderstanding the routing number itself. The error is treating it as a universal bank identifier.
In practice, payment identifiers are rail-specific. A US domestic payment may need a routing number. A UK domestic payment may need a sort code and account number. A SEPA or broader international transfer may require an IBAN, and sometimes a BIC depending on the bank, corridor, and payment setup.
There is also a second operational issue inside the US. Banks can use different routing numbers for different payment types, so the “bank routing number” in a vendor master record may still be wrong for the rail your team selected. That should be a warning sign for cross-border processing. If identifier rules vary within one country, they will vary even more once you move from ACH or US wires into UK Faster Payments, Bacs, CHAPS, SEPA Credit Transfer, or SWIFT.
For payment-file preparation, the safe approach is simple. Start with the destination country and payment rail, then collect the identifier set that rail expects. That prevents the classic remesa error where a US template asks for a routing number, the supplier sends an IBAN, and someone on the team pastes it into the wrong field just to get the batch uploaded.
## The UK’s Answer to Routing Numbers The Sort Code
If you’re paying someone domestically in the UK, the closest practical equivalent to a US routing number is the sort code. It isn’t identical in structure or role, but it fills a similar purpose in UK payment routing.
A sort code is typically written as three pairs of digits, such as 12-34-56. In practical terms, it identifies the bank and branch context for a UK domestic account. The account itself is then identified separately by the customer’s account number.
### How to think about a sort code
For US readers, the simplest translation is this:
- Routing number in the US: identifies the bank in the domestic US system
- Sort code in the UK: identifies the bank and branch context in the domestic UK system
- Account number in both cases: identifies the customer account within that framework
That means a UK supplier giving you a sort code isn’t withholding a routing number. They’re giving you the domestic bank identifier their system uses.
### What it looks like in operations
A UK beneficiary will often share bank details in a format like this:
- Account name: the legal or trading name on the bank account
- Sort code: the domestic UK bank identifier
- Account number: the customer account number
- IBAN and BIC: often included when the sender is outside the UK
If your payment is domestic inside the UK, the sort code and account number may be sufficient depending on the payment method and bank process. If your payment originates in the US or is going through an international channel, domestic-only details often won’t be enough.
That’s the point many AP teams miss. They collect the data that makes sense to the supplier locally, but not the data the sending bank or payment provider needs cross-border.
### Why sort code alone often fails for international use
A sort code isn’t designed to be a universal cross-border identifier. It works inside the UK domestic payment environment. Once the payment moves through SWIFT or a SEPA-related process, the file usually needs internationally standardized data rather than UK domestic shorthand.
A good operational habit is to ask suppliers for details in the exact context of the payment method you’ll use. Don’t ask, “Send your bank details.” Ask, “Please send the bank details required for an international transfer from the US, including IBAN and BIC if applicable.”
The format difference is easier to absorb once you see it discussed visually:
Field-level advice: If your form has a required nine-digit routing field, don’t force a UK sort code into it. Fix the payment method or the form design instead.
## Going Global with IBAN and BIC for International Transfers
For international transfers, especially when a US business is paying a UK or European beneficiary, the working identifiers usually become IBAN and BIC. This is the point where many teams stop thinking in domestic-bank terms and start thinking in standardized cross-border terms.
An IBAN is an International Bank Account Number. It packages account-identification data into a standardized format used across many countries. For UK accounts, the IBAN begins with the country code and incorporates the domestic account information into a longer structured string.
That matters because it gives the sending institution a more complete and internationally readable destination format than a domestic-only sort code and account number pair.
A BIC identifies the bank in the SWIFT network. In plain operational language, if the IBAN identifies the account destination, the BIC identifies the institution participating in the international messaging framework.
If your team has to explain this internally, the easiest translation is:
- Routing number: US domestic bank identifier
- Sort code: UK domestic bank identifier
- IBAN: international account identifier
- BIC: international bank identifier used in SWIFT context
For a deeper explanation of bank identification in cross-border messaging, this guide on BIC and SWIFT codes is a useful companion.
### US vs. UK and international bank identifiers compared
| Identifier | What It Is | Format | Primary Use Case |
|---|---|---|---|
| Routing number | US domestic bank identifier | Nine-digit ABA code | ACH, domestic wires, checks in the US |
| Account number | Customer account identifier within a bank | Bank-specific domestic format | Works with the domestic bank identifier |
| Sort code | UK domestic bank and branch identifier | Six digits, commonly shown in pairs | UK domestic payments |
| IBAN | Standardized international account identifier | Country-specific structured format | International transfers and European payment contexts |
| BIC | Bank identifier in the SWIFT network | 8 or 11 characters | International bank identification |
### Which details to request from a UK or EU supplier
If your business is sending money from the US to a UK supplier, ask for the data that matches the rail you’ll use. In most cross-border situations, that means:
- Beneficiary legal name: It should match the receiving account records.
- IBAN: This is usually the most important account identifier for international processing.
- BIC: Needed when the sending bank or provider requires it.
- Bank name and address: Some banks or internal forms still request this.
- Currency preference: The recipient may want payment in a specific currency and account setup.
What doesn’t work is collecting only the sort code because it “looks like routing info.” That’s a domestic UK detail, not a universal answer for cross-border processing.
## Common Payment Pitfalls and How to Avoid Them
A US finance team builds a supplier payment file on Friday, keys a UK sort code into the routing number field, and sends the batch. By Monday, some payments are rejected, some are held for repair, and AP is chasing vendors for “correct bank details” that were never wrong in the first place. The problem was the mapping.
This is the error pattern I see most often with cross-Atlantic payments. Teams start with a US routing-number mindset, then try to force UK or SEPA bank data into the same logic. That works poorly once you move beyond domestic US ACH and wires. For UK and EU payments, the right identifier depends on the rail, the currency, and the file format your bank expects.
### The mistakes that show up most often
These issues create the majority of avoidable rejects and repair items:
- Putting a sort code into an ABA routing field: A UK sort code identifies a domestic UK bank and branch. It is not a US routing number and should not be treated as one in an ERP or bank portal.
- Using sort code and account number for a cross-border payment that needs IBAN: A supplier may send domestic UK details because that is what appears on their invoice. Your sending bank may still require IBAN, and sometimes BIC, for the transfer to route correctly.
- Assuming one code works for every payment rail: In US payments, rail-specific bank identifiers matter. As noted earlier, ACH and wire instructions are not always interchangeable.
- Keeping outdated beneficiary data in the vendor master: Bank account changes, entity changes, and treasury restructures happen. Old data survives longer than teams expect.
- Relying on free-text instructions from invoices or email threads: That creates inconsistent records and raises the chance of putting the right data into the wrong field.
One practical rule helps here. Collect bank data based on the payment method you will use, not based on whichever code the supplier sends first.
### Better rules for payment setup
Payment controls do not have to be complex. They have to be specific.
Ask for different banking fields for different use cases. If you are paying a UK supplier locally from a UK account, sort code and account number may be enough. If you are sending from the US into the UK or EU, ask for the beneficiary legal name, IBAN, BIC if required, bank country, and currency instructions. That avoids the common remesas problem where the file is complete from AP’s perspective but unusable from the bank’s perspective.
It also helps to label fields in plain English inside your ERP or intake form. “Routing number” should not be the default label for every country. Use separate fields for ABA routing number, sort code, IBAN, and BIC. If your system cannot support that structure, the control gap is in the workflow, not in the vendor data.
### Checks that prevent avoidable rejects
Use a short review process before the first live payment and before any batch run:
- Match the destination country to the identifier type: US payments use ABA routing and account numbers. UK domestic payments use sort code and account number. Many cross-border and European payments rely on IBAN, with BIC sometimes required.
- Validate IBAN structure before file creation: A simple IBAN validation check catches formatting errors early.
- Confirm the beneficiary name against onboarding records: A valid account identifier does not fix a mismatched payee setup.
- Store multiple instruction sets when needed: A supplier can have domestic collection details and separate international receipt details.
- Review source documents consistently: Teams that automate financial document analysis usually find mismatches earlier than teams copying values manually from statements, emails, and PDFs.
### What breaks at batch level
Single payments can sometimes be repaired by hand. Batch files expose every weakness in your bank-data process at once.
That is why remesas need more discipline than one-off transfers. In a payment file, one bad field mapping can affect dozens or hundreds of transactions. A sort code placed in a routing-number column, an IBAN split across cells, or a missing BIC flag can turn a routine payout run into an exception queue. The fix is straightforward. Standardize collection, keep identifier types separate, validate before submission, and map each field to the payment rail your bank will process.
## How to Validate and Map Bank Data for Payment Files
Once you move from individual payments to batch files, bank-data quality becomes an operational issue, not just a banking one. The question is no longer “What is the right code?” It becomes “How do we make sure every row in this file contains the right code in the right field before the bank rejects it?”
For finance teams handling large batches of vendor payments or payroll, the key challenge is detecting invalid or outdated bank data at scale before it causes a failed transaction. Automated validation matters because the Federal Reserve directory is synchronized daily, which means stale data can create operational friction, as noted in this article on ABA routing numbers and validation workflows.
### A practical workflow for remesas
A dependable process usually follows five steps:
- Collect source data from ERP exports, supplier onboarding files, or treasury spreadsheets.
- Standardize the columns so names, account identifiers, beneficiary details, and amounts appear consistently.
- Validate the banking data before creating the payment file.
- Map each field to the structure required by your payment format.
- Generate and review the file before submission to the bank.
The mistakes usually happen in steps three and four. A team may have the right supplier data somewhere, but the spreadsheet heading doesn’t match the SEPA XML field, or the IBAN column contains hidden formatting issues from Excel.
### What to validate before file generation
Validation should be more than a visual check. At minimum, teams should review:
- Identifier format: Is the IBAN structurally correct for the target country?
- Field completeness: Do you have beneficiary name, account identifier, and required bank details?
- Rail compatibility: Are you mixing domestic-only details into an international file?
- Currency and account logic: Does the receiving setup match the intended payment method?
- Source consistency: Does the value in the file match the supplier-approved instruction?
If your team receives supporting bank letters, PDFs, or scanned forms from suppliers, it can help to automate financial document analysis before data is copied into your payment workflow. That reduces manual keying errors at the earliest stage.
### Why mapping matters as much as validation
Even clean bank data can fail if it’s mapped badly. I’ve seen teams keep one spreadsheet column called “Bank Code” and expect that to cover routing number, sort code, SWIFT, and IBAN logic. It won’t. Those are different data types with different destinations.
For SEPA preparation, use a purpose-built validation step rather than relying on spreadsheet formulas alone. An IBAN validation workflow built for payment preparation is far safer than asking staff to spot formatting problems by eye.
Good payment files come from disciplined mapping. Each column should have one meaning, one source, and one destination in the export.
## Frequently Asked Questions About UK Bank Identifiers
### Do UK banks have routing numbers
Not in the US ABA sense. UK domestic payments use sort codes and account numbers. For cross-border payments, you’ll usually work with IBAN and sometimes BIC.
### Is a sort code the same as a routing number
Not exactly. It’s the closest UK domestic equivalent in practical use, but it belongs to a different banking framework and shouldn’t be treated as a drop-in ABA replacement.
### Can I use only a sort code to pay a UK supplier from the US
Often, no. For an international transfer, the sending bank or provider will usually want internationally recognized beneficiary data such as IBAN and BIC, depending on the payment route.
### Do I always need a BIC for UK or European payments
Not always. Requirements vary by bank, country pair, and payment method. The safe approach is to collect it when onboarding cross-border beneficiaries unless your bank or platform clearly states it isn’t required.
### Why did my payment file fail even though the bank details looked correct
The most common reasons are wrong rail, wrong field mapping, incomplete beneficiary data, stale master data, or domestic identifiers being used where an international format was required.
### What should I store in the vendor master
Store payment instructions by payment context, not as one generic bank record. A supplier may need one setup for local collections and another for inbound international transfers.
If your team prepares SEPA remesas from Excel, CSV, JSON, or older banking formats, GenerateSEPA gives you a practical way to convert those files into valid SEPA XML, map fields correctly, and reduce avoidable submission errors before they reach the bank.
Frequently Asked Questions
- Do UK banks have routing numbers?
- Not in the US ABA sense. UK domestic payments use sort codes and account numbers. For cross-border payments, you usually work with IBAN and sometimes BIC. Treating a sort code as a routing number is one of the most common causes of failed batch payments to the UK.
- Is a sort code the same as a routing number?
- Not exactly. A sort code is the closest UK domestic equivalent to a US routing number, but it identifies a bank and branch within the UK domestic system, not within the US ABA framework. You should keep separate fields in your ERP for ABA routing number, sort code, IBAN and BIC instead of forcing them into one column.
- Can I pay a UK supplier from the US using only a sort code?
- Usually not. For an international transfer, the sending bank or payment provider will normally require internationally recognized beneficiary data, which means an IBAN and often a BIC. Domestic UK details alone are rarely enough for cross-border processing and may cause the payment to be rejected or repaired.
- Why did my payment file fail even though the bank details looked correct?
- The most common reasons are wrong rail, wrong field mapping, incomplete beneficiary data, stale master data, or domestic identifiers being used where an international format was required. A clean validation step before file generation, including IBAN structure checks, prevents most of these avoidable rejects.
