Reconciliation matcher missed an obvious match
You're reviewing a reconciliation run, you can see by eye that this bank line and that journal entry are the same payment, but the matcher dropped the bank line into the unreconciled bucket and never proposed the pair. The matching engine works on three rules — exact (date + amount + reference), proposed (amount + date within tolerance), and otherwise unreconciled — and a near-miss on any one of them produces this symptom. Walk through the five common causes top to bottom.
1. The date difference exceeds the tolerance window
The matcher only proposes pairs whose dates are within dateToleranceDays of each other (default: 3 days). Bank-clearing delays of a week or more — common on cross-border payments, GIRO collections, or anything routed through a clearing house — fall outside the window and get marked unreconciled.
Check: Compare the Bank txn date on the unreconciled item with the Entry date on the journal entry you expect it to match. If the gap is more than 3 days, the tolerance window is the cause.
Fix: Two options:
- Best practice — manually confirm the pair: open the unreconciled item, click Find match, search for the journal entry by amount, and link them. The match is recorded as
MANUALin the audit trail. - If this client has a recurring clearing delay (cross-border vendor pays them on a 5-day cycle, every month): widen the tolerance on the client → Bookkeeping config tab → Date tolerance (days). Bump it to a value that covers the typical delay (5, 7, or 10 days). Then re-run the matcher from the run detail page; previously unreconciled items get re-evaluated.
2. Amounts don't match — bank fees or FX rounding
The matcher requires the amount to match within half a cent. A bank fee of 0.50 SGD deducted at clearing, or an FX conversion that rounded differently than the journal entry, breaks the match. Bank line is 999.50, journal entry is 1,000.00 — no match.
Check: Compare the bank line amount with the journal entry total. Even a one-cent difference will block the match.
Fix: The accounting move is to add a small adjustment journal entry that absorbs the difference (a Bank charges entry for the 0.50 fee, or an FX gain/loss entry for the rounding). Once both entries are APPROVED, manually confirm the pair on the unreconciled item — the matcher won't auto-pair a 1-to-many relationship, but a reviewer can.
3. The journal entry isn't APPROVED yet
The matcher only considers journal entries in APPROVED status. A DRAFT, FLAGGED, or ESCALATED entry — even if the data is correct — is invisible to the matcher.
Check: Open the journal entry. Look at its status badge.
| Status | Eligible for matching? |
|---|---|
DRAFT | No |
FLAGGED | No |
ESCALATED | No |
APPROVED | Yes |
REJECTED | No (and never will be) |
Fix: Approve the entry through the normal review path (see Review a journal batch). If the entry is FLAGGED and the flag is something a senior accountant needs to override, escalate that first (see Override a flagged journal entry). Once the entry flips to APPROVED, re-run the matcher from the reconciliation run detail page. The previously unreconciled bank line will be re-evaluated and should now pair.
4. Currency mismatch
The matcher pairs on magnitude only — it does not perform currency conversion. A journal entry in USD with totalAmount: 750 will not match a bank line of SGD 1,012.50, even if both represent the same underlying payment at the day's FX rate.
Check: Open the journal entry → look for a NON_BASE_CURRENCY flag, or compare the journal entry's Currency field with the bank statement's Currency field.
Fix: Convert the journal entry to the bank account's currency by adding an FX-conversion journal entry (the standard accounting practice — original in foreign currency, conversion entry in base currency). The base-currency entry will then match the bank line. Alternatively, if you maintain separate reconciliation streams per currency, ensure the journal entry stream and the bank statement are in the same currency before running the matcher.
5. The bank line is on a duplicate reconciliation run
If the same statement got uploaded twice (one upload by the client via portal, another by a staff user via manual upload, both producing reconciliation runs), the bank line you're looking at might live on the run that isn't the one with the matching journal entries. Each run is a self-contained matching scope — entries matched on Run A don't appear as matched on Run B.
Check: Open the client → Bank reconciliations tab. Look for two reconciliation runs covering the same period and the same bank account. The audit log on each run shows which statement it was built from.
Fix: Identify which run is the canonical one (usually the older one if reviewers have already done work on it; otherwise the one based on the more complete statement). Delete the duplicate run from the run detail page — that releases the journal entries it had consumed. Re-run the matcher on the canonical run; the previously orphaned matches now land on it.
Still missed?
If you've worked through all five and the matcher still hasn't paired entries that you're certain belong together:
- Open the reconciliation run → Audit tab. The matcher logs a
bookkeeping.reconciliation.matcher_completedevent with summary counts (matches created, unreconciled created). Spot-check the counts against your own count. - Open the journal entry's Audit tab. If it shows a
bookkeeping.entry.matchedevent for a different bank line than the one you expected, the matcher consumed that entry against the wrong bank line — usually because two bank lines have the same amount within the same date window. Use Unmatch on the wrong pair, then manually confirm the correct pair. - If the audit log shows neither side recorded any matching activity, the matcher didn't run on this run. Re-trigger from the run detail page; if it still doesn't run, escalate via the on-call channel.