The shop has closed, the POS total looks healthy, and the bank credit is lower than expected. The owner has a processor report, a refund receipt and a spreadsheet, but no clear explanation of what arrived. Waiting until month-end only adds more batches to untangle.
Payment reconciliation connects each recorded sale to the payment provider's records and then to the money received in the bank. For a small business, the useful outcome isn't a spreadsheet full of matching totals. It's a signed daily close and a short exception list, with someone responsible for every unresolved amount.
The six reconciliation stages
| Stage | Source record | Match key | Output |
|---|---|---|---|
| 1. Capture | POS transaction log | Terminal ID, date and time, gross amount | Transaction ledger |
| 2. Acquirer match | Processor or wallet report | Authorisation code and amount | Matched and unmatched items |
| 3. Bank match | Bank statement credit | Settlement date and net amount | Confirmed settlement batch |
| 4. Classify | Unmatched items | Reason code | Timing, refund, fee, duplicate or shortfall |
| 5. Resolve | Exception queue | Owner and deadline | Cleared or escalated items |
| 6. Close | Ledger and bank balance | Zero unexplained variance | Signed-off daily reconciliation |
The working sequence is POS record to processor or wallet report to bank credit. A processor's settlement status supports the middle stage, but it doesn't replace evidence that the bank received the funds.
Singapore's electronic-payment scale makes reliable matching important: the Monetary Authority of Singapore's retail payment statistics record 500 million FAST transactions in 2024, worth S$661.748 billion. Those are national payment-rail figures, not POS settlement volumes, but they illustrate why references and transaction-level records matter.
The visual below summarises the route from capture through investigation, approval and archival.

