# Authorized, Settled, Deposited: Why These Three Numbers Never Match

Canonical URL: https://y.uno/en/blog/authorized-settled-deposited-why-these-three-numbers-never-match

> This is the markdown rendition for AI agents. The canonical page is served as HTML at the URL above.

By Yuno · Published 2026-11-09 · Payment strategy

Authorization, settlement, and deposit are three separate events that produce three different numbers. Reconciliation breaks on the exceptions, not the happy path, so test partial captures, split refunds, FX conversion, and chargebacks first.

What you will learn: How one order moves from authorization through capture, settlement, and deposit, with every deduction named, and why the authorized, settled, and deposited amounts are always different numbers, most of the time for expected reasons, and occasionally because something has gone wrong.
The common assumption is that reconciliation is an accounting formality: match the deposit to the invoice and move on. That assumption holds on the happy path. It breaks the moment you encounter a partial capture, a split refund, a cross-currency settlement, or a chargeback that arrives three weeks after the original transaction settled. Those exceptions are not edge cases. They are the normal operating reality of any merchant running volume at scale across multiple providers. The thesis here is direct: reconciliation breaks on the exceptions, not the happy path. Build your matching logic around those first, and the rest follows easily.

## Key takeaways

- Authorization, capture, settlement, and deposit are four separate events that produce different numbers by design.
- Fees, refunds, chargebacks, rolling reserves, and FX conversion each reduce the deposit below the authorized amount in predictable ways.
- Partial captures and split refunds create one-to-many relationships between orders and settlement records that break simple matching logic.
- Chargebacks appear in a separate data feed from settlement, often weeks later, and must be matched independently.
- Running multiple PSPs multiplies every exception: each provider has its own fee schedule, settlement cycle, and report format.

## The four events every payment passes through
Authorization, capture, settlement, and deposit are distinct steps, not synonyms. Conflating them is the root cause of most reconciliation confusion.
According to the Mastercard Integration Guide, authorization reserves the total order amount without debiting the customer's account. Capture is the separate action that debits the card and transfers funds to the merchant account. Authorization is a reservation. Capture is the actual debit.
Settlement follows capture. The acquirer nets your captured transactions against fees, refunds, and chargebacks, then schedules a transfer. The transfer to your bank account is the deposit. These four events can span hours, days, or weeks depending on the provider, the payment method, and the currency corridor.

### Why the gap between authorization and capture matters
Many merchants authorize at the moment of purchase and capture later, once goods ship. If the captured amount differs from the authorized amount, because an item was out of stock, for example, the settlement reflects the lower capture figure.
Say the authorization log shows EUR 1,000 and the settlement report shows a lower captured figure. Both are correct. Neither is an error. A reconciliation system that matches authorization to deposit directly will flag this as a discrepancy every time. Partial capture is the first exception to build for. It is common in retail, travel, and subscription businesses where the final order value is confirmed after the initial authorization.

## Gross-to-net: tracing every deduction
The deposit is the authorized amount minus every deduction applied between capture and bank transfer. There are five categories of deduction, and each one must be tracked separately.
The five deduction categories are:

- Provider fees: interchange, scheme fees, and acquirer processing fees, deducted at settlement
- Refunds: full or partial, reducing the net settlement for the period in which they are processed
- Chargebacks: cardholder-initiated disputes, plus a dispute fee from the acquirer, appearing in a separate report
- Rolling reserves: a percentage of gross volume withheld by the acquirer as a risk buffer, released on a delayed schedule
- FX conversion: the difference between the exchange rate at authorization and the rate applied at settlement

Image: Five deductions explain every gap between authorized and deposited amounts. Hypothetical EUR 1,000 order; all deduction rates are stated assumptions. Provider fees (interchange + scheme + acquirer): Deduction type: Fee; Expected or error: Expected; Appears in which report: Settlement file; EUR impact on EUR 1,000 order: −EUR 22.00. Partial refund (one item returned): Deduction type: Merchant-initiated; Expected or error: Expected; Appears in which report: Settlement file; EUR impact on EUR 1,000 order: −EUR 120.00. Chargeback (cardholder-initiated dispute): Deduction type: Cardholder-initiated; Expected or error: Expected; Appears in which report: Dispute report (separate); EUR impact on EUR 1,000 order: −EUR 200.00. Dispute fee from acquirer: Deduction type: Acquirer charge; Expected or error: Expected; Appears in which report: Dispute report (separate); EUR impact on EUR 1,000 order: −EUR 25.00. Rolling reserve (10% of gross): Deduction type: Risk buffer; Expected or error: Expected; Appears in which report: Reserve ledger; EUR impact on EUR 1,000 order: −EUR 100.00. FX rate movement (auth vs settlement): Deduction type: FX timing difference; Expected or error: Expected; Appears in which report: FX rate record; EUR impact on EUR 1,000 order: Auth 1.085 vs settle 1.078.
Five deductions explain every gap between authorized and deposited amounts. Source: Illustrative

