Fintech
Virtual POS Reconciliation: A Transaction-Level Guide
Reconcile orders, processors, bank settlements and the ledger while controlling fees, value dates, refunds and chargebacks.
Key takeaways
- Gross POS sales do not equal bank receipts.
- Store the order ID, processor transaction ID and bank reference together.
- Age exceptions by reason and owner.
- Track refunds and chargebacks as operating and financial risk metrics.
- Define accounting policy and exception ownership before automating.
Important information
This article provides general information and is not legal, tax or investment advice. The outcome depends on the facts, the parties and current legislation.
Four data sources
| Source | Evidence | Question |
|---|---|---|
| Orders | Sale, cancellation, return | Did the commercial event occur? |
| Processor | Status, gross, fee, payout | Was payment successful? |
| Bank | Net settlement, value date, hold | When did cash arrive? |
| Ledger | Revenue, VAT, receivable, fee, bank | Was the event recorded correctly? |
Gross-to-net bridge
| Item | Illustrative amount |
|---|---|
| Successful transactions | 100,000 |
| Refunds | (4,000) |
| Fees and related tax | (2,600) |
| Held/next-period settlement | (8,000) |
| Expected bank receipt | 85,400 |
Exception ageing
| Age | Action |
|---|---|
| 0–1 day | Confirm normal cut-off/value date |
| 2–3 days | Match payout bundle and bank reference |
| 4–7 days | Assign owner and resolution date |
| 7+ days | Escalate and assess collection/impairment risk |
Ledger logic
Do not record the net bank receipt directly as revenue. Split the movement into gross sale, tax, POS receivable, fee, refund and bank settlement. Explain the month-end POS receivable by processor payout and value date.
Minimum transaction key
- Order and sub-order ID
- Processor payment and merchant ID
- Bank settlement reference and payout bundle
- Authorisation, capture, refund and value dates
- Gross amount, currency, fee, tax and net amount
- Instalment, card scheme and sales channel
Common differences
| Difference | Likely cause | First action |
|---|---|---|
| Order exists, POS absent | Failed payment or data gap | Verify status and revenue record |
| POS exists, bank absent | Value date, hold, chargeback or wrong account | Inspect payout bundle |
| Bank exists, ledger absent | Integration or close delay | Post by settlement reference |
| Net amount too low | Fee, tax, refund or penalty | Match statement line to contract |
| Duplicate amount | Retry or duplicate event | Block posting and trace stable ID |
Operating procedure
Run the reconciliation at a frequency proportionate to volume, daily for high-volume operations. Keep an exception register with amount, age, reason, owner and promised resolution. Month-end should explain the POS receivable by processor and value date; it should not be the first time daily differences are discovered.
Automation readiness
- Stable identifiers exist across all sources
- Fee and tax rules are versioned
- Tolerance policy is approved
- Manual adjustments are logged
- Exception ownership is clear
- Source totals can be reconciled before transaction matching
Frequently asked questions
Why does the bank receipt differ from sales?
Settlement timing, fees, instalments, refunds, reserves and chargebacks can all create a difference.
Can net bank cash be posted directly as revenue?
No. It hides gross sales, VAT, processor receivables and fees.
Is monthly total reconciliation sufficient?
Not for a high-volume flow. Transaction-level daily reconciliation detects offsetting errors, ageing and product/customer misallocation.
How is a fee difference verified?
Recalculate the expected deduction using card, instalment, campaign, tax and value-date terms, then compare provider and bank data.
Official sources
Legislation last reviewed: 1 August 2026
Mikail Ege
Certified Public Accountant · SMMM
Mikail Ege works across accounting, tax, financial reporting, financial advisory, fintech and payment institutions.
Related insights
Fintech
Fintech Accounting in Türkiye: From Business Model to Close
A practical guide to licence boundaries, revenue, customer-money risks, funding, product costs and data-to-ledger reconciliation for fintech companies.
Read the guide →
Fintech
Payment-Institution Accounting in Türkiye: Safeguarding and Reconciliation
A 6493-focused guide to customer funds, safeguarding accounts, daily reconciliation, revenue and 2026 CBRT reporting.
Read the guide →
Make the decision with numbers
Assess the right structure for your business in Türkiye.
We can compare tax and cash-flow outcomes using your expected profit, owner withdrawals and growth plan.
Request an introductory call →