Bank reconciliation compares an imported statement with posted journal lines on the bank account's linked GL account. xMatix can rank eligible ledger lines and, when an active rule explicitly enables auto-match, confirm an unambiguous top result. Treat the result as an accounting control: verify the source statement, every confirmed pair and the remaining bank-to-book residual rather than relying on a confidence badge alone.
Prerequisites
- A bank account master linked to its GL account — an account with no GL link cannot reconcile.
- The period's bank statement imported, with its lines.
- The period's payments, transfers and journals posted — reconciliation matches against posted ledger lines only.
Procedure
- 1
Name should identify the account and statement period so the session is easy to audit.
- 2
Partner Account supplies the owning company context.
- 3
Bank Account determines the linked GL account and eligible posted ledger entries.
- 4
Bank Statement supplies the imported statement lines to match.
- 5
Difference must reach zero before the reconciliation is complete.
This image is deliberately limited to the new-record header. It proves which fields establish a reconciliation—name, company, bank account, statement and balance fields—but it does not pretend that a blank form is a populated match workspace.
Step 1 — Open the match workspace
Create a reconciliation with a name that identifies the account and statement period, then select the partner account, bank account and imported statement. Before saving, compare the statement identity and closing balance with the source bank file; choosing the wrong statement makes every later comparison meaningless. After opening the saved workspace, verify that its account card and statement-line counts belong to the selected account. Account availability is scoped by partner/branch and requires an active master linked to a GL account classified as Bank.
Step 2 — Understand the rule gates before requesting suggestions
Rules are either specific to the selected bank account or global. If at least one account-specific rule exists, global rules are not mixed in. Active rules run in sequence as a cascade: every enabled criterion on a rule is a hard gate, and each later rule narrows the survivors of the earlier rule. Supported criteria are amount, date, reference, transaction direction and document number; tolerances apply to amount and date.
With no applicable rule, the current built-in policy requires all of these conditions: signed amount within 100 currency units, date within five days, overlapping statement-reference/ledger-narration text, and the same debit/credit direction. It does not auto-confirm. This is intentionally more precise than calling the fallback an “exact amount” heuristic.
An active rule with Auto Match enabled can confirm only when its surviving top candidate is unique or strictly outscores the runner-up. Inspect every such result after it appears; auto-match changes data and a scoring lead is not independent proof of identity.
Step 3 — Review suggested matches
Open one unmatched statement line and read its date, signed amount, narration and reference before reviewing candidates. Eligible candidates are posted journal lines on the linked bank GL account that have not already been used by a reconciliation match for that bank account. The service scores each survivor as 100 − (date gap × 10) + 25 when references overlap; the UI maps 125 or more to Exact, 100–124 to Best, and lower scores to Possible. Open the source journal or originating business record when references are ambiguous. These labels rank candidates; they do not prove that two records represent the same transaction.
Step 4 — Confirm the match
Select the candidate whose direction, amount, date and reference establish the same transaction, then confirm it. The server records the full signed statement amount in the match and changes the statement line to Matched; it does not currently persist a partial applied amount from the suggestion card. Verify the match record and counts after the action completes.
Do not rely on an Unmatch instruction in this release. The checked-in match panel contains a legacy unmatch path aimed at BankingTransaction, while the bank-reconciliation server handler exposes suggest, confirm, account, detail and summary actions only. If a match is wrong, escalate it through your approved data-correction process until an implemented reversal action is available; do not create an offsetting fake match.
Step 5 — Handle what the books never saw
For a statement line with no genuine ledger counterpart—bank charges, interest credited or a direct debit—use the match panel's posting path to create the draft journal, complete its contra account and narration, and post it. Suggestions scan posted journals only, so the draft cannot become a candidate until posting succeeds. Return to the statement line and confirm the newly posted journal deliberately.
The visible Ignore control updates the statement line to Ignored, which is useful for filtering a proven duplicate. However, the detailed reconciliation calculation currently treats any statement line without a ReconciliationMatch as unmatched even if its workflow status says Ignored. Do not use Ignore as a shortcut to a fully reconciled result, and do not ignore a legitimate timing difference or missing book entry.
Step 6 — Close the session at zero
Review the detailed result after the final line. It calculates the ledger closing balance from all posted lines on the linked GL account, compares it with the statement closing balance, verifies the statement's own opening-plus-movement arithmetic, and counts unmatched lines on both sides. Treat the account as reconciled only when the difference is zero, every statement line has a match, no eligible ledger line remains unmatched and the statement arithmetic agrees. If that state cannot be reached, do not force it—locate the unposted, duplicated, wrongly linked or missing record.
Expected result
The reconciliation has a zero bank-to-book difference, statement arithmetic agrees, every statement line has a match record and no eligible posted ledger line remains unmatched. Newly discovered bank events have traceable posted journals rather than undocumented adjustments.
Common problems
A payment I know exists is not suggested. Either it has not posted (only posted lines are candidates), it was already matched to another statement line, or it falls outside the matching rule's amount or date tolerance. Check its posting status first, then widen the rule or match it manually.
The difference will not reach zero. Work the outstanding lists: bank-side leftovers are usually charges or interest needing a posting (Step 5); book-side leftovers are usually cheques not yet presented or deposits in transit — genuinely outstanding items that will clear on a future statement.
No candidate appears. Check the bank master has a linked GL account, the expected journal is Posted, the ledger line has not already been matched, and each active rule gate passes. Under the fallback, missing reference overlap alone is enough to exclude a candidate.
Nothing was auto-confirmed. Auto-match is off in the fallback policy. A configured rule must enable it, and its top survivor must be unique or strictly outscore the runner-up.
Common questions
What makes a suggestion "Exact"?
It is a score bucket, not a proof standard. A score of 125 or more is labelled Exact, 100–124 is Best, and anything lower is Possible. The score comes from date proximity plus a 25-point reference-overlap bonus after rule gates have already removed ineligible candidates.
Can I undo a confirmed match?
Not through a supported bank-reconciliation server action in the current implementation. The UI's dormant legacy path must not be treated as an available accounting correction. Escalate an incorrect match through the approved operational support/data-correction process and retain the reason.
How often should we reconcile?
As often as you import statements — monthly at minimum, since completed bank reconciliations are one of the advisory checks in the period close. Teams that import weekly or daily keep the unmatched list short enough that exceptions surface while the trail is still warm.