How Fintechs and Payment Companies Detect Revenue Leakage in Reconciliation

Revenue leakage is earned money a business never collects, or pays out twice, because its records do not agree across systems. Revenue leakage detection is the systematic identification of billing, settlement, fee, and transaction conditions that reduce recoverable revenue. It is distinct from fraud detection, which targets intentional manipulation, and from collections, which targets overdue balances. Leakage detection targets operational discrepancies: money that moved incorrectly because two systems recorded the same event differently, or one system failed to record it at all.

In fintech, payment companies, neobanks, and payfacs, leakage accumulates through duplicate payments, settlement breaks, unrecovered processor fees, and recurring write-offs. Datos Insights, in a June 2025 vendor landscape report hosted by FIS, found that financial institutions without mature pricing governance experience revenue leakage of 5% to 15% of potential earnings through unauthorized discounts, inconsistent pricing policies, and inadequate monitoring of fee waivers. The cost of operational inefficiency compounds that exposure: FIS’s Harmony Gap study, which surveyed more than 1,000 C-suite executives and business leaders, found that the average business loses $98.5 million annually on operational inefficiencies across billing, data collection, and reporting workflows.

The four leakage patterns finance teams miss

Most leakage in payment operations falls into four categories. Each originates in a different part of the money flow and is hard to catch because the evidence sits in more than one system.

• Duplicate payments: The same payout or settlement is issued twice, usually from a re-submission, a retry, or duplicate data entry. PYMNTS reported in October 2025 that double invoicing leads to overpayments, delayed reconciliations, and friction between buyers and suppliers, and that 63% of CFOs cite delays from manual AP workflows as a recurring problem. Without transaction-level matching, a duplicate looks identical to a legitimate second transaction.
• Settlement breaks: The amount a processor reports settling does not match what lands in the bank account or the internal ledger. The gap is often hidden inside net settlements, where fees, refunds, and chargebacks are deducted before the deposit arrives.
• Unrecovered processor fees: Fees charged by acquirers and payment service providers (PSPs) that were never validated against the contracted rate. When fee schedules change or are misapplied, the difference is rarely visible at the transaction level and is never recovered.
• Recurring write-offs: Unmatched differences that age past the point of investigation and get written off as a cost of doing business. A write-off is the accounting record of leakage that detection failed to catch in time.

None of these are visible from a single system. A duplicate payment, a settlement break, and an unrecovered fee can all touch the same transaction, recorded across a PSP export, a bank feed, and an internal ledger that never get compared line by line.

How a settlement break hides across systems

Consider a payment of $1,000 processed through a PSP. The PSP reports a gross settlement of $1,000 in its export file. By the time the funds arrive in the bank account, the deposit reads $982.50. The $17.50 gap covers interchange, processing fees, and a chargeback reserve the PSP netted before settling.

A finance team reconciling at the balance level sees the bank deposit and marks it closed. The PSP file says $1,000 settled; accounts receivable shows $1,000 expected; the bank shows $982.50 received. The $17.50 is not a write-off yet, but unless someone matches the three records at the transaction level and validates the fee deductions against the contracted rate, it either becomes one or disappears into a rounding account. Multiplied across thousands of transactions per day, that arithmetic is how unrecovered processor fees accumulate undetected.

Why fragmented systems make leakage invisible

A single online purchase may involve an authorization record, a capture transaction, processor fees, settlement batches, and potential refunds or chargebacks, with each step appearing in different systems at different times. PYMNTS reported in March 2026 that 66% of accounts payable teams saw an increase in manual workload over the prior year, and that finance teams spend most of the close cycle reconciling data across payments, ERP, billing, and banks rather than analyzing it.

For Controllers and Heads of FinOps managing multi-PSP environments, the data volume alone makes manual cross-system validation unsustainable. Detecting leakage requires reconciling at the transaction level across every source: PSP and acquirer exports, bank feeds, settlement files, and ledger entries. That is the function of payment reconciliation software, which defines the category, its core capabilities, and where different solutions fit.

Why late detection turns discrepancies into write-offs

A settlement break caught the day it appears can be corrected against the processor. The same break found at month-end close, after the cycle has closed, usually becomes a write-off. By the time a balance-level review notices a shortfall, the underlying transactions have aged past recovery and dispute resolution becomes difficult or impossible.

This timing problem is structural. PYMNTS reported in March 2026 that even companies with sophisticated ERP deployments export transaction files, conduct reconciliations in spreadsheets, and investigate exceptions across departments, with payment settlements, refunds, chargebacks, and fees frequently requiring separate tracking. Discrepancies that require separate tracking are discrepancies that get found late.

How reconciliation software detects leakage

Modern reconciliation automation follows a consistent sequence regardless of vendor. Understanding it clarifies where leakage is caught.

1. Data ingestion: Pull raw transaction data from every source (PSPs, acquirers, banks, ledgers, ERPs) through APIs, SFTP, or file exports.
2. Data normalization and standardization: Convert each input into a common schema so records from different systems can be compared across timing differences.
3. Transaction matching: Match records across all sources at the transaction level, not the balance level. Multi-source transaction matching is what isolates a duplicate payment or a settlement break to a specific transaction.
4. Exception surfacing: Group unmatched items into exceptions, then prioritize them by financial exposure so the highest-value differences are investigated first.
5. Exception resolution: Route each exception to investigation, correction, or escalation, with a logged record of the outcome.

Anomaly detection and cross-system validation flag records that do not reconcile at steps three and four. Exception prioritization ensures a finance team does not spend equal time on a $4 rounding difference and a $40,000 unrecovered fee.

Dig deeper: How reconciliation automation works end-to-end, from data ingestion through exception resolution

What detection looks like: manual versus automated

Manual workflows produce recurring write-offs because by the time a balance-level review notices a shortfall, the underlying transactions have aged past recovery. Automated, transaction-level reconciliation moves detection forward to the point where the difference can still be acted on. FIS reported in August 2025 that its Optimized Reconciliation Service targets at least 98% automated matching rates, with the goal of significantly reducing the time finance teams spend on discrepancy resolution.

Where agentic reconciliation fits

The next layer beyond rule-based matching is agentic reconciliation, where software investigates and resolves discrepancies rather than only flagging them. Rule-based systems surface an exception and stop. An agentic layer traces it back to the source: which PSP file, which transaction, which fee line caused the mismatch, and routes the finding to the right owner with the context needed to resolve it.

Rexi applies this model to payment reconciliation. The platform ingests, reconciles, investigates, and accounts for money flows across fragmented systems, surfacing duplicate payments, settlement breaks, and unrecovered fees as resolvable exceptions rather than end-of-cycle write-offs. The audit trail generated at the transaction level supports both internal controls and the traceability requirements from regulators and sponsor banks.

Dig deeper: What transaction-level audit trails require in practice for fintechs and their compliance teams

First steps for finance teams suspecting leakage

• Map your sources: List every system that records money movement: each PSP, acquirer, bank, ledger, and ERP. Leakage hides in the gaps between them.
• Move matching to the transaction level: Balance-level reconciliation cannot localize a duplicate payment or a fee error. Transaction-level matching can.
• Measure detection timing: Track how long a discrepancy takes to surface. If the answer is at month-end, that delay is where write-offs originate.

Revenue leakage is a measurement problem. It is solvable once reconciliation runs across every system at the transaction level, fast enough to act before the money is gone.