A reference number is a short identifier attached to a payment so the recipient can match it to the right invoice or account. It's the same code whether you call it a bank reference, payment reference, or order reference. You'll see it on bank statements, receipts, and remittance emails, and you'll be asked for it whenever you make a transfer.
A bank reference number and a payment reference number are both unique tracking codes that link a specific payment to its purpose. The terms get used in different places and mean slightly different things. This guide covers what each one is, where you'll find them, and why they matter when something goes wrong with a transaction.
The short version: in everyday use the two phrases are largely interchangeable. For a tight definition of the term itself, see our glossary entry on payment reference. The difference is mostly about who's using the term and where they're looking — passive (looking at a statement) or active (sending a payment). The rest of the page splits along that line.
Quick guide: account reference, sort code reference and transaction reference#
Before we get into the long-form sections, here's a clean breakdown of the four reference variants people ask about most often. They sound similar and they're often used interchangeably, but each one identifies a different thing inside a UK payment.
- Bank reference number — the code that lands on a bank statement next to a specific transaction. The recipient's bank doesn't generate this; the sender or the originating system supplies it.
- Account reference number — the identifier a business assigns to your account with them (utility account, council tax account, mortgage account, gym membership). Tied to you, not to one payment. It usually stays the same for years and you quote it every time you pay.
- Sort code reference — informal shorthand for the six-digit sort code (e.g. 20-00-00 for Barclays in the City) plus the routing identifier that tells the system which UK branch the destination account sits at. The sort code itself isn't a payment reference, but people often ask about it under the same umbrella because both appear on bank transfer forms.
- Transaction reference number — the unique ID generated by the payment system the moment a transaction is initiated. Sometimes called a transaction ID, payment ID, or in card-acquiring contexts an authorisation code. One per payment, generated by the rails (Faster Payments, Bacs, CHAPS, the card scheme, or the gateway), not by you.
The shorthand to remember: an account reference identifies you, a transaction reference identifies one payment, a sort code identifies a branch, and a bank reference is whatever lands in the description field on the statement. Often the same number ends up playing two of those roles. That's fine, as long as everyone reading the statement knows what they're looking at.
Looking at a reference number on a statement, card or receipt#
This first half is for anyone reading a reference number that's already on a document. You're not sending a payment — you're trying to work out what the number in front of you is for, where it came from, and what to do with it.
What is a bank reference number?
It works like the order number on an online purchase. That short string of letters and numbers connects a payment to a specific invoice, account, or transaction, so the recipient's finance team can match the money to the right invoice without guessing.
For any business handling more than a handful of payments a day, the reference is what makes automated reconciliation possible. Without it, finance teams spend afternoons trying to match anonymous bank credits to outstanding invoices using just the amount and the sender's name, which is slow and error-prone.
A consistent reference scheme is what makes finance ops work at volume. It turns a stream of anonymous credits into a record you can search, reconcile, and audit.
The reference number does three things at once. It matches incoming money to an invoice or account, gives support teams an instant lookup if a customer queries the payment, and creates an unambiguous audit trail for finance and compliance.
Where to find a reference number on a statement, card or receipt
Once a payment has happened, the reference shows up in three predictable places. On the bank statement line for the transaction. In the transaction detail screen of an online banking app. And on any receipt or remittance advice tied to that payment.
If you're holding a payment receipt or a remittance email, the reference is usually labelled "Reference", "Our ref", or "Payment reference". On a bank statement it's tucked into the description field next to the amount. Some banks truncate long references on the statement view but keep the full string in the underlying transaction detail — so if the visible text looks cut off, click into the transaction.
For payments tied to a fixed account — council tax, a mortgage, a utility bill — the same reference recurs on every statement. For one-off payments, the reference will be unique to that transaction.
What an account reference number actually is
An account reference number is the identifier a business gives you when you open an account with them. It's not the same as your bank account number — your bank account number is set by your bank and lives on the card or in your banking app, whereas the account reference lives on the supplier's side. It identifies you in their billing system.
Most utility bills, council tax bills, housing rent statements, mortgage statements, gym memberships, and broadband bills carry an account reference somewhere on the front page, usually near the top right or alongside the words "Account number" or "Customer reference". When you pay that bill by bank transfer, you type the account reference into the bank's "Reference" field. The supplier's reconciliation system then knows which account to credit the moment the payment arrives.
A few practical points worth knowing. Account references almost never change — once a utility company has issued you an account reference, it stays the same across years of bills and statements. They can be longer than they look on the bill: some companies pad them with leading zeros, others append a check digit. Type the whole string, including zeros. And they're not universal — your British Gas account reference is meaningless to Octopus, and vice versa. Each supplier issues its own.
If you ever lose an account reference, every supplier we've seen prints it on the most recent bill or shows it in the account-holder login on their website. Phoning support and asking for it works too, but they'll ask for ID verification first.
Sort code reference — what it really means
The phrase "sort code reference" comes up in two distinct contexts and people often mix them up. Here's the split.
First context: a UK sort code is the six-digit number, usually formatted as three pairs (12-34-56), that identifies a specific bank and branch in the UK. Every UK current account has one. When someone asks for your "sort code reference", they normally mean the sort code itself — the six digits — which they need to route a payment to your bank. The sort code is not a payment reference and won't appear in the reference field on a statement. It appears in the routing fields of the transfer form.
Second context: in older Bacs and CHAPS messaging, every transaction includes a sort code field alongside an account number and a reference field. Some businesses' internal systems lump the sort code and the reference together and call the combination a "sort code reference" for their own reconciliation purposes. This is internal jargon, not standard banking terminology.
If a supplier or recipient has asked for your sort code reference, ninety-nine times out of a hundred they want your six-digit sort code. You'll find it on the front of your debit card, in your banking app under "Account details", or printed on any bank statement at the top of the page.
For more on how UK rails route payments, see instant bank transfer and Faster Payments. The sort code is the routing key that tells those systems which bank and branch to deliver the credit to.
How standardised references changed banking
Before the structured systems we rely on today, banking ran on handwritten ledgers. Tracking a payment depended on a vague description, a name that could be misspelled, or the memory of a clerk. Slow, error-prone, and impossible at scale. The breakthrough came in the mid-20th century, when UK banks introduced sort codes — six-digit codes that gave every branch a unique, predictable identifier. The staggered rollout from 1957 onwards replaced the inconsistent identifiers used by London's clearing banks and slashed manual sorting errors.
That standardisation laid the groundwork for everything that followed. Once each branch had a stable code, machines could finally read and route cheques and payment instructions without a human in the loop. Transaction volumes scaled from thousands to millions per day, and the risk of sending funds to the wrong place dropped dramatically.
Standardised references weren't an admin tweak — they made banking automation possible. Manual matching by clerks gave way to machine-readable routing.
That same architecture now supports modern infrastructure like Bacs and CHAPS, which together process billions of transactions every year. Every time a correct reference is used, it reinforces the integrity of a system that took decades to build.
Choosing a reference for a payment, bill or invoice#
This second half is for anyone on the active side of a payment — sending money, raising an invoice, or setting up a transfer. The reference matters here because it's what tells the recipient what your payment is for. Get it wrong and the money still moves, but matching it back to the right invoice or account becomes someone else's problem.
What is a payment reference number?
A payment reference number is the identifier attached to a transaction as it moves through a payment system. The sender, the bank, and the recipient all use it to refer to the same payment. Depending on context, the same number goes by different names. It can be called an "invoice reference" when it's printed on a bill for the customer to quote, or a "transaction ID" when it's generated by a card gateway. It might also be a merchant reference number when it's the merchant's internal lookup code, or a "bank reference number" when it lands on a statement line.
You'll typically see payment reference numbers in three places. They appear on invoices (where customers type them into their bank when paying), on bank statements beside each transaction line, and in payment gateway dashboards (Stripe payment intents, Worldpay authorisation IDs, and so on). For a tight definition of the term itself, see our glossary entry on payment reference.
Transaction reference number, transaction ID and authorisation code — how they differ
People use "transaction reference number" to mean three slightly different things depending on which payment rail moved the money. Worth pulling apart, because if a customer phones up asking about "the transaction reference", knowing which one they mean saves twenty minutes.
On a card payment, there are usually three identifiers attached to a single transaction:
- Authorisation code — a short six-digit code returned by the card issuer at the moment of approval. It proves the issuer said yes. It's what a customer reads out from a receipt if you ask them to confirm a card payment went through.
- Transaction ID (TID) — a longer alphanumeric string generated by the acquirer or the gateway. This is the one your acquirer uses on settlement reports and is what you'd quote in a chargeback dispute.
- Merchant reference — the value your own checkout or order system supplied to the gateway when initiating the payment. This is the one your finance team cares about, because it ties the card transaction back to an order ID or invoice number in your systems. See our glossary entry on merchant reference number.
On a bank transfer (Faster Payments, Bacs, CHAPS), there's a single transaction reference assigned by the rail at the point of submission. UK Faster Payments uses a UTR — Unique Transaction Reference — which lets you trace a payment if it goes missing or arrives late.
If you ever need to investigate a problem payment, ask which identifier the other party has. Authorisation code for issuer-side queries, TID for acquirer-side queries, UTR for bank transfers, and merchant reference for queries inside your own order system.
Bank reference number vs payment reference number — what's the difference?
In everyday use these two terms are largely interchangeable. Both describe a unique identifier tied to a transaction, and both serve the same purpose — making sure money ends up matched to the right invoice or account. The difference is really about who's using the term and where they're looking.
"Bank reference number" is what banks and accounting teams say. It's the code on bank statements and in reconciliation reports, and it's the field accounting software matches against. "Payment reference number" is the broader phrase — it covers bank references plus gateway-generated transaction IDs, customer-facing invoice codes, and any other identifier attached to a specific payment. If a customer asks about "the payment reference" on an invoice, they mean the code to quote when making a bank transfer. If an accountant asks about "the bank reference" on a statement, they mean the field their reconciliation software reads. Same concept, two vantage points.
References on card payments — what happens behind the scenes
Card payments don't use the same reference field as a bank transfer. The customer never types a reference. Instead, your checkout (or the agent taking the call) supplies a merchant reference to the payment gateway at the moment the transaction is created, and the gateway returns its own transaction ID once the card issuer authorises the payment.
For card payments taken over the phone, this matters more than people realise. If an agent is reading card numbers off a screen — or hearing them spoken into a phone — that whole call sits inside PCI DSS scope until the card data is masked. We built DTMF masking precisely so the customer types their card details on their own keypad while the merchant reference flows through your CRM untouched. The reference identifies the order, the DTMF stream carries the card data, and the two only meet again on the gateway's settlement report. For the wider story see our blog on PCI compliance for call centres.
The result on the merchant side: the bank statement shows a deposit from the acquirer with the acquirer's batch reference, not the customer's name or invoice number. Your reconciliation software bridges the gap by matching the merchant reference between the order system and the acquirer's settlement file. That bridge depends on the merchant reference being unique, sensibly formatted, and present on every transaction.
The common types of payment reference and where they fit
Not every reference does the same job. Some are tied to a single transaction, some to a customer, some to an invoice. Knowing which is which helps when you're choosing what to put in the reference field.
- Customer reference — identifies the person or organisation paying. Stable. Used for recurring payments to the same supplier.
- Invoice reference — identifies one specific invoice. Changes with each bill. Used for one-off payments.
- Transaction reference — identifies one specific transaction on a payment rail. Generated by the rail or the gateway, not the customer.
- Merchant reference — internal identifier from the merchant's order system. Used by the merchant for reconciliation and by the customer for any after-sale queries.
- UTR (Unique Transaction Reference) — the unique ID assigned to UK Faster Payments transactions. Used for tracing missing payments.
Pick the customer reference for recurring bills (utilities, council tax, mortgage). Pick the invoice reference for one-off payments to a supplier. Use the merchant reference internally to tie everything together.
What to do when a reference is wrong, missing or rejected
The vast majority of payment problems we see in support don't come from the payment failing — they come from the reference being wrong, missing or truncated. Here's the practical playbook.
Reference rejected at the point of payment. Some banking apps validate the reference format before letting you send. If the recipient's account reference has a check digit and you mistype, the app might warn you. Re-check the number on the bill, watch for leading zeros, and try again. If the bank still rejects it, the issue is usually with the recipient's mandate setup, not your typing.
Reference missing on a payment you've already sent. The payment will still arrive, but the recipient won't know what it's for. Email the supplier with the date, amount and sort code/account number you paid from, and the reference you should have used. They can match it manually. Most billing teams handle this every day.
Reference truncated on the statement. UK Faster Payments allows up to 18 characters in the reference field. Bacs allows up to 18 too. Some older interfaces show only the first 12 — frustrating but the full string is in the underlying transaction data. Ask the recipient to check the transaction detail rather than the statement line.
Reference correct but money landed in the wrong account. This is the dangerous one. UK banks rolled out Confirmation of Payee (CoP) to help catch mismatches between the account name and the destination details before money moves. If you bypassed the CoP warning and the payment landed somewhere wrong, contact your bank within 24 hours. They can sometimes recall the funds, but speed matters.
Reference numbers for cross-border payments
UK-to-UK references are simple. Cross-border payments add layers. The SWIFT messaging standard (MT103 for single customer credit transfers) carries a structured reference field plus free-text fields, and the rules for what counts as a valid reference change across jurisdictions.
For payments inside SEPA (Single Euro Payments Area), the reference field uses the ISO standard structured creditor reference — sometimes called an RF reference. It starts with "RF" followed by two check digits and up to 21 characters. Recipients in Germany, Belgium, the Netherlands and the Nordics often require this format for automated reconciliation. If a European supplier sends an invoice with an RF reference, copy it character-for-character, including the RF prefix.
For payments outside SEPA — to the US, Asia, the Middle East — the reference travels in the SWIFT message's remittance information field. There's no character-by-character standard, so the safe move is to use a short, clean alphanumeric string and avoid punctuation or spaces. Banks correspondent-routing a SWIFT payment can and do strip out characters they don't recognise.
If you're a business that takes payments from international customers, give them a short reference. Twelve characters or fewer, no spaces, no special characters. It survives the journey across rails.
How reference numbers fit into reconciliation
For finance teams, the reference number is the only thing standing between a clean reconciliation run and an afternoon spent matching credits to invoices by hand. The tighter the reference scheme, the lower the manual work.
Good practice we see across our customer base: assign a unique reference at invoice creation, print it on every customer-facing document, embed it in the payment link or QR code where possible, and configure the accounting system to match against it automatically. When a credit arrives without a reference — or with a reference the system can't find — the credit goes into a holding queue rather than into the wrong account.
The holding queue is the single most important detail. Auto-matching with no holding queue eventually allocates a credit to the wrong customer, and that's harder to unwind than dealing with the unmatched credit on the day. Build the queue, review it daily, and the matching rate climbs.
For contact-centre teams taking telephone payments, the merchant reference assigned at the start of the call is what threads the whole transaction together — from the agent's CRM record, through the telephone payment capture, into the gateway, and back to the bank statement. Our contact-centre customers typically use the call's CRM case ID as the merchant reference, so any subsequent customer query lands back on the original agent's case.
Frequently asked questions#
What's the difference between a bank reference number and an account reference number?
A bank reference number is the description text attached to one specific payment on a bank statement. An account reference number is the identifier a supplier uses for your account with them, and you quote it on every payment to that supplier. The supplier-assigned account reference is what you usually type as the bank reference when paying.
Is the sort code the same as a sort code reference?
For most purposes, yes. "Sort code reference" is informal phrasing for the six-digit UK sort code (formatted as 12-34-56) that identifies a bank and branch. The sort code routes the payment to the right bank; it's not a payment reference in the reconciliation sense.
How long can a UK payment reference be?
UK Faster Payments and Bacs both allow up to 18 characters in the reference field. SEPA payments allow up to 35 characters for structured creditor references (RF format) or 140 characters for free-text remittance info. SWIFT cross-border payments depend on the message type and the correspondent banks, but short alphanumeric strings travel best.
What's a transaction reference number on a card payment?
It depends on which identifier the person asking has. Card payments have three: an authorisation code (issuer-side, six digits), a transaction ID or TID (acquirer-side, longer string), and a merchant reference (your own order system's ID). For chargebacks use the TID; for customer queries use the merchant reference; for issuer queries use the authorisation code.
What's a UTR and how do I find one?
UTR stands for Unique Transaction Reference. UK Faster Payments assigns one to every successful transaction at the point of submission. You find it in the transaction detail in your banking app, usually labelled "Payment reference", "FP reference", or "Transaction ID". You'd quote the UTR when investigating a missing or delayed payment.
Can I send a payment without a reference?
Technically yes — UK banks don't require a reference for a personal transfer. The payment will still complete. But the recipient won't know what it's for, and if you're paying a business, the credit will sit unallocated until someone matches it manually. Always include a reference for a business payment.
What happens if I use the wrong reference?
The money still moves to the correct account, because the routing is set by the account number and sort code, not the reference. The recipient just won't know which invoice or account to credit. Email the recipient with the date, amount, your sort code and account number, and the reference you should have used. They'll match it manually.
Why does my bank statement only show part of the reference?
Some banking interfaces truncate long references in the statement view to keep lines compact. The full reference is stored in the underlying transaction record. Click into the transaction detail in your banking app — the full string should be visible there. If you're working from a PDF statement, ask the bank for the underlying transaction record or check online banking.
Where does the reference go when paying through a payment link?
A payment link generated by a card gateway carries the merchant reference inside the URL or the gateway's backend session. The customer never sees or types it. When the card settles, the merchant reference flows through to the acquirer's settlement file, which is what your reconciliation system reads. We cover this pattern in detail on our payment links page.