Export the complete POS log. The closing employee exports sales, voids, refunds and manual adjustments for the trading day. The original file stays unchanged, with a separate working copy for matching. The common slip is exporting successful sales only, which leaves the finance lead trying to explain adjustments that never entered the ledger.
Build a consistent transaction ledger. Each row carries terminal ID, transaction date and time, gross amount, scheme or wallet type, authorisation code and merchant reference. An immutable transaction ID should remain attached throughout processing. The common slip is replacing a missing reference with free-text notes that another employee can't reliably match.
Match payment records line by line. The authorisation code, checked alongside merchant reference, terminal, date and amount, is stronger than amount alone. In a hypothetical café example, separate sales of the same value are indistinguishable if the spreadsheet checks only the amount. The common slip is treating an authorisation code as globally unique rather than validating the surrounding fields.
Structured references deserve attention at checkout, not just during accounting. The MAS PayNow Gen2 report identifies invoice IDs and standardised payment data as foundations for automated matching, exception handling and reporting.
Match the settlement batch to the bank. The finance lead compares the processor's net settlement with the bank credit using settlement date, amount and available payout reference. Where a credit combines batches, the supporting schedule must explain the composition. The common slip is comparing gross sales directly with cash received, overlooking refunds and deductions.
Assign a reason code to every unmatched item. Timing, refund, reversal, chargeback, fee, duplicate and unexplained shortfall should remain distinct categories. The difference table below provides the accounting treatment. The common slip is labelling everything “pending”, which gives the next reviewer no useful starting point.
Give every open item an owner and deadline. The exception queue records the amount, supporting reference, current explanation and next action. A missing report belongs with the employee responsible for obtaining it; a disputed settlement may need provider assistance. The common slip is assigning an item to “finance” rather than a named person.
Approve the close with no unexplained variance. Known timing items remain documented and open until the expected credit arrives. The reviewer records approval and retains the reports, bank evidence and adjustment history. The common slip is writing off a small unexplained difference just to make the worksheet balance.
Practical rule: A daily close can contain documented timing items. It shouldn't contain unidentified missing money disguised as a balancing adjustment.
Sambapay provides daily summaries and settlement reporting that make it easier to match card transactions with funds received in the business account. The merchant still needs a clear review routine and ownership of unresolved items.
For teams replacing repetitive spreadsheet work, autobankstatement's tips for automating reconciliations provide a useful starting point for designing repeatable imports and matching checks. A practical first test is tracing the latest Friday card batch through its settlement report to the bank statement before the next opening shift.
T+1 means the next business day, rather than the next calendar day. Sambapay settlements can be made from as early as T+1, depending on the merchant agreement. Banking schedules and card network processing times can affect settlement, including on weekends and public holidays.
The following hypothetical week assumes that Friday and weekend activity reaches the bank together on Monday. It also assumes that fees have already been accounted for in the expected credits, so the example isolates refunds and a possible batch gap. Actual schedules should follow the merchant's written terms and card payment settlement arrangements.
Illustrative T+1 settlement week (S$)
| Sales day | Received |
|---|---|
| Thursday | Friday credit of S$3,050, matching S$3,200 gross sales less S$150 refunds |
| Friday | Monday batch, with S$4,100 expected |
| Saturday and Sunday | Monday batch, with S$8,950 combined net expected |
| Monday batch total | S$13,050 expected; S$12,600 received; S$450 unexplained gap |
| Monday | Due Tuesday, pending credit |
Thursday's activity reconciles cleanly. The sales log supports the gross amount, the refund record explains the deduction, and Friday's bank credit matches the resulting expected settlement.
Friday's expected credit then joins the weekend's net activity in Monday's payout. The finance lead needs the batch detail behind that combined amount, not just a bank entry labelled with the processor's name.
In this scenario, the Monday credit is S$450 below the expected settlement. The first question is whether the expected batch contains a Sunday transaction that missed the provider's cut-off. If so, the employee should locate that transaction in the following batch before calling the difference a shortfall.
The next check is adjustment timing. A refund approved earlier may have entered this payout later, or the expected-credit worksheet may have omitted a recorded adjustment. The investigation should use the processor's itemised report rather than infer the cause from the size of the gap.
A lower credit isn't automatically a loss. It becomes an exception when the records don't explain the difference.
If neither batch composition nor adjustments explain the gap, the finance lead opens an exception with the settlement date, expected amount, actual credit and relevant transaction references. Monday's own sales remain a separate pending settlement due on Tuesday under the example's assumptions. Combining them with the unresolved Monday payout would conceal the original problem rather than resolve it.
Gross sales aren't the amount necessarily due in the bank. Refunds, scheme or wallet fees, reversals and other adjustments can reduce a payout. A total-only comparison can also conceal offsetting errors, such as a missing sale cancelled out by a duplicate entry.
The accountant needs an explanation for each difference, supported by the underlying record. Posting every deduction to merchant fees may make the reconciliation appear complete, but it misclassifies refunds, disputes and potential shortfalls.
Difference types and how to book them
| Difference | How it shows up | Accounting treatment |
|---|---|---|
| Timing difference | Sale today, bank credit next business day | Hold in a timing account and clear when the credit lands |
| Refund | Net settlement below gross sales | Link the reversal to the original sale ID and date; post in the appropriate accounting period |
| Chargeback | Debit from processor after the original sale | Track the disputed amount separately; retain as a receivable only where recoverability supports that treatment |
| Batch cut-off | Late-evening sales appear in the next batch | Match by batch date, not sale date |
| Scheme or wallet fee | Payout lower, with a corresponding fee deduction | Post the supported charge to merchant fees expense |
| Duplicate | Same authorisation code and supporting transaction details recorded twice | Reverse the confirmed duplicate entry |
| Genuine shortfall | Difference remains unexplained after checks | Escalate to the provider with settlement date and amount |
A refund record should retain its own processing date as well as the original sale reference. Linking the records doesn't mean changing a previously closed trading day. The accountant should preserve the original entry and post the refund in the appropriate period.
Chargebacks require more attention than a blanket receivable rule. A disputed deduction isn't automatically recoverable because the merchant contests it. The finance lead should retain the case reference, response deadline and evidence, while the accountant determines whether the amount remains a receivable or requires expense recognition.
If the merchant wins, the returned funds should clear the recorded dispute balance or reverse the relevant expense treatment. They shouldn't appear as a fresh customer sale.
Batch cut-offs are resolved by locating the transaction in the correct settlement file. Confirmed duplicates require corrective entries, not deletion of the original evidence. Fee differences require a comparison between the deduction and the applicable agreement.
When a refund needs tracing, an acquirer reference number can help connect the payment investigation to the relevant processing record. It doesn't replace the merchant reference or the supporting refund receipt.
Sambapay's settlement review identifies whether a difference comes from timing, fees, refunds, chargebacks or another adjustment. A useful escalation therefore includes the settlement date, amount, transaction details and checks already completed, so support can investigate the unresolved part rather than repeat the merchant's entire reconciliation.
A queue is only useful if the finance lead can distinguish new work from overdue work. Monthly payment reconciliation reporting should track matching quality, unresolved exposure and clearance activity, with consistent definitions.
The dashboard below gives a visual summary of the operating measures.

