Why does my POS sales total not match my bank deposit?

The POS usually reports sales by trading activity, while the bank receives grouped processor payouts after timing differences, fees, refunds, disputes, holds and adjustments. Cash and third-party payment methods may also sit outside the card payout.

What records do I need for retail payment reconciliation?

Keep the till sales report, processor transaction activity, payout details and bank statement. Preserve trading dates, tender types, receipt or transaction references, payout identifiers, payout dates and bank value dates.

Should gross sales equal a card processor payout?

Not necessarily. A payout can combine transactions from different trading days and can be reduced or changed by fees, refunds, disputes, reserves, holds or other adjustments.

How should I investigate a payment difference?

Start with one trading day, split sales by tender, identify the processor transactions included in each payout and match the payout to the bank entry. Then list remaining exceptions instead of editing totals to force a match.

Are delayed payouts the same as missing money?

No. A cut-off time, weekend, bank holiday, processor schedule or bank processing delay can move a valid payment into a later payout or bank date. Confirm status and references before classifying it as missing.

What should a retail system preserve for reconciliation?

It should preserve completed sales, tenders, refunds, voids, receipt or transaction references, user and store context, timestamps and useful exports. Processor payout and bank records remain separate inputs unless the product explicitly supports those integrations.

Does EzyCarto automatically reconcile payouts to bank deposits?

EzyCarto does not currently make that public claim. It can provide connected sale, receipt, reporting, store and export context as one operational input to the retailer's reconciliation process.

Is this article accounting advice?

No. It is an operational record-matching guide. Confirm bookkeeping, revenue recognition, tax and accounting treatment with a qualified accountant or bookkeeper who understands your business and payment providers.

Retail Payment Reconciliation: Match POS Sales to Bank Deposits

The till total, processor payout and bank deposit can all be correct while showing different amounts. Use this four-record map to trace the difference before treating it as lost money.

The till says the shop took GBP 1,240.

The card processor says GBP 1,087.36 is available for payout.

The bank receives GBP 842.10 the next morning.

That does not automatically mean GBP 397.90 has disappeared.

It means three different systems are answering different questions. Add cash, refunds, fees, settlement timing and another payment method, and matching one total to another becomes a poor way to investigate the day.

A retailer described the problem plainly:

"I'm trying to understand the correct accounting process from the sales report through to the bank reconciliation."

Source:

https://www.reddit.com/r/Bookkeeping/comments/1ur7qe4/how_should_shopify_sales_and_payouts_be_recorded/

The useful response is not to keep editing totals until two numbers agree. It is to map the four records between the sale and the bank.

The four records are related, but they are not interchangeable

1. Till sales

The till or POS records what happened at checkout. Depending on the setup, that can include:

gross sales
discounts
taxes
cash, card and other tender types
refunds and voids
receipt or transaction references
staff member, register, store and trading time

This record answers: what did the retail operation record as a sale, refund or reversal?

It does not prove that every card payment has settled, that a payout has been created or that the bank has received it.

2. Processor activity

The payment processor records what happened on its payment rail. It may show captured charges, pending transactions, failed payments, refunds, disputes, fees, reserves, holds and adjustments.

This record answers: what happened to the electronic payments after checkout?

It may not include cash. It may also exclude payment methods handled by another provider.

3. Payout

A payout is a group of processor activity scheduled or sent to a bank account. One payout may contain transactions from more than one trading day. One trading day may be split across more than one payout.

This record answers: which net funds did the processor group and send, and under which payout identifier?

4. Bank deposit

The bank statement records what reached the bank and when the bank applied it. Its description may contain a shortened provider name or transfer reference rather than individual receipt numbers.

This record answers: what amount entered the bank account on the value date?

The reconciliation path is therefore:

Till sales -> processor activity -> payout -> bank deposit

Trying to jump directly from the first record to the fourth hides the evidence in the middle.

A worked retail day

Consider a simplified Tuesday:

GBP 1,240 in gross sales.
GBP 120 was paid in cash.
GBP 1,000 was captured by the main card processor.
GBP 120 was handled by a separate payment method.
The main processor deducted GBP 18 in fees.
A GBP 40 refund from Monday was applied to the next available payout.
GBP 100 of late Tuesday card activity missed the processor's cut-off and moved to Wednesday's payout.

The Tuesday till sales total is still GBP 1,240.

But the main processor's Tuesday-related payout calculation might begin with only the transactions included before its cut-off, then account for the refund and fees. Cash never enters that card payout. The separate payment method follows its own report and schedule. The bank may receive the processor payout on Wednesday or later.

The example is intentionally simple. Real processors use different fields, fee models, schedules and statuses. The principle is what matters: preserve each layer and follow the references.

Current Shopify documentation illustrates this distinction. Its payout reconciliation report separates account activity, fees, refunds, disputes, adjustments, reserves, holds and payouts. Shopify also states that sales reports and payout reports can differ in timing and totals, and that third-party payment methods may not appear in the Shopify Payments payout report.

Provider reference:

https://help.shopify.com/en/manual/payments/shopify-payments/payouts/payout-reconciliation-report

That is one provider's model, not a rule for every processor. Check the documentation and exports for the providers your business actually uses.

First separate timing from exceptions

Retail teams often use the word discrepancy for two different things.

