A SaaS customer has not signed acceptance: prepare the revenue review

Find the contract language describing acceptance, the relevant deliverable and the customer's remedies. Record who can accept, how acceptance is communicated and whether a response period or objective test applies. Keep legal interpretation with the appropriate adviser. Finance needs an accurate statement of the terms before deciding what an absent signature means.

The customer-acceptance guidance in NZ IFRS 15 distinguishes objectively verifiable compliance from cases where compliance cannot be determined without customer acceptance. That is a reason to investigate the facts carefully. It is not a rule that every unsigned document blocks revenue, or that product access makes every acceptance condition irrelevant.

Ask the implementation owner to list the agreed requirements and evidence for each. Record test results, delivery dates, open defects and any customer statement that the service is unsuitable. Describe whether an issue prevents the promised use, affects a separate deliverable or reflects an additional request outside the original scope. Avoid replacing that detail with a single project status color.

A customer may use part of the application while waiting for an integration, migration or security requirement. Preserve that mixed fact pattern. Usage logs can support availability or activity, but they do not explain every contractual condition. Equally, a missing administrative signature should be distinguished from an explicit rejection when the evidence supports that distinction.

Collect the invoice, payment status, activation record and acceptance correspondence in one packet. Mark their dates separately. A customer paying in advance may still have unresolved acceptance rights; an unpaid invoice may relate to work that has already met the agreed delivery conditions. Ask accounting to evaluate the relevant framework instead of using cash receipt as a substitute for the assessment.

For an illustrative implementation, the customer could complete its tests on March 28 and return a signed form on April 4. Another customer could reject the same milestone on March 28 because required functionality is missing. Both files lack a March signature, but their evidence differs. The reviewer should explain which facts support the conclusion for each contract.

Request a short assessment that identifies the acceptance condition, evidence reviewed, unresolved facts and accounting conclusion. If work remains, name the person responsible and the event that will trigger a new review. If the conclusion relies on objective evidence, retain that evidence in a durable form with its preparation and review dates.

Preserve subsequent correspondence without backdating it. A later acceptance may provide information about earlier conditions, or may reflect work completed later. Give the accountant the actual sequence and let the reviewer assess its effect on the reporting period. Keep any journal adjustment connected to the contract and prior assessment.

Work with delivery and sales teams to define evidence at the start of a project. A useful milestone describes the promised output, a testable completion condition and the authorized recipient. It also explains how unresolved defects are recorded. This helps the customer understand the work and reduces the chance that month-end becomes a search through personal inboxes.

Review the first few completed files after changing the process. Ask whether another employee can understand the delivery state without interviewing the original project manager. If the answer is no, improve the evidence template and ownership. Keep the accounting conclusion specific to the contract; a better operational checklist supports judgment but does not replace it.