IT project acceptance: recording defects and comments

Materials required

• contract, technical specifications, detailed technical specifications, annexes and acceptance certificates;
• correspondence between the parties and comments on acceptance;
• logs, exports, screenshots, links and technical documentation;
• questions formulated for the specialist or court.

What is assessed

The examination assesses the actual condition of the deliverable, compliance with technical requirements, defects, causes of failures, the volume of completed work and the relationship between the findings and the documents in the dispute.

Why checks are needed before signing an acceptance certificate

After signing an acceptance certificate, a client may find it harder to rely on obvious shortcomings. Technical acceptance checks key scenarios, documentation completeness and handover of the necessary access in advance.

What to include in the verification program

• functions expressly specified in the technical specifications;
• load testing and critical user scenarios;
• data exchange with external systems;
• backup and restoration;
• source code, instructions, access credentials and documentation.

How to document comments

Each defect should preferably be described with reproduction steps, expected and actual results, date, system version and supporting materials.

Outcome of acceptance support

The client receives a structured list of comments, an assessment of compliance with requirements and a technical basis for a reasoned acceptance decision.

How work with a specialist proceeds

First, the task and available materials undergo a preliminary review. The examination subject, technically appropriate questions, required access and deliverable format are then agreed. If the initial data are insufficient, the specialist identifies in advance which additional files, documents or exports must be preserved.

The final opinion distinguishes the information provided, actions performed, indicators established, limitations and conclusions. This structure makes the reasoning verifiable and enables the document to be used in a formal claim, negotiations or court proceedings.

When to seek advice in advance

The earlier original data are preserved, the lower the risk of loss or alteration. Before reinstalling a system, updating software, clearing logs or handing a device over for repair, it is advisable to discuss how the materials should be recorded.

Expanded on 21 October 2026

Make the defect reproducible under agreed conditions

For each comment, specify the version, environment, user role, initial data, action sequence, expected result and actual result. Saying “it does not work” does not establish the scope of the problem. A test on a different application version may concern a different project state.

Link the comment to a requirement

Identify the clause of the agreed specification, change request or other document establishing the expected behavior. If the requirement's meaning is disputed, disclose this; a technical check must not silently choose one contractual version.

• Preserve original logs and recordings, rather than only cropped messages.
• Record fixes, repeat checks and package contents.
• Do not disclose active secrets in an openly accessible error description.
• Distinguish defects, requests and hypotheses that cannot be checked.

Before updating or reconfiguring, preserve the relevant state where possible. This helps examine the disputed version without attributing results obtained from a corrected product to the earlier deliverable.

On this subject: Logs and backups: what to preserve before changing an IT system.