Skip to main content
The Cases page is the main working queue for reconciliation operations. A ReconciliationCase is the system’s answer to “did the expected activity and the actual activity line up?” — every payment intent that has been created eventually resolves into a case with a status and a verdict.
Everything on this page is available through the API as well. The table reads from GET /v1/reconciliation-cases, the detail view from GET /v1/reconciliation-cases/{caseId}, and exports from GET /v1/exports/reconciliation-cases. The dashboard is a view onto these endpoints, not a separate source of truth.

​
Page layout

The page header reads “Reconciliation cases” with the description “The main queue for triage, investigation, and reconciliation operations.” Depending on your permissions, the header includes up to three actions:
  • New expected payment — opens a modal that creates a PaymentIntent via Create or reuse a payment intent (POST /v1/payment-intents, sent with an idempotency key), then loads the resulting case
  • Upload evidence — opens a modal that submits provider evidence via Submit provider evidence (POST /v1/evidence/provider)
  • Export view — opens the export modal described below

​
KPI strip

Below the header is a row of KPI cards summarizing the currently loaded cases: These counts reflect the cases currently loaded into the table (up to 100 at a time via GET /v1/reconciliation-cases?limit=100), not necessarily your entire organization’s history.

​
The case table

Each row represents one ReconciliationCase. The columns are:

​
Verdicts

​
Tabs

The table is organized into tabs that filter by verdict and status:
  • All
  • Needs review (verdict = needs_review)
  • SLA risk (slaRisk = true)
  • Matched with exception (verdict = matched_with_exception)
  • Reconciled (verdict = matched)
  • Unresolved evidence (verdict = unreconciled)

​
Filters

The filters drawer adds further refinement on top of the active tab:
  • Status — open, resolved, or archived (matches the status field), or all
  • Reconciliation status — filter by verdict
  • Exception type — free-text match against exceptionType
  • External reference — search by the payment intent’s externalReference
  • Provider — derived from the providers present in each case’s flowLegs
  • Date range — from / to on case creation
  • Amount range — min / max on the source amount

​
Exporting cases

The Export view action opens a modal that calls Export reconciliation cases:
Supported parameters include:
  • format — csv or json
  • from / to — date range
  • status — open, resolved, or archived
  • reconciliationStatus — unreconciled, tentatively_reconciled, or reconciled
  • externalReference
  • verdict — one or more of matched, matched_with_exception, needs_review, unreconciled, sla_risk, delayed
CSV exports are returned with Content-Disposition: attachment; filename="reconciliation-cases-{date}.csv" and include these columns: JSON exports return the equivalent records as structured objects rather than a flat CSV.

​
Case detail

Selecting View details opens the case detail screen, fetched from GET /v1/reconciliation-cases/{caseId} (Get reconciliation case detail). The header shows:
  • externalReference
  • A status badge (open, resolved, archived)
  • A verdict badge (using the same labels as the table)
  • An exception type badge, if exceptionType is set
  • The case id, plus createdAt / updatedAt
  • The source amount, an arrow, the destination amount, and the unexplainedDelta if it is nonzero

​
Tabs

Summary of the case, its payment route, amounts, and verdict.

​
Evidence coverage

Each case tracks coverage across up to five evidence sources — expected, provider, chain, bank, and file — each with a status of present, missing, failed, or not_provided. The Coverage column in the table and the Evidence tab on the detail page both reflect this. A case that is missing one or more sources may also appear in the Overview page’s Coverage Warnings widget.

​
Inline actions

The case detail screen also exposes Upload evidence (scoped to this case, with the external reference pre-filled), an override action, and a note action for recording context on the case.
The override and note actions in the current dashboard build operate on the case as displayed and are intended for working notes during triage. The reconciliation-cases API exposes read endpoints (list, detail, evidence) plus evidence-submission endpoints; if you need an action to durably change a case’s verdict or status, do it by submitting corrected evidence through Submit provider evidence or Submit on-chain evidence and letting the matching engine re-evaluate the case, or via your organization’s reconciliation rules.

​
Where cases come from

A case is created once a PaymentIntent exists and the matching engine has had a chance to evaluate it against available evidence (FlowLeg and RawRecord records). Evidence reaches the engine via:
  • The Imports pipeline (file uploads)
  • Provider and on-chain evidence submission endpoints (POST /v1/evidence/provider, POST /v1/evidence/on-chain)
  • Inbound provider webhooks
Once a MatchLink is established between a PaymentIntent and its evidence, the case’s verdict reflects the outcome of that match according to your organization’s reconciliation rules.

​
From here

List reconciliation cases

Query the same case list directly, with the same filters used by the table.

Export reconciliation cases

Generate CSV or JSON exports for reporting outside the dashboard.

Imports

See how file uploads turn into the evidence cases are matched against.

Audit

Review the full audit trail behind any case’s lifecycle.