Confirm proposed matches

Who does this: Bookkeeper · Senior Accountant · Platform Admin When: A reconciliation run has finished matching and is in AWAITING_REVIEW with one or more PROPOSED matches in the queue Result: Every proposed match is either confirmed (the pair is locked) or rejected (the bank line falls back to the unreconciled bucket). The run is then ready to advance toward client dispatch or completion.

The matching engine is conservative — it only auto-confirms when date, amount, and reference all line up exactly. Anything looser comes back as a proposed match: a candidate the engine thinks is the right pair, but won't lock without your sign-off. Confirming proposed matches is usually the bulk of reconciliation work — most pairs are right, but the few that aren't matter, so the platform doesn't auto-approve them.

Before you start

• [ ] The reconciliation run is in AWAITING_REVIEW (the matcher has run; you're not waiting for it).
• [ ] You have the matching journal batch open in another tab if you want to cross-check unfamiliar entries — knowing the entry's source document is often the difference between a confident confirm and a rejection.

Steps

1. Open Bank reconciliations in the staff dashboard sidebar and click into the run.
2. Click the Matches tab. The Proposed badge shows how many rows still need your sign-off.
3. Walk the list top to bottom. Each row shows:
   • Bank transaction — the bank line: date, description, debit/credit amount.
   • Journal entry — the candidate pair: entry date, reference, account, amount.
   • Type — EXACT (already confirmed by engine) or PROPOSED (your job).
   • Confirmed — timestamp once locked, or empty.
4. For each PROPOSED row:
   • Read the bank line and the candidate journal entry side-by-side.
   • Reasons the engine proposed this pair: amount matches, dates within dateToleranceDays, or amount-only outside tolerance. The engine doesn't show which pass produced the match — you decide on the merits.
   • Confirm if the pair is right. The row's status flips to confirmed; the entry is consumed and won't be proposed against any other bank line.
   • Reject if it isn't. The proposed pairing is removed; the bank line returns to the unreconciled bucket. The journal entry becomes available for re-pairing on the next matcher run.

TIP

If two bank lines look very similar (same vendor, same amount, different days) and the engine paired the wrong one, reject both proposed matches first, then re-run the matcher (Re-run matcher button at the top of the run page). With both bank lines back in play and both journal entries unpaired, the engine has another shot at it — usually the second pass settles correctly because the date tolerance and reference now break the tie.

After all proposed are decided

Once the Proposed counter on the summary tile reads zero, you have two paths depending on whether unreconciled items remain:

• Zero unreconciled — everything is paired. Click Complete + generate report in the top-right action row. The run transitions AWAITING_REVIEW → COMPLETE and the report is queued for generation.
• One or more unreconciled — you can't finalise without addressing them. Move on to Dispatch unreconciled items to the client.

How to know it worked

1. The Confirmed column on each Match row shows a timestamp.
2. The Proposed counter on the summary tile drops as you confirm; reaches zero when done.
3. The activity log shows bookkeeping.reconciliation_match.confirmed for each click, with your name and the match ID.
4. The run advances state — either toward COMPLETE (if no unreconciled) or stays at AWAITING_REVIEW until you dispatch.

Common situations

If you see…	It means…	What to do
Confirm button is greyed out	The match is already confirmed (EXACT or previously confirmed PROPOSED)	No action — move on. The Confirmed timestamp on the row tells you when it locked.
The candidate is plausibly the right entry but a few cents off	Bank fees, FX rounding, or partial settlement	Reject the match, then either edit the journal entry to match the bank line or treat the bank line as unreconciled and ask the client (typical for FX rounding); see Dispatch unreconciled items to the client
Two proposed matches both look right for the same bank line	The engine only proposes one entry per bank line — what you're seeing is one bank line proposed against one entry, but there are two bank lines competing for that entry	Confirm the better match; the unmatched bank line will drop into the unreconciled bucket and you can manually pair it later or send it to the client
You confirmed wrongly and want to undo	Confirmed matches can be unmatched manually	On the Matches tab, click into the row — there's an unmatch action. Once unmatched, the bank line returns to unreconciled and the journal entry is available for re-pairing
The matcher missed an obvious match	Engine doesn't have visibility into something the matcher key doesn't carry — e.g. you're looking at vendor name, but matcher pairs on amount + date + reference	See Reconciliation matcher missed an obvious match

Related runbooks

• Run a bank reconciliation — the step that produced this queue
• Dispatch unreconciled items to the client — for what's left after confirming
• Reconciliation matcher missed an obvious match — when proposed pairs are subtly off
• Reconciliation run status machine — when AWAITING_REVIEW transitions out
• Bookkeeping SOP §5.2 — the matching engine priority order