Review & confirm

Outcome

Every medium-confidence match is reviewed, confirmed (or rejected to Unmatched), and the Review tab clears.

Prerequisites

Scope	What it lets you do
billing.receivable.read	See the tab
billing.receivable.write	Confirm / reject

Why a row is on Review

The matcher couldn't reach high confidence. Common reasons:

Reason	What you'll see
Member ID matches but DOS or amount differs by < tolerance	"Member ID + DOS — amount diff $X".
Payer claim control # partial match (substring or off-by-one)	"Payer claim control partial".
Member ID match only	"Member ID match only".
Multiple candidates at similar confidence	"Multiple candidates: N".

The reason chip is on the row; hover for the underlying numbers.

The decision

Steps

1. Open the Review tab. Sort by reason — patterns help you batch similar cases.

2. For each row, open the candidate claim. Confirm:

   • The patient is the same (some payers re-sequence patient IDs).
   • The DOS is within the claim's range.
   • The amount lines up (allowing for the payer's adjustments).

3. Confirm or reject:

   Decision	Effect
   Confirm	Stamps MATCHED; will post on Post.
   Reject	Pushes to Unmatched for manual matching.

4. For "multiple candidates", the panel shows a candidate picker. Select the right one and confirm.

Bulk actions

Action	Effect
Confirm all (above N% confidence)	Confirms every row above the user-picked threshold.
Reject all (with same reason)	Pushes to Unmatched in bulk.

Bulk confirm-all-above-threshold is fast but careless; only use it after you've spot-checked a representative sample. Your audit row identifies you as the actor on every confirmation.

When the right claim doesn't exist yet

Sometimes the payer adjudicates a claim we haven't yet built — usually because the claim was reversed and rebuilt under a new ID, or because the payer is paying for a service we haven't ingested yet:

1. Reject the row to Unmatched. Don't fake-confirm.

2. Search the Claims index for the payer's claim control number. If nothing matches, this is a true unmatched.

3. Rebuild and submit the claim if our records say we should have. After it's ACCEPTED, manually match the unmatched line (4.4).

Validation

Check	Expected
Confirming a row decreases the Review count by 1	Yes.
Rejecting moves the row to Unmatched immediately	Yes.
Bulk confirm respects the threshold	Yes; rows below the threshold are skipped with a chip.
Audit row writes per row	Yes.

Troubleshooting

Symptom	Cause	Fix
Candidate claim doesn't open	Permission boundary (cross-facility, archived)	Use the search and confirm; or escalate to supervisor.
Multiple candidates panel doesn't update after edit	Stale cache	Refresh; the panel re-runs candidates.
Confirmed row reverts after refresh	Server transaction failed mid-confirm	Re-confirm; ping support if it persists.
Reject doesn't push to Unmatched	Status went MATCHED_FORCED somewhere	Reverse the force-match first (4.4).

Where to next

• 4.4 — Unmatched & manual match for the no-candidate cases.
• 4.5 — Exceptions for the variances that surface as you confirm.