What split tender actually requires.
A POS that handles split tender correctly accepts multiple payment events on a single transaction, validates that the sum equals the transaction total, posts each payment to its appropriate ledger account (Cash, Card Receivable, Apple Pay Receivable, etc.), and prints a receipt that itemizes both methods.
A POS that handles it badly forces you to ring two separate transactions, which fragments the audit trail and makes loyalty point calculation wrong. Or it accepts the split but posts a single Cash entry and ignores the card portion. Or it accepts both but does not validate the sum.
The journal entry for split tender.
An £82 ticket paid as £50 cash + £32 card posts: DR Cash £50, DR Card Receivable £32, CR Sales (net of VAT) £68.33, CR VAT Payable £13.67. Plus the COGS leg. Five lines minimum, all balanced.
The Card Receivable account clears when the card processor settles to your bank. That settlement, often T+1 or T+2, debits Bank and credits Card Receivable. If your POS does not maintain this two-step (booking then settlement), your bank reconciliation is going to be miserable.
Wallet payments specifically.
Apple Pay, Google Pay, Samsung Pay, PayPal, Venmo, Cash App — each is its own wallet receivable account. They settle on different schedules and have different fee structures. Posting all wallet payments to one "Wallet" account makes month-end reconciliation impossible because you cannot tell which provider owes you what.
Best practice: one receivable account per wallet provider. Cash and Cards are separate too. Five clean accounts. When the Apple Pay daily settlement file arrives, you reconcile only the Apple Pay account, not a generic Wallet bucket. Reconciliation goes from hours to minutes.
- Cash on Hand — drawer balance per branch
- Card Receivable — pending card settlements
- Apple Pay Receivable — pending Apple Pay settlements
- Google Pay Receivable — pending Google Pay settlements
- Other Wallet Receivable — for the long tail
The fee deduction problem.
Card processors typically charge 1.5-2.9% per transaction (Stripe, Adyen, Square, Worldpay are all in this range). Mobile wallets often pass through the underlying card rate plus a small premium. The fee is deducted from the settlement, so £32 charged to a card might settle as £31.36. That £0.64 is a card processing fee expense, not lost revenue.
The settlement journal entry: DR Bank £31.36, DR Card Processing Fee Expense £0.64, CR Card Receivable £32. The fee shows up as an expense line, not a missing revenue. Get this right and your gross margin reports stay accurate. Get it wrong and you cannot tell where the variance comes from.
Loyalty points on split tender.
Earn points on the full transaction value, not on each split. An £82 ticket earns the same points whether paid 100% cash, 100% card, or split. Customers should not feel penalized for splitting. The earn calculation runs once per transaction.
Some retailers run promotions that double points on card payments to drive card adoption (since cards have lower fraud risk and faster reconciliation than cash). That is a different loyalty rule layered on top — possible but adds complexity. Start simple, layer if needed.
Refunding a split-tender transaction.
Customer returns an £82 item from a split-tender purchase. Refund to which account? Default rule: refund to the original payment methods proportionally. £50 cash back, £32 to the original card. Anything else (refund all to cash, for example) creates fraud surface.
Some POS systems make this hard because they cannot retrieve the original split detail. They default to "refund to one method" which the customer often does not want (or which lets the cashier pocket the cash difference). Verify your POS handles split-tender refunds before you accept your first one.
The change problem.
Customer pays £60 in cash plus £30 on card for an £82 ticket. They want £8 cash back. Most POS systems handle this fine — the cash event is "received £60, change £8, net cash £52" plus the £30 card. But the receipt has to show all three lines.
Some cashiers, faced with this scenario, ring it as £52 cash plus £30 card with no change shown. The math foots but the original cash received is not on the record. If the customer later disputes, the audit trail is incomplete. Always ring the gross cash received with explicit change-given, even when it is more keystrokes.
Branch-level reconciliation.
At end of day, each payment method reconciles independently. Cash matches counted drawer minus float. Cards match the merchant settlement file (next day). Wallets match each provider's settlement (varies). Any of those three independent reconciliations failing tells you exactly where the issue is.
In Nonari the daily reconciliation dashboard shows all channels (cash, card, each wallet provider) per branch with expected vs actual. Variance per channel. This catches issues that bulk-reconciliation hides — a card terminal that was offline for an hour shows as a £300 card variance instead of disappearing into a generic "off by 2%" complaint.