A PSP settlement report closes at €12.34 million. The corresponding internal records show €12.461 million, leaving a €121,000 variance for finance to trace across processing fees, refunds, FX adjustments, and accounting entries.
When you’re dealing with multiple PSPs, currencies, and file formats, that work quickly becomes a heavily manual process that drains capacity, increases errors, and delays month-end close.
In this guide, we'll cover:
- What the payment reconciliation process typically includes
- The core record types involved
- The four operational contexts where reconciliation applies
- The step-by-step reconciliation process
- The discrepancy types responsible for most unexplained gaps
By the end, we’ll show you how your finance team can win back time and reduce reconciliation mismatches by using AI to unify and automate payment reconciliation across your entire stack.
What is payment reconciliation?
Payment reconciliation is the process of verifying that every payment collected matches what your PSPs report as transferred, and that what they transferred matches what landed in your bank account. It runs across the systems that record a transaction: order management records and the PSP or acquirer settlement files that confirm what was actually captured, refunded, and paid out. The goal is a confirmed match at the transaction level, line by line.
Without it, your finance and operations teams are left chasing unexplained discrepancies between orders, settlements, and bank deposits. That creates delays to month-end close, increases manual investigation work, and makes it harder to detect failed payments and revenue leakage before they become bigger problems.
What the payment reconciliation process covers
Although settlement and reconciliation are often used interchangeably, they describe different things. Settlement is the PSP transferring net funds (transaction volume minus fees, refunds, and any holds) into the merchant's bank account. Reconciliation is the verification layer that follows: confirming that what arrived matches what was expected, right down to the transaction level.
At the heart of that process is a core transaction-level match between two records:
- Order management record: What the customer paid at the point of transaction. This is the expected amount, the baseline against which everything else is checked.
- PSP settlement file: What the processor says it transferred after applying fees, FX conversions, and any rolling reserves.
In more complex setups, this match is then validated against bank statements, acquirer reports, and FX records to confirm what actually settled, what fees were applied, and when cash reached the merchant account. But discrepancies between these two core records are where most reconciliation issues occur. And in a multi-PSP environment, things become even more complex.
Where the payment reconciliation process applies
Bank reconciliation is the simplest version of the problem: one general ledger, one bank statement, and usually one timing difference to resolve. Most discrepancies come from transactions that were still pending when the statement closed and cleared shortly afterward. Annoying, perhaps, but generally predictable.
Payment reconciliation is broader. It spans order records and settlement files across multiple PSPs, currencies, and markets. The failure modes are different too: settlement file format mismatches, FX timing differences, and fees that belong to one reporting period but appear in another. These issues rarely announce themselves when they occur. They tend to surface during the period close, when someone notices the numbers don't quite add up.
The same pattern applies elsewhere: the longer the chain of systems and data relationships, the more opportunities there are for discrepancies to creep in unnoticed. A fee misclassified in the accounting layer can linger across a month-end close. A payout split error in a marketplace may compound across hundreds of seller disbursements before the variance becomes visible.
The 6-step payment reconciliation process
Payment reconciliation follows a strict sequence, with earlier steps gating later ones. Skipping normalization before matching produces false positives; classifying discrepancies before matching produces noise.
- Gather and normalize data from every PSP, acquirer, and bank.
- Run the match between order records and PSP/acquirer settlement files.
- Surface and classify discrepancies.
- Investigate the root cause and resolve ownership.
- Adjust, document, and create the audit trail.
- Verify, close, and report.
Each step is covered in detail below.
Step 1. Gather and normalize data from every PSP, acquirer, and bank
Each source covers a different point in the transaction's journey from customer payment to bank credit. Together, they form the complete data set the match needs to run against.
Five data sources feed the reconciliation process:
Before a single matching rule can run, every file needs to be transformed into a common schema with normalized field names, currency codes, and date formats. This same normalized data also needs to flow cleanly into downstream ERP platforms (such as NetSuite, SAP, or Oracle), where inconsistent PSP field structures and naming conventions otherwise create reporting and reconciliation gaps. That's not a one-off project.
Reconciliation therefore depends on the wider payment stack around it, including how transaction and settlement data move between systems.
PSPs change formats. APIs get version updates. New acquirer relationships get added. If normalization logic is buried inside matching rules, every change becomes a rebuild. Keeping normalization separate is what makes reconciliation manageable as the PSP stack grows.
These data consolidation issues are among the most common reconciliation challenges faced by enterprises, particularly as the number of PSPs and markets increases.
Step 2. Run a match across order and settlement
Once the data is normalized, you need to reconcile your transaction records against PSP and acquirer settlement files. The match runs between two layers: the order or merchant transaction record and the PSP or acquirer settlement file. That is where the money movement is confirmed: amount captured, fees deducted, refunds applied, and net payout.
Payrails' matching engine automates up to 95% of reconciliation across orders, payments, settlement, and accounting. The remaining 5% still needs human review and is concentrated in the transaction types that rules-based systems struggle with most.
The difference becomes more pronounced when comparing manual and automated payment reconciliation, particularly at volumes where spreadsheet matching and PSP-specific rules no longer scale.
The €121,000 discrepancy from the introduction is a useful example. When matched against settlement data, it breaks down into:
- €84,000 in acquirer markup and scheme fees applied at settlement that weren't reflected in the order record.
- €22,000 from an FX rate shift on a EUR transaction, where the capture rate differed from the settlement rate.
- €15,000 from a partial refund that reduced the settlement net without a corresponding adjustment in the order system.
None of these required the bank statement layer to identify. Every issue surfaced during the order-versus-settlement match long before the bank data is needed.
Step 3. Surface and classify discrepancies
Once the match runs, every unresolved item needs a classification before it can be routed to the right team. For finance operations and controllers, this is the step that gives you complete audit trails and keeps your month-end close on schedule.
Fee mismatches are the most common class at scale. The €84,000 discrepancy from earlier falls into this bucket: acquirer markup and scheme fees applied at settlement that weren't reflected in the order record. These issues typically arise when processor billing diverges from contracted rates. Finance owns the resolution, and Fee Monitoring can identify this class across every connected PSP from a single settlement file.
FX drift has a different cause. The $22 discrepancy came from a EUR transaction where the capture and settlement rates differed. Since currency conversion timing lies with the PSP, the discrepancy is expected. It still needs classifying and recording correctly so controllers can accurately report the variance and explain it during an audit, rather than raising an unnecessary dispute.
Partial refunds are the next class. This is the earlier $15 reduction, which stems from a refund that affected settlement totals without a matching adjustment in the order system. Because refund records are closer to customer operations than finance, ownership usually lands there.
Timing differences make up the fourth category. These occur when transactions appear in one source before another. They're not genuine discrepancies so much as sequencing gaps between settlement and bank credit dates. Left unclassified, however, they clutter the queue alongside real issues.
Within Payrails’ payment infrastructure, classification occurs as part of the matching process. Unresolved items are tagged as they're surfaced, allowing routing to happen automatically instead of creating another manual review step. This helps reduce the reconciliation workload that would otherwise consume your finance team’s time and require added FTE capacity as transaction volumes grow.
Step 4. Investigate root cause and resolve ownership
Most reconciliation delays are hand-off failures. A discrepancy sits untouched because finance assumed ops handled the refund adjustment, while ops assumed finance had already journaled it. By month-end close, everyone is suddenly very interested in ownership.
To avoid this, you need to start by assigning discrepancies to the right team from the outset.
- Finance owns fee mismatches, FX drift, and journal entries. Resolving these requires access to contracted fee schedules and FX records.
- Operations owns partial refunds and order adjustments. They’ll need access to customer service and order management systems rather than the payment layer to ensure commercial events are correctly reflected before they reach finance for reconciliation.
- Engineering owns data ingestion failures and PSP format changes. If a settlement file arrives in an unexpected format or a field mapping breaks, the fix belongs in the normalization layer.
Problems multiply when discrepancies aren't classified as they're surfaced. The bigger opportunity is to remove this manual coordination altogether. As finance teams adopt AI-powered workflows, discrepancies can be automatically classified and routed to the right owner.
Rather than relying on manual classification and routing, Payrails surfaces and clusters discrepancies by class.
Step 5. Adjust, document, and create the audit trail
Resolution is complete only when three things happen together: the journal is posted, the reason is logged, and the supporting evidence is attached, in that order every time.
The audit-grade evidence chain runs from order to settlement to adjustment to posting. Every adjustment carries a reason code. Every reason code has supporting evidence attached in the form of a PSP report excerpt or FX rate snapshot, along with dispute correspondence and a timestamped sign-off showing who approved it.
Although many teams get the resolution right, the challenge often comes later. Months down the line, a SOX sample request arrives. The adjustment is sitting in the ledger, but the supporting evidence is scattered across email threads, a Notion page, and a spreadsheet nobody remembered to update.
Treating the audit trail as part of reconciliation means the evidence chain is intact before anyone asks for it.
Every adjustment posted through Payrails Reconciliation is timestamped, reason-coded, and stored alongside the source evidence, so the full chain is already intact before anyone asks for it.
Step 6. Verify, close, and report
Each check targets a different layer of the close: PSP-level totals confirm volume accuracy, discrepancy statuses confirm nothing was left unresolved, and audit trail entries confirm every adjustment can be evidenced on demand. Together, they give your finance team the confidence to sign off the period and support any subsequent audit.
"Closed" has a very specific meaning. Every transaction is matched or explained. Every adjustment is posted. Every audit trail is complete. Anything less is still open, regardless of how the period looks in aggregate.
Verification happens per PSP, per currency, per reporting period. Three final checks confirm the close:
- Merchant totals equal PSP totals for the period.
- Every flagged discrepancy has a final status: resolved, written off, or deferred with a documented reason.
- Every adjustment from Step 5 has a corresponding audit trail entry.
The reporting cadence then follows the audience. Finance leadership receives weekly reporting on open items and discrepancy aging. The CFO receives monthly reporting on close completeness and adjustment volume by class. Auditors receive year-end reporting covering the complete evidence trail for each close period.
Under SOX 404 and SOC 1, auditors typically request the chain, reason code, evidence, and sign-off in a single sample pull, all of which were covered by Step 5.
How Payrails Reconciliation automates the match across every PSP
If your merchant transaction records and PSP settlement files don't reconcile at period end, the gap belongs to one of four classes: fee mismatch, FX drift, partial refund, or timing difference. Start with correctly classifying the issue so that ownership over resolving it can be defined at the outset.
Manual reconciliation is often slow because the data layer underneath wasn't built for the scope of a multi-PSP, multi-currency operation. Every new processor adds a format and a fee structure that the matching logic has to account for. If you’re a hospitality business reconciling bookings across multiple refund windows, exceptions will quickly accumulate, making manual reconciliation impractical.
The teams that consistently close on time have one thing in common: unified data across every PSP. That means fewer manual matches, less time spent investigating exceptions, a lighter workload for finance teams, and a faster, more reliable period close.
If your team is spending time chasing discrepancies across PSP portals instead of closing the period, the data layer is usually the problem.
Book a demo to see how Payrails Reconciliation takes the pain out of closing the books.
Frequently asked questions
What is the difference between payment reconciliation and bank reconciliation?
Bank reconciliation matches your books against a single bank statement and resolves any timing differences along the way.
Payment reconciliation is a much bigger job. Instead of one ledger and one data source, you're matching order records against every PSP and acquirer settlement file, often across multiple currencies, PSPs, and legal entities. On top of that, you need a complete audit trail linking transactions all the way through the payment lifecycle.
How long should the payment reconciliation process take?
Daily reconciliation should be completed within one business day of receiving T+1 files. Weekly reconciliation should take around two days from period end, while monthly reconciliation should be wrapped up within five business days. If your process is consistently slower than that, the culprit is usually fragmented data or breakdowns between teams rather than the matching engine itself.
What causes most payment reconciliation errors?
The usual suspects are the same four issues covered in Step 3: fee mismatches, FX drift, partial refunds, and timing differences. The problem tends to snowball when data arrives scattered across multiple PSP portals instead of being normalized into a common schema before matching begins.
Can payment reconciliation be fully automated?
For high-volume transactions with clean, consistent data, yes. The more complicated cases (split refunds, unusual fee structures, FX edge cases) typically require human review. Rather than automating every edge case, the goal is to automate the routine work and surface the exceptions that genuinely need attention.
I am the text that will be copied.
