Revenue recognition fraud risk: when and how to rebut the presumption under ISA 240

You're signing off on a file where the team rebutted the revenue recognition fraud presumption with a single paragraph. No per-stream analysis. No engagement with the conditions. Just a boilerplate sentence about "simple revenue streams." That file will not survive inspection.

Under ISA 240.47, auditors must presume that revenue recognition is a fraud risk and either respond with appropriate procedures or, where rebuttal is attempted, document the specific conditions justifying the conclusion for each revenue stream separately, with partner sign-off on every rebuttal decision.

What ISA 240.47 actually requires

ISA 240.47 creates a presumption. The auditor treats revenue recognition as containing a fraud risk unless the engagement team has specific reasons to conclude otherwise. The presumption exists because revenue is the line most susceptible to manipulation across every industry, every size of entity, every audit. It is the single most common area where fraudulent financial reporting occurs.

The standard does not say you must always treat revenue as a fraud risk. It says you must always engage with the question. The distinction matters.

When you accept the presumption, you identify which types of revenue transactions or assertions give rise to fraud risks and design procedures that respond to those risks. When you rebut the presumption, you document why the conditions at this entity, for this revenue stream, make fraud risk sufficiently low that no fraud-specific response is needed for that stream.

Both paths require documentation. The failure mode is the third path: ignoring the presumption entirely, treating revenue as a "standard" risk, and designing no fraud-specific procedures. That is what inspectors find.

What "ordinarily inappropriate" means in ISA 240 (Revised)

ISA 240 (Revised) raises the bar. The extant standard allows rebuttal where the engagement team concludes that revenue types are simple, with limited opportunity for fraud. The Revised standard (effective for periods beginning on or after 15 December 2026) describes rebuttal as "ordinarily inappropriate."

That phrase does not prohibit rebuttal. It shifts the default position. Under the extant standard, rebuttal is permitted with justification. Under the Revised standard, rebuttal is expected to be rare, and the auditor carries a higher burden when attempting it.

Practically, this means two things for your file.

First, the conditions supporting rebuttal need to be stronger than before. A simple assertion that revenue is "straightforward" is not sufficient under the extant standard and falls far short of what the Revised standard requires. You need entity-specific evidence: the nature of the revenue stream, the degree of judgment involved in recognition, the existence (or absence) of side arrangements, variable consideration, bill-and-hold patterns, or channel incentives that create opportunity for manipulation.

Second, partner involvement becomes non-negotiable. The Revised standard's emphasis on rebuttal being "ordinarily inappropriate" means the decision to rebut is one the engagement partner must own personally. A manager-level sign-off is insufficient. The partner's name goes on the rebuttal. That changes behaviour.

Why blanket rebuttal fails inspection

The AFM and FRC have flagged this repeatedly. The most common deficiency is not that firms rebut the presumption. It is that firms rebut it as a single assessment across all of the entity's revenue, without distinguishing between streams that carry different fraud risk profiles.

Consider a logistics company with four revenue streams: freight forwarding (recognised on delivery), warehousing (recognised monthly), customs brokerage (recognised on completion of filing), and performance-based logistics consulting (recognised over time with variable consideration). Treating all four streams identically for fraud risk purposes ignores the obvious differences in judgment, timing, and opportunity for manipulation.

A blanket assessment typically reads: "Revenue is derived from the provision of services. Revenue streams are simple and there is limited opportunity for fraud." That sentence could apply to any service company. It contains no entity-specific reasoning. An inspector reading it cannot determine whether the engagement team actually evaluated anything.

The per-stream approach forces engagement. Each stream gets its own assessment: does this stream involve significant judgment? Does the recognition timing create opportunity for cut-off manipulation? Are there variable elements (bonuses, penalties, volume rebates) that management could exploit? Only after answering these questions for each stream can the team conclude whether to accept or rebut the presumption for that stream.

This is where the structure of your working paper matters. If the template allows a single field for the entire revenue presumption assessment, the team will write a single paragraph. If it requires one row per revenue stream with mandatory fields for each condition, the team cannot take the shortcut.

The four-column structure that forces per-stream evaluation

The ISA 240 fraud risk assessment pack addresses this in the risk register through four linked columns dedicated to the revenue recognition presumption.

The first column requires the engagement team to engage with the presumption for every risk entered in the register. This is not limited to revenue risks. For every fraud risk, the team must state whether it relates to revenue recognition. The column prevents the presumption from being overlooked simply because the team focused on other fraud risks first.

The second column activates when the team attempts a rebuttal. It becomes mandatory: the engagement team must document the specific conditions that support rebuttal. These are not free-text fields with no guidance. The column requires the team to address the conditions specified in the standard (limited types of revenue, simple recognition, limited opportunity for fraud) with entity-specific evidence. A generic statement does not satisfy the field.

The third column is where blanket rebuttal dies. It requires a revenue-stream-by-stream analysis. The team cannot enter a single assessment across all revenue. Each stream requires its own row, its own evaluation, its own conclusion. If the entity has four revenue streams, the register contains four assessments. If rebuttal is appropriate for warehousing revenue but not for consulting revenue, the documentation reflects that split.

The fourth column requires the engagement partner's personal sign-off on any rebuttal decision. Not the manager. Not the senior. The partner. This column sits at the end of the chain deliberately: the partner signs only after reviewing the per-stream analysis and the conditions assessment. If the analysis is thin, the partner's signature exposes the partner personally.

