Data Review and Anomaly Detection

The tests are not improvised. AU-C Section 240 directs auditors toward the characteristics of potentially inappropriate journal entries, and the same characteristics recur across the audit-analytics literature: entries posted to unrelated, unusual, or seldom-used accounts; entries recorded at the end of a period or as post-closing adjustments with little explanation; entries containing round numbers or consistent ending digits; and entries made by people who do not ordinarily make them. Translate those into rules against an extract and you get the working screens of an exception review: duplicate payments, weekend or period-end postings, round-dollar amounts, and entries booked to the wrong account or on the wrong side.

One screen deserves a name of its own. Benford's Law describes the distribution of leading digits in many naturally occurring sets of numbers: the digit 1 leads far more often than you might expect, roughly thirty percent of the time, while 9 leads under five percent of the time. Genuine ledger activity tends to follow that curve; a population that has been padded with invented or manipulated figures often does not. Used as a first-digit screen, Benford's Law does not accuse any single entry of anything. It points to a distribution that looks off and is worth a closer look, which is exactly the posture of every screen here.

The other half of doing this work well is the audit trail. A review is only as defensible as the record it leaves: what population was in scope, which tests were run, what thresholds were set, what each test found, and how each finding was dispositioned. The standard the work is held to is reperformance. Another preparer, handed the same extract and the same documented tests, should be able to run them and arrive at the same list. If the review lives only in one person's head or in an unrecorded series of ad hoc looks, it is hard to stand behind, however careful it was.

A good exception review is judged on two things at once, and they pull in opposite directions. It should find the entries that genuinely warrant review, and it should leave the clean entries alone. A false positive, a clean entry flagged as an exception, is not harmless: it costs a reviewer time, and the AICPA's data-analytics guidance is candid that a test can surface a large number of items that then have to be evaluated one by one. If those flags are mostly noise, they train people to distrust the report. So "good" here is not "flag as much as possible." It is closer to "flag the right entries and only those."

Bring that to a controllership desk. You are at Meridian Components, a mid-market industrial parts manufacturer. The month's general-ledger extract just landed: about fifty entries, each with a document number, a posting date, a vendor, an account, a description, and a debit or credit amount. Most of it is ordinary activity. Somewhere in the file, though, are a handful of entries that warrant a second look: a payment that may have gone out twice, an amount that lands on a suspiciously round figure, a posting dated to a weekend, a balance sitting on the wrong side of an account. Your job is to find them without raising a false alarm on the clean ones, and to leave an audit trail a reviewer could reperform.

This is a strong candidate for AI assistance because the screening itself is mechanical. A duplicate is two entries that share a vendor and an amount. A weekend posting is an entry whose date falls on a Saturday or Sunday. These are rules, not judgment calls, and a rule can be run against a whole file in one pass. What takes judgment is deciding what a flagged entry means and what to do about it, and that is where a person, briefed by the model's draft, still does the deciding. That split, mechanical screening on one side and judgment on the other, is the design of the whole workflow, and it is the subject of Part Two.

The finish line for this workflow is not a cleaned-up ledger; it is a short exception report and the audit trail behind it. The report lists the entries that tripped a rule, the rule each one failed, and a proposed next step for each. The audit trail records what tests you ran, what thresholds you set, what you found, and how you decided to treat each finding. Knowing that destination up front shapes the work: you are not asking the model to "look for anything odd," you are asking it to run named tests and report the results in a fixed shape.

Giving the model a picture of that destination, even a one-line sketch of the columns the report should have, anchors the far end of the journey the same way a worked example anchored the close workflow. The clearer the target, the less the model improvises, and improvisation is exactly what you want to avoid when the deliverable is a list of entries someone will act on.

Running an exception rule is deterministic work. Whether two entries share a vendor and an amount is a fact about the data, not a matter of opinion. Whether a date falls on a Saturday is a fact. Whether an amount ends in .00 with no cents is a fact. For a given extract, each rule has one correct set of hits, so that work belongs in a query, a formula, or a short script that runs the same way each time, rather than in a paragraph the model composes on the fly.

What the model adds is the non-deterministic work: reading each flagged entry in context, naming the rule it failed in plain language, and proposing a sensible disposition. There can be several reasonable ways to word a finding or to frame a next step, which is the sort of judgment-and-language task a model is suited to. When the rule tests live in code and the model narrates the results, you get one reliable list of exceptions and a readable write-up, instead of a model eyeballing hundreds of rows and hoping it catches them.

Minimum context here is close to literal: the folder holds one file, the general-ledger extract for the period under review, and nothing else. A single month keeps the tests meaningful. Dropping several periods into the same file would blur the duplicate test, since the same recurring vendor and amount might legitimately appear month after month, and would dilute the date tests with entries that belong to a different close. Scope the extract to the period, run the rules against it, and keep unrelated data out. The period boundary is itself part of the control: it fixes the exact population the audit trail will later claim to have tested, so a reviewer can see at a glance what was in scope and what was left out. A smaller, cleaner file is both a quality choice and, at your own desk, a governance one.

Three rules run against real rows from Meridian's file, and they land on three different verdicts. That spread is why the split matters.

The duplicate test fires. Two rows post to the vendor Corradi Metals, each for $18,450.50, one dated Wednesday, October 14 and the next Thursday, October 15. The test does not read them as prose. It groups the extract by the pair (vendor, amount) and counts the rows in each group; this pair returns a count of two on adjacent dates, so both rows surface as a single duplicate finding. Buried in that rule is a design choice: keying on the amount alone would flag any two unrelated $18,450.50 payments anywhere in the file, while keying on vendor, amount, and closeness in time is what makes the hit precise. The count is a fact with one correct answer for this extract, which is why it belongs in a query rather than in a sentence the model composes.

