Monday's exception report has three lines
At 07:40 on a Monday, the accounts payable lead opens the weekly exception report. It has three lines. A vendor whose bank account was changed on Thursday received $18,400 in Friday's payment run. Two invoices from the same supplier, each for $2,316.50, carry the numbers INV-1043 and INV1043. A manual journal entry posted at 23:12 on Saturday was approved by the user who created it.
None of these proves anything. Each is a question with a name beside it and a date to answer by. This is an illustrative example, and it shows what continuous controls monitoring looks like in a mid-market finance team when it works: a small number of specific tests, run on a schedule, with every exception routed to a person who can close it.
Annual reviews miss fast problems
An annual audit and a quarterly review look at samples, after the fact. Payment fraud moves faster than either. The Association for Financial Professionals reported in April 2026 that 76 percent of US organizations experienced attempted or actual payments fraud in 2025, and that 74 percent were affected by business email compromise.
A test that runs weekly over every transaction finds a changed bank account before the second payment, not at year end. The ACFE's 2026 Report to the Nations lists proactive data monitoring and analysis among the anti-fraud controls associated with lower fraud losses and quicker detection.
What makes a test worth running
A test earns a place in the schedule when it meets four conditions:
- It uses data you already hold. The ledger, the vendor master and its change log, payment files, the payroll register and user access listings.
- Its rule fits in one sentence. The reviewer should understand at a glance why an item was flagged.
- Each exception has an obvious next step. Call the vendor at a known number, ask the preparer, reverse the entry.
- The reviewer is independent of the activity. The person who changes vendor bank details never clears the bank-change exceptions.
Ten tests, each with an owner
The thresholds below are starting points. Set your own from your approval limits and a year of history.
| Test | Data source | Logic | Frequency | Reviewer |
|---|---|---|---|---|
| 1. Duplicate payments | AP invoices and payment history | Same vendor or bank account, same amount, invoice numbers that match once spaces and punctuation are removed, within 90 days | Weekly, before the payment run | AP lead; controller above $5,000 |
| 2. Bank change, then payment | Vendor master change log, payment files | Bank details changed, then a payment within 30 days; check for a documented callback to a number already on file | Every payment run | Controller, never the person who made the change |
| 3. Vendor and employee matches | Vendor master, HR and payroll master | A vendor and an employee share a bank account, address, phone number, email or tax ID | Monthly | Controller; CFO if finance staff are involved |
| 4. Self-approved journal entries | Journal entry log with preparer and approver IDs | Manual entries where preparer and approver are the same user, or approval is missing | Weekly during close | Controller; CFO for the controller's own entries |
| 5. After-hours journal entries | Journal entry log with timestamps | Manual entries posted between 20:00 and 06:00, on weekends or holidays, or after the period was closed | Monthly | Controller |
| 6. Split purchases under limits | AP invoices, purchase orders, card transactions | Two or more items from the same requester or vendor within seven days, each under the approval limit, together above it | Monthly | Purchasing manager or CFO |
| 7. Just-below-limit and round amounts | AP invoices, card and expense data | Amounts within 5 percent below an approval threshold, and round-dollar amounts above a floor you set | Monthly | Controller |
| 8. New vendor, fast payment | Vendor master, payment history | Vendor created and paid within 14 days, or set up without a tax ID or with only a PO box | Weekly | AP lead with purchasing |
| 9. Payroll anomalies | Payroll register, HR master | Pay after a termination date, two employees sharing a bank account, pay changes without HR approval | Every payroll | HR director, not the payroll processor |
| 10. Access conflicts | User and role exports from the ERP, bank portal and payroll | Users who can both create vendors and release payments, or post and approve entries; new administrator accounts | Monthly | CFO with the system owner |
Tests 1 to 3 and 8 protect cash before it leaves. Tests 4, 5 and 7 look for entries that bypass review. Tests 6, 9 and 10 look for structures that let one person act alone. For the callback that test 2 depends on, see vendor bank-change fraud: five controls that stop it.
Build tests in order of use
Start with three
Begin with duplicate payments, bank changes followed by payment, and self-approved entries. Each is a simple join on fields every accounting system has. The exceptions are easy to act on, and two of the three stop money before it goes out.
Run against history first
Before you schedule a test, run it on the last twelve months. Expect noise. Monthly rent in identical amounts looks like a duplicate. A controller working late at close looks like an after-hours entry. Record each exclusion and the reason for it, and have the reviewer approve the list. Exclusions are part of the control and should be reviewed each quarter.
If you would rather see the whole year scanned at once before deciding which tests to keep, a one-time full-ledger analytics review does that and shows which rules produce useful exceptions in your data.
Route every exception to a name
Each exception gets an owner, a due date and a conclusion from a short list: explained, corrected or escalated. Five business days is a workable default. Escalations go to someone senior to the reviewer, and anything that touches the reviewer's own work goes around them.
Keep the evidence
For every run, keep the run date, the population tested, the exceptions, the reviewer, the conclusion and the date of the conclusion. Record the population as a count and a total and reconcile it to the ledger, so you can show the test saw every transaction and not just the ones that loaded. That record turns a script into a control that an auditor, a lender or a board can rely on.
What the tests will not catch
Rules narrow where to look. They do not replace judgment. Plan for these gaps:
- Collusion. Two people who each do their part correctly will pass every test above.
- Shared logins. If two people use one user ID, test 4 cannot see who did what. Fix access before you trust the result.
- Activity outside the feeds. A bank account or card program nobody connected to the monitoring is invisible to it.
- Estimates and reserves. Judgment calls need a reviewer who understands them, not a rule.
- Time zones. Set the after-hours window in the time zone of the person posting, not the server.
Walkthroughs of real transactions and a periodic access review still matter. Monitoring tells you where to point them.
Where to start
Pick the three starter tests and run them on last year's data this month, with a named reviewer for each. If you want the tests built, tuned and run on a schedule, with a monthly exception report and a quarterly review, that is the scope of our continuous controls monitoring service. For test 10, the free segregation-of-duties conflict finder shows which combinations of duties to look for first.