> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.
# Exception routing
> Understand automatic severity classification and use explicit assignment, bulk actions, caller-directed dispatch, and callbacks.
Matcher automatically classifies unmatched transactions by severity. Assignment, bulk operations, and dispatch are explicit API actions. Matcher does not automatically route or escalate exceptions.
## Severity classification
***
Matcher classifies exceptions automatically from base amount, age, and source signals to support review prioritization.
### Default severity rules
| Severity | Default amount or age criteria |
| ------------ | ---------------------------------------- |
| **Critical** | Base amount ≥ 100,000 OR age ≥ 120 hours |
| **High** | Base amount ≥ 10,000 OR age ≥ 72 hours |
| **Medium** | Base amount ≥ 1,000 OR age ≥ 24 hours |
| **Low** | All other cases |
Source signals can also influence classification. Matcher caps exceptions with reason `FEE_DATA_MISSING` at `MEDIUM`, even when amount or age thresholds would otherwise classify them as `HIGH` or `CRITICAL`.
## Assignment
***
Assignment is explicit. For an `OPEN` exception, the assignment API accepts one opaque `assignee` string and changes the exception to `ASSIGNED`.
Matcher has no user-group model and does not implement automatic assignment, round-robin routing, or least-loaded routing. If you use a user or group identifier, encode it in the `assignee` string and resolve its meaning in your own identity system.
## SLA behavior
***
Matcher stores an SLA due date only when an inbound callback supplies `dueAt`. It does not derive a deadline from severity, emit automatic SLA warnings, escalate exceptions through an SLA workflow, or route them automatically. Dashboard aggregates can report compliance for those externally supplied due dates. Define and enforce the SLA policy in the external system that sends the callback.
## Additional exception endpoints
***
Beyond the basic exception CRUD, Matcher provides endpoints for advanced exception workflows:
| Endpoint | Method | Description |
| ----------------------------------------------------------------------------- | -------- | ------------------------------------------------------------------ |
| [Dispatch exception](/en/reference/products/matcher/dispatch-exception) | `POST` | Attempt caller-selected dispatch without changing exception status |
| [Process callback](/en/reference/products/matcher/process-exception-callback) | `POST` | Apply a token-authenticated, idempotent external update |
| [Bulk assign](/en/reference/products/matcher/bulk-assign-exceptions) | `POST` | Assign exceptions to one `assignee` string |
| [Bulk resolve](/en/reference/products/matcher/bulk-resolve-exceptions) | `POST` | Resolve multiple exceptions independently |
| [Bulk dispatch](/en/reference/products/matcher/bulk-dispatch-exceptions) | `POST` | Dispatch multiple exceptions independently |
| [List comments](/en/reference/products/matcher/list-exception-comments) | `GET` | Retrieve all comments on an exception |
| [Add comment](/en/reference/products/matcher/add-exception-comment) | `POST` | Add a comment to an exception for audit and collaboration |
| [Delete comment](/en/reference/products/matcher/delete-exception-comment) | `DELETE` | Remove a comment from an exception |
| [List disputes](/en/reference/products/matcher/list-disputes) | `GET` | Retrieve all disputes with filtering |
| [Get dispute](/en/reference/products/matcher/retrieve-dispute) | `GET` | Retrieve details of a specific dispute |
| [Open dispute](/en/reference/products/matcher/open-dispute) | `POST` | Flag an exception as disputed for escalated review |
| [Close dispute](/en/reference/products/matcher/close-dispute) | `POST` | Close a dispute with a resolution |
| [Submit evidence ](/en/reference/products/matcher/submit-evidence) | `POST` | Add evidence to support a dispute case |
Bulk assign, resolve, and dispatch accept 1–100 exception IDs. Matcher processes each ID independently, so expect partial success. Bulk assignment accepts a single `assignee` string, not a user or group object.
## Dispatch and callbacks
***
Dispatch is caller-directed: each request names the target. Dispatch records an audit event but does not change the exception status. Do not treat the accepted target names as preconfigured integrations.
### Dispatch targets
When dispatching an exception, the `targetSystem` field must be one of the following values:
| Target | Description |
| ------------ | ------------------------------------------------------------------------------------------------------------- |
| `JIRA` | Attempts caller-directed JIRA dispatch; runtime connector configuration is required. |
| `SERVICENOW` | Attempts caller-directed ServiceNow Table API incident creation; runtime connector configuration is required. |
| `WEBHOOK` | Attempts caller-directed webhook dispatch; runtime connector configuration is required. |
| `MANUAL` | Acknowledges the dispatch locally without sending to an external system. |
Inbound callbacks are a separate token-authenticated, idempotent flow. A callback can set an exception to `ASSIGNED` when it includes an assignee, or to `RESOLVED`. Dispatch does not perform bidirectional synchronization.
### Filtering by external system
When listing exceptions, the `external_system` query parameter accepts any string value for filtering. This allows you to filter exceptions dispatched to any system, including custom identifiers that callbacks may set.
### Dispatch error handling
Request validation and connector failures use API problem responses. An unconfigured ServiceNow connector returns `MTCH-0509`. If Matcher cannot confirm a ServiceNow dispatch, it returns `MTCH-0514`. Check ServiceNow before dispatching again because the incident may already exist. A successful dispatch acknowledges the target operation but still leaves the exception status unchanged.
## Queue summaries and observability
***
The exception list exposes queue-scoped summary counts. Dashboard aggregates expose SLA compliance counts for externally supplied due dates. Matcher does not expose routing-rule distribution or integration success and failure analytics. Use your external observability stack for those operational signals.
## Best practices
***
Use the classified severity to prioritize review, and account for the `FEE_DATA_MISSING` cap at `MEDIUM`.
Pass a stable identifier in the opaque `assignee` string and resolve ownership in your identity system.
Define deadlines, warnings, and escalation in your workflow system because Matcher does not enforce them.
Confirm the selected connector's configuration before you rely on caller-directed JIRA, ServiceNow, or webhook dispatch.
Treat bulk operations as independent per ID and handle partial success explicitly.
Protect callback tokens and use stable idempotency keys when external systems update exception status.
## Next steps
***
Resolve exceptions through the API or external systems.
Advanced event delivery and callback handling.