Daily payment reconciliation: matching orders, transactions and settlement

Choose the records and the comparison period

Identify the order system, payment transaction source and provider report that will be compared. Agree the timezone and reporting period before exporting data. A payment completed near midnight can fall into a different date in another system, so a date-only join may create false exceptions. Preserve the original timestamps and currency fields. For example, an online shop reviewing yesterday's orders should document whether the comparison concerns order creation, payment confirmation or a provider settlement period. Those are different views and should not be collapsed into one ambiguous daily total.

Payment reporting

Match using identifiers rather than descriptions

Start with durable references: internal order, payment operation and provider transaction. Customer names and free-text descriptions are poor primary matching keys because they can change, repeat or contain unnecessary personal information. Build a reference map that supports several attempts against one order. In the shop example, two failed attempts and one successful payment should explain one completed order, not three sales. Where a reference is missing, create an exception with an owner. Do not invent a match merely because two amounts happen to be equal on the same day.

Merchant cabinet

Separate amounts that represent different things

Keep requested amount, confirmed payment amount, refund amount and settlement amount in distinct fields where the source supports them. Record the currency alongside each value. Provider charges and separately invoiced software fees should not be casually deducted from a transaction amount to force agreement. Use the provider's own reports and commercial terms to explain settlement differences. A common operational view can help locate the relevant records, but it does not transform those records into a complete accounting ledger. Label the purpose and limits of each export so users do not infer more than it contains.

Classify discrepancies before investigating

Create a small set of operational categories such as missing confirmation, unresolved attempt, unmatched reference, refund in progress and timing difference. The category should determine the next evidence to inspect. A missing order update may require checking webhook delivery, while a settlement difference belongs with provider records. Avoid one generic failed bucket that conceals the distinction. Each exception needs a responsible person, next action and review date. Keep closed exceptions with their explanation so recurring integration problems can be recognised rather than rediscovered every morning.

• Compare like currencies and like reporting periods.
• Keep attempts separate from completed orders.
• Assign ownership to unmatched records.
• Record the evidence used to close an exception.

Design the handover between teams

Finance, support and engineering need different details, but they should work from compatible references. A useful handover says which order is affected, what is known, which source was checked and what remains uncertain. It should not require copying an entire payment payload into a chat. For a customer reporting payment, support can locate the transaction and verification status; engineering investigates delivery failures; finance checks the provider's financial report when settlement is the question. This division reduces duplicated work while keeping the final responsibility for each discrepancy explicit.

Use OrsunPay reporting within its scope

OrsunPay provides payment dashboards, searchable transaction records and CSV exports in the cabinet. These tools support investigation and comparison with your own records. Expanded provider and method analytics, scheduled email reporting and an operator discrepancy journal remain planned capabilities. The reporting view is not a settlement or accounting ledger. Begin with a repeatable manual reconciliation using available fields, then automate only the rules your team can explain. The measure of success is fewer unexplained exceptions and a clear trail for the remaining ones, rather than a dashboard that always appears to balance.

Sources

• Stripe — Payments
• Stripe — Webhooks