## Worked example: one EUR 1,000 order, fully traced
This company is hypothetical. All assumptions are stated below. The purpose is to show each deduction in sequence so the calculation can be reproduced on a whiteboard.
Assumptions: gross authorized amount EUR 1,000; interchange fee 1.5% of gross; scheme fee 0.3% of gross; acquirer processing fee 0.4% of gross; one partial refund of EUR 120 (one item returned); one chargeback of EUR 200 with a EUR 25 dispute fee; rolling reserve of 10% of gross; EUR/USD authorization rate 1.085; EUR/USD settlement rate 1.078.
The Mastercard API Documentation confirms that refunds can be partial, and are linked to the original order through the orderId with the specific amount to refund stated. The Mastercard Integration Guide confirms that capture is what actually debits the card and transfers funds. These two facts anchor the deduction sequence below.
Step one: apply provider fees to gross captured amount.

- Interchange: EUR 1,000 × 1.5% = EUR 15.00
- Scheme fee: EUR 1,000 × 0.3% = EUR 3.00
- Acquirer processing: EUR 1,000 × 0.4% = EUR 4.00
- Total fees: EUR 22.00
- After fees: EUR 1,000 − EUR 22.00 = EUR 978.00
Step two: deduct the partial refund. According to the Mastercard API Documentation, a refund is linked to the original order via the orderId and can be for any partial amount. EUR 978.00 − EUR 120.00 = EUR 858.00.
Step three: deduct the chargeback and its dispute fee. The chargeback of EUR 200 arrives in a separate dispute report, not in the standard settlement file. The acquirer also charges EUR 25 as a dispute processing fee. EUR 858.00 − EUR 200.00 − EUR 25.00 = EUR 633.00.
Step four: apply the rolling reserve. The acquirer withholds 10% of gross: EUR 1,000 × 10% = EUR 100.00. EUR 633.00 − EUR 100.00 = EUR 533.00.
Step five: apply FX conversion. The authorization was recorded at EUR/USD 1.085. By settlement, the rate has moved to 1.078. The USD deposit is EUR 533.00 × 1.078 = USD 574.57. If the authorization rate had held, the deposit would have been EUR 533.00 × 1.085 = USD 578.31. The FX difference is USD 3.73. This is not an error. It is a known exposure that must be recorded per transaction.
Summary: an order authorized at EUR 1,000 produces a USD deposit of approximately USD 574.57. The gap is entirely explained by five deductions applied in sequence. None of them are errors. All of them must appear in your reconciliation logic, or the gap will look like a discrepancy.

## Where reconciliation actually breaks
The happy path reconciles itself. One full capture, no refund, same currency, no chargeback: the deposit is the gross amount minus a fixed fee schedule, and any matching tool handles it in seconds.
The failures accumulate in the exceptions. Here is where to focus your testing:

### Partial captures
A single authorization can produce multiple capture records if the order is fulfilled in stages. Each capture settles separately.
Your order ledger shows one authorization ID. Your settlement report shows two or three capture records. A naive one-to-one match will mark all three as unmatched. The fix is to group captures by the original authorization reference before matching.

### Split refunds
The Mastercard API Documentation confirms that a refund is linked to the original order through the orderId, and the amount can be any partial figure. A customer who returns two items in separate shipments generates two refund records tied to one order ID.
Both reduce the settlement for the period in which they clear, which may be different settlement cycles. Your matching logic must sum all refunds against the original order before comparing to the deposit.

### Chargebacks across providers
When a merchant runs multiple PSPs, a chargeback may arrive through a different reporting channel from the original settlement. PSP A settled the transaction. PSP B processes the dispute.
The chargeback debit appears in PSP B's report with no direct link to PSP A's settlement record. Without a normalized order identifier spanning both providers, this discrepancy is nearly impossible to match automatically. This is the most common source of unreconciled items in multi-PSP environments, and it compounds at scale. For further reading on this specific problem, see how enterprise SaaS platforms should think about payment reconciliation when operating across multiple PSPs.

