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
PROPOSEDstatus. - 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) | No action needed |
REJECTED | Match was declined | 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 |
| Rule match | 10% | Whether a deterministic rule matched |
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
Reversing confirmed matches
Sometimes you need to reverse a confirmed match because it was approved incorrectly. The unmatch operation breaks an existing match and returns transactions to the unmatched pool.
When to unmatch
Common scenarios for unmatching:- 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 unmatch
When a match is unmatched:- Match status changes: From
CONFIRMEDtoUNMATCHED - Audit trail created: Full record of who unmatched and why
- Transactions returned: All transactions return to unmatched pool
- Exceptions created: New exceptions are created for each transaction
- Webhook triggered:
match.unmatchedevent is emitted - Re-matching possible: Transactions can be matched again in next run
Best practices
Start with lowest confidence matches
Start with lowest confidence matches
Review matches with the lowest confidence scores first. These are most likely to be incorrect and need the most attention.
Set appropriate confidence thresholds
Set appropriate confidence thresholds
If you find yourself rejecting many auto-approved matches, consider raising the auto-approval threshold. If you’re approving most 60-70% matches, consider lowering the review threshold.
Document your decisions
Document your decisions
Always add notes when confirming or rejecting matches. This creates an audit trail and helps team members understand the reasoning.
Use bulk operations wisely
Use bulk operations wisely
Bulk confirm is efficient but use it only after reviewing a sample. Never bulk confirm without understanding what you’re approving.
Review high-value matches carefully
Review high-value matches carefully
Regardless of confidence score, give extra attention to high-value matches. The impact of an incorrect match is proportional to the amount.