Together, these four columns create a documentation chain that mirrors the standard's requirements: engage with the presumption, evaluate conditions, analyse per stream, obtain partner approval. Skipping a step is visible because the column is empty.

Worked example: Dijkstra Logistics B.V.

Entity: Dijkstra Logistics B.V., a Dutch logistics group with €87M revenue across four streams: freight forwarding (€41M), warehousing (€23M), customs brokerage (€12M), and performance-based logistics consulting (€11M). Year end 31 December 2025.

1. The engagement team populates the risk register with a revenue recognition fraud risk linked to ISA 240.47. The first presumption column confirms engagement: this risk relates to revenue recognition. Documentation note: risk register row records the risk as "Revenue recognition fraud risk per ISA 240.47" with source cross-references to the team discussion tab and the fraud risk factors tab.

2. The team decides to evaluate rebuttal for each stream individually. For freight forwarding (€41M), the team notes: point-in-time recognition on delivery, BOL documentation, limited judgment in timing, no variable consideration. Rebuttal conditions assessed as met. Documentation note: revenue stream analysis column records "Freight forwarding. recognised on delivery per signed BOL. No variable consideration. No bill-and-hold. Cut-off risk exists but is an error risk, not a fraud risk at this entity given absence of revenue targets tied to delivery timing."

3. For warehousing (€23M), the team notes: monthly recurring invoicing against fixed contracts, no judgment in amount or timing. Rebuttal conditions assessed as met. Documentation note: "Warehousing. fixed monthly fee per contract. Invoiced in arrears. Amount determined by contract with no variable element. Recognition is mechanical."

4. For customs brokerage (€12M), the team notes: recognised on filing completion, but 8% of revenue relates to penalty-avoidance bonuses paid by clients when Dijkstra meets filing deadlines. The bonus element introduces variable consideration and judgment about whether deadline performance conditions are satisfied. Rebuttal conditions not met for this stream. The team retains the presumption and designs fraud-specific procedures for the bonus revenue component. Documentation note: "Customs brokerage. base fee (€11M) is simple, but performance bonus component (€1M) involves management judgment on deadline satisfaction. Presumption retained for this stream. See response matrix for fraud-specific procedures."

5. For consulting (€11M), the team notes: over-time recognition using percentage-of-completion with management estimates of total project hours. Significant judgment in both the estimate and the measurement of progress. Rebuttal conditions clearly not met. Documentation note: "Consulting. percentage-of-completion recognition. Management estimates total hours; actual progress measured against estimate. Variable consideration (performance fees on 3 of 7 active projects). Presumption retained."

6. The engagement partner reviews all four stream assessments, approves the rebuttal for freight forwarding and warehousing, and confirms that the presumption is retained for customs brokerage and consulting. The partner signs the fourth column with date. Documentation note: "Partner sign-off: rebuttal approved for freight forwarding (€41M) and warehousing (€23M). Presumption retained for customs brokerage (€12M) and consulting (€11M). Fraud-specific responses designed per response matrix rows [linked references]."

The result: two streams rebutted with entity-specific justification, two streams retained with fraud-specific procedures designed. A reviewer can trace the logic from each stream through the conditions assessment to the partner's decision. No blanket language. No boilerplate.

Practical checklist for revenue presumption documentation

1. Before rebutting, identify every distinct revenue stream the entity recognises and list them separately in the risk register. Do not group streams together unless they share identical recognition methods, timing, and judgment characteristics (ISA 240.47).

2. For each stream where rebuttal is attempted, document the specific conditions: nature of revenue, simplicity of recognition, degree of judgment, presence or absence of variable consideration, side arrangements, or channel incentives. Generic language fails this test.

3. Confirm that the rebuttal analysis addresses opportunity, not just complexity. A revenue stream can be "simple" in recognition method but still carry fraud risk if management has incentive and opportunity to manipulate timing or cut-off (ISA 240.A59).

4. Obtain the engagement partner's personal sign-off on each rebuttal decision. Under ISA 240 (Revised), a manager-level approval is not sufficient given the "ordinarily inappropriate" characterisation of rebuttal.

5. Where the presumption is retained (even for one stream), confirm that fraud-specific procedures are documented in the response matrix and cross-referenced back to the risk register row.

6. On every engagement, document the presumption engagement even when rebuttal is not attempted. The file must show that the team considered the question, not just that revenue appeared in the risk register.

Common mistakes

• Treating the presumption as binary across all revenue. The AFM's inspection findings consistently flag files where the entire entity's revenue is assessed in one paragraph, with no distinction between streams carrying different risk profiles.

• Confusing "simple revenue" with "low fraud risk." A construction company recognising revenue over time may have a straightforward percentage-of-completion method, but the estimates underlying that method create significant opportunity for manipulation. Simplicity of method does not equal absence of fraud risk.

• Documenting rebuttal without partner sign-off. PCAOB inspection reports have cited files where the rebuttal decision was made at the manager level with no evidence of partner engagement, despite the standard requiring the engagement partner to evaluate the presumption.

Related content

• ISA 240 glossary entry. Explains the core ISA 240 framework, including the fraud triangle and the required engagement team discussion.
• ISA 240 fraud risk assessment pack. The working paper template that enforces per-stream revenue presumption analysis with four linked columns in the risk register.
• How to build a fraud risk response matrix that links every risk to a procedure. Explains how identified fraud risks (including retained revenue recognition risks) flow into specific audit responses.