Revenue cut-off: follow delivery, not the invoice date

A cut-off test checks that income is linked to the correct period. I wouldn't reduce it to comparing invoice date and end of year. The timing of recognition depends on the contract, obligations and applicable accounting framework. For a sale of goods, the conditions of delivery and transfer of control may be decisive. For a service, you must understand the benefits and the conditions of recognition.

An error can affect revenue, cost of sales, receivables, merchandise inventory and taxation. Transactional risk therefore exceeds EBITDA. The professional must understand the consistent effects and present them according to the mandate, without adding the same impact several times in the bridges. Cut-off procedures must also distinguish one-off errors from systematic closing practices.

If IFRS 15 applies, the analysis relates in particular to the satisfaction of performance obligations and the transfer of control. It should not be applied to a target whose accounts follow another accounting framework without examination. I would read the commercial conditions, proof of delivery and any acceptances from the customer. The date of payment does not, in itself, determine the time of recognition of income.

You need to know the closing procedures: who triggers invoicing, what data controls the accounting, how are late deliveries and credit notes processed? Technical extraction without understanding the flow can select the wrong populations. Close-to-the-close handwriting and unusual variations are leads, not evidence of manipulation.

I would select transactions before and after the cutoff date, taking into account the actual delivery or service cycle. The extent depends on materiality, risk and data. It is necessary to reconcile the extraction with the accounting, keep the exclusions and specify what the sample allows us to conclude. A selection based only on the largest bills may miss repeated practice on small amounts.

Tests should examine transactions in both directions: anticipated revenue and incorrectly deferred revenue. Subsequent credit notes may reveal returns, errors or trade adjustments; their cause must be understood. I wouldn't automatically deduct them all from December income. The analysis must relate each element to the operation and period concerned.

A sale of 120 k€ is invoiced on 29 December. The contract and supporting documents show, in this example, a transfer of control upon delivery on January 4. The associated cost is 75 k€. If these conditions and the accounting framework confirm recognition in January, revenue and cost must be moved together. The December result falls by 45 k€, not by 120 k€.

I would check the treatment of receivables and inventory of goods at the same closing as well as the entries already made after closing. The illustrative calculation does not resolve all the tax effects or the definitions of the SPA. The historical correction must be presented and its possible impact on the transactional balance sheet must be examined separately, with double counting checked.

If the contract provided for another transfer time, the conclusion could change. Proof of delivery alone is not universally determinative. This is why the file must retain the relevant clause and reasoning, rather than just a “January delivery” flag. An exception must be able to be understood by a second reviewer.

I would distinguish between identified errors, exposure of the dataset and limitations of the procedures. A projection may require a defensible method; multiplying an observed error rate on a targeted selection is not automatically appropriate. If several similar deviations appear, additional work or a reservation may be necessary. The report should explain what was tested.

The discussion with management can clarify a clause or an operational flow. The new supporting documents must be preserved and compared with the first sources. The final check verifies that the figures used in QoE, trading and balance sheet are consistent. A correction that disappears in one version of the report but remains in a bridge can distort the restitution.

Extracting dates and clauses can speed up preparation. I would test multiple dates, scans, amendments and different delivery clauses. The tool must indicate the source and make it possible to recognize missing information. A date extracted without connection to its function can produce a false but apparently accurate test.

To evaluate a Solenor workflow, I would ask for a chain of proof going from the contract to the calculation and the decision. The conclusion is based on the accounting framework and the facts established by the team. Procedures must be proportionate to the risk and remain reproducible outside of a narrative response.