How to automate bank reconciliation

What this automation does

The workflow does the matching, and the accountant does the judgment.

1. Pull both sides. Each night, it collects new bank and card transactions from bank exports or a bank API, and posted entries for the same accounts from QuickBooks Online, Xero or NetSuite.
2. Normalize. Dates, signs and descriptions are cleaned into one shape. Overlapping exports are de-duplicated using the bank’s transaction ID or a hash of date, amount and raw description.
3. Match in stages. Exact matches first (amount equal, date within a window, reference or check number equal). Then rule matches for known patterns such as payroll, loan payments and merchant fees. Then one-to-many matches, where one deposit equals several invoices or one processor payout equals many charges minus fees and refunds.
4. Propose the hard ones. For bank lines still open, an LLM reads the description and proposes the likely counterparty and candidate entries, with a reason. Code checks that the proposed entries sum exactly to the bank amount.
5. Publish the worksheet. Matched, proposed and unmatched lines for each account land in a reconciliation sheet with links back to the source entries.
6. Close the loop. The accountant accepts or fixes proposals, creates any missing entries, and reconciles the account in the accounting system using the worksheet.

When it is worth building

This pays off when reconciliation is the step that holds up your close. Signs include an accountant who spends several days a month ticking lines, accounts that are reconciled weeks late, or a growing pile of unmatched items nobody wants to touch.

It is not worth building for one or two accounts with mostly one-to-one transactions. The bank feed rules inside QuickBooks Online or Xero will handle those. It also is not the right first project if transactions are not being recorded in the ledger at all. Fix entry first with QuickBooks data entry automation, then reconcile. The custom matcher shines for accounting firms with dozens of client accounts, ecommerce and hospitality businesses with daily processor deposits, and multi-entity groups that move money between their own accounts.

Architecture

How to build it

1. Inventory the accounts. List every bank and card account with its source format, typical volume and the kinds of transactions it sees. Rank by hours spent today and start with the top two.
2. Load history. Pull at least three months of bank lines and ledger entries and run them through matching offline. This is how you tune rules before anyone depends on the output.
3. Build the exact and rule stages. Use a date window of a few business days. Add rules for recurring counterparties, and keep the rules in a table the accountant can edit.
4. Build one-to-many matching carefully. Searching every combination of open invoices is slow and produces false matches. Narrow candidates by customer, date window and amount ceiling before searching, and cap the group size.
5. Expand processor payouts. For Stripe or similar processors, fetch the payout’s balance transactions and match the deposit to the gross charges, fees and refunds rather than to one total.
6. Add AI proposals last. Give the model the bank line, a short list of candidate entries and your vendor and customer names. Require a structured answer with candidate IDs and a reason. Verify sums in code, and drop any proposal that does not tie.
7. Publish and review. Write the worksheet, notify the accountant in Slack or email, and log every accept and correction so you can turn repeated corrections into rules.

What breaks in production

• Truncated descriptions. Banks cut descriptions short and add codes, so “ACH CORP PMT 4471 ACME IND” may be the only clue. Keep an alias table built from accepted matches so the same text matches by rule next time.
• Timing differences. Outstanding checks and deposits in transit straddle month end. Treat them as expected open items with an age, not as errors.
• Reversals and returns. A returned ACH or NSF appears as a new line with the opposite sign. Pair it with the original before it pollutes the exceptions list.
• Transfers between your own accounts. One transfer shows up twice, once in each account. Match both legs together, or each side sits unmatched.
• Overlapping exports. Someone downloads the same week twice. Without de-duplication on the bank’s transaction ID, lines double.
• Combinatorial blowups. One-to-many search on a large deposit with hundreds of open invoices can hang. Time-box the search and send it to a person if it does not resolve.

Timeline and cost

Two to four accounts on one ledger typically take two to four weeks, including the history backtest. Lumeor builds it for $6,000 to $12,000, depending on the number of accounts and formats, whether processor payouts need expanding, and whether the ledger is QuickBooks Online, Xero or NetSuite. Running costs are low because only unmatched lines reach the model. For why we use Postgres rather than a spreadsheet as the matching store, see Airtable vs Postgres for operations data. Reconciliation is usually the first piece of a faster close, covered in the month-end close reporting guide.

How to measure success

• Auto-match rate per account, tracked monthly as rules improve
• Accountant hours per account per month
• Business days after month end until every account is reconciled
• Unmatched items older than 30 days, by account
• AI proposals accepted versus corrected, which shows whether the description reader is helping