Cases - ReconLayer

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:

Card	Definition
Open cases	`status === 'open'`
Needs review	`verdict === 'needs_review'` (highlighted when positive)
Matched w/ exception	`verdict === 'matched_with_exception'`
Reconciled	`verdict === 'matched'`
Unresolved evidence	`verdict === 'unreconciled'`
SLA risk	`slaRisk === true` (highlighted when positive)

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:

Column	Source	Notes
Case ID	`id`	Shown truncated
Verdict	`verdict`	Rendered as a badge — see verdict table below
Route	`paymentType` + `paymentSubtype`	Describes the payment rail/route
Source	`expectedAmount` + currency	The expected (source-side) amount
Destination	`actualAmount` + currency	The observed (destination-side) amount
Delta	`unexplainedDelta`	Shown with a warning icon when nonzero
Coverage	`evidenceCoverage`	Per-source coverage cell (see Evidence coverage)
SLA age	`slaAgeMinutes` + `slaRisk`	Age of the case with an at-risk indicator
Action	—	“View details” link to the case detail page

Verdicts

`verdict`	Label shown in the UI
`matched`	Matched / Reconciled
`matched_with_exception`	Matched with exception / Exception
`needs_review`	Needs review
`unreconciled`	Unreconciled / Unresolved evidence
`sla_risk`	SLA risk
`delayed`	Delayed

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:

GET /v1/exports/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:

CSV column	Source field
`case_id`	`id`
`external_reference`	`externalReference`
`status`	`status`
`verdict`	`verdict`
`payment_type`	`paymentType`
`source_amount` / `source_currency`	expected amount and currency
`destination_amount` / `destination_currency`	actual amount and currency
`exception_type`	`exceptionType`
`sla_age_minutes`	`slaAgeMinutes`
`last_event`	most recent audit event

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

Overview
Evidence
Flow Legs
Reconciliation Checks
Audit Timeline

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

A breakdown of each evidence source (Get reconciliation case evidence, GET /v1/reconciliation-cases/{caseId}/evidence)). Sources include the expected payment (the PaymentIntent itself), provider webhook evidence, on-chain confirmation evidence, bank statement evidence, and file-import evidence. Each source shows its provider, source reference, signature/validation status, when it was received, and any validation errors.

The individual FlowLeg records linked to this case, fetched from Get flow detail (GET /v1/flows/{flowId}) for each leg.

A technical summary table: raw record count, flow leg count, match link count, and the reconciledAt, lastRunAt, createdAt, and updatedAt timestamps for the case.

The append-only AuditEvent history for this case — each entry has an id, eventType, actor, message, and occurredAt, plus any linked paymentIntentId or caseId. This is the same data shown organization-wide in Audit, filtered to this case.

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.

​Page layout

​KPI strip

​The case table

​Verdicts

​Tabs

​Filters

​Exporting cases

​Case detail

​Header

​Tabs

​Evidence coverage

​Inline actions

​Where cases come from

​From here

List reconciliation cases

Export reconciliation cases

Imports

Audit

Page layout

KPI strip

The case table

Verdicts

Tabs

Filters

Exporting cases

Case detail

Header

Tabs

Evidence coverage

Inline actions

Where cases come from

From here