Payment OperationsReconciliationFinance AutomationMay 20, 20268 min read

Payment Settlement FX Reconciliation in 2026: Rate Timestamps, Historical Replays, and Exception Queues

Cross-border payment teams rarely lose time because a single conversion failed. They lose time because the processor file, bank file, billing ledger, and customer-facing record all tell a slightly different story. The FX rate is one part of that story, but it is often the part nobody can reproduce quickly.

A settlement reconciliation workflow gives finance and operations a repeatable answer: which policy date was used, which rate was returned, when that rate was timestamped, how the expected amount was calculated, and why a row moved into review. That is different from a generic payment optimization article. The goal here is not to promise lower fees or faster settlement. It is to make multi-currency settlement rows explainable.

The verified Currency-Exchange.app surface supports this as an API-based pattern: conversion, exchange-rate lookup, historical date parameters, currency metadata, rateTime, optional provider and cached, rate-limit headers, usage statistics, and usage export. No native PSP, bank, ERP, spreadsheet, no-code, or MCP integration is assumed.

Why Settlement FX Reconciliation Matters

Settlement is where clean checkout math meets real operational data. A customer pays in one currency, a processor deducts fees, a marketplace pays a seller, a bank receives a net amount, and finance closes the period in a reporting currency. If the FX policy is not recorded at the row level, the team ends up arguing from screenshots and spreadsheets.

A better workflow separates the source-of-truth files from the FX evidence. The processor may own the settled amount. The ERP may own the invoice. The rate service owns the conversion evidence. Finance owns the policy that says which date and tolerance apply.

Source Files and Failure Points

SourceFields to NormalizeCommon Risk
Payment processor or PSP settlementpayment ID, settlement ID, gross amount, fees, net amount, currencies, datesFees and FX can be mixed together unless the row is normalized before review.
Bank statement or treasury filebank reference, value date, received amount, account currency, counterpartyValue date and processor settlement date may not match.
Commerce, billing, or marketplace ledgerorder ID, invoice ID, customer currency, presentment amount, refund amountCustomer-facing currency can differ from settlement currency.
FX evidence tablepolicy date, exchangeRate, rateTime, provider, cached, request ID, reviewerWithout rate evidence, every variance becomes a manual investigation.

Step-by-Step Workflow

Normalize the settlement file

Load processor, PSP, bank, marketplace, or wallet settlement rows into one table with payment ID, settlement ID, source amount, source currency, settlement amount, settlement currency, payment date, settlement date, and fee columns.

Attach currency metadata

Validate ISO codes, active status, symbols, and decimal behavior with the currency list or details endpoint before calculating expected values.

Replay the policy-date rate

Call conversion or exchange-rate lookup with the date parameter that matches your policy, such as payment date, authorization date, capture date, refund date, or settlement date.

Calculate variance and route exceptions

Compare expected converted amount with the settled amount after fees and rounding. Send rows outside policy tolerance to a review queue with rateTime and request evidence.

Export usage evidence for close

Reconcile API calls from usage statistics or downloadable usage exports against the rows processed in the settlement workbook, warehouse job, or orchestration layer.

API Examples

Replay a historical conversion for the policy date

curl "https://api.currency-exchange.app/v1-convert-currency?from=EUR&to=USD&amount=1240.50&date=2026-05-15" \
  -H "x-api-key: YOUR_API_KEY"

Fetch the rate only and capture headers

curl -i "https://api.currency-exchange.app/v1-get-currency-exchange-rate?from=EUR&to=USD&date=2026-05-15&skipCache=true" \
  -H "x-api-key: YOUR_API_KEY"

The rate-only endpoint is useful when your settlement system calculates amounts itself. Capture rate-limit headers with the row so operations can explain retries, throttling, or automation spikes.

Validate currency metadata before processing rows

curl "https://api.currency-exchange.app/v1-list-currencies?code=EUR&code=USD&code=JPY&active=true&pageSize=50" \
  -H "x-api-key: YOUR_API_KEY"

Export usage for the close period

curl "https://api.currency-exchange.app/v1-download-api-usage?from=2026-05-01&to=2026-05-31&service=currency&format=csv" \
  -H "x-api-key: YOUR_API_KEY"

TypeScript Reconciliation Function

type SettlementRow = {
  paymentId: string;
  settlementId: string;
  sourceAmount: number;
  sourceCurrency: string;
  settlementAmount: number;
  settlementCurrency: string;
  policyDate: string;
  processorFee?: number;
};

type FxEvidence = {
  paymentId: string;
  policyDate: string;
  exchangeRate: number;
  expectedSettlementAmount: number;
  varianceAmount: number;
  rateTime: string;
  provider?: string;
  cached?: boolean;
  rateLimitRemaining: string | null;
  status: 'approved' | 'review';
};

function roundMoney(value: number) {
  return Math.round(value * 100) / 100;
}

export async function reconcileSettlementRow(row: SettlementRow): Promise<FxEvidence> {
  const url = new URL('https://api.currency-exchange.app/v1-convert-currency');
  url.searchParams.set('from', row.sourceCurrency);
  url.searchParams.set('to', row.settlementCurrency);
  url.searchParams.set('amount', String(row.sourceAmount));
  url.searchParams.set('date', row.policyDate);

  const response = await fetch(url, {
    headers: { 'x-api-key': process.env.FX_API_KEY ?? '' },
  });

  if (!response.ok) {
    throw new Error(`FX replay failed for payment ${row.paymentId}: ${response.status}`);
  }

  const data = (await response.json()) as {
    exchangeRate: number;
    convertedAmount: number;
    rateTime: string;
    provider?: string;
    cached?: boolean;
  };

  const expectedSettlementAmount = roundMoney(data.convertedAmount - (row.processorFee ?? 0));
  const varianceAmount = roundMoney(row.settlementAmount - expectedSettlementAmount);
  const status = Math.abs(varianceAmount) <= 1 ? 'approved' : 'review';

  return {
    paymentId: row.paymentId,
    policyDate: row.policyDate,
    exchangeRate: data.exchangeRate,
    expectedSettlementAmount,
    varianceAmount,
    rateTime: data.rateTime,
    provider: data.provider,
    cached: data.cached,
    rateLimitRemaining: response.headers.get('X-RateLimit-Remaining'),
    status,
  };
}

