How Check Image Matching Works

Check image matching does not run on its own. Uploading check images, or waiting for extraction to finish,
does nothing by itself.

Clicking Find New Matches dispatches a background job. You'll see a notification that reads
"The system is looking for new matches, please check back in a few minutes..." — the screen may
not refresh on its own, so check back rather than assuming nothing happened. When it finishes, a
"Bank to Check Items match completed" notification appears and the grid refreshes.

What gets compared

The comparison only looks at a small set of fields: check number, amount, date, and the check
item's type (a Deposit Slip, an individual outgoing or incoming check "Front," a Transfer Ticket,
a Withdrawal Slip, and so on).

• Amount must match exactly. There is no cents-level or dollar tolerance anywhere in the
  comparison. A one-cent difference is enough to prevent a match.
• Date matches exactly, or within a 15-day window measured one direction — the bank
  transaction's date has to fall on or after the check's date, within 15 days of it.
• Check number matters most in combination with amount (see below).
• Payee and payor are never compared at all. They aren't inputs to the matching logic in any
  form. A clear check image made out to a payee you recognize, sitting right next to the
  transaction it obviously belongs to, will not match if its check number or amount don't
  independently line up.

The three tabs

Every check item lives in one of three places:

• TO MATCH (grid status: To Match) — no confirmed pairing yet. This is where a check item
  starts, and where it goes back to if a match is rejected or undone.
• TO APPROVE (grid status: To Approve) — a candidate pairing exists, but it needs a person
  to confirm it before it counts as matched.
• MATCHED (grid status: Matched) — a confirmed pairing between the check item and a bank
  transaction.

Why some matches land in MATCHED and others wait in TO APPROVE

Confidence is decided by the check item's type and by which comparison found the match — and the
rule is not the same for money coming in as for money going out.

• A Deposit Slip that matches a transaction on amount and date alone goes straight to
  MATCHED — no check number needed.
• An outgoing check (a Front) only auto-confirms into MATCHED when its check number and
  amount both match. An amount-and-date match on an outgoing check, without a check number match,
  lands in TO APPROVE for review instead.
• Any match that was only found because it fell inside the 15-day date window — rather than
  matching the date exactly — always goes to TO APPROVE, regardless of type.

If more than one check item or bank transaction ties on amount and date, the system does not
guess. The whole ambiguous cluster is left in TO MATCH for someone to sort out by hand.

Re-running the match

Clicking Find New Matches again rescans the entire current pool of unmatched items and
transactions — it is not scoped to what changed since the last run. For checks, there is no
memory of pairings a person has previously rejected: if a rejected pair still satisfies the
comparison rules, it can be proposed again on a later run. If that happens repeatedly, resolving
it usually means fixing the underlying data (a wrong check number, a misread date, or a duplicate
transaction) rather than expecting the system to remember your earlier decision.