Quick quiz: Under the fraud standards (ISA 240/AU‑C 240/PCAOB AS 2401), what are the two presumptions we must address on every engagement? I’ll start: revenue recognition as a fraud risk and management override of controls, with required journal-entry testing and a retrospective review — I caught a team skipping the override workpaper on a 12/31/2025 year-end and shut it down fast.
I always script the JE extraction and attach the SQL in the override workpaper, then filter for late-posted entries with descriptions like “plug” or “adj” and any admin-user postings — that’s where I’ve found the cleanest override evidence. In SaaS, I also sweep manual credit memos and price concessions posted after close because they quietly rewrite revenue.
For override, I lock the JE population first: on “12/31/2025” year-ends I export a read-only GL with user/timestamps, compute a SHA‑256 hash, and drop the hash in the override workpaper so any reopened postings show up before we test entries. It’s five extra minutes but saves fights when someone swears the period was locked. Do you freeze or hash the population before selection?
On 12/31/2025 year-ends, I run a day-by-day cutoff analytic comparing the last 10 business days of December to the first 10 of January, then vouch any spikes to shipping/BOLs rather than invoices. It surfaces classic bill‑and‑hold and “parked” revenue without fancy tools — just Excel pivots and a weekday adjustment. Seasonal clients need a prior‑year baseline, though — do you anchor to t‑1 or a rolling 28‑day window?
I add a KPI-threshold scan on override: recompute the nearest covenant/bonus metric and flag any top-side entries posted within three days of the measurement date that move EBITDA or revenue by >0.5%, then trace each to approval and the board deck; if volatility’s high, I widen the window or lower the threshold. @OP do you tie JE testing to covenant dates, or keep it period-end only?