The Limits of Sample-Based Auditing
Suppose a company posts 300,000 journal entries a year and its internal audit team samples 300 of them. That is a review rate of 0.1%. If 30 problematic entries (0.01%) are hidden in the population, the chance that a random sample of 300 contains none of them is about 97%. Sampling works well for confirming that controls operate as designed, but it is a poor tool for finding a handful of abnormal transactions.
That is why many organizations add rule-based checks: weekend or late-night postings, amounts ending in 000, amounts just under an approval limit. Rules alone still fall short.
What Makes an Entry "Anomalous"
Anomalies show up in combinations of conditions, not in any single one.
A flagged entry is not proof of fraud. Input errors, deliberate fraud, and legitimate business exceptions call for different responses: correction and training, investigation, or a refinement of the rules. The model's job ends at shortlisting entries worth a look. The judgment belongs to the auditor.
Choosing a Model: Starting Without Labels
Most companies have almost no entries confirmed as fraudulent, so the realistic starting point is unsupervised anomaly detection, which needs no labels.
Existing rules are not thrown away. They become features or are blended into the score. Once auditors have confirmed a few hundred cases, a supervised model such as gradient boosting can be added, while the unsupervised model stays in place to catch new types of anomaly.
Keeping False Positives Manageable
The threshold should come from human capacity, not from the model. Two auditors reviewing 25 entries a day handle 50 a day, or 1,000 over 20 working days a month. With 25,000 entries a month, they can look at the top 4%. So instead of cutting at a fixed threshold, deliver a ranked list of the top N entries by risk score, and measure success by the share of those N that led to real action.
A bare score forces the auditor to take the entry apart from scratch. Feature contributions such as SHAP values let the system show two or three reasons with each flag, for example "preparer does not normally use this account" or "approved within 2 minutes". That shortens review time and builds trust in the results.
Operations and Data Preparation
How POLYGLOTSOFT Helps
POLYGLOTSOFT builds this in stages: integrating ERP journal and approval data, developing the anomaly detection model, and delivering a review screen where auditors see each flagged entry with its reasons and record their findings. We recommend validating detection results on one to two years of historical data before expanding into ongoing operation. If you are considering moving internal audit toward full-population testing, contact POLYGLOTSOFT.