Is payment reconciliation the same as bank reconciliation?

Related but narrower. Bank reconciliation ties your books to the bank statement. Payment reconciliation focuses on the money moved by processors and platforms, matched against what you were owed, and often against the bank as a third checkpoint.

How often should it run?

As often as payouts land, so nothing accumulates. Many operators reconcile monthly; higher-volume teams reconcile per payout cycle.

What do you need to do it?

Your processor's payout and balance reports, your record of expected amounts (orders, invoices, or a billing export), and ideally the matching bank statements.

What is payment reconciliation?

Payment reconciliation is matching the payments a processor or bank says it moved against your own record of what you were owed. It confirms every charge, payout, fee, and refund actually landed correctly, and surfaces the ones that were short, missing, or wrong.

What does payment reconciliation compare?

On one side is what a payment provider reports: settlements, payouts, fees, refunds, and adjustments. On the other is your own expectation: the orders you booked, the invoices you issued, the amounts you were owed. Payment reconciliation ties the two together so the money that moved matches the money that should have. A third checkpoint, the bank statement, confirms that the payout the processor says it sent is the payout that actually landed.

What errors does payment reconciliation catch?

Charges that failed or were never collected, processing fees above the contracted rate, refunds deducted twice, disputes never reversed, reserves never released, and payouts that arrived short or not at all. Each is small per transaction and easy to miss inside a plausible-looking net deposit.

Why is the net payout total not enough?

A single payout nets thousands of transactions into one number, so the deposit can look right while individual charges inside it are wrong. Two errors in opposite directions cancel each other out and leave a total that ties perfectly. Real payment reconciliation matches each transaction to its settlement line and its bank landing, which is the only way the individual errors surface.

How do you run a payment reconciliation, step by step?

Pull three exports covering the same date range: the processor's transaction-level settlement report, your own record of what was owed, and the bank statement. Normalize them so amounts, currencies, and timestamps are comparable. Match on a stable key that appears on both sides, such as an order id, invoice number, or charge id, rather than on amount and date alone. Classify every line as matched, short, or missing. Then document each exception with the two source lines that disagree, so it can be disputed rather than argued about.

What does a payment break actually look like?

Take an illustrative payout. Your records show 1,000 orders totalling $50,000 for the period, and the processor deposits $47,850 after fees. The total looks plausible, so it gets accepted. Matched line by line, three things surface: eleven orders were captured but never settled, one refund was deducted twice, and the processing rate applied to part of the volume was higher than the contracted rate. None of the three is visible in the net figure, and each is provable against the settlement line that produced it.

Where does payment reconciliation usually break down?

Timing is the most common cause: a charge captured on the last day of the month settles in the next one, so a strict calendar cutoff reports a break that is really only a boundary. Gross-versus-net reporting is the second, where one side records the full charge and the other records the amount after fees. Multi-currency conversion, batched payouts that bundle several days together, and platform adjustments posted without a transaction reference account for most of the rest.