Authorization settlement accounting is the process finance teams use to match approved payment transactions to the funds that eventually settle in a bank account and the corresponding entries in an accounting ledger. A card payment authorization and its eventual settlement are two separate events produced at different times, by different systems, and often at different amounts. For fintechs, payment companies, and banks processing card transactions at scale, closing the gap between these two events is a core financial control requirement. Failures to link authorizations to their settlements create unmatched exceptions, distort cash positions, and produce audit findings that accumulate faster than manual investigation can resolve them.
For a full overview of how payment reconciliation is structured across data sources and workflows, see payment reconciliation software for fintechs and payment companies.
How a card payment moves from authorization to settlement
Card payments move through three stages: authorization, clearing, and settlement. Authorization is when the cardholder’s issuing bank approves the transaction and places a hold on the account to reserve the funds. Clearing is when the merchant’s acquirer exchanges transaction details with the card scheme and the issuing bank, producing a settlement file. Settlement is when the issuing bank transfers funds to the acquiring bank, which deposits them into the merchant’s account. Finextra describes each stage as a distinct step involving different participants and different data artifacts: authorization confirms the transaction, clearing creates the settlement file, and settlement moves the funds. The authorization event is a signal, not a transfer. The accounting entry for a payment cannot be confirmed until all three stages are complete and the amounts reconcile.
Why authorized amounts frequently differ from settled amounts
The amount authorized at the start of a transaction is not always the amount that settles. PYMNTS describes the gap between authorization and final settlement as a structural issue in card payments, one that recurs regularly in hotel bookings, car rentals, and restaurant payments where the final amount is not known at the point of authorization. Three scenarios generate authorized-to-settled discrepancies that require specific accounting treatment:
- Partial captures occur when a merchant captures less than the authorized amount. The uncaptured portion must be released from the hold without a corresponding settled value.
- Pre-authorization holds are placed for an estimated amount and adjusted when the final transaction is confirmed. The ledger entry must be updated when the final settled amount differs from the authorized amount.
- Cancellations occur when an authorized transaction is voided before capture. The authorization hold must be reversed without creating a receivable or a pending settlement expectation.
Each scenario requires different handling in the reconciliation workflow. A partial capture closes when the settlement file confirms the lower amount and the remainder is released. A pre-authorization closes when the final capture is matched to the adjusted settlement amount. A cancellation closes when the authorization record is voided and no corresponding settlement entry is expected.
How the auth-to-settlement gap generates accounting complexity at scale
A single payment transaction can produce records across multiple disconnected systems at different times. PYMNTS reports that a single online purchase may generate an authorization record, a capture transaction, processor fee entries, a settlement batch entry, and potential refund or chargeback records, each appearing in a different system at a different time. Finance teams processing high transaction volumes must reconcile authorization records from payment processors against capture files, settlement batches, bank deposits, and ledger postings, often with different reference identifiers across each system. When no common transaction identifier spans the full authorization-to-settlement chain, automated matching tools must apply fuzzy matching logic using amount, timing, and counterparty identifiers to reconstruct the connection.
Dig deeper: Why timing differences are the most common cause of reconciliation breaks
How reconciliation software links authorization records to settlement files and ledger entries
Reconciliation software handles authorization settlement accounting by ingesting data from payment processors, acquirer banks, and internal ledger systems and applying matching logic across all sources to connect each authorization event to its corresponding settlement record and ledger posting. Finextra describes authorization and clearing as two distinct messages sent from the merchant’s acquirer to the issuing bank via the card scheme, with actual funds movement occurring only after the issuer receives the transaction details file. Because these messages carry different reference identifiers, reconciliation tools apply time-window and amount-tolerance rules to link the authorization message to the clearing message and eventually to the settled funds entry.
PSP reconciliation handles the matching of payment service provider settlement files against internal transaction records, covering how PSP settlement files are structured and why settlement amounts differ from authorized totals due to fees, refunds, and chargebacks. Ledger reconciliation handles the matching of internal ledger entries against external data sources including settlement files and bank statements. Authorization settlement accounting spans both workflows: it requires confirming that each authorization was captured, that the capture was included in a settlement batch, and that the settled amount is reflected in both the bank statement and the general ledger.
How unlinked authorizations surface as exceptions
When reconciliation software cannot match an authorization record to a settlement entry within the expected processing window, it flags the authorization as unlinked and creates an exception for finance team review. Finance teams investigate whether the exception represents a timing difference (the settlement file has not yet arrived), a partial capture (the settlement amount differs from the authorized amount), a cancellation (the authorization was voided before capture), or a genuine missing settlement (the funds were never received). The accounting treatment differs across all four cases. Timing differences close automatically when the settlement file arrives. Cancellations require the ledger hold to be reversed without creating a receivable. Genuine missing settlements require escalation to the payment processor or acquirer bank, and may require a write-off if the funds are unrecoverable. PYMNTS confirms that payment settlements, refunds, chargebacks, and fees frequently require separate tracking because each appears in a different system at a different time, compounding the investigation workload when exceptions are not classified and resolved systematically.
How Rexi handles authorization settlement accounting
Rexi ingests authorization records, settlement files, and internal ledger entries from payment processors, acquirer banks, and internal systems into a unified data model. The Reconciler agent applies configurable matching logic to link each authorization event to its corresponding settlement record, accounting for timing differences, partial captures, and amount variances between authorized and settled values. Unmatched authorizations are surfaced as exceptions and routed to the finance team with the source data required to investigate and resolve each break. Every match decision, exception classification, and resolution is logged to an auditable record that finance teams can access without engineering support.
Frequently Asked Questions
How is authorization settlement accounting different from payment settlement reconciliation?
Authorization settlement accounting focuses specifically on tracing each approved payment transaction through to its captured and settled state, verifying that the authorized amount corresponds to a capture event and that capture event to a settlement entry at the expected amount. Payment settlement reconciliation covers the broader matching of settlement files against bank deposits, ledger entries, and processor records without specifically tracing the lifecycle of the original authorization. In practice, authorization settlement accounting is a sub-process within a larger settlement reconciliation workflow: it closes the auth-to-settlement gap before the settlement data is matched against the bank account and general ledger.
What happens when a payment authorization expires before it is captured?
Payment processor authorization holds have a maximum validity period, typically between seven and thirty days depending on the card scheme and merchant category code. If a merchant does not capture an authorized transaction within the validity window, the authorization expires and the hold on the cardholder’s account is released automatically. The authorization record remains in the payment processor’s logs, but no settlement entry will appear for it. Reconciliation software should be configured to close expired authorizations as voided exceptions rather than leaving them open as unresolved breaks. Finance teams that do not classify expired authorizations separately will accumulate a growing backlog of exceptions that have no corresponding settlement to investigate.
How does authorization settlement accounting work differently for recurring billing?
Recurring billing adds matching complexity because each charge in a subscription cycle generates a new authorization event with a different transaction identifier than the original enrollment authorization. Finance teams cannot rely on a single reference that spans the full subscription lifecycle to match each recurring authorization to its capture, settlement batch, and ledger posting. Reconciliation software handles this by applying matching rules based on merchant identifier, expected charge amount, and expected charge date rather than a single transaction reference. When a recurring charge fails to settle, the reconciliation system must surface the unmatched authorization as an exception and distinguish it from expected timing differences in the regular settlement cycle.
Does a payment authorization always settle within one business day?
Settlement timing varies by card scheme, processor, and settlement model. Next-business-day settlement is the standard for most consumer card transactions, but some processors operate on a two-to-three day settlement cycle. Same-day settlement is available from certain processors under specific agreements. Pre-authorization scenarios, such as hotel checkouts and car rental returns where the final amount is confirmed at a later date, can extend the gap between authorization and final settlement to several days or longer. Reconciliation workflows must account for variable settlement windows to distinguish open authorizations that represent timing differences from those that represent genuine exceptions requiring investigation.
How do chargebacks affect authorization settlement accounting records?
A chargeback reverses a settled payment after the settlement has already been matched to a bank deposit and posted to the ledger. For authorization settlement accounting purposes, the original authorization-to-settlement match is closed by the time the chargeback is initiated. The chargeback generates a new set of records, including the dispute filing, the reversal credit from the processor, and the chargeback fee, each of which must be matched against the original settled transaction and the current ledger balance. Reconciliation software tracks chargebacks as separate exception workflows rather than reopening the original authorization settlement match, ensuring that the audit trail for the original transaction remains intact while the chargeback dispute and its financial impact are tracked separately.
