Fraud rarely shows up as a number that's wrong. The books balance. The reports foot. What gives it away, when anything does, is that a number is unusual. A journal entry posted at 2:00 on a Sunday morning. An amount that's exactly $50,000. A vendor whose address matches an employee's. An adjustment whose audit trail is dated before the record it describes. None of those is proof of anything, and most have an innocent explanation. But they're where an investigator starts, and NetSuite doesn't offer a report that lists them.

The Sonar edition of my prompt library added a group of prompts for exactly this kind of looking. There are seven in the Forensics and Anomaly Detection category, and this post is a tour of what each one does and, just as important, what each one refuses to conclude.

If you're new to this, Sonar AI is an AI agent that runs inside NetSuite. Every prompt in the library is a playbook that I engineered and tested against live NetSuite data, and you run it inside your own account, against your own records.

The Rule They All Share

Every one of these prompts opens with the same hard rule, worded slightly differently each time: never conclude fraud. An after-hours transaction is an indicator requiring review. A statistical outlier is a statistical finding. A duplicate vendor may be the same parent company in two legal entities. The prompts flag, score, and rank. A person decides what it means, and the reports say so in as many words.

I think that's the only responsible way to build this kind of tool. A model that's willing to write "this looks fraudulent" will eventually write it about the controller's legitimate month-end batch, and the damage from that sentence is hard to undo. So the prompts are written to produce evidence for an investigator, and the investigator's judgment stays with the investigator.

When Things Were Posted

Three of the seven are about timing, and they work at different grains.

Day-of-Week / Hour Anomaly Heatmap is the wide view. It counts every posting transaction by the day of the week and the hour it was created, renders a seven-by-twenty-four grid with business hours outlined, and summarizes weekend and overnight activity by transaction type and by user. It carries a baseline: weekend plus overnight posting should be under 3% of transaction count for a typical business, above 10% warrants investigation, and above 20% is a red flag. And it carries a caveat that I'd want in any report like this: the timestamps are server time, and a contractor in another timezone or a scheduled script looks exactly like a person working at midnight.

Off-Hours Transaction Audit is the same question at the individual level. It lists every transaction created outside business hours or on a weekend, with dollar amounts, ranks the high-value ones for review, concentrates the results by user, and breaks out journal entries as the highest-risk sub-population. Its baseline is relative rather than fixed. If 95% of journal entries in the account post during business hours, an off-hours one deserves scrutiny. If 60% do, because there's an end-of-day batch, the context dominates and the report has to say so.

Journal Entry Forensics goes deepest, and only on manual journals. It runs seven tests: weekend and after-hours posting, round amounts in multiples of a thousand, entries to revenue or retained earnings, a segregation-of-duties proxy where the creator is also the last modifier, backdating by more than 30 days, creator concentration by value, and blank memos on material entries. Each test an entry trips adds two points. Six or more is high and goes to the CFO. Three to five is management review. One or two is document and monitor. Before any high-scoring entry is escalated, the prompt loads the full record so the memo can cite the lines, the accounts, and the approval trail.

Who Posted Them

Manual Journal Entry User Map answers a question that the segregation-of-duties test only hints at: who is actually making the journal entries, and how concentrated is that? It summarizes volume and value per user, tracks each user's monthly trend to catch activity spikes, finds journals posted by inactive users, which is a controls failure rather than a suspicion, and reports the concentration. A single user above 50% of journal value is critical. Above 30% is high and needs documented justification. Top three users above 80% is elevated, because it's key-person risk as much as anything.

The prompt is careful about what concentration means. High journal volume from one person may simply reflect their job. That's the difference between a finding and an accusation, and the report is written to deliver the first.

Whether They Make Statistical Sense

Z-Score Transaction Outliers takes the population of each transaction type, computes the mean and standard deviation of amounts, and scores every transaction by how many standard deviations it sits from the mean. Up to two is normal. Two to three is elevated, worth a look on high-risk types. Three to four is an outlier and every instance gets reviewed. Above four goes to the controller. Journal entries get their own pass using the accounting lines rather than the header, because that's where the risk is.

The prompt also includes something that most z-score analyses skip: a check on whether the distribution is anywhere near normal. Financial transaction amounts usually aren't. They're skewed, with a long tail of large items. So the report builds a ten-bucket histogram and says how much to trust the scores before anyone acts on them.

Whether the Counterparties Are Real

Phantom Entity / Duplicate Detection looks at the master data instead of the transactions. Seven tests: vendor name duplicates, customer name duplicates, vendors sharing a phone number or email, vendors with no transactions at all, vendors whose address matches an employee's, vendors sharing an address with each other, and high-value vendors that were created and paid within 30 days. The address-matches-employee test is the one that escalates immediately, because it's the classic phantom vendor pattern. The rest score. A vendor created by someone outside accounts payable, paid within a month, and sharing contact details with another vendor adds up quickly.

Bank account detail isn't exposed to SuiteQL, so the prompt describes a record-load procedure for checking shared bank accounts as an enhancement step, rather than pretending the query channel can see them.

Whether the Records Agree With Themselves

Inventory Adjustment Forensics is the most elaborate prompt in the group, and it came out of a real engagement. It reads every inventory adjustment through five layers that it treats as independent witnesses: the transaction header and its timestamps, the lines, the general ledger, the system notes, and the deletion log. The findings live where the witnesses disagree. A transaction dated in one period but entered in another. A creator field that's empty with no audit trail behind it. System notes dated 92 days before the record they describe. A gap in the numbering series that the deletion log explains, or doesn't. A positive-quantity adjustment at zero cost that has already fed the average cost of an item that has since sold.

It's also the only prompt in the library that submits its own claims to a second AI model for adversarial review before publishing. The claims go over neutrally stated, with the raw query results first and the recommendations withheld. When the reviewer challenges one, the prompt's instruction is to harden it with a new query rather than soften it with a weaker adjective. The published report carries a claim-by-claim verdict table. In the reference engagement, the reviewer caught a sampling shortcut, an over-claimed cause, and one arithmetic slip, which is a good argument for the step.

Wrapping Up

What these seven have in common, beyond the rule against concluding fraud, is that they make the ordinary visible. Most of what they find is explained in a sentence: the batch job, the timezone, the acquisition that brought in a second vendor record. The value is in the small remainder that isn't, and in having the list at all. Before prompts like these, the list existed only in an auditor's sample, once a year.

All seven are in the paid tier of the Sonar AI Prompt Library, under Forensics and Anomaly Detection: Day-of-Week / Hour Anomaly Heatmap, Off-Hours Transaction Audit, Journal Entry Forensics, Manual Journal Entry User Map, Z-Score Transaction Outliers, Phantom Entity / Duplicate Detection, and Inventory Adjustment Forensics.