Super Intelligence Systems
Home/Automation/Reconciliation case study
Back to automation
Superintelligence Systems · Case studyOctober 2026

Reconciliation close audit

The month-end pack that explains its own differences. Forty-one ledger rows, forty source rows, five findings, and a variance that ties to the cent.

Month-end reconciliation fails in a specific way: the totals do not tie, and the person holding the pack has no ordered list of why. The difference might be a missing source row, a duplicate ledger entry, a twelve-dollar mismatch, or a sync that stopped nine days ago. This build matches the two extracts, names every difference, ranks it by impact, and sends material findings for a person to sign off.

The brief

A form starts the run: period, materiality threshold, source label. The audit loads the ledger export and the source-system export, normalises both to one shape, matches on the invoice reference, and runs deterministic checks. Every finding carries the reference, the side it came from, the amount it affects and a plain description. Findings above the materiality threshold become pending sign-offs; nothing is marked reconciled until a person decides.

Evidence from the demo run

41ledger rows
5findings, all explained
2,682CAD variance explained
10/10check tests passing

Run RC-778025, period 2026-09, materiality threshold 50 CAD. 41 ledger rows against 40 source rows, 39 matched references. Five findings: one duplicate, one ledger-only, one source-only, one amount mismatch, one stale source. Two findings are material and wait for sign-off. Variance is the sum of the affected amounts: 2,450.00 plus 220.00 plus 12.00.

The reconciliation workflow: form, fixtures, match and check, run record, findings split and sign-offs
The workflow. The check is deterministic code with a written rule for each finding type.
Demo environment · sample data · no client names1 / 2
Reconciliation close auditHow it works

Every finding has a rule

FindingRuleIn this run
duplicate_ledgerA reference appears more than once in the ledgerINV-1005
missing_in_sourceLedger row has no source rowINV-1012, 220.00
missing_in_ledgerSource row has no ledger rowINV-1099, 2,450.00
amount_mismatchAmounts differ by more than 0.50 toleranceINV-1018, 12.00
stale_sourceSource date is more than 3 days older than the runINV-1027, 9 days
sign_errorSign differs between ledger and sourcetest case

Each finding is written to the audit sheet with its type, severity, affected amount and a description. The summary row records the counts, the variance and how many items needed sign-off, so the next reader does not have to reconstruct the run.

Live audit tabs: run summary, five findings, two pending sign-offs
Live run: the run row, the five findings and the two material items waiting for sign-off.

What the reviewer gets

An email with the period, row counts, matched references, findings, variance and the count of material items. The email is a summary, not the evidence: the evidence is the audit sheet, where each finding keeps its reference and rule.

What this does not do. It does not post journals or change the ledger. It reads two extracts and produces findings and sign-offs. It also does not decide whether a finding is acceptable; that stays with the person who owns the close.
What it proves. A month-end pack can arrive with the differences already named, ranked and tied to an amount, instead of a totals check and a hunt through two files.

Where it fits

  • Month-end and period-end reconciliation between an accounting export and an operational source.
  • Any two-system comparison where "the totals are close" has replaced "the rows tie".
  • A close process that needs a written sign-off trail without a new accounting system.
Built with n8n, Google Sheets, deterministic validation2 / 2
Start a conversation