# Settlement & reconciliation
**Settlement** is when money actually moves between you and your suppliers (or partners). **Reconciliation** is the matching of expected money flows against actual ones — what should have arrived against what did. Together they are the operational heart of the payment surface.
## What settlement looks like
Settlement happens against a contract, on a schedule the contract defines. Common patterns:
* **Per-booking settlement** — each booking settles individually as soon as the cancellation window closes. Common with virtual-card flows.
* **Daily settlement** — Adrasis batches the day's settled bookings and runs one transaction per supplier per day.
* **Weekly settlement** — same pattern, weekly cadence; common for higher-volume contracts where daily transactions add overhead.
* **Monthly settlement** — common for B2B partners and some chain hotels; one consolidated batch per month. Example: *Hotel Sunrise contract is monthly*; on 1 May you see one batch totalling EUR 18,400 across 26 April bookings.
The contract surface defines the cadence; the settlement surface honours it. You do not have to think about which bookings belong to which batch — Adrasis groups them.
## What you see in the settlement surface
The settlement page shows:
* **Pending settlements** — bookings whose cancellation window has closed and which are due for settlement.
* **Settlements in progress** — batches that have been initiated, the transactions that are currently flowing.
* **Completed settlements** — recent batches with their status (success, partial failure, failed).
* **Settlement health per contract** — for each active contract, the timing and quality of recent settlements.
Each row drills into the specific bookings that make up the batch, the currency conversions applied, and the record of every transaction.
## What reconciliation looks like
Reconciliation is the loop that closes the settlement story. For each settlement:
Reconciliation matches expected transfers against actuals and shows what needs review.
Adrasis compares what should have transferred (from the booking + the contract) against what actually did transfer (from the bank, the payment gateway, or the supplier's confirmation). Three outcomes:
* **Match.** The settlement is recorded as complete; the booking is closed on the financial side.
* **Mismatch.** The amounts disagree; the discrepancy surfaces for review with the booking, the expected amount, the actual amount, and the candidate causes (currency-conversion variance, ancillary charge, partial cancellation not yet applied).
* **Missing.** The expected transaction did not arrive; Adrasis flags it for follow-up — sometimes a supplier-side delay, sometimes a real reconciliation issue.
You see all of this on the settlement page. Adragent can sweep the queue: *"Find every settlement mismatch in the last week and group them by likely cause."*
## Why mismatches happen
A few common reasons:
* **Currency-conversion variance.** The card is charged at the supplier's gateway rate, which differs from the rate Adrasis recorded at issuance. The variance is usually small but adds up — example: a EUR 600 virtual card lands as EUR 597.40 at the supplier because their acquirer used a slightly different rate. It is recorded so you can identify it.
* **Ancillary charges.** The supplier charged for a late check-out or a mini-bar that wasn't on the booking; the variance reflects what they added.
* **Partial cancellation timing.** A cancellation came through after the settlement was triggered; the next settlement run reconciles the difference.
* **Supplier error.** The supplier charged the wrong amount — sometimes an honest mistake, sometimes a clawback dispute. Either way, Adrasis makes it visible.
The reconciliation surface lets you accept a mismatch (record the variance, close the booking), open a discrepancy (dispute it with the supplier through the contract's defined channel), or hold it for finance review.
## Multi-currency reconciliation
When the booking, the card, and the bank account are in different currencies, reconciliation tracks every conversion. Concrete example on a *Hotel Sunrise* booking:
* **Booking currency** — traveller paid TRY 24,000.
* **Contract currency** — supplier charged EUR 600.
* **Settlement currency** — TRY 23,950 net arrived in your bank account.
* **Conversion variance** at each step (the difference between the rate Adrasis recorded and the actual rate the bank or gateway used).
A single booking can carry three variance lines on the reconciliation. Each is recorded and explainable; finance can rebuild the chain.
## Per-contract reconciliation rollups
For a finance team, the per-booking view is too granular. The settlement surface offers rollups:
* **Per-contract summary** — for a contract, total settled this month, total expected, total variance, percentage match.
* **Per-supplier summary** — across all contracts with a supplier, the same rollup.
* **Per-period summary** — for a date range, your full settlement health across all contracts.
These views are what finance uses for monthly close.
## When a settlement fails
Settlement transactions can fail at the payment gateway, the bank, or the supplier:
* **Gateway decline** — the card-funding source does not have the funds, fraud rules triggered, or the supplier's terminal had a transient issue.
* **Bank rejection** — for wire transfers: destination details were wrong, the account is closed, or the bank flagged it for review.
* **Supplier rejection** — rare, but the supplier explicitly refuses the payment for a contract reason.
Adrasis treats every failure as a recoverable event:
* The settlement is marked *failed*; the booking stays open on the financial side.
* A retry is scheduled per the contract's retry policy.
* After repeated failure, the case escalates to operations with full context — the booking, the failure history, the supplier's stated reason.
You see the failure on the settlement page; ops sees it through the notification surface. See [Notifications](/console/notifications-and-ops/notifications.md).
## Adragent and reconciliation
Common phrases that map to Adragent reconciliation operations:
* *"Run today's settlement batch for the Europe contracts."*
* *"Show me every settlement that's mismatched by more than 2% across the last 30 days."*
* *"Find the bookings still pending settlement after 7 days."*
* *"Pull the per-contract reconciliation summary for finance for last month."*
Read operations return immediately; writes preview before applying.
## Where to next
* **Virtual cards as the settlement instrument** → [Virtual cards](/console/payments/virtual-cards.md)
* **What happens on cancellations and disputes** → [Refunds & chargebacks](/console/payments/refunds-chargebacks.md)
* **The contracts that drive settlement cadence** → [Contracts](/console/contracts-and-onboarding/contracts.md)
* **The notification surface that flags settlement failures** → [Notifications](/console/notifications-and-ops/notifications.md)
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://adrasis.gitbook.io/console/payments/settlement-and-reconciliation.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.