Retail payment reconciliation software follows the money from the sale to the bank: what the POS recorded by method, what was counted in the drawer, what the card terminal settled, what the payment processor paid out and deducted, and what arrived in the account. It matches each step to the next and lists where they differ. With Pentoggle, a retailer can describe how they take payment and generate the starting application around it.
This page is about takings from the store's own channels. Marketplace settlements, which arrive net of a different set of deductions, are Marketplace Order and Payment Management Software. The daily close that produces the expected figures is Retail POS Software. Paying suppliers is Retail Vendor Payment Software. Where a variance turns out to be a control failure, the pattern belongs in Retail Loss Prevention Software.
Most retailers already run an accounting system such as QuickBooks, Tally or Xero, which records the bank receipts and, with the accountant, the fees. That stays where it is. What is often still managed outside it is the chain between the sale and the receipt: the shift-level cash count, the terminal batch that did not match the till, and the processor payout that was short by an amount nobody traced.
Key takeaways
- A day's takings pass through four records on the way to the bank, and a difference can appear at any step. Reconciling bank to POS in one jump hides where the gap opened.
- Cash and card fail differently. Cash variance is counted at the drawer and belongs to a shift; card variance is usually a timing or a fee question and belongs to a batch.
- Processor payouts are net figures. Matching the amount that arrived is not the same as checking that the fees and holds behind it were correct.
- A variance without a status is a number that gets rediscovered every month. Each difference needs an owner and an outcome.
- A useful number is the share of daily takings reconciled through to bank within a defined period, read alongside the value of open variances.
The spreadsheet is often not the problem
A store where the owner checks the bank statement against the week's till totals and investigates anything that looks wrong is doing real reconciliation, and for a single store with mostly cash and one card terminal it works.
The trouble starts at identifiable points.
When the jump is too large
The bank shows a card receipt for the week. The POS shows card sales for the week. They differ, and the difference is a combination of fees, a declined transaction that was rung, a refund from the previous week and a batch that settled late. Which one is unknown because the steps between are not recorded.
When methods are blended
The POS reports a day's total. Cash, two card types, a wallet and gift card redemptions are inside it. The drawer is short, but the total is close because a card overage offsets it, and both errors survive.
When fees are accepted
The processor's payout arrives. It is less than the card sales, which is expected, so it is posted. Whether the difference is the agreed fee rate on the agreed transactions, or includes something else, is not checked.
When the variance is a note
A shortage on Tuesday was noted. Nobody owned it. It reappears at month end as part of a larger unexplained figure and is written off.
What payment reconciliation software holds
POS close by method
Expected takings by payment method, by shift and by store, from the daily close: cash, each card type, wallets, gift cards, store credit, online payments.
Cash count
Counted cash by shift with the opening float, cash in and out during the shift, and the variance against expected.
Terminal settlement
Batch totals from each card terminal, matched against the POS card total for the same period, with unmatched transactions listed.
Processor payout
Each payout with its gross, fees, refunds, chargebacks, holds and net, matched against the terminal batches it covers.
Bank receipts
Amounts arriving in the account matched to processor payouts and to cash deposits, with timing differences tracked.
Other methods
Wallet, gift card, store credit and online payments each followed through their own provider's settlement in the same way.
Variances
Every difference at every step, with the step it arose at, the amount, the likely cause where known, an owner and a status.
Reporting
Reconciled share by day and store, open variances by age and method, fees as a share of card sales by processor.
Four records, three joins
A card sale on a Tuesday afternoon appears first in the POS as a sale paid by card. It appears second in the terminal's batch when the terminal settles, usually that night. It appears third, netted with hundreds of others, in the processor's payout some days later. It appears fourth as a receipt in the bank.
Reconciling the bank to the POS directly compares the first record to the fourth, and any difference is a mixture of everything that happened at the two steps between. That is why such reconciliations end in an unexplained figure.
Reconciling step by step keeps each difference small and attributable. POS to terminal catches transactions rung but declined, declined but rung, or rung on the wrong terminal. Terminal to payout catches fees, refunds, chargebacks and holds. Payout to bank catches timing and the occasional missing deposit. Each join has its own typical causes, and knowing which join opened the gap is most of the diagnosis.
The same structure applies to every method that goes through a provider. Wallets, gift card platforms and online payment gateways each have a settlement and a payout, and each can be followed the same way.
Cash is shorter: POS to drawer, drawer to deposit, deposit to bank. The first join is the shift's variance and belongs to a person; the others are about handling and timing.
Cash and card fail differently
Treating all takings as one reconciliation blends two kinds of problem.
A cash variance is physical. The drawer was counted and it did not hold what the POS expected. It belongs to a shift and a cashier, and the causes are counting error, change error, an unrecorded payout from the drawer, a void after payment, or something worse. It is investigated by looking at the shift's exceptions, as described on Retail POS Software, and it should be closed within days while the shift is still remembered.
A card variance is almost never about a person at the counter. It is a transaction rung on the POS that the terminal declined, or one that went through on the terminal that was voided on the POS, or a batch that settled across midnight, or a refund processed on a different day from the sale. It belongs to a batch and is resolved by matching transactions rather than by asking a cashier.
Keeping the two apart in the reconciliation, and in the reporting, means the cash figure is a control on the counter and the card figure is a control on the payment chain. Blending them produces a daily total that can be close to right while both are wrong.
The payout is a net figure
The amount a processor pays into the bank is what remains after fees, refunds, chargebacks and any holds. Matching that amount to the bank confirms the processor paid what it said. It does not confirm that what it said was right.
Building the expected payout independently is the check. The terminal batches for the period give the gross. The agreed fee structure, as the store understands it, gives the expected fees. Known refunds and chargebacks are subtracted. What remains is the expected net, and the difference from the actual payout is the list of things to look at: a fee rate that changed, a chargeback the store was not told about, a hold applied and not yet released, a batch that settled into a different payout than expected.
Fees deserve a regular look on their own. As a share of card sales, by processor and by card type, the figure should be stable. A drift upward may mean a rate change, a shift in card mix, or a category of transaction being charged differently, and each is worth a conversation with the processor.
How fees, holds and chargebacks should be recorded in the accounts is a matter for your accountant. The application's job is to hold each one against the payout and the transactions it relates to, so the accountant has the detail and the store has the question.
Where payment reconciliation looks different by business type
- Supermarket Software, where many lanes, many terminals and high transaction counts make step-by-step matching the only way to find a small error.
- Convenience Store Software, where cash is a large share, shifts change round the clock and the drawer count is the daily control.
- Liquor Store Software, where cash handling is significant and high-value transactions make a single variance worth chasing.
- Jewelry Retail Software, where transactions are few and large, deposits and balances span days, and one mismatched payment is material.
- Multi-Store Retail Software, where the same reconciliation runs per store and the comparison across stores is itself a control.
- D2C Brand Software, where nearly all takings arrive through gateways and processors and fee structures decide channel margin.
Why retailers choose Pentoggle for payment reconciliation
Step by step, not in one jump
POS to terminal, terminal to payout, payout to bank, each join reconciled separately so the difference is small and attributable.
Cash and card kept apart
Drawer variance as a counter control by shift; card variance as a batch-matching task with its own typical causes.
An expected payout to check against
Gross from your batches, fees as you understand them, refunds and chargebacks known, so the processor's figure is verified rather than accepted.
Every variance has an owner and a status
Differences listed by step, day, store and method, and closed with an outcome rather than rediscovered monthly.
Sits around your accounting
QuickBooks, Tally, Xero and comparable systems continue recording receipts and, with your accountant, fees and adjustments. Pentoggle holds the chain between the sale and the bank and what was found in it.
A useful number for payment reconciliation
The share of daily takings reconciled through to bank within a defined period, read alongside the value of open variances.
The first says how much of the money the store took can be followed all the way to the account. Anything less than nearly all of it means the chain has gaps that are being accepted rather than explained.
The second is the money currently in question. It should be small, young and moving. A large or ageing figure means variances are being logged and not worked, and the value in the process is in the working.
Read fees as a share of card sales alongside both, by processor. It is the one number in this workflow that a store can change by negotiation, and it only becomes visible when payouts are reconciled to batches rather than to the bank.
Ready to build retail payment reconciliation software?
You know what reached the bank last week.
You may not be able to say which shift the cash shortfall belonged to, or whether the processor's fees were what you agreed.
Describe how you take payment, what your close produces and what your processors send you to Pentoggle in plain English and generate a working first version in hours, then refine it around your process.