For reporting, the written aged-exception definition above should govern the calculation, since the graphic uses a different denominator. Recovery and resolution should also use a consistent label in the merchant's own dashboard. Clearing an old backlog can make period clearance activity exceed newly raised work, so the opening balance should remain visible.
Channel-level targets are more useful than a blended target across card, PayNow, QR and wallets. Their reference formats and batch schedules differ, and a combined average can hide a problem in a smaller channel.
In the MAS interoperable-QR proof-of-concept report, 4% of reported merchant feedback cited reconciliation or settlement challenges. That finding describes feedback within the proof of concept, not a universal transaction failure rate.
A software change can justify adjusting that order. If exceptions begin immediately after a POS update, the finance lead should inspect status mapping and exported fields early, without assuming the update proves the cause.
The weekly aged-item review should show both the number of unresolved entries and their monetary value. A queue can shrink while its financial exposure grows if employees clear easy, low-value items and leave material discrepancies untouched.
Original events must remain intact. Corrective entries should identify the person, date, reason and supporting evidence, allowing another reviewer to reconstruct the resolution without relying on an employee's memory.
A reconciliation template should make the evidence easy to follow, not merely produce a green “matched” cell. Separate transaction data, exception handling and management reporting so that an employee's resolution note can't accidentally alter a source amount.
A reviewer should be able to move from a summary difference to its source records without searching through email attachments.

Three realistic setups compared
| Setup | Best fit | Watch-out |
|---|---|---|
| Spreadsheet with lookup formulas | A small shop whose transaction rows remain manageable for daily review | Manual edits can break the audit trail |
| Accounting software with bank feed | A merchant using one acquirer | Check whether card fees post gross or net |
| Dedicated reconciliation platform | Several channels and high transaction volume | Assess setup effort and cost against the work removed |
Excel or Google Sheets can be a sensible starting point when the finance lead can inspect unmatched rows daily. Lookup formulas help connect references, but protected source tabs, controlled access and version history matter more than elaborate formatting. A formula that returns the first match can conceal duplicate references unless the workbook checks for them separately.
Accounting software with a bank feed reduces bank-entry handling, but a feed alone doesn't explain a net processor credit. The merchant still needs the underlying settlement detail, including how fees and adjustments are posted.
A dedicated platform becomes more attractive when the employee spends most of the close assembling files or splitting combined settlements. The trade-off is implementation work: channel mappings, status definitions and exception routing need testing before automated approval is trusted.
Any setup should retain immutable transaction IDs, detect duplicates and restrict report imports to authorised users. Re-importing the same file must not create fresh transactions, and changed matching rules should leave a reviewable history.
Structured exports are more useful than screenshots because reviewers can search references and test totals. Access and storage decisions should also reflect PCI compliance responsibilities, without copying unnecessary cardholder information into reconciliation workbooks.
The owner's first action this week should be obtaining written confirmation of the settlement schedule. The agreement should explain the applicable payout timing, batch cut-off and treatment of weekends and public holidays. Without that schedule, an employee can't reliably distinguish an overdue credit from one that isn't due yet.
The next action is a bounded pre-close test, using a recent reporting period and sample trading days that include weekend activity. The purpose isn't to recreate every daily task. It's to confirm that the process produces evidence another person can review.
A passing sample doesn't prove that every transaction is correct. It shows whether the merchant's controls can trace a sale through settlement and identify what remains unresolved. The same sample review at month-end can expose drift in exports, mappings or staff practice.
For a settlement discrepancy, the merchant contacts Sambapay support as soon as possible with the settlement date, amount and relevant transaction details. The finance lead should retain the support reference and record the next follow-up date rather than mark the item resolved when the message is sent.
A provider response closes the investigation only when it explains the difference and supports the resulting accounting treatment. Until then, the amount remains visible to the owner.
A gap that can be named is a task. A gap that cannot be named must be treated as a potential loss until explained.
Sambapay offers a free, no-obligation payment cost review showing how much a business could save by switching. An owner assessing reconciliation workload alongside processing costs can visit Sambapay to discuss the current setup and bring a recent statement plus an example of a settlement difference.