Payment Reconciliation Software: An Automated Payment Reconciliation System for Stripe, PayPal, and Square Payouts
One deposit lands in your bank. Behind it sit two hundred charges, a fee on every one of them, three refunds, a chargeback, and a reserve you did not ask for. Reconciler reads the processor and the ledger read-only, rebuilds the payout from the activity that produced it, and tells you in a sentence why the number is the number.
Read-only ยท Never moves money
In short
Payment reconciliation software matches the money that actually arrived in your bank account against the sales, invoices, and ledger entries that were supposed to produce it, and reports whatever does not line up. It exists because payment processors do not deposit what they collect. A payout is a net figure: gross charges, minus a fee on each one, minus refunds issued in the window, minus any chargebacks and reserve holds, paid out on a delay of a few business days. Stripe settles to US accounts on a standard T+2 timing, so nothing about the deposit matches anything in your ledger on either amount or date. Reconciling it means decomposing the payout back into the underlying charges rather than looking for a matching number. Reconciler connects Stripe, PayPal, Square, your bank feeds and corporate cards, and QuickBooks, Xero, NetSuite, Sage Intacct or Business Central read-only, rebuilds each payout from its components, explains every match in plain English, and never moves money or posts a journal entry. Pricing is published and starts at $49 per month.
Last updated July 2026
Processors and cards on one side, your ledger on the other
The mechanics
What each payment source actually deposits, and why it never matches your ledger
Every row here is a real reason a deposit and a ledger entry disagree. The last row is the one we do not cover, and it is in the table because you should know that before you buy, not after.
| Source | What lands in your bank | What your ledger shows | Why they disagree | What has to happen to tie it out |
|---|---|---|---|---|
| Stripe payout | One net deposit covering many charges, on a standard T+2 timing for US accounts. | Individual invoices or sales receipts at gross, dated when the sale happened. | Neither the amount nor the date agrees. Fees are deducted before the money moves. | Rebuild the payout from its charges and fees, then match the components to the ledger. |
| PayPal settlement | A transfer from the PayPal balance, which is itself a running account of receipts, fees, and refunds. | Sales at gross, and often nothing at all for the balance sitting inside PayPal. | The balance is a real asset account most teams never reconcile, so the deposit is only part of the story. | Treat the PayPal balance as an account to reconcile in its own right, not just a source of deposits. |
| Square deposit | Daily deposits with the fee taken per transaction rather than per payout. | Point-of-sale revenue, frequently summarized by day rather than per transaction. | Summary-level ledger entries cannot be matched to transaction-level deposits without recomposition. | Group the day of activity, net the per-transaction fees, and match the group to the deposit. |
| Processing fees | Never a separate line. They are already subtracted from every deposit before it arrives. | Often nothing, because the net deposit was booked straight to revenue. | Revenue is understated and processing cost is invisible, in every period, until somebody notices. | Split each payout into gross receipts and fees so both land in the right account. |
| Refund | A reduction in a later payout, sometimes weeks after the sale it reverses. | A credit memo, if anyone remembered to raise one. | The payout arrives light and the shortfall looks like a missing deposit rather than a reversal. | Link the refund to the original charge so the reduced payout explains itself. |
| Chargeback or dispute | A deduction plus a dispute fee, often months later, occasionally reversed again if you win. | Usually nothing until someone investigates the variance. | It hits a period unrelated to the sale, and the reversal-of-a-reversal case breaks naive matching. | Track the dispute against the original charge through every state change, including the win. |
| Reserve or rolling hold | Money the processor collected and is holding back, so it is neither in your bank nor lost. | Nothing. There is no entry for cash you have earned but cannot access. | The bank plus the ledger will not reconcile to the processor while a reserve exists and is unrecorded. | Recognize the reserve as a receivable from the processor and reconcile it as its own account. |
| Marketplace payout (Amazon, Shopify Payments) | A net settlement after commissions, advertising, storage, and returns. | Order-level revenue, if the channel is integrated at all. | The deductions are numerous and channel-specific, and they change without notice. | Not a direct Reconciler connector today. It comes in on the bank side and is reconciled from there. |
The Stripe case in full is on Stripe payment reconciliation, the card side on credit card reconciliation, and the reasons items end up unexplained in what causes reconciliation discrepancies.
What it does
What payment reconciliation software is actually for
Payouts rebuilt from the charges underneath
The only reliable way to reconcile a processor deposit is to reconstruct it: take the payout, pull every charge, fee, refund, and adjustment the processor assigned to it, and prove the components sum to the amount that hit the bank. Reconciler does that automatically for each payout, so the tie-out is arithmetic you can inspect rather than a fuzzy amount match that happened to land inside a tolerance.
Fees separated from revenue, not netted into it
Booking the net deposit as revenue understates both your income and your costs, and it is the single most common processor bookkeeping error. Reconciler splits each payout into gross receipts and processing fees so the two land in the right accounts. You get the numbers to post; a person decides the entry, because we do not write to your ledger.
Refunds and chargebacks tracked to the original sale
A refund reduces a payout weeks after the sale it reverses, and a chargeback can arrive months later with a fee attached. Both look like unexplained shortfalls if you only compare totals. Reconciler links each one back to the charge it came from, so a payout that came in light shows you exactly which reversal accounts for the gap.
Several processors and entities in one view
Teams selling through more than one channel end up with different payout schedules, different fee structures, and sometimes different currencies, reconciled in separate spreadsheets by different people. Reconciler treats every processor and every entity as sources against the same ledger, so multi-entity payment reconciliation is one exception list instead of six.
Corporate cards on the same footing
Card spend has the mirror-image problem: an authorization, then a settlement at a different amount days later, then the statement, then the expense coding. Reconciler matches card activity to the ledger the same way it matches deposits, which is why credit card reconciliation and payment reconciliation are one job here rather than two tools.
Read-only, and it never posts
Reconciler connects to your processors, banks, cards, and ledger with read-only access. It cannot move money, issue a refund, or write a journal entry. A tool with write access to a payment processor is a category of risk nobody in finance actually wants, and a tool that silently posts corrections puts its own mistakes somewhere no reviewer is looking. We did not build either.
How it works
From a net deposit to an explained tie-out
Connect the processors and the ledger
Link Stripe, PayPal, Square, your bank feeds, and your corporate cards on one side, and QuickBooks, Xero, NetSuite, Sage Intacct or Business Central on the other. It is credentials and a date range, read-only. There is nothing to implement, because nothing is ever written back.
Each payout is decomposed
For every deposit, Reconciler pulls the charges, fees, refunds, disputes, and adjustments the processor attributed to it, and checks that the components add up to the amount that reached the bank. A payout that does not reconcile against its own components is flagged before it ever reaches your ledger comparison.
Both sides are matched
The rebuilt payout is matched to the invoices, sales receipts, or deposit entries in your ledger. Exact pairs close on rules. Fee-reduced amounts, settlement delays, and batch payouts covering many invoices go to learned matching, scored against the matches your team has already confirmed.
You work a ranked exception list
What did not tie arrives ordered by how much of the difference it explains, each item carrying the reason and the candidates that were rejected. A person decides what each one is and posts any entry in the ledger, where it belongs. Reconciler never posts.
How the category compares
Who actually connects a payment processor, and who only connects bank and ERP data
This is the distinction that decides whether a tool can solve your problem, and it is not the one the category markets on. Most reconciliation platforms are excellent at bank and ERP matching and were never built to take a payout apart.
| Tool | What it connects | Decomposes a processor payout? | How you buy it | Published price |
|---|---|---|---|---|
| Reconciler | Stripe, PayPal, Square, bank feeds, and corporate cards | Yes. Payouts are rebuilt from their charges, fees, and refunds. | Sold directly, self-serve | $49, $149 and $399 per month |
| Ledge | Payment processors including Stripe, Adyen and PayPal, plus bank and ERP | Yes. Processor reconciliation is the product it leads with. | Demo request, three tiers named Track, Execute and Enterprise | Not published. Stated as tailored to close scope, not per user |
| BlackLine | Bank, ERP, and high-volume source systems | Not the deposit-decomposition case. Matching assumes bank and ERP detail. | Module of the BlackLine close platform | Not published |
| Trintech | Bank, ERP, and card sources | Card and bank matching, configured during implementation. | Module of Cadency or Adra | Not published |
| HighRadius | Bank, ERP, and remittance data | Strong on remittance and cash application rather than processor payouts. | Module of the Record to Report suite | Not published |
| Numeric | Bank and ERP, including QuickBooks, Xero and NetSuite | Reconciliation and close workflow, not payout decomposition. | Part of the Numeric close platform | Essentials from $30 per user per month |
| Stripe's own reporting | Stripe only | Yes, for Stripe, and it is genuinely good at it. | Included with your Stripe account | Included |
| QuickBooks or Xero built in | One bank feed, plus a basic processor app in some cases | Rarely. Payouts usually arrive as a single unexplained deposit. | Included in your existing subscription | Included in the subscription |
Prices are listed only where the vendor publishes them on its own pricing page. Checked July 2026. If your central problem is certification workflow across every balance sheet account rather than payment settlement, BlackLine, Trintech and HighRadius are the right buy and we are not. The full market view is on account reconciliation software pricing, and the head-to-head with the closest competitor here is Ledge alternatives and competitors.
Before you buy
What to understand about payment reconciliation before you shop
Why payment reconciliation is harder than bank reconciliation
Bank reconciliation has a fixed shape. Two records of the same transactions, kept by two parties, differing mostly by timing, and both denominated in the same units at the same gross amounts. A check clears late, a deposit is in transit, and the difference resolves itself next period. Payment reconciliation breaks that symmetry: the processor does not deposit what it collected. It collects gross, subtracts a fee per charge, subtracts refunds issued since the last payout, occasionally subtracts a chargeback from a sale two months old, sometimes holds a reserve, and then pays the remainder on a delay. There is no amount in your ledger equal to the amount in your bank, and no date in your ledger equal to the date it arrived. Every naive matching approach fails on the first payout, which is why so many teams stop reconciling processors properly and start estimating instead.
The netting error that quietly misstates your books
The most common processor bookkeeping mistake is also the easiest to make: the deposit arrives, somebody codes it to revenue, and the books balance. They balance because the entry is internally consistent, not because it is right. Booking net deposits as revenue understates gross revenue by the entire fee load and makes processing cost disappear from the income statement completely. For a business running meaningful card volume, that is not a rounding issue, it is a visible percentage of the top line hidden inside a single account. It also destroys your ability to answer basic questions: what your real blended processing rate is, whether a channel is profitable after fees, whether a fee change actually happened. The fix is structural, not diligence. Split each payout into gross receipts and fees at the point of reconciliation, so the right numbers exist before anybody has to remember to look for them.
Why hand-built rules are the wrong answer here
The instinct with an unmatched payout is to write a rule: this deposit type, from this source, allow this percentage of variance. It works for a quarter. Then the processor adjusts a fee structure, or you enable a new payment method with different economics, or a refund lands inside a payout and the variance exceeds the tolerance, or you cross into a second currency. Now the rule matches the wrong things, which is worse than matching nothing, because a confident wrong match closes an item nobody will look at again. Tolerance-based rules on processor payouts are a maintenance liability that grows with your volume. Decomposition does not have this failure mode: if the charges, fees, and refunds attributed to a payout sum to the deposit, the payout is explained, and the arithmetic is inspectable by a reviewer who was not there when it ran.
The accounts most teams forget to reconcile at all
Ask a finance team which accounts they reconcile and you will hear cash, cards, and maybe clearing. Processor balances almost never come up, and they are real balance sheet accounts holding real money. The PayPal balance is an asset. A Stripe reserve is a receivable from Stripe. Funds captured but not yet paid out are cash you have earned and cannot spend. When none of these are reconciled, the bank ties out, the ledger ties out, and the actual position is still wrong, because a chunk of your money is sitting in a place with no account behind it. This is also the failure that surprises people during diligence or an audit, when somebody asks how much cash the business has and the answer turns out to depend on three processor dashboards nobody reconciles. Treat every processor balance as an account with an owner and a monthly tie-out.
What changes when you sell through more than one channel
One processor is a manageable problem. The difficulty is not linear in the number of channels, because each one brings its own payout cadence, its own fee model, its own refund and dispute mechanics, and sometimes its own currency and its own entity. Two processors and two entities is four reconciliations that have to agree with one ledger, usually maintained by different people in different spreadsheets, which is how the same transaction ends up counted twice or not at all. The practical symptom is that nobody can state the consolidated cash position without a meeting. This is the point at which multi-entity payment reconciliation stops being a spreadsheet job, and it arrives at a much lower revenue level than most teams expect, typically the moment a second sales channel goes live.
Marketplaces are a different and harder problem, and we will say so
Amazon, Shopify Payments, Etsy, and similar channels settle net of commissions, advertising, fulfillment and storage charges, returns, and adjustments that are specific to each platform and change without much notice. Reconciling them properly means parsing a settlement report per channel and mapping every deduction type to an account. Reconciler does not have direct connectors for marketplace payouts today. They reach us on the bank side, which means we will reconcile the deposit and the ledger, but we will not decompose an Amazon settlement report for you. If marketplace settlement decomposition is your central problem, buy a tool built for that channel. We would rather lose the sale than have you find that out in week two.
What to ask a payment reconciliation vendor on the demo
Six questions, and they are not the ones on the feature comparison. Which processors do you connect natively, and does that connection pull charge-level detail or only the payout total? Show me a payout reconciled back to its charges, fees, and refunds. What happens to a chargeback that arrives four months after the sale, and what happens if we win it? Do you split fees from gross receipts, or hand us the net? Do you write to our ledger, and can that be turned off? And what does it cost for our volume, in writing, before a call. Almost every vendor in this category will answer the first question with a logo wall and the second with a slide. Ours are answered on this page, and the vendor-by-vendor pricing position is on our pricing comparison.
Payments are one source among several. If the account under pressure is cash, bank reconciliation software covers the bank side end to end. The matching engine itself, independent of where the data comes from, is on transaction matching software. If the pressure is substantiating every account at period end, start with balance sheet reconciliation software, and if it is the close running long, month end close software separates the four different products sold under that name. For how much of the work is genuinely a model, AI reconciliation software goes through it stage by stage, and comparing vendors head to head is what the best account reconciliation software roundup is for.
Who buys it
Teams that need payouts reconciled rather than estimated
Questions people ask
Payment reconciliation, answered
What is payment reconciliation?
Payment reconciliation is the process of confirming that the money received from your payment processors matches the sales, invoices, and ledger entries that generated it, and explaining any difference. Because processors deposit a net amount after fees, refunds, and holds, the check is not a simple comparison of two totals. It is a reconstruction of each payout.
What is payment reconciliation software?
Payment reconciliation software connects to your payment processors, bank accounts, and accounting ledger, rebuilds each payout from the charges and deductions behind it, matches it against your ledger, and reports what does not tie as an exception. Good implementations separate processing fees from gross receipts and trace refunds and chargebacks back to the original sale.
What is a payment reconciliation system?
A payment reconciliation system is the combination of connections, matching logic, and review process that keeps your recorded revenue in agreement with the cash your processors actually paid out. In small operations it is a spreadsheet and a monthly habit. Above a few hundred transactions a month across more than one channel, it needs to be software, because payout decomposition does not scale by hand.
How do you reconcile a Stripe payout?
Take the payout amount that reached your bank, then pull every balance transaction Stripe assigned to it: each charge at gross, the fee on each charge, any refunds issued in the window, disputes, and adjustments. Those components must sum to the deposit. Then match the gross charges to invoices or sales receipts in your ledger and post the fees separately as an expense.
Why does my Stripe deposit not match my sales?
Because Stripe pays out net and on a delay. The deposit equals gross charges minus a fee on each one, minus refunds issued since the last payout, minus any disputes and reserve holds, and it settles to US accounts on a standard T+2 timing. Your ledger records sales at gross on the date they happened, so the amount and the date both differ by design.
How do you reconcile PayPal to your accounting system?
Reconcile the PayPal balance as its own asset account rather than only reconciling the transfers into your bank. Receipts, fees, and refunds all move the balance, and transfers to your bank are a separate movement. Treating the transfer as the whole transaction leaves the balance itself unreconciled, which is where most PayPal differences hide.
How do you automate credit card reconciliation?
Connect the card program read-only, then match each settled charge to the expense or payable entry recorded for it, allowing for the gap between authorization and settlement. Automation handles the volume and the timing; it cannot decide the expense coding for an ambiguous charge, so a reviewer still works an exception list. Reconciler does the matching and never posts the entry.
Is payment reconciliation the same as bank reconciliation?
No. Bank reconciliation compares your cash ledger to the bank statement, where both sides hold the same gross amounts and differ mainly on timing. Payment reconciliation deals with processors that deposit a net figure after fees, refunds, and holds, so there is no matching amount to find. Payment reconciliation is the harder of the two and most tools only do the first.
How do you reconcile payments across multiple entities?
Reconcile each entity against its own ledger first, then reconcile the intercompany movements separately, and only then consolidate. The failure mode is netting across entities to make a total agree, which hides an error in both. Reconciler treats each entity as its own set of sources against its own ledger and flags intercompany transfers rather than eliminating them for you.
What causes payment reconciliation differences?
In order of frequency: processing fees netted into revenue instead of being split out, refunds reducing a later payout, settlement timing across a period end, chargebacks arriving months after the sale, reserve holds that were never recorded, duplicate charges, and currency conversion on cross-border payments. Almost every difference is one of those seven.
Does payment reconciliation software post journal entries?
Some do. Reconciler does not, and the setting does not exist. We produce the reconciled figures, the fee split, and the explanation for each match. Deciding the entry and posting it is an accounting judgment with a named owner. Keeping those separate means an engine mistake surfaces in an exception queue rather than inside your ledger where nobody is looking for it.
What does payment reconciliation software cost?
Most of the category does not publish a figure. Ledge names three tiers and no prices, describing pricing as tailored to close scope. BlackLine, Trintech, HighRadius and OneStream publish nothing. Numeric publishes an Essentials tier from $30 per user per month. Reconciler is $49, $149, and $399 per month by volume and entity count, with no implementation fee.
Around payment reconciliation
Reconcile payments into your ledger
Point it at last month's payouts
Connect your processors, cards, banks, and ledger read-only, then look at what the payouts decompose into before you commit to anything. Every match carries the reason it was made, and nothing is written back to your books.