A deposit reaches the bank, and it is smaller than the sales your ledger recorded for the same days. Payment reconciliation is how you find out why. Each payment you recorded is checked against what your payment processor reported and against the cash that reached your bank account. The gap might be a processing fee, a refund or a chargeback. A currency conversion can cause one as well, and so can a payment that has not reached the bank yet.
A spreadsheet copes with a few dozen payments a month. Thousands of payments across two or more providers are a different job, because the mismatches come in faster than one person can check them line by line. At that volume the work becomes a design problem. The aim is a system where most lines match with nobody checking them by hand.
What payment reconciliation is, and what it is not
The bank statement shows up in both jobs, which is why the two names get mixed up. "Payment reconciliation" and "bank reconciliation" start from different records.
Bank reconciliation begins with the statement the bank sends. Each line on it is checked against the transactions in your cash account.
Payment reconciliation begins with one payment, such as an invoice a customer paid by card. You follow it to the processor, into a payout and onto the bank statement. That trail tells you whether this customer's payment settled. It also explains why Tuesday's deposit came in below Tuesday's sales, which the statement alone cannot show.
Processors rarely pay out sale by sale. Stripe's documentation describes each automatic payout as settling a batch of transactions. Fees, refunds and disputes come out of the batch, and the bank receives one net amount. The itemized payout report shows what went in. It lists each payment and refund in that payout, and each dispute and fee as well.
For a platform business, splitting that deposit is the harder part of the job. Until it is broken back into payments, nobody can say which customers it paid for. Each processor may group its payouts its own way, so the split has to be worked out once for every provider you use.
Types of reconciliation, and where this one fits
Accounts payable and payroll reconciliation track money leaving the business, so they sit outside this guide. They are two of the seven types in Stripe's guide to payment reconciliation, and each type starts from a different record. The table shows the other five.
| Type | What it compares | How payment reconciliation relates to it |
|---|---|---|
| Bank reconciliation | Transactions in your cash account against the bank statement | Shares the bank side. Payment reconciliation explains what each deposit contains |
| Credit card reconciliation | Transactions in your accounting system against the statements for the company's own credit card accounts | Covers what the company spends by card. Card payments from customers belong in the three-way match below |
| Accounts receivable reconciliation | Invoices you issued, against customer payments and credit notes | Shows AR which invoices the payments in a deposit paid. Underpayments and overpayments show up here |
| General ledger reconciliation | General ledger accounts against sub-ledgers or supporting documents | Matched payments, fees and refunds are the detail behind the cash and fee accounts |
| Intercompany reconciliation | Transactions between entities in the same corporate group | Comes in when one group company collects money that belongs to another |
Two rows in that table touch the path of a single payment. The deposit belongs to bank reconciliation, and the invoice each payment settles belongs to AR. Payment reconciliation, as this guide uses the term, runs from order to processor to bank, so it overlaps with both.
The method in this guide is what CFI, a finance training provider, calls document review, done for every payment. CFI names analytics review as a second method. It also says reconciliation should run regularly on every balance sheet account.
The three-way match
Most payment reconciliation comes down to three records and the IDs each one carries.
| Record | Source | What it shows | Identifiers to match on |
|---|---|---|---|
| Your ledger or order system | Your own platform | The payment you expected: who owes it, and for what | Order ID, invoice number, customer ID |
| Processor or PSP report | Stripe, Adyen, a bank acquirer or another provider | Charges, refunds, holds and deductions, plus the payout each one went into | Charge or transaction ID, payout ID, fee lines |
| Bank statement | Your bank: a file export, an API, or a format like ISO 20022 camt.053 | Cash that actually arrived, and the date it arrived | Bank reference, amount, value date, payer text |
The processor report and a bank line match on the payout amount and its reference. Your ledger connects to the processor report through a shared transaction ID when you send your own order ID to the provider with the payment. The ledger and the bank statement often share no field. That is why the processor report sits in the middle of the match.
We recommend storing the order or invoice ID in the provider's metadata. The ID has to travel with the payment from the first request, so this is set up before any matching starts. With it in place, most of these matches become a lookup. Without it, matching falls back on amounts and dates, and that is where the errors come from.
The payment reconciliation process, step by step
A nightly matching job and a person with a spreadsheet work through the same seven steps.
- Collect the three records for the same period: orders or invoices, the processor's itemized payout report, and the bank statement. The dates need a second look, since a payout may be grouped by its expected arrival date while the bank posts it on another day.
- Match ledger entries to processor transactions. Use your own reference where you have it. Flag any order with no processor transaction and any processor transaction with no order.
- Break each payout into its lines by subtracting fees, refunds and dispute debits from the gross payments, along with any adjustments. What remains should equal the payout amount.
- Match payouts to bank deposits on the amount and the provider's reference. When a payout has no deposit, it is either still in transit or a problem to chase.
- Explain every difference as a timing difference, a known deduction, or an item that a person has to investigate.
- Record corrections as new entries. The original payment stays exactly as it was posted, and the correcting entry says what changed and why.
- Review what is left open. Unmatched items go into a queue with an owner, and the oldest are worked first.
When a correction overwrites the original payment, next month's reconciliation starts from records that no longer show what happened. Step 6 is there to prevent that. The design section further down, under "Make posted entries immutable", covers how to build for it.
Why the totals do not match
The cause of a mismatch decides the response: wait for it to clear, post an adjustment, or investigate. Almost every mismatch traces back to one of these seven.
| Cause | What you see | What to do |
|---|---|---|
| Processing fees | Deposit below gross sales | Book fees from the processor's report as their own entries. The sale keeps its full value |
| Refunds | A later payout comes in under that period's sales | Link the refund to the original payment, so the payment's history shows both |
| Chargebacks and disputes | Money leaves your balance with no action from you | Post the debit and any fee against the original payment; track the outcome separately |
| Currency conversion | Small differences from the invoiced amount | Keep the original currency, the settled currency and the rate used |
| Timing | Recorded in your ledger, still missing from the bank | Mark it in transit with an expected date instead of treating it as missing |
| Partial or combined payments | One deposit pays several invoices, or one invoice arrives in parts | Allow one-to-many and many-to-one matches, and keep any remainder visible |
| Duplicate imports | The same bank line twice | Fingerprint each imported line and skip repeats |
Disputes are the easiest cause in the table to misread. Once a dispute opens, the disputed amount and a dispute fee are debited from the business's balance, as Stripe's dispute documentation describes. The disputed amount can differ from the original charge, for example when exchange rates moved between the purchase and the dispute. A ledger that expects the original amount back will then show a mismatch where nothing is wrong.
What payment reconciliation catches: errors, duplicates and fraud
A duplicate charge shows up as two processor charges against one order. Step 2 matches the first charge and closes the order in full, so the second has nothing left to match and is flagged. Two refunds for one order are caught the same way. A person then checks the extra item in the step 7 queue. A bank file imported twice is caught too, as a deposit with no payout behind it. CFI's manual example is a rent expense charged twice, found by going through the receipts.
CFI accepts that a payment and its deposit may land on different days. A gap that nobody can explain is different, it warns, because it may point to theft or misuse of funds. It lists what reconciliation helps uncover as "omissions, duplication, theft, and fraudulent transactions". Stripe also treats reconciliation as a control against error and fraud. For a company's own credit card statements, it says, reconciliation helps detect unauthorized or fraudulent transactions.
A payment in transit needs no action until its expected date passes. Any other unexplained difference needs an owner and an answer. That is why timing has its own row in the mismatch table in the previous section, apart from every other cause.
Controls: who can match, adjust and approve
A manual match, a write-off and an adjustment all change the books. Someone has to decide who may post them and what proof stays behind. Stripe's reconciliation guide names three controls for this: segregation of duties, review and approval, and audit documentation. We add a fourth, a tolerance threshold for small differences, and use a setting in Microsoft Dynamics 365 Finance as the example. Oracle's and Microsoft's products show how finance software enforces these rules.
Segregation of duties
Oracle Account Reconciliation will not let one user hold both the preparer and the reviewer role on the same reconciliation profile. A user who belongs to both teams can prepare a reconciliation or approve it, but not both. Stripe's guide states the same principle on its own terms. The person who records transactions should not also reconcile the accounts, so each role acts as a check on the other. A platform with its own reconciliation needs the same rule in its permissions, so the user who creates an adjustment cannot approve it.
A tolerance threshold
In Microsoft Dynamics 365 Finance, each bank account has a field called "Allowed penny difference". A bank statement line and a book transaction can still be matched when their amounts differ by no more than that figure. This covers the small rounding gap a currency conversion can leave, which is not worth chasing. A gap above the limit goes to the exceptions queue.
Raising the limit lets more gaps clear with no review at all. We therefore recommend logging every change to it, and writing down the limit, who may change it and which account takes the cleared amounts.
Review and approval
Manual matches, write-offs and adjustments above the tolerance should reach a second person before they post. We recommend giving that reviewer the evidence for each one, such as the bank reference and the payer details. Stripe's guide says "a supervisor or manager may need to review and approve" the reconciliation, depending on the size and structure of the company. Oracle's product supports up to 10 levels of review, in a chain the customer sets up. A platform you build should allow a chain like that instead of hard-coding one approver.
Audit documentation
For each period, we recommend a record with four parts:
- the processor and bank files, exactly as received
- each match, and the person or rule that made it
- each adjustment, with its reason and its approver
- the sign-off that closes the period
Stripe's guide asks for a record of every reconciliation, with the discrepancies found and the adjustments made. That record serves the audit and shows who changed what, and the guide adds that good records let auditors work efficiently with less risk of audit adjustments. It also recommends written procedures, so that every period is reconciled the same way.
A posted entry that could still be edited would make this record unreliable. The next section therefore starts with immutable entries.
Designing reconciliation into your platform
The six decisions below matter most for a system that moves money, either the company's own money or money it moves for customers. Each one shapes how records are kept. We recommend settling all six before the first payment is posted.
Make posted entries immutable
When someone asks why a balance changed last March, the answer has to come from the ledger. It will be there only if nobody edits a posted payment, fee or refund. Each correction goes in as a new entry that points back to the original.
In our payment ledger case study, a database trigger refused any change to a posted row. Batches were later sealed into a hash chain, and a verification command could check it. When a multi-step transfer failed, the system voided or refunded the legs that had already run instead of rolling back the whole operation. The record kept the history of what happened.
Keep processing state separate from balances
Your API can accept a payment that the ledger has not posted yet, and a posted payment may still be unsettled at the bank. The payment ledger case kept those three states apart. Operators could see which work was queued, which was posted and which had been compensated. Imported statement entries were matched to ledger transactions by configurable rules.
A status field with only "paid" and "unpaid" has no value for a payment that is authorized but not captured, or captured but not paid out. Reconciliation then has nowhere to put it.
Write matching rules that know when to stop
The tempting design is to auto-match anything where the amount lines up. It breaks in ordinary ways. The same amount can belong to different customers, a bank description can shorten a payer's name, and a converted amount can be slightly off.
Two of our case studies handled this the same way, by being strict about what the system decides on its own:
- In the rent ledger and reconciliation case study, automatic posting needed a previously confirmed payer, an amount equal to the outstanding charge and an unambiguous match. Everything else became a review decision, and each suggestion showed the evidence behind it, such as a known bank account or a unit reference.
- In the receipt matching case study, the system scored name, amount and date one by one, and checked currency on its own. A high score alone was not enough to attach a receipt automatically. The pair also needed a record of repeated confirmations, and a rejected pair took a penalty that faded over time.
We recommend the rule both systems shared. The software proposes matches and a person settles anything uncertain. Automatic matching should cover only the cases your own history has shown to be safe.
Give exceptions a home
An unmatched item with no owner tends to end up in a spreadsheet tab that nobody opens until month end. Each one needs a place in a queue, a named owner and a visible age.
Before the rent ledger prepared a reminder, it checked for payments still waiting on review, so a likely payment was in view before anyone contacted the tenant. Uncertain payments and unapplied amounts stayed visible beside open, partly paid and overdue charges. Extra money stayed unapplied, and the system never moved it onto another charge by itself.
In the receipt matching workspace, an uncertain receipt could stay unassigned while the team kept working through the rest.
Make imports safe to repeat
Someone downloads the same bank file twice, a webhook is delivered a second time, or two imports start at once. An import that is not idempotent can turn each of these into a duplicate. Idempotent means that running the same import again adds nothing new.
The rent ledger gave each statement line a fingerprint, built from the bank reference or other fields that identify it. A line it had seen before was skipped, even when two imports raced to add it. The payment ledger checked each transfer's reference before running it, and a unique index in the database enforced that check. Receipt matching used upserts for bank transactions it had seen before, so a known transaction was updated in place instead of added again.
Accept the formats your banks actually send
The rent ledger case imported camt.053 XML files alongside CSV. ISO 20022 defines camt.053 as a bank-to-customer statement message. A structured format helps, since the columns in a CSV export can change from bank to bank and sometimes from month to month. We recommend one normalized internal record at the center of the importer, with one adapter for each source.
Payment reconciliation software: buy or build?
Cost and time matter, and so do where your payment data lives and who uses the results. The table sets payment reconciliation software against a build on those points, and on how exceptions and the audit trail are handled.
| Factor | Buy reconciliation software | Build it into your platform |
|---|---|---|
| Where your payment data lives | Standard processors, banks and an accounting system the tool already connects to | Inside your own product, with its own payment states and objects |
| What you reconcile | The company's own revenue and cash | Money you move on behalf of customers, merchants, tenants or users |
| Who uses the results | Your finance team | Your finance team, plus your customers inside the product |
| Matching rules | The vendor's rule engine, which you configure | Your own rules on your own data, such as customer history or contract terms |
| Exceptions | Handled in the vendor's interface | Handled where your operators already work |
| Audit trail | Vendor log | The ledger's own immutable history |
| Time to start | Usually faster | Longer; the ledger design comes first |
| Ongoing cost | A subscription, often tied to volume | Engineering and maintenance |
For your own company's revenue, collected through standard providers and reconciled into a standard accounting system, we recommend buying a tool. That is our advice even though we build software. In that case a bought tool will be faster and cheaper than building one.
Building fits products where customers expect to see their own matched and unmatched payments, such as a marketplace, a payments platform, or a property or billing system. In those products, reconciliation is part of what the product does. An outside tool cannot easily sit inside that experience. The ledger, the matching rules and the exception queue then count as product features.
Some teams do both, building the ledger and matching into the product and feeding a bought finance tool for the company's own books.
Where this fits
Reconciliation gets harder with every provider you add. If you are routing payments across several processors, our guide on how payment orchestration works covers the layer that sits upstream of all this. Our pages on financial services software and fintech and digital banking platforms cover related work, and our custom software development services page explains how we build.
FAQ
What is payment reconciliation?
It matches each payment in your records against your payment processor's report and the deposits in your bank. Then it explains every difference between them.
What is the payment reconciliation process?
Ledger, processor and bank records for one period are collected and matched pair by pair, and each payout is split into its lines. After that, every difference is explained and corrections go in as new entries. Anything still open is reviewed in a queue.
How often should payment reconciliation be done?
With daily payouts, reconciling each one as it arrives keeps a problem small and easy to trace. Otherwise the right frequency depends on your volume and risk.
What is the difference between payment reconciliation and bank reconciliation?
Bank reconciliation starts from the bank statement. Payment reconciliation follows each payment from order to processor to bank, which is how you find out why a deposit does not equal sales.
Can payment reconciliation be fully automated?
Most of the matching can be automated, though not all of it. An amount that matches but comes from an unclear payer should go to a person to confirm. The software can learn from each decision the person makes.
Should I buy payment reconciliation software or build it?
Buy if you are reconciling your own revenue from standard providers. Build when reconciliation is part of your product and your customers need to see it.
When reconciliation becomes part of your product, or still depends on someone exporting three files every morning, you can get a range for your reconciliation build. We start from the providers, banks and ledger you have today.
