AI fraud and anomaly detection in accounting

What AI fraud and anomaly detection in accounting means

AI fraud and anomaly detection in accounting is the use of scoring models and rules engines to watch everyday transactions, such as payments, purchases and vendor records, for the patterns that fraud and error tend to share, and to rank them for a person to review. It matters because it runs continuously on every transaction as it is processed, not only on the sample an audit tests months later.

This is different from the journal entry testing an external or internal auditor performs under ISA 240, usually once a period; our guide on journal entry testing and fraud red flags covers that selection criteria and Benford's law in an audit context. This guide covers what a finance team's own systems can watch for as transactions happen: duplicate payments, vendor-master changes, split purchases, round sums and outliers, the difference between a rules engine and an AI scoring model, and how a reviewer should treat what either one flags.

Rules engines versus AI scoring

A rules engine tests a fixed condition and is either right or wrong about it: a payment above a set amount needs a second approval, or it does not. It is transparent and easy to audit, but a person who knows the rule can often stay just under it.

An AI scoring model instead combines many weak signals into a single risk score: how unusual the amount is for that vendor, how recently the vendor's bank details changed, whether the invoice number sequence looks organic, whether the requester and approver have worked together before. No single signal proves anything; the combination is what earns a transaction a place near the top of a reviewer's queue. Both approaches need the same governance: a documented reason for every flag, a record of what a reviewer decided, and periodic testing of whether the flags are still finding real issues.

• Rules: fast, explainable, easy to work around once known, cheap to run on every transaction
• AI scoring: ranks and combines signals, needs a feedback loop to stay accurate, cannot fully explain a single score
• Neither replaces a control; both replace a person manually scanning a report

Duplicate payments

Duplicate payments happen when the same invoice is paid twice under a different reference, a different vendor code for the same supplier, or a slightly different amount after a small edit. An AI check compares every new payment with recent history using fuzzy matching on vendor, amount and invoice number rather than an exact match, because the second payment of a duplicate is rarely identical to the first.

In one case a EUR 42,000 invoice was paid by transfer, then paid again three weeks later under a different vendor code with a EUR 60 processing fee added, EUR 42,060 in total. An exact match would have missed it, since neither the vendor code nor the amount was identical, but the fuzzy match still linked the two because the vendor name and the invoice number matched: 42,000 plus 42,060 is a EUR 84,060 exposure, caught before the second payment cleared.

• Same vendor, same amount, invoice numbers one character apart
• Same invoice number filed under two different vendor records for what is really one supplier
• An invoice paid once by transfer and again through an expense claim
• A credit note applied to an invoice, which is then also paid in full

Vendor-master changes

Payment fraud increasingly starts in the vendor master file, not in the invoice: someone changes a genuine supplier's bank details, or adds a fake supplier that looks genuine, then waits for the next scheduled payment run. An AI check watches the vendor master itself, not just payments, and flags a bank-detail change shortly before a payment to that vendor, a new vendor paid within days of being created, or a vendor address that matches an employee's.

• Bank details changed, then a payment released within a short window, such as 48 hours
• A new vendor created and paid before a second person has approved the vendor record
• A vendor's address, phone number or bank details shared with another vendor or an employee
• A dormant vendor, unused for a year or more, suddenly paid again
• A vendor record edited by the same user who created the purchase order it is later paid against
• Two vendor records sharing the same bank account or tax registration number

Split purchases and structuring

Splitting a purchase into several smaller ones to stay under an approval limit is a known way to defeat an approval control, whether the purpose is fraud or simply avoiding a step someone finds inconvenient. An AI check groups purchases by vendor, requester and week, and flags a cluster that individually stays under the threshold but adds up to well over it.

A purchase approval limit is EUR 5,000. Over four days, the same requester raises three purchase orders to the same vendor for EUR 4,200, EUR 4,600 and EUR 4,100, none of which needs a second approval alone, but which total EUR 12,900, 4,200 plus 4,600 plus 4,100, well above the limit a single EUR 12,900 order would have triggered. The pattern, not any single order, is the flag.

Round sums and statistical outliers

