Picture the payables run at quarter-end. Two queued bills carry the same vendor invoice number with one character changed. A vendor created last month shares a bank account with an old one. A round manual journal entry lands on the final evening of the month, posted by a user who rarely posts manual entries. None of this is hidden. It sits in the ledger, and in most companies nobody looks until the annual audit.
The ACFE’s Occupational Fraud 2026 report, built on 2,402 cases from 143 countries and territories, found that the median fraud runs 12 months before it is detected, and that tips, not controls, remain the top detection method at 43% of cases. AI does not change who commits fraud. It changes how quickly the ledger can tell you that something does not fit. Below: what the models test, how to triage their output, and the line every finance team must hold: a flag is not proof.
What is AI financial fraud detection?
AI financial fraud detection is the use of rules, statistical models and language models to score every transaction in a company’s books for patterns associated with fraud or error, so that people review the riskiest items first instead of a random few. Three parts of that definition matter. It covers every transaction, which is why it belongs with full-population testing rather than sampling. It produces a score, not a verdict. And it ends with a person, because a model can rank but cannot judge intent.
It is also wider than fraud. The pattern behind a fraudulent payment equally fits an honest duplicate, a cut-off error or a misconfigured tax. Most flags turn out to be error, which is useful: both usually live in the same weak control.
Which red flags can AI test across the whole ledger?
These red flags recur in MFT’s continuous-audit work. Each is testable from ERP data and points back to a control, where the lasting fix belongs.
| Red flag | What the model compares | First test by a reviewer | Control it points to |
|---|---|---|---|
| Duplicate and near-duplicate payments | Vendor, amount, date and invoice reference, including near-identical references | Pull both bills and payments; confirm two real deliveries exist | Duplicate checks at bill entry and the three-way match |
| Near-duplicate vendors | Names, tax numbers, bank accounts and addresses across the vendor master | Trace who created each record and who approved the bank details | Approval of vendor master changes |
| Approvals outside the approval matrix | Approver and value band against the approved matrix | Check whether the approver held that authority on that date | Approval limits and segregation of duties |
| Round manual entries posted late at month-end | Entry source, posting time, user, and how round the figure is | Read the support; confirm the business reason | Journal entry review before the close |
| Cut-off errors | Delivery, receipt and invoice dates against the period posted | Match the goods movement to the accounting date | Period-end cut-off procedure and lock dates |
| Inventory valuation drift | Unit cost movement against purchase history and the valuation method | Recompute the cost of the items that moved | Costing review and the valuation close |
How do the models behind a fraud flag work?
Three families of technique do the work; a credible setup uses all three.
Rules: the patterns you already know
Rules encode what an experienced auditor already looks for: the same vendor and reference twice, a payment approved by the person who created the vendor. They are transparent and easy to defend in a working paper, but find only what someone thought to write down.
Anomaly scoring: what does not fit
Anomaly models learn what normal looks like for each account, vendor or user and score departures: a user who never posts manual entries suddenly posting several, a vendor whose invoice frequency doubles. They catch new patterns but also flag every legitimate business change, so their output needs triage, not trust.
Language models: reading the narrative
Language models read what numbers cannot: entry descriptions, bill labels, vendor names written in two scripts. Their known risk is stating things that are not in the data. That is why MFT’s agents work under the rule we call evidence or silence, set out in our article on AI provenance and the audit trail: a finding that does not cite the records it was drawn from is rejected, not reported.
What is a fraud flag not?
A flag is not proof of fraud. It is not proof of a misstatement either. It is a statement that a transaction differs from a pattern, and that the difference has an explanation someone has to find. Treating flags as accusations exposes honest staff to suspicion and teaches the organisation to argue with the system instead of using it.
A flag is a question the ledger asks; only evidence can answer it.
Every flag should therefore close in one of three documented outcomes, with the evidence attached:
- Explained: the reviewer found a legitimate reason (a split delivery, an agreed advance, a corrected bill) and attached the document that shows it.
- Error or control gap: no fraud indicator, but a mistake or a weak control. It becomes an internal audit finding with an owner and a target date, rated by impact and likelihood.
- Escalated: the explanation is missing, contradicts the documents, or comes only from the person under review. It goes to whoever owns fraud matters (often the audit committee chair, the owner or legal counsel), outside the reporting line involved, and the evidence is preserved before anyone is asked.
In the third case, do not confront, delete or quietly "fix" the entry. Corrections come later, by reversal, so the original record survives.
Why does detection speed matter so much?
Because time is what fraud needs. The ACFE’s 2026 report puts the median duration at 12 months before detection, the same figure as its 2024 report. More than half of the 2026 cases involved a lack of internal controls or an override of existing ones, and the controls associated with stronger outcomes (lower losses and faster detection) include proactive data monitoring, management review and surprise audits. An annual audit examines the year after it ends; as we argue in why the annual audit misses eleven months, that leaves the window open for most of the year.
Standards point the same way. ISA 240 requires the auditor to test the appropriateness of journal entries, and Principle 16 of COSO’s Internal Control, Integrated Framework expects ongoing evaluations, not only separate ones. A model that scores entries weekly is ongoing evaluation in practice; one that runs once a year is a better sampling tool.
What does Odoo 20 add for fraud prevention?
According to Odoo’s 20 release notes, several accounting changes make some red flags harder to create in the first place:
- Duplicate detection on invoices and bills with two warning levels: red for a highly likely duplicate, yellow for a potential one.
- A payment wizard that detects pending payments, to prevent the same bill being paid twice.
- Bank consistency: entries that affect bank accounts must originate from bank transactions, which closes the manual route into the bank balance.
- User group changes logged in the user’s chatter, so a temporary grant of rights before a sensitive posting leaves a trace.
- Hashing of cash journal entries on reconciliation.
These are preventive controls at entry. They do not look back across history, compare the vendor master for near-duplicates, or score a user against their own pattern. A yellow warning that staff learn to dismiss is no control at all. For the AI items in the release, see Odoo 20 AI features for accounting. Confirm each feature in your own database and edition before you design controls around it.
Where are the limits of AI fraud detection?
- Data: cash taken before it is recorded, or a side agreement with a vendor, leaves no line to score.
- Collusion: when requester and approver act together, every individual control passes. Testing pairs (requester with approver, buyer with vendor) lowers the odds but does not close the gap.
- False positives: flooded reviewers stop reading. Start with fewer, sharper tests.
- Override outside the system: an approval given by phone and keyed in later looks clean in the data.
- The tool itself: anything that drafts entries is a user and needs the same segregation and logging as a person.
None of these is a reason to wait. Pair the model with management review, surprise checks and an easy reporting channel, since more than half of tips come from employees.
Where should a finance team start on Monday?
- For each red flag in the table above, name the preventive control and its owner.
- Export one quarter of vendor bills, payments, the vendor master and manual journal entries. Run the duplicate payment, near-duplicate vendor and late round entry tests first; the same data also feeds daily matching, as described in automating journal entries and bank reconciliation with AI.
- Agree the triage outcomes and the escalation owner before the first flag.
- Tune for two or three cycles: retire noisy tests, tighten useful ones.
- Move to weekly once triage keeps pace.
This is the approach behind seg-audit, MFT’s continuous audit platform. It reads the books straight from the ERP, read-only, scores every transaction by risk instead of sampling a few percent, links repeat findings to earlier ones, and no finding closes without a named, registered approver. The MFT Auditor agent drafts findings and corrections under the evidence-or-silence rule, and a person approves them. If you want an independent view of where your controls are thin, our internal audit service starts with exactly these tests.