Unit 4 / 12

Anomaly and Error Detection: Journal Entry Testing and Outlier Analysis

Gains:

  • Understand why journal entry testing is mandatory under BDS 240 and how artificial intelligence can scan suspicious entry criteria
  • Ability to mark and prioritize outliers, unusual timing and unusual amount patterns with artificial intelligence support
  • Being able to maintain that every anomaly flagged by artificial intelligence is not a finding, but a question mark that the auditor will investigate, and the elimination of false positives is human responsibility.

The financial statements of a business are basically the sum of millions of journal entries (in accounting, each financial transaction is recorded as debit and credit). Both error and fraud ultimately live in a journal entry: an amount written to the wrong account, an allowance that is "forgotten" and reversed at the end of the period, an unusual entry entered manually in the middle of the night. Therefore, BDS 240 (the standard regulating the auditor's responsibilities regarding fraud in the audit of financial statements) clearly requires the auditor to perform journal entry testing. Its purpose is to reveal possible manipulations by management through management override.

In this unit, we will cover how to turn artificial intelligence into an engine of anomaly and error detection, but why each marked record is a "question mark" rather than a "finding". First two concepts. An anomaly is an unusual record in a data set that deviates from the expected pattern. An outlier is an observation that is numerically significantly different from the others (such as a very large amount, a very high frequency). Anomaly is not always an error; but it is where the auditor should look.

Suspicious posting criteria in journal entry test

BDS 240 states that records with certain characteristics are more salient to the risk of fraud. AI can scan hundreds of thousands of records based on these criteria in seconds. Typical "red flag" criteria:

  • Unusual timing: Manual records entered after working hours, on a weekend, on a public holiday, or on the last day of the end of the term.
  • Unusual user: Records entered by a user who does not normally enter accounting records (for example, an administrator).
  • Unusual account combinations: Postings between accounts that do not expect each other (e.g., a revenue account and an unusual non-cash account).
  • Round amounts: "clean" large amounts such as 100,000, 500,000; It is a typical trace of manual manipulation.
  • Records with empty or ambiguous descriptions: empty descriptions such as "correction", "miscellaneous", "provisional".
  • Reversed records: Records entered at the beginning of the period and canceled (storno) after a short time.
  • Subthreshold duplicates: Large numbers of records clustered just below the approval threshold (e.g. $50,000).
Tip: Think about these criteria together, not individually. "Round amount" alone may be innocent; but "weekend, by an administrator, description blank, round consistent, end of period manual posting" is a strong red flag. Having AI combine criteria to produce a “risk score” helps you prioritize.

The false positive truth: why not every sign is a finding

The nature of anomaly scanning is false positives: records flagged by the rule that are actually legitimate. For example, a company automatically enters a round-robin rent accrual on the last business day of each month; This is stuck with the "round amount + end of period" criterion, but it is completely normal. The auditor's job is to extract real risk from the flagged pile. This sorting is not transferable; because distinguishing legitimate from suspicious requires knowing the business and the context — something AI does not have.

So always read the output like this: "The AI ​​flagged 420 records for me. Most of them are probably false positives. My job is to find out of these 420 the ones that really need to be investigated, the patterns and the individual suspicious ones." This view protects you from both automation bias (taking every sign for an error) and laziness (not looking at any of them).

Anomaly detection step by step

  1. Prepare data and verify completeness. (Reconciliation steps in previous unit.)
  2. Define the criteria clearly. What timing, amount, user and description patterns will be flagged?
  3. Scan and score with AI. Mark each record according to criteria; Give higher priority to those that meet multiple criteria.
  4. Eliminate false positives. Filter or flag known legitimate patterns (such as automatic accruals).
  5. Examine the remaining records. Link each to the supporting document, approval, and business logic.
  6. Document the conclusion and rationale. Write down what you found suspicious and why, and what you eliminated and why.

three mini cases

Case 1 — Actual finding. An auditor scanned 240,000 journal entries with AI; It combined the criteria "last 3 days of the period + manual + description 'correction' + 100,000 times the amount". 14 records received high scores. In the review, 11 were legitimate year-end adjustments; However, 3 entries were entered in a way that would inflate the income account and be reversed the following period, and there was no supporting documentation. This was a pattern of management bypassing controls and was a significant finding. The AI ​​asked 14 questions; The auditor's skepticism found the 3 real answers.

Case 2 — False positive trap. A team member wrote the 380 “round consistent” records that AI had flagged directly onto the worksheet under the heading “suspicious transactions.” When the officer looked, he saw that most of them had fixed rent, fixed consultancy fee and automatic depreciation records; they were all legitimate. The worksheet had become a "list of false findings" that led the audit in the wrong direction. Lesson: not every flagged record is a finding; The auditor makes the selection.

Case 3 — Setting the criteria too narrowly. An auditor used only the "weekend record" criterion and found no suspicious records; He was relieved. However, in the business, manipulative records were entered during weekday working hours, but with unusual account combinations. Relying on a single, narrow criterion prevented him from seeing the real risk. When the auditor expanded the criteria, the pattern emerged. Lesson: single criterion does not provide assurance; Look at it multidimensionally.

Weak prompt / Strong prompt

Weak prompt:

Find fraudulent entries in these journal entries.

Problem: AI cannot “detect” cheating; Fraud is a legal/professional consequence, not a data pattern. Also "fraudulent" is undefined. This prompt produces either a made-up "cheat list" or meaningless flags.

Powerful prompt:

Your role: you are an independent auditor's journal entry analysis assistant. You MARK the record according to the criteria; cheating/error decision belongs to me.Context: Anonymized journal data (columns: record_number, date, time, user_role, debit_account, credit_account, amount, record_type[manual/automatic], description). End of term: 31.12. Working hours: 09:00-18:00, Mon-Fri.Task:1) Give an "attention score" to each record according to the following criteria (depending on how many criteria are attached): a) record_type=manual b) date between 29-31 December OR weekend/holiday c) hour off-duty d) amount 100,000 TL solid (rounded) e) description is empty or {correction, miscellaneous, temporary} in2) Give those with a score of 3 and above as a priority list.3) Write each criterion you apply in plain text (auditability).4) Make it clear that these are "exceptions to be examined" and are not the RESULT of fraud/error. Adding a fake record.

This prompt is powerful because it clearly defines the criteria, requires multidimensional scores, auditability, and accurately locates the output (the exception, not the outcome).

Common mistakes

  • It means "find the trick". AI does not detect cheating; puts a mark according to the criteria. Cheating is a professional/legal consequence.
  • Mistaking the sign for a finding. Writing the suspicious record as "error" without eliminating false positives.
  • Relying on one criterion. Using a narrow rule and missing the real pattern.
  • Not filtering out legitimate patterns. Creating noise by including automatic accruals in the suspicious list.
  • Not documenting the rationale. Leaving the worksheet untraceable without writing down what you eliminated/kept and why.
Caution: Describing a recording as "suspicious" is a serious statement. Verify with evidence (supporting document, confirmation, business case) before writing as a finding. Otherwise, you will be unfair to the business and damage the audit quality.

In summary

Journal entry testing is required under BDS 240, and AI is the ideal engine for this: it scans hundreds of thousands of records against multidimensional criteria in seconds and produces an attention score. But AI doesn't "detect" cheating or errors; it only marks the unusual. The output is a pile of exceptions full of false positives; It is up to the auditor's skepticism and judgment to sort out the real risk from it, eliminate the legitimate one, and draw conclusions. The sign is a question mark, not an answer.

Application task

Specify five anomaly criteria for a hypothetical journal data (schedule, user, amount, account combination, description). Have the AI ​​produce a multi-dimensional "attention score" with the powerful prompt pattern above. Then write a “screening guide”: which legitimate patterns (automatic accrual, fixed rent, etc.) should be filtered out as false positives? Finally, for the 5 high-scoring records, “what evidence do I look for?” Answer the question.

checklist

  • [ ] I anonymized the data and verified its completeness.
  • [ ] I defined the anomaly criteria multidimensionally and clearly.
  • [ ] I received the plaintext of the attention score and applied criteria from the AI.
  • [ ] I filtered out known legitimate patterns as false positives.
  • [ ] I have reviewed high-scoring records with supporting documentation and confirmation.
  • [ ] I verified it with evidence before concluding "cheating/error".
  • [ ] I documented what I found suspicious and why.