A timing difference is explained by when records move. Examples include:

transactions after a daily cut-off
weekends or bank holidays
a payout marked sent while the bank is still processing it
a refund scheduled against a later payout
different report time zones
a pending payment not yet included in a payout

An exception is an event that changes the expected amount or needs investigation. Examples include:

processor fees
refunds
chargebacks or disputes
reserves or held funds
a failed payout
a duplicate, voided or failed transaction
cash recorded in the till but compared with card deposits
split tenders
a third-party payment method reported separately
a manual adjustment

A timing difference should have a status and expected next event. An exception should have an owner, supporting reference and next action.

Do not combine both into one unexplained balancing figure. That makes the total agree today while making tomorrow harder to understand.

Run a one-day reconciliation map

Choose one ordinary trading day. Avoid the busiest or most unusual day for the first test.

Step 1: freeze the till record

Export or save the completed sales report before changing anything. Record:

trading date and time zone
gross sales
refunds and voids
totals by tender type
receipt or transaction references
store and register where relevant

If the report combines cash and electronic payments, split them before moving on.

Step 2: match electronic tenders to processor activity

For each processor, identify the captured transactions associated with the day. Keep pending, failed and refunded activity visible rather than deleting it from the working file.

Match using references and timestamps, not only amounts. Two customers can pay the same amount. A repeated GBP 24.99 is not a reliable identifier.

Step 3: group transactions by payout

Use the processor's payout identifier where available. Record:

payout amount
payout status
payout date
transactions included
fees, refunds, disputes, holds and adjustments
transfer reference

Current Shopify payout details, for example, can include charges, refunds, adjustments, reserves, fees and a transfer reference. Its documentation also notes that a payout marked deposited may still require bank processing time.

Provider reference:

https://help.shopify.com/en/manual/payments/shopify-payments/payouts/view-details

Again, use the fields supplied by your own provider.

Step 4: match the payout to the bank

Find the bank entry using the transfer reference, provider description, amount and value date. Mark the payout as matched only when the bank record supports it.

If the payout is sent but not yet visible, keep it as an open timing item. If the bank rejected it, follow the processor's failed-payout process rather than treating it as a sales shortage.

Step 5: build an exception list

Every remaining difference should have:

a category
amount
sale, transaction or payout reference
owner
next action
expected resolution date
final outcome

Useful categories include timing, fee, refund, dispute, hold, failed payment, failed payout, cash, separate processor and unknown.

An unknown item is acceptable temporarily. An unknown item silently absorbed into another total is not.

Use a daily rhythm and a weekly review

A small retailer does not need to turn every close into a long finance project.

The daily check can be narrow:

1. Confirm completed sales by tender.

2. Confirm processor activity arrived for the expected electronic payments.

3. Note pending, failed, refunded or disputed items.

4. Record payout identifiers and statuses.

5. Match bank deposits that have arrived.

6. Carry forward open timing items with dates.

Then use a weekly review for unresolved exceptions:

Which timing items should have cleared by now?
Which refunds or disputes changed a later payout?
Are fees within the expected provider structure?
Are unidentified differences repeating by store, register, tender or staff workflow?
Is a separate payment method being omitted from the review?
Does every adjustment have a reason and owner?

The goal is not merely to balance a spreadsheet. It is to make repeated operational weaknesses visible.

What your retail platform should preserve

A useful retail record should make the first part of the journey traceable. Look for:

completed sale and refund records
tender type
receipt and transaction references
store, register and staff context
timestamps with a clear time zone
void and adjustment history
reports by store and timeframe
exports that retain useful identifiers

Those records do not replace the processor's payout report or the bank statement. They give the retailer a dependable starting point and enough context to investigate exceptions.

Where EzyCarto fits

EzyCarto POS is designed to preserve connected sale and receipt context while linking checkout activity with the wider retail operation.

EzyCarto POS:

https://ezycarto.com/solutions/ezycarto-pos

EzyCarto Analytics supports sales and inventory reporting by store, product and timeframe, alongside custom reports and exports.

EzyCarto Analytics:

https://ezycarto.com/analytics

These records can support the till-sales side of a reconciliation and help a retailer investigate where an operational difference began.

EzyCarto does not currently claim to automatically reconcile processor payouts to bank deposits. Processor payout details and the bank statement remain separate records unless a supported integration explicitly says otherwise.

If you are evaluating EzyCarto, bring one real trading day to the conversation. We can show how the supported sale, receipt and reporting records would fit into your operating process without pretending that one dashboard replaces every financial record.

Do not force a match

The till total is not the bank deposit.

It is the start of an evidence chain.

Reconcile one trading day across all four records. Preserve gross sales. Separate tenders. Follow processor transactions into a named payout. Match that payout to the bank. Give every remaining difference a category, owner and next action.

For accounting, tax and revenue-recognition treatment, confirm the process with a qualified accountant or bookkeeper who understands your business and payment providers.

The operational test is simpler:

Can your team explain how each recorded payment moved from checkout to processor, from processor to payout, and from payout to the bank without changing the evidence to make the numbers agree?

Related guide:

https://ezycarto.com/blog/your-pos-is-not-offline-ready-until-the-recovery-plan-is-clear

The Till Total Is Not the Bank Deposit: A Retail Payment Reconciliation Map

Key takeaways