Why a Check Image Didn't Match

A check image sits in To Match (or a proposed pairing sits in To Approve but looks
wrong), and it seems obvious what it should be matched to. Here's how to work out which
comparison is failing.

Matching only compares four things: check number, amount, date, and the check item's type. It
never looks at payee or payor, and it never actually reads the account number even though the
item carries one. Walk through the fields in this order.

1. Is the amount exactly right?

Amount is the strictest field. There is no cents-level or dollar tolerance anywhere in the
comparison.

What to check: open the check item and compare the extracted AMOUNT: against the statement
line. If it was misread, correct it (amount is editable while a check item is still in To
Match — see the amount-editability note below), then run Find New Matches again.

2. Is the date exactly right, or within 15 days?

Dates match in one of two ways: exactly, or within a fixed 15-day window, one direction only —
the bank transaction's date has to be on or after the check's date. A transaction dated before
the check's date will not match on this pass even if it's only a day off.

If the date on a check item couldn't be read at all during extraction, it is stored with no date
— not a guessed or blank-looking value, genuinely no date. An item with no date can then only ever
match on check number, which in practice means it usually won't match, since a check-number-only
match (without a corresponding amount match) is turned off everywhere in the current release.

What to check: open the check item and look at the DATE: field. If it's missing, that's
why matching skipped it — enter the correct date if you can read it from the image, and re-run
matching.

3. Does the check number match?

Check number only matters combined with an exact amount match — a check-number match by itself,
without amount also matching, doesn't produce a candidate in the current release, even though
that comparison exists in the matching logic. So a check number alone won't rescue a mismatched
amount.

4. Is it a payee/payor problem? It can't be — check something else.

This is the one customers hit hardest: payee and payor are never compared, in any pass. A
perfectly clear check image made out to a payee you recognize will not surface as a match on that
basis. If amount and date (or check number and amount) don't independently line up, matching
won't offer it — no matter how obvious the pairing is to a person looking at both documents. This
isn't a bug to report; it's how the comparison is built. If you've confirmed amount and date are
both correct and it's still not matching, the transaction it belongs with may simply not be
uploaded yet, or may be sitting in a different account than you expect (see next).

5. Could it be matched to the wrong account?

The account number on a check item is captured and displayed, but it is never actually read by
the matching comparison. All accounts in a project are pooled together for the amount/date
passes. In practice this means a check can match a transaction that happens to share the same
amount and date but sits in a completely different account than the check was actually deposited
to or drawn on. If a match looks right on amount and date but wrong on account, that's the likely
cause — check the account on both sides of the pairing before approving it.

If more than one candidate ties

When two or more check items or bank transactions tie on amount and date, matching does not
guess — the whole set is left in To Match for you to resolve by hand rather than being
silently paired.