Clearing and reconciliation

Find a transaction use case — purchases, amount changes, clearing, reversals and matching.

This guide covers the clearing-stage side of the transaction lifecycle.

A presentment can arrive after its authorization, before the referenced authorization is received, or without an authorization reference. The posting rule is the same: process each distinct presentment once.

For the end-to-end transaction map, use Transaction lifecycle.

Clearing supplies the financial record for each presentment. It does not by itself establish that no further presentments will follow for the authorization.

Presentment webhook

FINCI delivers the presentment event through a webhook once the transaction reaches the clearing stage.

That event supplies a clearing record for posting and reconciliation. Each distinct presentment is handled as its own financial event.

In the common case, presentment can be linked back to an earlier authorization flow.

Where a non-empty authorization_id is supplied, use it to link the cleared transaction to the exact earlier authorization ID. This reference can be empty or absent.

When presentment arrives

The merchant and acquirer decide when to submit clearing. Presentment normally arrives in 1–3 business days, but this is typical timing, not a delivery guarantee.

For ordinary Mastercard purchase flows, the common presentment windows are:

Preauthorization is useful when the amount is estimated first, for example a taxi fare, hotel stay or other travel purchase. Those categories do not require preauthorization: the merchant can use a final authorization, so a travel transaction does not automatically get 30 days.

These common windows have transaction and regional exceptions. Use the applicable category and program configuration, rather than inferring preauthorization from Goods, advice or merchant category alone. See Mastercard Transaction Processing Rules, sections 2.5, 2.7 and 2.8.

Keep receipt timing, the presentment window and your hold-closing timer separate. Configure hold expiry with FINCI for the applicable network/category rules; release an open hold if no presentment or other closing event has closed it by that expiry. A lack of clearing after three business days is not itself a decline or a reason to release the hold.

If a distinct presentment arrives after the hold expires, post it once under the funding and reconciliation rules. Do not reopen the expired hold or discard the clearing solely because it is late. Timing alone does not establish chargeback eligibility.

Process a presentment

1. Store the complete payload and its own id without rounding. Use environment, program, webhook type and presentment id to identify a repeated delivery.
2. Resolve a non-empty authorization_id to the exact authorization in the same card/program context. Keep a missing target pending; an empty reference stays unlinked. The reference may identify a related authorization: follow its original links and revisit a pending chain when earlier records arrive.
3. For each accounts_local[] entry, post its signed account_amount once in account_currency. The local total in the FX and ATM examples already includes fees.
4. In the same accounting operation, release the entire remaining hold for the matched authorization or shared purchase reservation. This applies even when the presentment is smaller than the approval. Post only the supplied presentment amount; any unused reserved amount becomes available again. Handle any uncovered debit under the program's funding policy.
5. Acknowledge durable receipt using the response format in Webhook events. If processing is queued, retry the queued work without creating another posting.

Match authorization identity separately from account allocation. The account arrays do not have to be identical. Post the supplied local entries in their own currencies, then close the whole matched reservation, including its account allocations. Keep reservations for unrelated authorizations unchanged. If a reference or its original chain resolves after posting, close the matched hold once without posting again or recreating a reservation.

Presentment amounts

Read accounts_local[] for the actual local movement. Read settlement_details[] for the breakdown used to explain and reconcile it.

Presentments have no top-level amount_transaction, amount_settlement or rate. For EUR cards, the Transaction component uses EUR, matching accounts_local[].account_currency. Component signs can differ from the local posting sign. In the ATM example, EUR +215.22 principal, EUR -6.88 fee and EUR -1.08 markup accompany a local debit of EUR -223.18. Post the supplied local debit once.

Use Webhook amounts for every exact field meaning and complete purchase, FX, ATM, decline, reversal, partial-clearing and refund examples.

Presentment without an authorization reference

Merchant 11 sends a EUR 1.84 debit presentment with authorization_id: "". Post accounts_local[0].account_amount: -1.84 once and retain the clearing without an authorization link. An empty reference does not identify why authorization is absent; do not guess an RRN or NRN match for a presentment.

Several presentments

One approval usually has one presentment. In rare cases, it can have several, for example when shipments or services are billed separately. The first matched presentment releases the entire remaining hold. Post each later distinct presentment once; do not recreate the hold or release it again.

For Merchant 6, a EUR 0.01 authorization is followed by two EUR 2.90 presentments. Their own IDs differ; the authorization reference is the same:

Record both financial movements, totaling EUR 5.80. The first EUR 2.90 presentment releases the full EUR 0.01 hold and posts EUR -2.90. The second distinct presentment posts another EUR -2.90; the hold stays at EUR 0.00. Deduplicate by each presentment's own ID, not by authorization ID or amount. Apply the program's funding and excess rules to any uncovered amount; this example does not define a universal tolerance.

Smaller presentment and hold release

Merchant 7 authorizes EUR 6.50 and clears EUR 6.00. Release the full EUR 6.50 hold and post EUR -6.00 once in the same accounting operation. The unused EUR 0.50 becomes available again; the remaining hold is EUR 0.00.

A smaller presentment closes the matched hold. It does not prevent a later distinct presentment: post that later record once while keeping the original hold closed. A reversal received after clearing has no remaining hold to release and does not refund the posted debit.