The tolerance in this example is illustrative, not a recommendation. Finance should set tolerances by currency, processor, contract, and materiality. Some workflows need exact review; others accept rounding variance. The important part is that every approved or reviewed row carries the rate evidence.

Spreadsheet Review Queue

Spreadsheets are still useful when they are the review surface, not the source of truth for manual rates. A script, warehouse job, or no-code step can call the API, write evidence columns, and let finance approve exception rows.

payment_id,settlement_id,source_amount,source_currency,settlement_amount,settlement_currency,policy_date,exchange_rate,rate_time,expected_amount,variance,status,reviewer,override_reason

That structure works for Google Sheets, Excel, CSV exports, BI staging tables, and ERP imports. Keep the workflow honest: if the integration is a script or middleware job, call it that. Do not market it internally as a native connector.

Exception Matrix

ExceptionRouteEvidence to Keep
Unsupported or inactive currency codeData-quality queuecurrency metadata response, original file row, and source system owner
Missing or unparseable rateTimeEngineering incident queueAPI response, request timestamp, endpoint, and headers
Variance above toleranceFinance review queueexpected amount, settled amount, fee columns, policy date, and historical rate result
Unexpected API usage spikeAutomation ownerjob ID, row count, retry count, rate-limit headers, and usage export

Where the Workflow Runs

Spreadsheet review

Use Sheets or Excel as the approval surface after a script or middleware job writes normalized rows.

Avoid: Do not let reviewers type exchange rates manually into hidden columns.

Warehouse or BI pipeline

Upsert rates by pair and policy date, then join settlement rows to approved FX evidence tables.

Avoid: Do not recalculate historical rates differently in every dashboard.

ERP or accounting export

Export approved rows with original amount, converted amount, rateTime, variance, and approver.

Avoid: Do not claim a native ERP connector unless one is verified.

AI or no-code assistant

Let the assistant summarize exception rows only after the API and rules engine produce evidence.

Avoid: Do not let an agent invent a rate, policy date, or settlement explanation.

Choose the Date Policy Before You Automate

Historical exchange-rate access is useful only when the date rule is explicit. Finance, support, product, and engineering should agree on the policy before a worker starts filling cells or writing warehouse rows. The API can replay a date; it cannot decide which business event should govern the settlement explanation.

Date PolicyBest ForCaution
Authorization dateCard or wallet flows where the customer accepted a price before capture.Settlement may happen later, so variance review must separate price commitment from cash receipt.
Capture or invoice dateB2B invoices, marketplace orders, and quote-to-cash flows where finance books the receivable later.The ERP or billing system should store the policy date so downstream reports do not recalculate it.
Settlement dateCash reconciliation, bank statement matching, and payment-ops review of actual received funds.This can differ from the customer-facing rate and should not be used to rewrite the original quote.
Refund or adjustment dateSupport workflows, chargeback packets, partial refunds, and post-settlement corrections.Store the original transaction date too, because support often needs both views.

Payment Cost Optimization Without Made-Up Savings

Settlement reconciliation can support payment cost optimization, but it should not invent savings. The clean workflow is to label every fee, FX variance, routing choice, and rounding difference separately. Once those columns are consistent, finance can compare processors, corridors, and settlement currencies using its own data.

The API role is narrower and more reliable: provide the conversion evidence that lets a team distinguish rate movement from payment fees, settlement timing, or internal rounding. That distinction matters when a payment-ops team decides whether to change a corridor, update a billing policy, or ask a provider for a fee explanation.

For AI-assisted review, keep the same boundary. An agent can summarize exceptions, draft support notes, or explain why a row needs approval. It should quote the stored rate evidence and policy date instead of creating its own FX story.

Internal Links for the Build Path

FAQ

Is Currency-Exchange.app a native payment processor integration?

No native payment processor, bank, ERP, CPQ, spreadsheet, no-code, or MCP connector is verified on the public site. The workflow here is API-based: your settlement job, spreadsheet script, BI pipeline, or orchestration layer calls documented endpoints and stores the returned rate evidence.

Which date should settlement reconciliation use?

The API can accept an optional historical date, but the business must choose the policy. Common choices are authorization date, capture date, settlement date, refund date, or month-end close date. Store that policy date separately from request time and rateTime.

Can this workflow run in spreadsheets?

Yes, as a workflow pattern. Google Sheets, Excel, and no-code tools can call the API through scripts, connectors, or middleware, then review exception rows. That is different from claiming a native spreadsheet add-on.

Does this require a native bulk conversion endpoint?

No. For this article, bulk settlement processing means repeated documented calls through your queue, spreadsheet script, worker, or orchestration layer. Use rate-limit headers and usage exports to control volume.

Give settlement rows a rate trail

Test Currency-Exchange.app against your real settlement files: historical replay, currency metadata checks, exception queues, and usage exports. The best reconciliation workflow is the one finance can explain without asking engineering to reconstruct it by hand.