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.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.
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) |
Assignment routing
Assignment routing ensures exceptions reach the appropriate teams automatically.
User groups
User groups allow scalable and resilient assignment strategies.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.
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 | POST | Send an exception to an external system or team |
| Process callback | POST | Receive resolution callbacks from external systems |
| Bulk assign | POST | Assign multiple exceptions to a user or group at once |
| Bulk resolve | POST | Resolve multiple exceptions in a single operation |
| Bulk dispatch | POST | Dispatch multiple exceptions to external systems |
| List comments | GET | Retrieve all comments on an exception |
| Add comment | POST | Add a comment to an exception for audit and collaboration |
| Delete comment | DELETE | Remove a comment from an exception |
| List disputes | GET | Retrieve all disputes with filtering |
| Get dispute | GET | Retrieve details of a specific dispute |
| Open dispute | POST | Flag an exception as disputed for escalated review |
| Close dispute | POST | Close a dispute with a resolution |
| 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.
- Secure authentication
- Retry and backoff
- Bidirectional status updates (when enabled)
Dispatch targets
When dispatching an exception, thetarget_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, theexternal_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
Start simple
Start simple
Begin with severity-based routing and expand as patterns emerge.
Prefer groups over individuals
Prefer groups over individuals
Group-based routing improves resilience and workload balance.
Define realistic SLAs
Define realistic SLAs
Align SLA targets with operational capacity.
Monitor SLA trends
Monitor SLA trends
Frequent breaches indicate misaligned thresholds or staffing gaps.
Validate integrations before production
Validate integrations before production
Always test JIRA and webhook integrations in non-production environments.
Plan for webhook failures
Plan for webhook failures
Configure retries and alerts for critical notification paths.
Next steps
Resolving exceptions
Resolve exceptions through the API or external systems.
Webhooks & callbacks
Advanced event delivery and callback handling.