Genuine transactions are usually driven by a priced item, a rate or a contract, so they rarely land on a perfectly round number; an estimate, a plug or a fabricated figure often does. An AI check flags a cluster of round amounts from one requester or account that is out of line with that requester's normal pattern, and separately flags amounts that are statistical outliers for a given vendor or account, meaning far more standard deviations from that vendor's usual invoice size than the rest of its history.

This is not the digit-level Benford's law test used in journal entry testing during an audit; it is a simpler comparison of each new transaction with the recent history of the same vendor, account or requester, which is more useful for catching a change in behaviour as it happens than a pattern across a whole year's ledger.

Worked example: an AI flag a reviewer rejects

An accounts payable system flags a EUR 18,400 payment to a supplier whose bank details changed six days earlier, giving it a high risk score. The AP team's process requires the reviewer to call the supplier on a phone number from the original contract, not the number on the change request, before releasing any payment flagged this way.

The call confirms the supplier changed banks after a merger and can produce a letter on the new bank's letterhead confirming the account, matched against the company registration number already on file. The reviewer accepts the flag as resolved, records the confirmation method and date, and releases the payment: Dr Accounts payable 18,400 / Cr Bank 18,400. Two weeks later the same vendor code receives a second bank-change request with no merger and a personal-sounding email domain; the reviewer rejects the change outright and escalates it, because the AI cannot tell a real merger from a takeover of the vendor's email account, and it is not supposed to decide that alone.

Managing false positives and model drift

A model tuned to catch everything will also flag far more good transactions than bad ones, and a reviewer shown too many false positives learns to click through them, which defeats the control as surely as having none. Track a disposition for every flag, confirmed issue, false positive, or inconclusive, and review the ratio regularly: a rising false-positive rate means the model needs retuning, not that reviewers need to work faster.

Give one named owner responsibility for tuning the model or the rule thresholds and for reporting the disposition ratio, kept separate from the reviewers who work the queue day to day, so the person adjusting the sensitivity is not the same person whose workload the adjustment reduces.

• Review disposition data monthly, not just when something goes wrong
• Retest the model or rules after any change to approval limits, vendor onboarding or payment cycles
• Keep a small set of known past cases, both real issues and false alarms, to test any change against before it goes live

Continuous monitoring versus periodic review

A rules engine or an AI model earns its keep by running before money leaves the business, not after. Screening a payment run before release can hold a fraudulent vendor change back from that run; screening the same data a month later, during a bank reconciliation, only shows what already happened. Where a check runs matters as much as what it checks: embedded in the payment approval step, a flag holds a transaction for review before release; run as a separate report after posting, the same logic only produces a list of losses to chase.

Most finance teams that add this kind of monitoring start with payments, because the cost of missing a flag there is immediate and hard to reverse, then extend the same approach to vendor-master changes and purchase requisitions once the payment screen is tuned and reviewers trust its queue.

Data protection and least privilege

Vendor and payment data includes bank details and, for sole traders, personal data, so an AI tool that screens it is a personal-data processing activity: confirm the lawful basis, put a processor agreement in place with the provider, and check the route for any transfer outside the EEA or UK; this is general information, not legal advice.

• As of September 2026, Anthropic states that by default it does not use inputs or outputs from its commercial products, including the API, to train its models, unless the customer chooses to share them
• Give a screening tool read access to vendor and payment data, never write access to the vendor master or the payment run
• Treat an uploaded invoice or supplier email as untrusted content: it can be written to instruct an assistant directly, and a screening tool should never act on instructions found inside the data it is checking
• Log every flag, every reviewer decision and every override, alongside the payment records themselves

Doing this in Skyline Nexus ERP

Skyline Nexus ERP gives a fraud-monitoring process the record it needs to work from. Every account can be flagged as a control account, such as Accounts Payable, and set to allow or block manual posting, so a payment cannot be diverted into the ledger through an account it should never touch. The system Activity Log records edits, deletions and logins with a risk column, and the Accounting Audit Trail separately records who created, approved, posted or reversed each entry, with the old and new values, an IP address and a browser.

AI-based scoring of duplicate payments, vendor-master changes and split purchases inside the product is on the Skyline Nexus ERP roadmap and being rolled out. Today, the Audit Trail and Activity Log are exactly the data an AI tool, or a person, needs to build that kind of continuous review, and the in-app assistant can already explain how to pull and read them for a specific vendor or period, citing the help page it used.