The sign test fires. One row posts a $96,000.00 debit to the account "4010 Revenue - Precision Components." The test carries a short table of each account's natural balance side, revenue being credit-natured and most expenses debit-natured, and compares the posting side against it. A debit landing in a credit-natured account does not match, so the row trips the sign or account-error rule. Here too the machine is doing lookup and comparison, not judgment; what to make of the reversal is the part left for a person.

The clean rows a naive test would trip. Fairmont Utilities appears eleven times in the file, one ordinary monthly invoice after another, each for a different amount. A crude duplicate test keyed on the vendor alone would flag that whole run as suspected repeats, even though each row is a distinct, legitimate charge. Keyed on vendor and amount together, as above, no two Fairmont rows share an amount, so they pass untouched. That gap between the broad rule and the precise one is where false positives are born: tuned too loosely, a rule buries the reviewer in clean entries; the craft is to catch the genuine repeat, the two Corradi rows, while sparing the honest recurring vendor.

Reinventing this review every month is wasted effort, so it carries two pieces of reusable scaffolding. The first is a saved skill or prompt that encodes the whole shape: the named tests to run (duplicates keyed on vendor and amount, weekend and period-end postings, round-dollar amounts, sign or account errors, and a Benford first-digit screen), the fixed columns the exception report should carry, and the voice to write findings in. Because the deterministic tests live in code, the skill's real job is to hold the framing steady, so next month's run produces a report in the same shape as this month's rather than whatever the model improvises that day.

The second is a short reviewer checklist that travels with the output, so a person can confirm the run before acting on it. A workable version: the extract covers exactly one period and nothing else; every test that was supposed to run is listed in the audit trail with its threshold; each flagged entry names the rule it failed; each finding carries a proposed disposition rather than a verdict; and no entry has been called fraud or error by the model without a person confirming the cause. The checklist is where the "flag, do not conclude" discipline of AU-C 240 stops being a slogan and becomes a step someone actually performs.

Download the folder and run the anomaly-detection pattern in whatever AI you use. Inside is a single file, Meridian's GL extract for the month, holding about fifty entries. Most are ordinary. A small number were planted: a duplicate payment, a weekend posting, a round-dollar entry, and a revenue account carrying a debit. Let a rule-based test hold the mechanical screening, have the model draft each flagged entry with the rule it failed and a proposed disposition, and then come back for scoring. The company and each figure are fictional.

Because the lab's anomalies are seeded, the score is not a matter of opinion. Line your flagged entries up against the planted set and count three things: the anomalies you found, the anomalies you missed, and the clean entries you flagged in error. A clean run finds each planted exception and raises no false positives against the roughly 45 clean entries. Work the checklist below against your report before you would call the review done, and treat any blocker it surfaces as a reason to go back to the extract rather than to ship the list.

The write-up below is what you would hand to the controller. Each finding names the entry, states the rule it tripped, and proposes a proportionate next step, while stopping short of a verdict.

• Corradi Metals, two entries at $18,450.50 (duplicate-payment rule). Same vendor and amount on adjacent dates. Disposition: confirm whether two separate invoices exist; if the payment was issued twice, initiate recovery. Framed as a question to resolve, not a confirmed double payment.
• Freight, $27,310.22 posted Saturday, October 17 (weekend-posting rule). Disposition: confirm who posted the entry and why it fell on a weekend. A legitimate reason is common, so this is a look, not a finding of error.
• Consulting fees, $50,000.00 exactly (round-dollar rule). Disposition: tie the amount to its supporting invoice; if it is an accrual, confirm the estimate and its basis.
• Precision Components revenue, $96,000.00 debit (sign or account-error rule). Disposition: investigate the posting; if it is a misclassification, reclassify to the correct account or side.

The audit trail sits underneath this list: the tests run (duplicates, weekend postings, round-dollar entries, sign or account errors), the thresholds used, the four findings across five entries, and the disposition for each. Another preparer could take that note, rerun the same tests on the same extract, and reach the same list, which is what makes the review defensible.

The lab is clean by design: the anomalies are seeded, the extract is one tidy file, and the rules are stated. Live ledgers are messier, and a review that ran clean here can still stumble on real data in a few recognizable ways.

Legitimate duplicates. A vendor can be billed twice in the same month for two genuine orders, say two separate truckloads of the same alloy at the same price, which trips the duplicate rule even though both payments are valid. On live data these good-faith matches can outnumber the real double-payments, so the duplicate test usually needs an invoice-number check or a tight proximity window to stay useful.

Systematic weekend activity. Some systems post scheduled batch jobs, bank feeds, or recurring accruals with weekend timestamps, so a whole class of routine entries lands on Saturdays and Sundays. Run raw, the weekend test can drown one real off-hours posting in that noise, which is why it is often paired with a source-system or user filter.

Anomalies that hide from plain rules. An entry sized just under a round-number or approval threshold, or a single payment split across two smaller postings, can slip past the plain rules entirely. Catching that kind tends to call for a sharper test, such as leading-digit (Benford) analysis or a near-duplicate window, or a second human pass over what the rules leave behind.

The rules narrow a large file down to a short list worth human attention; they do not settle what each exception means. That judgment, and the sign-off, stay with the reviewer.

Rate your own exception report against the rubric below. An honest self-rating shows which parts of the review are solid, from scoping the data to writing a defensible disposition, and which still need practice. Your scores roll up to the workflow maturity dashboard on the course hub.