journal-entry-tester

Journal Entry Tester

This skill helps an auditor or reviewer run a structured set of journal-entry tests over a general-ledger (GL) extract, following the mindset of ISA 240 The Auditor's Responsibilities Relating to Fraud in an Audit of Financial Statements. ISA 240.32(a) requires the auditor to test journal entries and other adjustments because of the risk of management override of controls. This skill profiles the journal population, applies repeatable anomaly screens, and produces a flagged-items workpaper that an engagement team can follow up, document, and sign off. It is for external auditors, internal audit, and finance teams running self-review or month-end controls.

When to use this

• You are performing the mandatory journal entry testing required by ISA 240.32 (management override of controls).
• You have a full-period GL extract (the journal population, not a sample) and need to identify entries warranting individual inspection.
• You want population analytics for a planning or completion memo (count, value, distribution by source, by user, by period).
• You are running data analytics over postings as part of a controls or fraud review.
• You need a defensible, reproducible record of which screens were run and what they flagged.

Inputs

Provide the GL extract as a CSV (or describe an Excel sheet). The bundled sample samples/general_ledger_extract.csv shows the expected shape. Useful fields, with typical headers:

• journal_id / document_no - unique entry identifier (header level).
• line_no - line within the journal.
• posting_date - date the line hit the ledger.
• entry_date / created_date - date/time the entry was keyed (often differs from posting date).
• period - accounting period the entry posts to (e.g. 2025-12).
• account and account_name - GL account code and description.
• debit, credit (or a single signed amount).
• source / journal_type - e.g. AP, AR, payroll, bank, MANUAL, top-side.
• created_by / user_id - who entered it.
• approved_by - approver, if captured.
• description / narrative - free text.

Also ask the user for the parameters that drive the screens (do not guess):

1. Reporting period and period-end date (e.g. year end 31 Dec 2025).
2. Approval threshold(s) in the entity's currency (e.g. entries over 10,000 need a second approver).
3. Functional currency and whether amounts are already in one currency.
4. Holiday calendar / non-working days relevant to the entity's jurisdiction.
5. Known automated source codes so manual entries can be isolated.

If posting date and entry date are the same field, note that the after-hours and post-period-vs-keyed tests are weakened, and say so in the workpaper.

How to do it

Work in two phases: profile the population, then run targeted screens. Keep every record's journal_id and line_no so flags trace back to source.

Phase 1 - Validate and profile the population

1. Completeness reconciliation. Sum all debits and all credits. They should be equal (or net to zero on a signed amount). Reconcile the total movement to the trial balance or to the GL control total the user provides. Note any difference - an unreconciled population invalidates the testing. Confirm the date range covers the full period with no gaps and no entries outside the period.
2. Integrity checks. Confirm each journal balances at the header level (debits = credits per journal_id). Flag one-sided entries, blank accounts, blank dates, zero-amount lines, and duplicate journal_id+line_no keys.
3. Population statistics. Produce: total entries (headers) and lines; total debit and credit value; count and value by source; count and value by created_by; count and value by period/month; count and value by account. This is the denominator for every screen and belongs in the planning memo.

Phase 2 - Anomaly screens

Run each screen as a separate, named test so results are auditable. For each, record the rule, the parameter used, the count and value flagged, and the percentage of population.

4. Weekend and holiday postings. Flag lines whose posting_date (and/or entry_date) falls on a Saturday, Sunday, or a date in the supplied holiday calendar. Legitimate automated postings may run on weekends; isolate manual weekend entries for higher scrutiny.
5. After-hours postings. If entry_date carries a timestamp, flag entries keyed outside normal working hours (e.g. before 06:00 or after 20:00 local). State the window used.
6. Post-period / back-dated entries. Flag entries where posting_date falls in the period but entry_date is after period-end (entries booked late and dated back), and any entry whose posting date is after period-end but posts to the period under audit. These bridge the cut-off and are high risk.
7. Round-number amounts. Flag absolute line amounts that are exact multiples of a materiality-scaled rounding unit (e.g. ending in 000 or 0000, or exact thousands/millions). Round numbers can indicate estimates or fabricated figures. Report the rounding rule used.
8. Just-below-threshold entries. For each approval threshold T, flag entries in the band [0.90 * T, T) - amounts sized just under an approval limit, a classic override pattern. Report the band per threshold.
9. Rare user-account combinations. Build a frequency table of (created_by, account). Flag pairs that occur at or below a rarity cut-off (e.g. a user touching an account once or twice in the whole period when their normal accounts differ), especially for sensitive accounts (revenue, reserves, suspense, intercompany, cash, related party).
10. Unusual account pairings. Within each journal, list the debit account / credit account combinations. Flag pairings that are rare across the population or that span unrelated cycles (e.g. revenue debited against a cash/suspense account, or P&L lines paired directly with equity/reserves). Sensible pairings (AR vs revenue, AP vs expense) are not flagged.
11. Manual and top-side entries. Flag entries whose source/journal_type is manual or top-side (i.e. not from a sub-ledger feed), particularly those posted near period-end, to the consolidation level, or by senior/finance users. ISA 240 treats non-standard, manual adjustments as inherently higher risk.
12. Keyword and narrative scan. Flag blank descriptions and narratives containing words that warrant inspection in context (e.g. "adjust", "reclass", "correction", "plug", "to balance", "per management", "reverse"). Treat hits as prompts to read the support, not as conclusions.
13. Seldom-used and dormant accounts. Flag postings to accounts used only a handful of times in the period, and reactivations of accounts dormant earlier in the year.