### FX timing mismatches
Every cross-currency transaction carries a rate at authorization and a different rate at settlement. The difference is expected but must be tracked per transaction.
Merchants running volume in multiple currencies can accumulate FX differences across hundreds of transactions per settlement cycle. Without per-transaction FX records, the aggregate difference looks like a provider error. It is not.

### Rolling reserve releases
Reserves withheld in one period are released on a delayed schedule in a later period. The deposit in month four includes both current-period net settlement and a reserve release from month one.
If the reconciliation model does not account for reserve movements separately, the deposit will never match the period's settlement report. Build a reserve ledger alongside your main reconciliation ledger.

## Matching three provider reports to one order ledger
Multi-PSP reconciliation requires a normalized layer between provider reports and the order ledger. Each PSP delivers data in its own format, on its own cycle, with its own fee labeling conventions.
The practical approach is to normalize all provider reports to a common schema before attempting any match. The common schema needs at minimum: a canonical order ID, a provider transaction ID, a gross amount, a currency, a settlement date, an itemized fee breakdown, a refund flag and amount, and a chargeback flag and amount. Once normalized, matching runs against the order ledger on the canonical order ID.

Image: Each exception breaks simple matching in a different way. Illustrative; exceptions drawn from the five deduction categories named in the piece. Partial capture: One-to-many records: One auth, one or more capture records; Separate data feed: Appears in settlement report; Delayed arrival: Typically same cycle; Reduces deposit: Deposit reflects lower captured amount. Split refund: One-to-many records: One order, multiple refund line items; Separate data feed: Appears in settlement report; Delayed arrival: Processed in period of refund; Reduces deposit: Nets against settlement for that period. Chargeback: One-to-many records: One order, separate dispute record; Separate data feed: Arrives in dispute feed, not settlement; Delayed arrival: Can arrive weeks after settlement; Reduces deposit: EUR 200 debit plus EUR 25 dispute fee. Rolling reserve: One-to-many records: Single withholding line per period; Separate data feed: Appears in settlement report; Delayed arrival: Released on delayed schedule; Reduces deposit: 10% of gross withheld until release. FX conversion: One-to-many records: Single conversion per transaction; Separate data feed: Appears in settlement report; Delayed arrival: Applied at settlement date; Reduces deposit: Rate at auth 1.085 vs settlement 1.078.
Each exception breaks simple matching in a different way. Source: Illustrative
The table below summarizes which differences between authorized, settled, and deposited are expected versus which signal a potential error.

| Difference observed | Expected or error | What to check |
| --- | --- | --- |
| Deposit below authorization by fee percentage | Expected | Confirm fee schedule matches contract |
| Settlement below capture due to partial refund | Expected | Match refund records to original orderId |
| Deposit below settlement by chargeback amount | Expected | Match chargeback report to original transaction |
| Deposit reduced by rolling reserve | Expected | Verify reserve rate matches contract; track release schedule |
| FX difference between authorization and deposit | Expected | Record rate at both events; flag if gap exceeds tolerance |
| Settlement record with no matching order ID | Error | Investigate provider report for duplicate or ghost transaction |
| Fee amount exceeds contracted rate | Error | Raise with provider; request credit note |
| Chargeback on a transaction already refunded | Error or fraud | File representment; alert fraud operations |

## Where Yuno fits
Yuno's Reconciliations module normalizes settlement data across all connected providers into one ledger, automatically. This is the structural problem it solves: each provider has its own reporting format, settlement cycle, and fee structure, and the finance function should not need to merge those manually.
Yuno is the AI-native intelligence system of global payments and financial services. It has processed more than one billion payments across 150-plus currencies since January 2025. Because Yuno sits outside the funds flow and does not touch the money, the reconciliation data it surfaces is a neutral read of what every connected provider reports, with no incentive to favor one provider's numbers over another's.
Heads of payments at companies like Rappi and inDrive operate across many markets with many local providers. The reconciliation challenge in those environments scales directly with the number of providers and currencies. A normalized, provider-agnostic ledger is the only practical answer. For a deeper look at what to automate first, see payment reconciliation software for businesses with several PSPs: what to automate first.
The question of which payment platform best unifies multi-PSP setups into one finance dashboard comes down to one capability: does the platform normalize provider reports at the transaction level before matching, or does it leave that to the finance function? Normalization is the work. The dashboard is just the output.
Reconciliation is not a reporting problem. It is a data-quality problem that shows up in reporting. The merchants who solve it first build their matching logic around the exceptions: partial captures, split refunds, cross-currency chargebacks, and rolling reserve releases. Test those scenarios before you test the happy path. The happy path was never the problem.