> ## Documentation Index
> Fetch the complete documentation index at: https://docs.reconlayer.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Cases

> The reconciliation case queue: triage, filter, investigate, and export outcomes.

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`.

<Note>
  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.
</Note>

## 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](/api-reference/payment-intents/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](/api-reference/reconciliation-cases/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](#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](/api-reference/reconciliation-cases/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](/api-reference/reconciliation-cases/get-reconciliation-case-detail)).

### Header

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

<Tabs>
  <Tab title="Overview">
    Summary of the case, its payment route, amounts, and verdict.
  </Tab>

  <Tab title="Evidence">
    A breakdown of each evidence source ([Get reconciliation case evidence](/api-reference/reconciliation-cases/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.
  </Tab>

  <Tab title="Flow Legs">
    The individual `FlowLeg` records linked to this case, fetched from [Get flow detail](/api-reference/reconciliation-cases/get-flow-detail) (`GET /v1/flows/{flowId}`) for each leg.
  </Tab>

  <Tab title="Reconciliation Checks">
    A technical summary table: raw record count, flow leg count, match link count, and the `reconciledAt`, `lastRunAt`, `createdAt`, and `updatedAt` timestamps for the case.
  </Tab>

  <Tab title="Audit Timeline">
    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](/dashboard/audit), filtered to this case.
  </Tab>
</Tabs>

### 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](/dashboard/overview#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.

<Note>
  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](/api-reference/reconciliation-cases/submit-provider-evidence) or [Submit on-chain evidence](/api-reference/reconciliation-cases/submit-on-chain-evidence) and letting the matching engine re-evaluate the case, or via your organization's [reconciliation rules](/dashboard/configuration#reconciliation-rules).
</Note>

## 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](/dashboard/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](/dashboard/configuration#reconciliation-rules).

## From here

<CardGroup cols={2}>
  <Card title="List reconciliation cases" icon="code" href="/api-reference/reconciliation-cases/list-reconciliation-cases">
    Query the same case list directly, with the same filters used by the table.
  </Card>

  <Card title="Export reconciliation cases" icon="file-export" href="/api-reference/reconciliation-cases/export-reconciliation-cases">
    Generate CSV or JSON exports for reporting outside the dashboard.
  </Card>

  <Card title="Imports" icon="file-import" href="/dashboard/imports">
    See how file uploads turn into the evidence cases are matched against.
  </Card>

  <Card title="Audit" icon="list-check" href="/dashboard/audit">
    Review the full audit trail behind any case's lifecycle.
  </Card>
</CardGroup>