Every finance manager knows the suspense account that grows a little each month. A customer pays three invoices in one transfer and the bank deducts a charge; the receipt does not equal any single invoice, so it is parked. A vendor bill is coded the way the last one was, whether or not the last one was right. By year end the reconciliation agrees, but nobody can explain a handful of lines without opening old emails.
This is where AI earns its place in accounting: high volumes of entries whose correct treatment is mostly evident from the documents. It is also where careless automation does the most damage, because a wrong match clears a balance that should have stayed open. This article, part of our practical guide to AI in accounting, sets out how to automate both safely.
What does automating journal entries with AI mean?
AI journal entry automation is the use of learned patterns and document reading to prepare entries and reconciliations that a person then reviews and approves, rather than keying each one by hand. In practice it combines four layers, and it helps to know which one you are looking at:
- Rules: reconciliation models that propose or book a fixed treatment, such as a recurring bank charge. Available in recent Odoo versions; confirm their behaviour in your 20 database.
- Extraction: bill digitization (OCR) that reads vendor documents, which in recent Odoo versions consumes IAP credits.
- Prediction: according to Odoo’s 20 release notes, when a bill is encoded manually or by import, Odoo suggests the product, account, tax, analytic and vehicle values from bill history and the label.
- Agents: the release notes also describe AI agents that can create and update records, including from an uploaded instruction file such as a PDF, and that can be triggered by automated or scheduled actions.
How does AI match bank transactions?
Bank matching is a search for the open item that best explains a statement line. Good matching works in a fixed order, from strongest evidence to weakest, and stops at the first confident answer:
- Exact reference: the payment reference on the statement equals an invoice or payment number.
- Partner and amount: the counterparty is recognised and the amount equals one open item.
- Combination: the amount equals the sum of several open items of the same partner.
- Tolerance: the amount differs from an open item by less than an agreed tolerance, and the difference goes to a defined write-off account.
- No match: the line stays open for a person, with the candidates the system considered.
Odoo 20 formalises much of this. According to Odoo’s 20 release notes, matching rules for invoices and bills now support a payment tolerance and a matching order, you can run Auto Reconciliation manually, and a write-off created during reconciliation can carry an analytic distribution. The AI-powered financial insights feature can review suspected reconciliation errors and return findings and recommendations, working only from the accounting data in your database.
A worked example without amounts
Take the customer who pays three invoices in one transfer with a bank charge deducted. Steps 1 and 2 fail: no single reference, no single invoice amount. Step 3 finds the three invoices whose total is close to the receipt. Step 4 accepts the shortfall only if it is within the tolerance the controller set, and books it to the bank charges account with the customer’s analytic tag. If the shortfall is larger, the line stays open, because a customer short-payment is a collection issue, not a bank charge. The rule protects the receivable ledger from being quietly written down.
What does Odoo 20 change in bank and entry controls?
The most important change is not AI at all. Odoo’s 20 release notes state that entries impacting bank accounts must originate from bank transactions, with clearer statement validation. A manual journal entry straight to the bank account, the classic way a ledger drifts from the statement, is no longer the normal path. Alongside it, the notes list a bank reconciliation summary report of reconciled and unreconciled items at period end, statement batching and quick reconciliation shortcuts, red and yellow duplicate warnings on invoices and bills, a payment wizard that detects pending payments to prevent double payment, and hashing of cash journal entries on reconciliation. We cover the payables side in Odoo 20 bank reconciliation and bill payments.
Which entries should AI draft, and which should it never touch?
Our decision rule is simple: automate in proportion to the external evidence behind the entry. The table applies it to the entries a typical finance team posts every month.
| Entry type | Evidence available | Automation level | Control |
|---|---|---|---|
| Bank charges and recurring fees | Bank statement line | Rule or match, auto-proposed | Monthly review of the charges account by the controller |
| Customer receipts | Statement line plus open invoice | AI match within tolerance | Weekly list of tolerance write-offs, reviewed and signed |
| Vendor bills with stable history | Vendor document plus purchase order | Predicted lines, person confirms | Override rate tracked; coding policy beats history |
| Accruals and provisions | Estimates and judgement | AI drafts the schedule only | Preparer and approver both named; reversed next period |
| Closing adjustments | Analysis, often off-system | Draft with cited records | Second approver above materiality |
| Correcting entries | The original error and its source | Agent drafts a reversal and a new entry | No deletion; approver is not the preparer |
| Manual entries to bank accounts | None beyond the entry itself | Not allowed in Odoo 20 | Bank entries come from bank transactions |
Notice what the bottom rows share: the less the external evidence, the more the AI is limited to drafting, and the more the approval depends on your ISA 320 materiality threshold.
What controls keep automated entries auditable?
The existing bank reconciliation controls still apply: an independent reviewer, aged reconciling items, no plugging differences. Automation adds five of its own:
- A distinct system user for every agent or automation, so the audit trail shows the machine as preparer and a person as approver. How that fits your access matrix is covered in AI, segregation of duties and internal controls.
- Tolerances, write-off accounts and matching order owned by the controller and changed only through a logged approval.
- Corrections by reversal, never by deletion, so the original AI proposal remains visible.
- Every AI explanation of a match or entry cites the records it used; one that cites nothing is rejected. This is the principle behind evidence or silence.
- Lock dates on closed periods, a long-standing Odoo control, so no automation can reach back into a signed-off month.
Automate the match, never the explanation of a difference.
How do you know the automation is working?
Measure it like any other control, monthly and on the full population rather than a sample. Four indicators are enough to start:
- Auto-match share: the percentage of statement lines matched without manual intervention, tracked by matching rule.
- Tolerance write-offs: count and trend of differences booked under tolerance. A rising count is a collection or pricing issue, not an efficiency gain.
- Prediction override rate: how often people change a predicted bill line. High rates on one vendor point to bad history.
- Reversals of automated entries: each one is a finding about a rule, a model or a document.
These indicators feed straight into the close; see AI in the monthly close and financial reporting for how they fit the close calendar.
What will an auditor test?
ISA 240 requires the auditor to test the appropriateness of journal entries, and the population now includes entries prepared by software. Expect an auditor to ask for the list of automation users and rules, the approval log for changes to tolerances, and a full-population extract of entries by preparer. The patterns we look for in our own continuous-audit work are familiar: duplicate and near-duplicate payments, manual entries posted late at month-end in round amounts, and approvals outside the approval matrix. A flagged entry is a question for management, not proof of error or fraud; AI-based fraud detection explains how to treat flags. Testing every entry rather than a sample is covered in from sampling to full-population testing.
Where to start on Monday
- Export last month’s bank statement lines and your reconciliation, and count lines matched manually, lines parked in suspense and lines older than thirty days.
- List every reconciliation model and matching rule in your database, with who created it and what write-off account it uses.
- Set a tolerance in writing, approved by the finance manager, before enabling any automatic matching.
- Run automatic matching on a copy of the closed month and compare each match with what your team did. Every disagreement is either a rule to fix or a human error found.
- Go live on one bank account, review the tolerance write-off list weekly for a full quarter, then extend.
If you are on Odoo, confirm each feature above in your own 20 database and edition before you design around it. Reconciliation rules and approval paths are design decisions for any Odoo ERP implementation, not settings to leave at default, and our MFT Intelligence agents draft correcting entries that a named, registered person approves; nothing is auto-posted. For the full rollout sequence, see the step-by-step guide to AI accounting on Odoo 20.