Payment Reconciliation

Payment reconciliation ties every transaction from order to bank deposit — fees, payouts, disputes and exceptions — so that what the merchant sold, what the processor settled and what the bank posted all agree. This page lists the 59 data points Athia uses for this use case, with the definition, type, expected source and availability of each.

The field names below are the payments-standard names for each data point. Use this page as a mapping aid: line up each field against its equivalent in your order, PSP, acquirer and bank data, and note where a name, format or grain differs.

Sub-use cases

• 3-way reconciliation — Matching the order record, the PSP/acquirer record and the bank posting on shared identifiers — order and gateway transaction IDs, auth code, ARN, RRN, STAN, settlement ID, bank transaction ID — and reconciling the amounts and timestamps across the three.
• ERP cash-application — Applying bank receipts back to invoices and orders using invoice ID, merchant reference, bank reference, remittance information and the posted amount.
• Tax & tip — Explaining differences between the order total and the amount actually captured, using order amount against capture amount.
• FX / cross-border — Reconciling presentment amount and currency against settlement amount and currency, including the applied rate, its source, FX markup in basis points, DCC flag and cross-border fee.
• Multi-PSP / multi-acquirer — Normalising records across processors and acquirers using gateway transaction ID, MID, TID and raw processor response codes.
• Network reports — Reconciling network-level lines — interchange amount, scheme fee, settlement ID and ARN — against acquirer settlement files.
• Chargebacks & refunds — Tracking dispute cases end to end: case ID, reason code, chargeback cycle, response deadline and representment outcome, plus refunds and the settlement they land in.
• Reserves — Following amounts held back and released, using batch and settlement IDs, settlement date, gross and net settlement amounts, posted amount and payout ID.
• Fee reconciliation — Verifying charged fees line by line — interchange program code and rate, scheme fee code and amount, cross-border fee and FX markup — against gross and net settlement amounts.
• ISO 20022 bank layer — Working with structured bank message fields: value date, end-to-end ID, instruction ID, transaction ID and remittance information.
• Marketplace payouts — Tracing funds out to sub-merchants or sellers via the payout identifier.
• Exception management — Handling breaks that do not reconcile: exception type, aging in days, monetary impact and resolution code.

Data points

All 59 fields, grouped by category.

Order layer

Gateway / PSP

Acquirer settlement

Bank layer

Fee detail

FX detail

Disputes & refunds

Exceptions

Availability

Availability describes how reliably Athia can obtain a field in practice, not how important it is. A field marked Partial is still worth mapping — it simply will not be present for every provider or every transaction.

For payment reconciliation, no field is marked Not available — every data point on this page is obtainable. Two are Partial: tid, which only applies where terminals are involved, and dcc_flag, which depends on the provider reporting dynamic currency conversion. Where either is absent, terminal-level and DCC-specific breakdowns are correspondingly incomplete.

Data class

PCI fields are minimised: BIN plus last four only, never a full PAN and never a CVV value. PII should be delivered hashed, tokenized or generalized wherever the analysis allows it — in this use case customer_id is the only field carrying PII, and a stable pseudonymous identifier is sufficient. Sensitive fields are never required.

Field-level definitions for the core entities are in Athia Data Dictionary.