How it works, screen by screen

account | transaction number | MMM-YY — both sides must have the same triple to count as matched. Periods are read from the AR GL date and the GL Period Name and are always shown as MMM-YY.

AR lines whose key has no GL counterpart — "we billed it, GL never saw it." Usually the more alarming direction.

GL lines on receivable accounts with no AR counterpart. Two reasons appear: Missing GL Transaction Number (typical for converted opening balances) and No matching AR transaction.

An audit concept: the RM threshold below which a difference is considered too small to chase. Set it in the top bar and any account whose variance falls within the threshold is labelled Immaterial instead of demanding review — so the team spends time on differences that matter. Worked example (sample data): at 60,000, Non-trade debtors' variance of (54,419.29) flips to Immaterial, while 983,667.17 stays flagged. It is a review aid only — no figure is hidden and the control total never changes; 0 keeps strict mode. In practice the threshold is agreed with the client or auditor per engagement, which is why it is a setting rather than a fixed rule.

Each exception row carries a status — Open → Investigating → Resolved → Written-off — so a team can work the list. Statuses are stored locally in the browser (IndexedDB) and survive a refresh or a re-run. Export and sign-off always show live numbers.

For GL journals whose transaction number is missing, the app proposes AR candidates on account + period + amount (± 0.005) — drawn only from AR transactions that are not already matched, so accepting one always keeps the control identity tied. Accepting fills the missing transaction number into the GL journal and re-runs the reconciliation — the same remedy as correcting the source file. Rejections are remembered for the session; every accepted match is listed with an undo. Journals with no AR twin (converted opening balances) stay in exceptions — they are the variance, not matchable noise.

Any run can be saved as a named local project (IndexedDB). Pick a saved run as the baseline and the app diffs the exception registers — raised, cleared, recurring — using content-based identities (account + reference + period + amount) that survive re-sorted exports, plus a control-total trend across saved runs.

A second check the macro did by hand (the Dist Account vs GL column): each AR line's distribution account is also looked up in GL. Automates a manual step and cross-checks the first.

Two reviewer-tag matchers complement the machine match: Credit netting pairs an invoice exception with applied credit memos of the same customer + currency when GL holds only the net journal; Timing differences pairs the same account + invoice + amount across a month boundary as a proven cutoff. Both are confirm-or-dismiss tags — the engine figures never move.

Classifies every receivable line into Trade / Unapplied cash / Customer deposits & advances from the subledger's own labels (template-configurable) — so the statement note's gross-trade vs contract-liability split is proven per line, not assumed.

Owner and reviewer note ride every exception (showing as a filterable Note dot). The exported workbook is 6 sheets: Recon Summary, AR Summary, GL Summary, AR Exceptions, GL Exceptions and Follow-up — every exception with status, owner, note and age days, open items first. Exceptions get keyboard triage too: j / k walk the shown rows, Enter opens the drawer, x ticks it.