A successful card payment does not complete the financial process.
The transaction may be authorised today, captured later, included in a settlement batch tomorrow and reach the business bank account after processing fees, refunds, chargebacks or other adjustments have been applied.
Finance then needs to establish:
- which customer payments were included;
- which orders or invoices they relate to;
- which fees were deducted;
- whether refunds were included;
- whether chargebacks or other adjustments were deducted;
- which legal entity, store or business unit owns the revenue;
- which currency was used;
- which accounting entries should be created; and
- whether the amount arriving at the bank is correct.
That process is payment reconciliation.
For a business processing a handful of payments each day, reconciliation may be relatively straightforward.
For a company processing thousands of transactions through multiple gateways, merchant accounts, stores, currencies or software platforms, it becomes part of the payment architecture itself.
A payment integration is not really complete if checkout is automated but the finance team still has to reconstruct every settlement manually.
What Is Payment Reconciliation?
Payment reconciliation is the process of matching internal business records with information supplied by payment providers and banks to confirm that transactions, deductions and settlements have been recorded correctly.
For card payments, that typically means connecting several records:
Order / Invoice → Payment Transaction → Refunds or Adjustments → Settlement Batch → Bank Deposit → Accounting Ledger
The exact process varies by business and payment provider.
However, the objective remains the same:
Can you explain how the original customer transaction ultimately became the amount recorded in your accounts and received into your bank?
Payment Reconciliation vs Bank Reconciliation
These terms are related, but they are not the same.
Bank reconciliation
Bank reconciliation checks whether entries within the accounting records correspond with movements on the business bank account.
Payment reconciliation
Payment reconciliation goes further into the payment-processing layer.
It can explain how:
- hundreds or thousands of customer transactions;
- processing fees;
- refunds;
- chargebacks;
- foreign exchange;
- reserves;
- adjustments; and
- other payment events
resulted in the net settlement appearing in the bank.
Bank reconciliation might confirm that:
£47,600 arrived from the payment provider.
Payment reconciliation should be able to explain why the settlement was £47,600.
Why Doesn't Card Turnover Match the Amount Paid Into the Bank?
Because payment providers commonly settle transactions as a net amount rather than depositing each gross customer payment individually.
Consider a simplified example:
| Settlement component | Illustrative amount |
|---|
| Gross card transactions |
£50,000 |
| Refunds |
- £1,000 |
| Chargebacks / adjustments |
- £500 |
| Payment-processing fees |
- £900 |
| Illustrative net settlement |
£47,600 |
The £47,600 bank entry is therefore not a missing £2,400.
It is the net result of several payment events.
In a real payment environment, the calculation may be more complicated because transactions, fees and adjustments do not necessarily fall into the same reporting or settlement period.
How Does Card Payment Reconciliation Work?
A useful reconciliation process normally connects three main layers.
1. Internal transaction data
This is what the business believes happened.
Depending on the organisation, the source could be:
- EPOS;
- ecommerce platform;
- ERP;
- CRM;
- booking system;
- billing platform;
- subscription system;
- order-management platform; or
- an internal database.
It might say:
Order 98452 – customer paid £250.
2. Payment-provider data
The gateway, PSP or acquirer should provide information about what happened to that payment.
This can include:
- merchant reference;
- provider transaction ID;
- authorisation status;
- capture status;
- payment method;
- currency;
- gross amount;
- refunds;
- chargebacks;
- fees;
- settlement date;
- settlement batch; and
- net amount.
3. Bank and accounting records
Finally, the business needs to match the provider's settlement with:
- the bank deposit;
- sales ledger;
- fee accounts;
- refund accounts;
- chargeback entries;
- FX entries where relevant; and
- other required accounting records.
The result should be a traceable path from sale to cash.
The Most Important Reconciliation Field: A Useful Payment Reference
Reliable reconciliation becomes considerably easier when transactions share meaningful identifiers across systems.
For example:
ERP Invoice 10482 → Gateway Merchant Reference INV-10482 → PSP Transaction ID → Settlement Batch 8762
That allows finance or software to follow the transaction through different systems.
Useful references might include:
- order ID;
- invoice number;
- booking reference;
- customer account reference;
- PSP reference;
- merchant reference;
- refund reference;
- settlement reference; or
- batch number.
Provider-generated and merchant-generated identifiers should both be retained where possible.
Adyen, for example, documents the use of both its PSP reference and merchant reference to track and combine payment information across different reports.
Transaction Reconciliation vs Settlement Reconciliation
Businesses should understand the difference between reconciling transactions and reconciling settlements.
Transaction-level reconciliation
This asks:
What happened to this specific £250 customer payment?
The answer may include:
- authorised;
- captured;
- settled;
- partially refunded;
- fully refunded;
- charged back;
- reversed; or
- otherwise adjusted.
Settlement-level reconciliation
This asks:
Which transactions and deductions created this £47,600 payout?
One settlement can potentially contain:
- many card transactions;
- several payment methods;
- refunds;
- chargebacks;
- fees;
- adjustments; and
- other account movements.
Providers may therefore offer both transaction-level and batch-level reporting.
Adyen's current reporting documentation, for example, distinguishes between transaction-level settlement reconciliation and batch-level reconciliation against bank statements.
Is reconciliation driving your payment-provider decision?
If payments need to connect with accounting, ERP, CRM or other business software, reporting should be considered before choosing the provider.
Merchant Advice Service can help you understand the wider payment requirement before identifying providers that may support the reporting and integration you need.
Get personalised recommendations
What Should Be Included in Payment Reconciliation?
A useful reconciliation process should account for more than successful card sales.
Payments
Match successful payments to the correct:
- customer;
- order;
- invoice;
- booking;
- subscription; or
- other business record.
Refunds
A refund should remain linked to the original transaction wherever possible.
The finance record may need to show:
- original sale;
- refund amount;
- partial or full refund;
- refund date;
- provider reference;
- customer record; and
- settlement impact.
Chargebacks and disputes
A card transaction can appear to have settled successfully and later become subject to a dispute.
The reconciliation process therefore needs to account for:
- original payment;
- chargeback amount;
- chargeback fee where applicable;
- representment or dispute outcome;
- reversal where successful; and
- the relevant settlement adjustment.
Processing fees
Processing fees may include several components depending on the provider and pricing structure.
Our merchant account fees guide explains areas including interchange, scheme costs and provider margin.
Foreign exchange
Businesses taking several currencies may need to reconcile:
- transaction currency;
- settlement currency;
- conversion rate;
- FX charges;
- provider conversion entries; and
- the final amount received.
Reserves and delayed funds
Where a payment provider retains funds under a reserve arrangement, gross processed sales and actual available settlement can differ further.
Finance needs to distinguish between:
money earned → money processed → money currently withheld → money settled.
Why Settlement Dates Cause Reconciliation Problems
The date a customer pays is not necessarily the date the transaction appears in the business bank account.
There can be several relevant dates:
- transaction creation date;
- authorisation date;
- capture date;
- booking date;
- settlement date;
- value date; and
- bank-credit date.
Those distinctions become important around:
- month end;
- year end;
- weekends;
- bank holidays;
- different time zones;
- multi-currency payments; and
- providers operating several settlement batches per day.
Adyen's reconciliation documentation specifically distinguishes booking dates from value dates and warns that reporting periods and time-zone differences can create reconciliation mismatches.
This is one reason simply matching transactions by calendar date can fail.
Why Refunds Can Appear in a Different Settlement
A customer may buy something on Monday and receive a refund on Friday.
The original transaction and refund may therefore affect different settlement batches.
For example:
Monday → customer pays £1,000
Tuesday → original £1,000 transaction settles
Friday → business refunds £250
Following settlement → £250 refund is deducted
If reconciliation only looks at the original order, Friday's payout can appear unexpectedly short.
This is why refunds should retain a link to the original transaction while also being treated as their own financial event.
Why Chargebacks Make Payment Reconciliation More Complicated
Chargebacks can create an even longer transaction lifecycle.
A sale may initially appear:
authorised → captured → settled → complete
and then become:
disputed → amount deducted → evidence submitted → dispute won or lost → possible reversal
Several settlement periods can therefore relate to one original sale.
This is particularly important for businesses with meaningful chargeback volumes.
Payment Reconciliation Across Multiple Payment Providers
Reconciliation becomes considerably more difficult when a business uses more than one PSP or acquirer.
This can happen because the company uses:
- different providers in different countries;
- different acquirers for routing or resilience;
- separate providers for online and face-to-face payments;
- local acquiring in overseas markets;
- alternative payment methods;
- several legal entities;
- multiple ecommerce brands;
- marketplace payments; or
- different providers following acquisitions.
Each provider can have different:
- transaction IDs;
- file formats;
- settlement schedules;
- fee structures;
- currencies;
- time zones;
- report names;
- API structures; and
- definitions.
Finance can therefore end up translating several different payment languages into one accounting ledger.
Businesses considering this architecture should read our acquirer-agnostic payment gateways guide.
Payment Reconciliation for Multi-Site Businesses
A multi-site business may need reconciliation at several levels.
For example:
Group → Legal Entity → Merchant Account → Store → Terminal → Settlement → Individual Transaction
Head office may need consolidated reporting, while individual locations may need to understand their own daily takings.
Useful reporting fields can therefore include:
- store;
- terminal;
- merchant ID;
- legal entity;
- cost centre;
- department;
- channel;
- currency; and
- business unit.
This should be discussed before selecting payment technology if the business needs provider data to feed directly into financial reporting.
Payment Reconciliation for Marketplaces and Platforms
Marketplaces and platforms can add another layer because the customer's payment may need to be split between several parties.
For example:
Customer pays £200 → platform retains £20 → seller receives £180
The platform may need to reconcile:
- customer transaction;
- seller allocation;
- platform fee;
- payment-processing fees;
- refunds;
- chargebacks;
- seller payout;
- platform balance; and
- bank movements.
If one customer payment contains several sellers, allocations or commissions, the reconciliation data needs to preserve those relationships.
Our split payments guide explains this payment model in more detail.
Batch Payment Reconciliation
Card payments are frequently settled in batches rather than as individual bank transfers.
A settlement batch can contain many underlying transactions and adjustments.
Batch reconciliation therefore asks:
Does the net value of all relevant entries in this batch equal the amount actually settled?
The batch might include:
Successful payments − refunds − chargebacks − fees ± adjustments = settlement amount
For businesses processing substantial volumes, this approach can be considerably more practical than attempting to match every card sale directly against the bank statement.
See our guide to batch payment processing for more detail.
Manual vs Automated Payment Reconciliation
Payment reconciliation can range from a spreadsheet process to a fully integrated finance workflow.
Manual reconciliation
A smaller business might:
- download a payment-provider settlement report;
- download internal sales information;
- compare the records;
- match the settlement against the bank;
- investigate discrepancies; and
- post relevant accounting entries.
This can work where transaction volumes and complexity are low.
Automated reconciliation
At higher volumes, transaction and settlement data can potentially flow automatically between:
- PSP;
- gateway;
- bank;
- ERP;
- accounting platform;
- data warehouse; and
- reconciliation software.
Matching rules can then identify entries automatically and route exceptions for investigation.
The goal should not necessarily be zero human involvement.
A better goal is:
automate predictable matching and give finance a clear exception queue for the transactions that genuinely need investigation.
What Can Be Used to Automate Payment Reconciliation?
Depending on the provider and business architecture, reconciliation data can be supplied through:
- CSV or spreadsheet reports;
- SFTP files;
- APIs;
- webhooks;
- scheduled settlement reports;
- accounting integrations;
- ERP connectors;
- data warehouses; or
- specialist reconciliation platforms.
Large payment providers increasingly expose detailed transaction and settlement data programmatically.
Stripe's Balance Transactions API, for example, provides records for movements affecting an account balance and allows automatic payouts to be associated with the balance transactions included in a particular payout.
Adyen provides settlement, payment-accounting and balance reports that can be used for transaction-level, batch-level and fee reconciliation.
The exact capability differs significantly between providers.
Reporting therefore deserves to be part of the provider-selection process rather than something finance discovers after the contract is signed.
Payment Reconciliation and ERP Integration
For an established business, the most valuable payment integration may happen after checkout.
Imagine an ERP contains:
Invoice INV-18832 – £12,500 due.
The customer pays.
A well-designed payment flow could potentially:
create payment request → process £12,500 → retain invoice reference → update invoice status → receive settlement data → allocate payment fees → reconcile bank settlement
The alternative is:
payment happens → finance receives an unexplained settlement later → employee searches several systems → invoice manually marked as paid.
The first model treats the payment as part of the financial workflow.
The second treats the gateway as an isolated checkout tool.
Our Integrated Payments guide explains how payments can connect with ERP, CRM, EPOS and accounting systems.
Payment Reconciliation and Accounting Software
Integration with accounting software can reduce manual entry, but merchants should understand exactly what information is being posted.
An integration that records only:
“£47,600 payment received”
may not provide enough detail if finance needs to understand:
- £50,000 gross sales;
- £1,000 refunds;
- £500 disputes;
- £900 fees; and
- £47,600 net bank settlement.
The required level of detail depends on the business's accounting processes and reporting requirements.
Before selecting an integration, establish whether accounting needs:
- individual transaction entries;
- daily summaries;
- settlement-batch summaries;
- fee breakdowns;
- separate payment methods;
- multi-currency entries;
- department or store allocation; or
- other dimensions.
Common Payment Reconciliation Problems
When payment records do not match, the cause is not necessarily a missing payment.
Common causes include:
Settlement timing
The transaction and bank payment occur on different dates.
Cut-off times
A late transaction may move into the following settlement batch.
Refund timing
A refund may be deducted from a later payout than the original sale.
Chargebacks
A dispute may affect settlement weeks or months after the original transaction.
Processing fees
The provider may deduct some fees from settlement while invoicing others separately.
Foreign exchange
The transaction and settlement may use different currencies or conversion dates.
Missing references
The PSP transaction cannot easily be matched back to the originating order or invoice.
Duplicate records
The same event is imported more than once.
Time zones
Two systems can assign the same payment to different calendar dates.
Partial capture
The authorised amount and final captured amount differ.
Partial refunds
Only part of an original transaction is returned.
Multiple merchant accounts
The settlement is associated with a different merchant account or legal entity from the one finance expected.
Reserves
Part of the processed balance is retained rather than immediately settled.
Payment Reconciliation and Provider Fees
Reconciliation is also one of the best ways for established merchants to understand what they are actually paying their payment provider.
A quote might show:
0.35% + interchange + scheme fees
but the real processing environment can include:
- interchange;
- scheme fees;
- provider markup;
- authorisation charges;
- gateway fees;
- international-card costs;
- FX;
- refund fees;
- chargeback charges;
- monthly charges; and
- other adjustments.
Adyen's current payment-accounting documentation, for example, explains how its reports can be used to match transaction lifecycle events with associated fees and reconcile those costs against payment-processing invoices.
For wider pricing information, see our Payment Gateway Fees UK guide.
Using more than one gateway or acquirer?
Do not wait until after implementation to decide how finance will reconcile the payments.
Tell us about the providers, software, currencies and reporting your business needs. We can help you consider those requirements when comparing payment providers.
Find suitable payment providers
What Should a Good Payment Reconciliation Report Show?
The precise fields depend on the business, but useful information can include:
- merchant account;
- merchant reference;
- provider transaction reference;
- order or invoice reference;
- transaction date;
- booking date;
- settlement date;
- payment method;
- transaction currency;
- settlement currency;
- gross amount;
- refund amount;
- chargeback amount;
- interchange where relevant;
- scheme fees where relevant;
- provider fee;
- FX adjustment;
- other adjustments;
- net amount;
- settlement batch;
- store or terminal;
- legal entity; and
- payout reference.
Not every merchant needs every field.
The question is whether the reporting contains enough information to explain the business's payment flow without repeatedly logging into several systems and manually reconstructing it.
What Should You Ask a Payment Provider About Reconciliation?
If reporting matters to the business, ask these questions during provider selection.
Can we reconcile at transaction level?
Can individual payments, refunds, chargebacks and fees be traced?
Can we reconcile at settlement level?
Can finance identify exactly what produced each bank payout?
What reports are available?
Ask for examples before contracting where possible.
Can reports be generated automatically?
Manual portal downloads may become difficult at scale.
Is data available through an API?
This can matter where reconciliation will feed an ERP, data warehouse or bespoke finance system.
Are merchant references preserved?
Can the original order or invoice identifier survive throughout the payment lifecycle?
How are fees reported?
Can finance distinguish the provider margin and other relevant processing costs?
How are refunds and chargebacks represented?
Can they be linked back to the original transaction?
Can we identify store, terminal or business unit?
This can be essential for multi-site businesses.
Can several merchant accounts be consolidated?
Large organisations may need group-level as well as merchant-level reporting.
How are multiple currencies handled?
Understand both transaction and settlement currency reporting.
What happens if we change provider?
Establish how historic reports and transaction data remain accessible following termination.
Should Reconciliation Influence Which Payment Provider You Choose?
For a small merchant with simple daily card sales, reporting differences may not materially affect provider choice.
For a larger or more complex organisation, they absolutely can.
Imagine two payment providers offering similar processing rates.
Provider A offers:
- transaction-level reporting;
- settlement reports;
- reliable references;
- scheduled report generation;
- API access; and
- good ERP integration.
Provider B offers:
- basic portal exports;
- limited settlement detail;
- poor reference mapping; and
- manual finance processes.
If Provider B costs slightly less per transaction but creates hundreds of hours of manual finance work, the apparent saving can become misleading.
The cost of accepting payments includes the operational cost of managing them.
The MAS Payment Reconciliation Test
For a complex merchant, we would break the requirement into these areas:
Transaction → Reference → Fees → Settlement → Bank → Accounting → Exceptions → Reporting
1. Transaction
Where does the sale originate and what system owns the original transaction?
2. Reference
Which identifier links the payment back to the underlying order, booking or invoice?
3. Fees
What processing, scheme, interchange, FX and other costs need to be accounted for?
4. Settlement
How are transactions grouped into payouts?
5. Bank
How does the settlement appear on the bank statement?
6. Accounting
Which entries need to be posted into ERP or accounting software?
7. Exceptions
How are missing records, refunds, chargebacks and unmatched items investigated?
8. Reporting
Can the business obtain the information at the level and frequency finance actually needs?
How Merchant Advice Service Helps With Payment Reconciliation Requirements
Merchant Advice Service does not provide accounting services or operate a reconciliation platform.
Our role is to help businesses understand their payment requirements before comparing payment providers.
For businesses where reconciliation matters, that can include:
- payment gateway reporting;
- merchant-account settlement data;
- multiple acquirers;
- multi-currency payments;
- local acquiring;
- ERP integration;
- CRM integration;
- accounting integration;
- APIs;
- webhooks;
- payment references;
- multi-site reporting;
- marketplace payments;
- split payments;
- provider switching; and
- more complex payment architecture.
That helps prevent a business choosing a payment provider first and then trying to force its finance workflow around whatever reporting happens to be available.
You can also explore payment gateway providers through The Payments Directory®.
Need payments to work properly after checkout?
Tell us how your business takes payments, which systems need the data and where the existing reconciliation process is causing problems.
We can help you consider reporting, settlement and integration alongside the wider payment-provider requirement.
Get personalised recommendations
Editorial Note
This guide is written and reviewed by Merchant Advice Service to help UK businesses understand payment reconciliation, settlement reporting and the role of payment-provider data within wider finance processes.
Merchant Advice Service is an independent payment advice and provider-matching service. We are not an accounting practice, payment processor or reconciliation-software provider.
Reporting functionality, settlement processes, file formats and integration options vary between payment providers and can change over time. Businesses should confirm current functionality directly with prospective providers.
Our information, matching and introduction service is free to businesses. MAS may receive commission or a referral fee from some commercial partners where an introduction results in a completed product or account.
Related Merchant Advice Service Content
Integrated Payments UK: EPOS, ERP & CRM Integrations
Explains how payment processing can connect with ERP, accounting, CRM, EPOS and other business software, including why reconciliation should be designed as part of the integration.
Batch Payment Processing
Further guidance on payment batches and how high-volume transaction groups can be processed and reconciled.
Acquirer-Agnostic Payment Gateways
For businesses using or considering multiple acquirers, including the additional routing, reporting and reconciliation requirements created by multi-acquirer architecture.
Payment Gateway Fees UK
Explains transaction, gateway and other processing costs that may need to be identified during payment and settlement reconciliation.
Merchant Account Fees Explained
Our wider guide to interchange, scheme fees, acquiring margin and the other costs that can appear within merchant processing and settlement reports.
Split Payments & Multi-Party Payment Processing
Explains how customer payments can be allocated between platforms, sellers and other parties and why this creates additional reconciliation requirements.
Sources & References
Adyen – Settlement Reconciliation
Official Adyen documentation explaining transaction-level and batch-level settlement reconciliation and how payments, refunds, chargebacks and processing costs can be matched to payout batches.
Adyen – Settlement Details Report
Technical documentation for transaction-level settlement reporting, including settled transactions, transaction costs and reporting across one or multiple merchant accounts.
Adyen – Payment Accounting Report
Explains how payment lifecycle events and associated processing costs can be used for invoice and fee reconciliation.
Adyen – Reconciling Payments
Shows how provider-generated PSP references and merchant references can be used to track payments and connect records across different reports.
Adyen – Preparing Reports for Reconciliation
Guidance on report periods, time zones and transaction references, including common reconciliation problems caused by inconsistent reporting periods or time-zone settings.
Stripe – Balance Transactions API
Official Stripe API documentation covering movements that affect a Stripe account balance, including charges, refunds, fees, transfers and other balance activity that can be used when reconciling payouts.
