> ## 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

> Classify, assign, and escalate unmatched transactions with severity-based SLAs and routing to external workflow systems.

Exception routing defines how unmatched transactions are classified, assigned, and escalated.
This guide describes severity classification, assignment rules, SLA tracking, and integrations with external workflow systems.

## Severity classification

***

Exceptions are automatically classified by severity to prioritize review and resolution.

### Default severity rules

| Severity     | Default criteria                    | SLA                |
| ------------ | ----------------------------------- | ------------------ |
| **Critical** | Amount ≥ 100,000 OR age ≥ 120 hours | 24 hours           |
| **High**     | Amount ≥ 10,000 OR age ≥ 72 hours   | 72 hours           |
| **Medium**   | Amount ≥ 1,000 OR age ≥ 24 hours    | 120 hours (5 days) |
| **Low**      | All other cases                     | 168 hours (7 days) |

Severity directly affects SLA deadlines, escalation behavior, and routing priority.

## Assignment routing

***

Assignment routing ensures exceptions reach the appropriate teams automatically.

### User groups

User groups allow scalable and resilient assignment strategies.

<Note>
  Automatic user group assignment methods (round\_robin, least\_loaded, random, all) are planned but not yet implemented. Currently, exceptions can be assigned to individual users or groups manually via the assignment API.
</Note>

## SLA tracking

***

SLA tracking monitors exception aging and triggers warnings or escalations when thresholds are reached.

## Additional exception endpoints

***

Beyond the basic exception CRUD, Matcher provides endpoints for advanced exception workflows:

| Endpoint                                                             | Method   | Description                                               |
| -------------------------------------------------------------------- | -------- | --------------------------------------------------------- |
| [Dispatch exception](/en/reference/matcher/dispatch-exception)       | `POST`   | Send an exception to an external system or team           |
| [Process callback](/en/reference/matcher/process-exception-callback) | `POST`   | Receive resolution callbacks from external systems        |
| [Bulk assign](/en/reference/matcher/bulk-assign-exceptions)          | `POST`   | Assign multiple exceptions to a user or group at once     |
| [Bulk resolve](/en/reference/matcher/bulk-resolve-exceptions)        | `POST`   | Resolve multiple exceptions in a single operation         |
| [Bulk dispatch](/en/reference/matcher/bulk-dispatch-exceptions)      | `POST`   | Dispatch multiple exceptions to external systems          |
| [List comments](/en/reference/matcher/list-exception-comments)       | `GET`    | Retrieve all comments on an exception                     |
| [Add comment](/en/reference/matcher/add-exception-comment)           | `POST`   | Add a comment to an exception for audit and collaboration |
| [Delete comment](/en/reference/matcher/delete-exception-comment)     | `DELETE` | Remove a comment from an exception                        |
| [List disputes](/en/reference/matcher/list-disputes)                 | `GET`    | Retrieve all disputes with filtering                      |
| [Get dispute](/en/reference/matcher/retrieve-dispute)                | `GET`    | Retrieve details of a specific dispute                    |
| [Open dispute](/en/reference/matcher/open-dispute)                   | `POST`   | Flag an exception as disputed for escalated review        |
| [Close dispute](/en/reference/matcher/close-dispute)                 | `POST`   | Close a dispute with a resolution                         |
| [Submit evidence ](/en/reference/matcher/submit-evidence)            | `POST`   | Add evidence to support a dispute case                    |

## Integrations

***

Matcher integrates with external systems to support operational workflows.

* **JIRA**: Use JIRA to track and resolve exceptions as issues.
* **Webhooks**: Send exception events to custom systems in real time.

All integrations support:

* Secure authentication
* Retry and backoff
* Bidirectional status updates (when enabled)

### Dispatch targets

When dispatching an exception, the `target_system` field must be one of the following values:

| Target       | Description                                                        |
| ------------ | ------------------------------------------------------------------ |
| `JIRA`       | Dispatch to a JIRA project                                         |
| `SERVICENOW` | Dispatch to ServiceNow *(not yet implemented — returns MTCH-0508)* |
| `WEBHOOK`    | Dispatch to a custom webhook endpoint                              |
| `MANUAL`     | Flag for manual handling outside of automated systems              |

### 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 may have been set through callbacks.

### Dispatch error handling

When dispatching an exception to an external system, Matcher returns specific error responses:

| Status Code | Condition                 | Description                                                                                                              |
| ----------- | ------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| 200         | Success                   | Exception dispatched and external issue created                                                                          |
| 400         | Invalid request           | Missing required fields (exception ID, target system, or actor)                                                          |
| 422         | Unsupported target system | The target system value is not one of the supported dispatch targets listed above                                        |
| 422         | Connector not configured  | The target system is valid but has no connector configuration. Verify that the integration is set up before dispatching. |
| 422         | Invalid state transition  | Exception is not in a dispatchable state                                                                                 |

## Monitoring and analytics

***

Use routing statistics to evaluate effectiveness:

* Exception volume by severity
* SLA breach rates
* Routing rule distribution
* Integration success and failure rates

## Best practices

***

<AccordionGroup>
  <Accordion title="Start simple">
    Begin with severity-based routing and expand as patterns emerge.
  </Accordion>

  <Accordion title="Prefer groups over individuals">
    Group-based routing improves resilience and workload balance.
  </Accordion>

  <Accordion title="Define realistic SLAs">
    Align SLA targets with operational capacity.
  </Accordion>

  <Accordion title="Monitor SLA trends">
    Frequent breaches indicate misaligned thresholds or staffing gaps.
  </Accordion>

  <Accordion title="Validate integrations before production">
    Always test JIRA and webhook integrations in non-production environments.
  </Accordion>

  <Accordion title="Plan for webhook failures">
    Configure retries and alerts for critical notification paths.
  </Accordion>
</AccordionGroup>

## Next steps

***

<CardGroup cols={2}>
  <Card title="Resolving exceptions" icon="triangle-exclamation" href="/en/matcher/daily-reconciliation/matcher-resolving-exceptions">
    Resolve exceptions through the API or external systems.
  </Card>

  <Card title="Webhooks & callbacks" icon="webhook" href="/en/matcher/integrations/matcher-webhooks-callbacks">
    Advanced event delivery and callback handling.
  </Card>
</CardGroup>