BreezyCorp Handbook

Appearance

Run a bank reconciliation ​

Who does this: Bookkeeper · Senior Accountant · Platform Admin When: A bank statement has been uploaded for the period, and the matching journal batch is APPROVED (so there are real entries to match against) Result: The matching engine has paired every bank line against journal entries where it could; you're left with three buckets to work through — auto-confirmed exact matches, proposed matches awaiting your confirmation, and unreconciled items that need either client follow-up or a new journal entry.

A reconciliation run is the step that ties what actually went through the bank to what's in the books. Before it can do useful work it needs both sides — the bank statement (uploaded and parsed) and the journal entries it's matching against (in an APPROVED batch). If the journal batch is still DRAFT the matcher will only see entries you've already approved individually, which usually isn't the full picture.

Before you start ​

  • [ ] The bank statement has been uploaded and parsed for the period — see Upload a bank statement. The statement's parseStatus should be PARSED (not PENDING_PARSE or FAILED).
  • [ ] The matching journal batch for the period is in APPROVED status — every entry has been Approved or Rejected and the batch is sealed for matching. (Pending entries are skipped by the matcher.)
  • [ ] You know the client's dateToleranceDays — set on the client's bookkeeping config. Default is 3 days. Tighter for clients that book on the day; looser for clients with multi-day delays between transaction date and entry date.

TIP

If the journal batch is still DRAFT, finish reviewing it first. Matching a sparse batch produces a high unreconciled-items count for spurious reasons (the entry just hadn't been approved yet) and you'll have to re-run.

Steps ​

  1. Open Bank reconciliations in the staff dashboard sidebar.
  2. Find the run for this client and period. If a run was auto-created when the bank statement was parsed, it's listed in PENDING status; if not, click New reconciliation, pick the bank statement, and create one.
  3. Click into the run to open the detail page.
  4. Click Re-run matcher in the top-right action row. (The button is labelled the same whether this is the first run or a re-match — both go through the matching engine.)
  5. State transitions:
    • PENDING → MATCHING (engine running, takes a few seconds)
    • MATCHING → AWAITING_REVIEW (engine done, results ready for you)

The engine runs three passes per bank line, in priority order (per the Bookkeeping SOP §5.2):

  1. Exact — same date, same amount, same reference. Auto-confirmed by the engine, no reviewer action needed.
  2. Proposed (within tolerance) — same amount, dates within dateToleranceDays. Awaits your confirmation.
  3. Proposed (amount only, outside tolerance) — same amount, dates anywhere in the period. Awaits your confirmation.

Anything that none of the three passes can pair becomes an UnreconciledItem and goes into the unreconciled bucket. Each journal entry is consumed by at most one match — once an entry is paired with a bank line, the engine doesn't reuse it.

Reading the AWAITING_REVIEW screen ​

After the matcher finishes, the run's detail page shows three counters in the summary tiles:

  • Matched — exact matches, auto-confirmed. No action required.
  • Proposed — proposed matches awaiting your confirm/reject. This is your queue.
  • Unreconciled — bank lines with no candidate at all. These need either client follow-up (dispatch the unreconciled-items portal) or a new journal entry.

Tabs on the page:

  • Matches — every paired bank line + journal entry, with match type (EXACT, PROPOSED, MANUAL) and confirmation timestamp. Use the Confirm button on each PROPOSED row — see Confirm proposed matches.
  • Unreconciled — every bank line with no match. From here you can dispatch the items to the client — see Dispatch unreconciled items to the client.
  • Report — empty until the run is COMPLETE. Becomes a downloadable CSV summarizing matches, confirmations, and resolutions.

NOTE

Re-running the matcher on a run that's already AWAITING_REVIEW is safe — it re-evaluates from scratch. Confirmed matches stay confirmed; new candidates may appear if you've added or approved journal entries since the last run.

How to know it worked ​

  1. The run's status badge flips to AWAITING_REVIEW within a few seconds of the click.
  2. The summary tiles show non-zero counts — Matched for the exact-match auto-confirms, Proposed for the matches needing your sign-off, Unreconciled for the leftovers.
  3. The activity log shows bookkeeping.reconciliation_run.matcher_completed with the three counts as event metadata.

Common situations ​

If you see…It means…What to do
All bank lines land as unreconciledThe matching journal batch isn't APPROVED, or it's emptyConfirm the batch is APPROVED; if it's empty, the journal-entry pipeline didn't generate entries — see A document didn't appear in any batch
Far too many proposed matchesMultiple journal entries share the same amount; the engine pairs them in iteration orderAdd reference fields to your journal entries (the reference field on the entry is what EXACT matches against), or tighten dateToleranceDays on the client config
Bank statement says parseStatus: FAILEDThe PDF/CSV couldn't be parsedSee Bank statement won't parse
Run gets stuck in MATCHING for more than a minuteThe matcher worker is backed up or has hit an errorClick Re-run matcher — the engine is idempotent. If it stays stuck, see Outbox stuck runbook for the diagnosis flow on stuck workers
You see a match you know is wrongAn auto-confirmed EXACT matched the wrong entry, or a PROPOSED looks tempting but isn't rightOn the Matches tab, click into the row — manual unmatch is available; once unmatched, the bank line returns to the unreconciled bucket

Internal use only — BreezyCorp