Scoring and follow-up

14. Aggregate flags per journal. A single entry may trip several screens. Assign a simple risk score (e.g. count of distinct screens triggered, or weighted by screen severity) so the team can prioritise. Do not auto-conclude: a flag is a prompt for professional inspection of supporting evidence (invoice, contract, approval, board minute), not a finding.
15. Document the test design. Record every parameter, rule, and cut-off, plus any data limitations (missing timestamps, single date field, mixed currencies). This is what makes the workpaper defensible.

Output

Produce two artifacts.

1. Population summary (Markdown or CSV). Sections: scope and period; data source and row count; debit/credit reconciliation to TB; tables for count and value by source, by user, by month, and top accounts; list of screens run with parameters.

2. Flagged-items workpaper (CSV, one row per flagged journal line). Suggested columns:

journal_id, line_no, posting_date, entry_date, period, account, account_name, debit, credit, source, created_by, approved_by, description, flags_triggered, risk_score, reviewer_comment, conclusion

Leave reviewer_comment and conclusion blank for the human to complete. flags_triggered lists the screen names that fired (e.g. WEEKEND;ROUND_NUMBER;MANUAL). Sort by risk_score descending. Optionally add a short cover memo stating the objective (ISA 240.32 journal entry testing), population tested, screens applied, total items flagged, and that all flags require inspection of underlying evidence before any conclusion.

Quality checks

• Confirm debits equal credits and the population reconciles to the TB before reporting any screen results.
• State the exact parameter for every screen (rounding unit, threshold band, after-hours window, rarity cut-off). A screen without a stated rule is not auditable.
• Do not double-count: report flagged lines and flagged journals separately.
• Distinguish automated from manual postings before judging weekend/after-hours entries - automated feeds at odd hours are usually benign.
• Never present a flag as a misstatement or fraud. Every flag is a candidate for inspection only.
• Watch for false comfort from a clean run: a low flag count may mean weak data (e.g. all entries share one source code or one user), not low risk. Call this out.
• Preserve traceability - every flagged row must carry journal_id and line_no back to the source extract.
• Mind currency and sign conventions; mixing signed amounts with separate debit/credit columns is a common error.

Worked example

Using samples/general_ledger_extract.csv (fictional, year end 31 Dec 2025, approval threshold 10,000):

• Profile: 20 lines across 12 journals; debits = credits; sources AP, AR, BANK, PAYROLL, and MANUAL.
• JNL-0142 posts 9,800 to a marketing accrual, source MANUAL, created_by jsmith, posted Sat 27 Dec 2025 with narrative "to balance". This trips JUST_BELOW_THRESHOLD (within [9,000, 10,000)), MANUAL, WEEKEND, and KEYWORD ("to balance") - risk score 4, top of the list.
• JNL-0150 posts a round 50,000 dated 31 Dec 2025 but keyed 06 Jan 2026 (entry_date after period-end), debiting revenue against suspense: trips ROUND_NUMBER, POST_PERIOD, and UNUSUAL_PAIRING.
• JNL-0151, created by treasury posting to account 7400 (a payroll account treasury never otherwise touches), trips RARE_USER_ACCOUNT.

The workpaper lists these with their flags_triggered and risk scores so the team requests support (approval, invoice, board minute) for the highest-scoring items first.

Disclaimer

Disclaimer: This skill is a drafting and analysis aid, not professional advice. It does not provide accounting, audit, tax, investment, or legal advice. All output must be reviewed and approved by a qualified professional before use or reliance.

---

Part of LedgerSkills - security-vetted Claude Code skills for finance teams. New skills scanned and tested weekly; subscribe on the site.