Hold expiry before presentment

Apply configured expiry only while a hold is still open. For example, if EUR 6.50 is approved and no presentment arrives before expiry, release the open EUR 6.50 hold. Do not run a second release for a hold already closed by presentment or reversal.

If clearing arrives after expiry, preserve the authorization link and post the supplied amount once without reopening the expired hold.

Amount differences, funding and disputes

Compare amounts in the same currency, including approved additional authorizations and the relevant conversion and fee components.

A larger presentment can create a funding shortfall. A chargeback is a separate network dispute process with specific grounds, evidence and deadlines. A funding shortfall does not, by itself, establish chargeback eligibility; an unauthorized, duplicate or incorrectly billed charge needs its own dispute assessment.

Permitted excesses depend on the authorization type, transaction category, region and scheme/program rules. Use the limits agreed for your program; the API does not define one percentage for every transaction.

Deferred-authorization and offline transactions

A deferred authorization is an authorization request sent after the purchase, for example when connectivity returns. An offline transaction is accepted without a real-time issuer authorization. These terms describe different processing paths; neither can be inferred from an empty authorization_id.

If presentment is the first event you receive, post the supplied local movement once. Keep a non-empty authorization reference pending until its target arrives. If the reference is empty, keep the clearing unlinked. When the reference resolves, close the whole matched hold once without posting again. Do not create a new hold from an authorization that arrives after its linked clearing.

Reconciliation approach

Reconcile your reservations and posted movements from the stored webhook records. To reconcile those movements against FINCI's core ledger, your program also needs Payments API access to the relevant master account.

1. Retain each presentment's own id, its authorization_id where supplied, and every local account movement.
2. Retrieve the master-account transactions through the program's Payments API setup.
3. Match the supplied authorization references exactly. Several presentments can share one authorization_id, so it is not a unique financial-event key; reconcile each movement using the identifiers and matching rules in your Payments API contract.

An authorization is not the final financial record, and receipt of presentment does not confirm completed network cash settlement. Payments API endpoints and ledger fields are covered by that API's separate integration contract.

What should be linked

Keep the authorization, its related authorizations and reversals, and every distinct presentment. A partial reversal can be followed by clearing of the remainder, and one approval can have several presentments. Keep any reliable purchase link on a later refund separately from its link to the return authorization.

Reversals

An authorization reversal cancels all or part of a previously approved authorization's eligible unposted reservation.

A reversal arrives on the authorization webhook with authtype: "Reversal". Its id identifies the reversal itself. Store it separately from the earlier authorization and apply its hold-release effect once.

Release only the affected eligible hold; a partial reversal must not release the whole original reservation.

Link the reversal to the original authorization. It changes the reservation, not the amount already posted.

Use the automatic linking procedure. Match the exact original ID first. When it is empty, use only the configured original-reference or reversal RRN fallback. Keep a missing explicit target pending and conflicting references unresolved; the configured scope and time window must produce one qualifying record. After linking, release only the affected eligible unposted hold, once.

Sign note: the positive local amount on these reversals releases the eligible unposted hold. It does not post a refund or negate an already posted debit.

Partial reversal

For example, a Merchant 5 approval of EUR 10.00 is followed by a matched EUR 2.46 reversal and EUR 7.54 presentment: release EUR 2.46 before clearing, then release the entire remaining EUR 7.54 hold and post EUR -7.54 once. The reversal's original-reference fields are empty; its rrn matches the earlier authorization in the same card/account context, while its own nrn is different. The shared tlid supports the match. It is not a standalone matching key.

Full reversal

Merchant 9 authorizes GEL 7.30. Its local EUR 2.55 total includes a EUR 0.01 fee. The full reversal returns that same local EUR 2.55 amount, including the fee component.

The reversal has its own id and empty original-reference fields. A unique RRN match within the same card/account context identifies the earlier approval. Release the eligible EUR 2.55 hold once; a reversal does not post a refund.

Returns (refunds)

A return in this context represents a refund credit received after the original transaction flow.

In practice, that refund should also be posted and cleared through the transaction flow, rather than being treated as only an authorization-side event.

That refund may or may not carry a reliable link to the original transaction.

Where a reliable link is available, refunds should be matched to the original transaction so the integrator ledger and reporting remain coherent.

Refund: EUR 177.17

Merchant 10 sends a Return authorization and its approval, followed by a Return-Presentment with sign: "Credit" and local amount 177.17. Post the EUR +177.17 credit at presentment, once.

The presentment's authorization_id references the return authorization. It does not identify the earlier purchase. Keep a purchase link only when a reliable reference is available.

Reconciliation handling principles

• place reservations on approved authorizations if your model requires it
• release the affected open reservation on reversal, or an open hold at its agreed expiry
• post each distinct presentment once and release the whole matched hold on the first presentment
• post credits correctly for refunds
• distinguish webhook authtype values correctly: Cash, Goods, PaymentDebit, and QuasiCash as debit-side flows; PaymentCredit and Return (refund) as credit-side flows; Reversal as cancellation of a prior authorization; and GetContractInfo as a technical message
• keep a durable link between related transaction events using authorization_id and the corresponding ledger record