Data Review and Anomaly Detection
Exception-based testing on a messy general-ledger extract, with an audit-trail artifact to back it. Because the anomalies are seeded, validation is fully objective: the lab is scored on what you found, what you missed, and what you flagged that was clean. Duplicate payments, weekend postings, round-dollar entries, and sign reversals.
120 min
6
16
5
Learning Objectives
By the end of this chapter you should be able to:
- 1Define exception-based testing on a general-ledger extract and describe what a good exception review looks like: it surfaces the entries that genuinely warrant a look while sparing the clean ones.
- 2Apply the core exception rules to a GL extract: duplicate payments, weekend postings, round-dollar entries, and sign or account errors.
- 3Design the review so the deterministic rule tests run mechanically against the data while the model handles the non-deterministic framing of each finding.
- 4Produce an audit-trail artifact that records the tests run, the thresholds applied, the findings, and the disposition for each, so another preparer could reperform the work.
- 5Apply governance to sensitive general-ledger data and keep AI-assisted review inside the normal controllership sign-offs.
- 6Score the review objectively against the seeded anomalies, counting what was found, what was missed, and where a clean entry was flagged in error.
- 7Frame each finding with a defensible disposition, such as investigate, reclassify, or confirm with the vendor, in a measured controller's voice.
Part One: The Exception-Review Problem and What Good Looks Like. Section 1 of 6.
Part One · The Exception-Review Problem and What Good Looks Like
The Exception-Review Problem and What Good Looks Like
Part One
The Exception-Review Problem and What Good Looks Like
A month of ledger activity lands as a single extract, mostly ordinary, with a few entries that deserve a second look. This module builds the workflow that finds them with AI. It starts, as the close module did, with the standard the output has to meet.
The overnight extract
You are on the controllership team at Meridian Components, a mid-market industrial parts manufacturer. The month's general-ledger extract just landed on your desk: 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.
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.
What a good exception review looks like
Exception-based testing is the practice of screening a full population against a small set of rules and pulling out only the entries that trip one, so a reviewer can spend time on the exceptions rather than reading the ledger line by line. The rules are chosen to catch the errors and irregularities that tend to hide in a general ledger: payments made twice, amounts that look estimated rather than invoiced, postings at odd times, and entries booked to the wrong account or on the wrong side.
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 a harmless extra: it costs a reviewer time, and if these pile up, it trains people to ignore the flags. So "good" here is not "flag as much as possible." It is closer to "flag the right entries and only those." Because the lab's anomalies are seeded, you can score both sides of that exactly: what you found, and what you flagged that you should not have.
Check Your Understanding
Knowledge Check 1
Data Review & Anomaly Detection
An analyst screening a general-ledger extract flags 40 of 300 entries as exceptions. On review, 4 of the 40 are genuine anomalies and the other 36 are ordinary, correctly recorded transactions. What does this result most clearly show about the screening?