> ## 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.
# Reviewing matches
> Interpret match results, understand confidence scores, and approve or reject proposed matches after a reconciliation run.
After running a matching job, you'll need to review the results. This guide explains how to interpret match results, understand confidence scores, and approve or reject proposed matches.
## Match status lifecycle
***
Matches progress through a defined lifecycle:
* When the matching engine finds a pair of transactions that belong together, it creates a match in `PROPOSED` status.
* High-confidence matches (score 90 or above) are auto-confirmed immediately.
* Lower-confidence matches wait for manual review—an analyst can then confirm or reject them.
* Rejected transactions return to the unmatched pool for another matching attempt.
### Status definitions
| Status | Description | Next Actions |
| ----------- | ----------------------------------------------------- | ------------------------------------- |
| `PROPOSED` | Match identified by the system, awaiting confirmation | Review, confirm, or reject |
| `CONFIRMED` | Match has been approved (auto or manual) | Revoke if incorrect |
| `REJECTED` | Match was declined | Transactions return to unmatched pool |
| `REVOKED` | A previously confirmed match was revoked | Transactions return to unmatched pool |
## Confidence tiers
***
Matcher assigns a confidence score (0-100) to each proposed match. The score determines how the match is handled.
### Confidence levels
| Tier | Score range | Behavior |
| ------------- | ----------- | ---------------------------------------------------------------------------- |
| Auto-Approved | 90-100 | High confidence matches are automatically confirmed without manual review. |
| Needs Review | 60-89 | Medium confidence matches require manual review before confirmation. |
| No Match | Below 60 | Low confidence candidates are not proposed as matches and become exceptions. |
### Understanding the score
The confidence score is calculated from weighted components:
| Component | Weight | What it Measures |
| --------------- | ------ | ------------------------------------- |
| Amount match | 40% | How closely transaction amounts align |
| Currency match | 30% | Whether currencies are the same |
| Date tolerance | 20% | How close the transaction dates are |
| Reference match | 10% | Whether transaction references match |
**Example Score Breakdown:**
```
Match: BANK-001 ↔ LED-001
Amount: $1,000.00 vs $1,000.00 → 100% × 40% = 40 points
Currency: USD vs USD → 100% × 30% = 30 points
Date: 2024-01-15 vs 2024-01-15 → 100% × 20% = 20 points
Reference: PAY-001 vs PAY-001 → match → 10 points
─────────────────────────
Total Confidence: 100 points
```
## Understanding variances
***
When matches have differences, review the variance details:
### Amount variance
Common causes of amount variance:
* Bank fees
* Currency conversion differences
* Rounding differences
* Partial payments
### Date variance
Common causes of date variance:
* Settlement timing
* Time zone differences
* Posting vs. transaction date
* Weekend/holiday processing
## Revoking confirmed matches
***
Sometimes you need to reverse a confirmed match because it was approved incorrectly. The revoke operation breaks an existing match and returns transactions to the unmatched pool.
```bash cURL theme={null}
curl -X POST "https://api.matcher.example.com/v1/matching/groups/{groupId}/revoke" \
-H "Authorization: Bearer $TOKEN"
```
Revoking a confirmed match creates a full audit trail and may trigger approval workflows. This operation should be used carefully and only when necessary.
### When to revoke
Common scenarios for revoking:
* **Incorrect match confirmed**: The match was approved but transactions actually belong to different records
* **New information**: Additional data shows the match is wrong
* **Source correction**: The source system issued a correction or reversal
* **Duplicate transaction**: One of the transactions was a duplicate that should be removed
### What happens after revoke
When a match is revoked:
1. **Match status changes**: From `CONFIRMED` to `REVOKED`
2. **Audit trail created**: Full record of who revoked and why
3. **Transactions returned**: All transactions return to unmatched pool
4. **Exceptions created**: New exceptions are created for each transaction
5. **Webhook triggered**: `match.revoked` event is emitted
6. **Re-matching possible**: Transactions can be matched again in next run
## Best practices
***
Review matches with the lowest confidence scores first. These are most likely to be incorrect and need the most attention.
Confidence thresholds are fixed in the system. Scores of 90 or above are auto-confirmed. Scores between 60 and 89 require manual review. Scores below 60 become exceptions. These values are not configurable per context. Use rule tuning (priority, tolerance values) to influence how many matches land in each tier.
Always add notes when confirming or rejecting matches. This creates an audit trail and helps team members understand the reasoning.
Bulk confirm is efficient but use it only after reviewing a sample. Never bulk confirm without understanding what you're approving.
Regardless of confidence score, give extra attention to high-value matches. The impact of an incorrect match is proportional to the amount.
## Next steps
***
Handle transactions that couldn't be matched automatically.
Deep dive into how confidence scores are calculated.