How to Reconcile Online Orders, Payments and Refunds

Reconciliation is the process of proving that the orders fulfilled by the takeaway agree with the payments taken, refunds issued, provider statements received and money deposited in the bank. It should identify differences while staff can still investigate them, not months later during bookkeeping.

Prepare the data before starting

For each channel, obtain:

• completed, cancelled and rejected orders;
• gross order values and price components;
• payment transaction status;
• refunds, voids and chargebacks;
• provider or marketplace settlement statements;
• bank deposits;
• cash and terminal batch totals where relevant;
• the accounting export.

Use the same date basis throughout. Order date, payment date, settlement date and bank date can differ. Mixing them without a clear rule produces false discrepancies.

Step 1: reconcile orders to payments

Order position	Expected payment position	Exception to investigate
Completed card order	Successful captured or settled payment	No payment, lower amount or duplicate payment
Rejected order	No captured payment or a complete reversal/refund	Customer charged despite rejection
Cancelled before fulfilment	Void or agreed refund according to policy	Payment retained without a documented reason
Cash order	Cash received and included in till or driver return	Order completed with no cash record
Partially refunded order	Original payment plus traceable partial refund	Refund recorded in POS but not sent to provider

Start with exceptions rather than manually checking every normal order. The system should flag:

• payments without orders;
• orders without payments;
• amount mismatches;
• duplicate transactions;
• unknown payment outcomes;
• refunds without a linked order;
• manual adjustments without a reason.

Step 2: reconcile refunds and chargebacks

For every refund, retain:

• order reference;
• reason;
• full or partial amount;
• person authorising it;
• system used to submit it;
• provider reference;
• customer communication;
• accounting treatment.

A POS adjustment does not necessarily move money. Confirm that the refund was actually submitted through the gateway or marketplace. Conversely, a marketplace may issue a customer adjustment that does not appear in the restaurant POS until the next statement.

Track chargebacks separately. They may remove funds after the original settlement and can include an additional fee.

Step 3: rebuild each settlement

For a direct payment provider, the settlement may be:

successful captured payments − refunds − chargebacks − provider fees ± adjustments = settlement

For a marketplace, the statement may also include commission, delivery-related deductions, restaurant-funded promotions, support adjustments and previous-period corrections.

Do not force the numbers to match by posting a balancing entry to “fees”. Identify the actual cause.

Step 4: match settlements to the bank

• Use provider payout references where available.
• Allow for weekends, bank holidays and stated settlement delays.
• Check whether several trading days are grouped into one deposit.
• Check whether one statement is split across deposits.
• Investigate bank-detail changes, reserves or failed payouts immediately.

A missing bank deposit is not resolved merely because the provider dashboard says “paid”. Obtain the trace or support reference and retain the evidence.

Step 5: reconcile accounting categories

Confirm that the bookkeeping process distinguishes:

• gross food and drink sales;
• delivery charges;
• service charges and tips;
• discounts;
• VAT categories;
• refunds;
• marketplace commission;
• payment-processing fees;
• chargeback losses and fees;
• cash differences.

Provider terminology is not tax advice. Ask the accountant how each category should be posted for the specific business.

Daily, weekly and monthly rhythm

Frequency	Control
Daily	Orders to payments, cash and terminal totals, failed payments, refunds raised
By settlement	Provider statement to bank deposit, deductions and adjustments
Weekly	Old exceptions, missing payouts, repeated refund causes, manual overrides
Monthly	Channel totals to bookkeeping, VAT mapping, unresolved balances and supplier-fee review

Exception log

Maintain a simple log with:

• date discovered;
• order or payout reference;
• amount;
• type of difference;
• systems checked;
• owner;
• next action;
• resolution date;
• root cause.

Repeated differences should trigger a process or integration change. Reconciliation is not successful if staff correct the same mapping error every week.

Controlled automation

Automation can match stable references and expected amounts, but retain human review for:

• partial refunds;
• split settlements;
• marketplace adjustments;
• chargebacks;
• orders recovered manually after an outage;
• tax-category exceptions.

Test automated rules against a known period before allowing them to post entries without review.

Completion checklist

• Every completed order has a payment or documented cash route.
• Every refund has evidence that money was moved.
• Every statement rebuilds to the stated net payout.
• Every payout matches the bank or has an open support case.
• Gross sales and deductions are recorded separately.
• Old unresolved exceptions have an owner.
• Exports are retained in a readable format.

Related guides

• Payments — the main guide for the wider topic.
• Receipts and Reconciliation — the broader guide that frames this implementation.
• Record Keeping for Tax and Compliance — a closely related operational control to review alongside this page.
• How to Set Up Digital Receipts — a closely related operational control to review alongside this page.

Official guidance checked

• HMRC: VAT record keeping
• GOV.UK: records required for VAT
• GOV.UK: payment obligations and disputed card payments

Guidance checked: 24 July 2026. Settlement timing, statement fields and accounting treatment are provider- and business-specific.