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.

API partner statements

Open Connectivity > Sales channels > API partners, choose a partner account and open Statements. The list groups bookings charged to that account by the stay's departure week or month and by currency. Each period shows the amount billed, collections and outstanding balance. These statements are separate from sub-agency sales summaries.

Open a period to review its bookings and adjustments. With export permission, download that statement as CSV or Excel. It is a reconciliation record, not an invoice.

Record a payment already received

For a sealed statement, enter the amount in the statement's currency, the date received, payment method and reference, then choose Record payment. This records money already received; it does not start a bank transfer or charge a card. Recording and reversing payments require their own permissions.

The detail distinguishes payments recorded against the statement from collections against its bookings. Check both before entering a receipt so you do not record it twice. For example, a 1,575 TRY statement with a 500 TRY receipt leaves 1,075 TRY outstanding.

Use Reverse for a payment recorded in error. It adds a reversal without deleting the original payment and restores the balance. It does not return money through a bank or card provider.

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:

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. Adrasis AI Operator 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, because of an error or a disputed recovery. 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.

AI Operator and reconciliation

Common phrases that map to AI Operator 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
• What happens on cancellations and disputes → Refunds & payment disputes
• Contracts defining the settlement schedule → Contracts
• The notification surface that flags settlement failures → Notifications