Reconciliation Export
Merchant and accounting export for payments, spend, fees, and settlement state
Reconciliation Export
Use this page for BDT-322 on the M6 Observability + Settlement Ops milestone.
The goal is to give merchant finance and accounting ops a stable export that can be reconciled against ledger activity and bank or chain records.
Export scope
The reconciliation export should cover:
- payment sessions
- spend events
- fees
- settlement state
- refunds when they exist
The export is merchant-scoped and can be filtered by merchant and date range.
Required columns
| Column | Meaning |
|---|---|
session_id | Payment session id |
merchant_id | Merchant scope |
merchant_name | Human-readable merchant label |
chain | Chain involved |
network | Network involved |
token | Token symbol |
amount | Gross amount |
fee_amount | Fee amount |
status | Operational status |
tx_hash | Settlement or spend transaction hash |
proof | Verification or settlement proof when available |
created_at | Creation timestamp |
updated_at | Last update timestamp |
settled_at | Settlement timestamp when available |
Output format
Use either CSV or JSON.
- CSV is the default for accounting review.
- JSON is acceptable when a downstream system wants structured ingestion.
- Keep field names and column order stable across runs.
- Do not add hidden columns or per-request formatting changes.
Filtering rules
Apply filters in this order:
- Merchant scope
- Date range
- Status or settlement state
- Optional chain/token slice
That order keeps exports deterministic and avoids cross-tenant leakage.
Reconciliation guidance
- A payment export row should match the ledger view for the same
session_id. - A spend row should match the spend or payout audit record for the same merchant.
- Fee rows should stay separate from principal rows so accounting can sum them independently.
- Missing
tx_hashorproofvalues mean the row is not final yet.