EU Machinery Regulation technical file acceptance workflow

Start the acceptance review by freezing the release candidate: product name, type or model, serial or batch logic, intended use, reasonably foreseeable misuse considered by the team, EU economic-operator role, and whether the item is machinery, a related product, or partly completed machinery.

Then record the route decision. If the product is not listed in Annex I, Article 25 points to internal production control. If it is listed in Annex I Part A, one of the notified-body routes is required. If it is listed in Annex I Part B, internal production control is available only when the relevant harmonised standards or common specifications cover all relevant essential health and safety requirements for that category; otherwise use one of the notified-body routes.

A technical file should not pass acceptance because it contains drawings and certificates alone. Annex IV Part A requires documentation showing the means used to ensure conformity with the applicable Annex III essential health and safety requirements.

The reviewer should sample the requirement-to-evidence matrix against the risk assessment. For each applicable EHSR, the file should show the hazard, protective measure, residual risk where relevant, applied standard or other technical specification, and the test, inspection, calculation, or examination result that verifies the design decision.

The standards file must say more than 'EN standards applied'. Annex IV Part A asks for applied harmonised standards or common specifications and, when only parts are applied, the parts that were applied. Where those standards or specifications are not used or are only partially used, the file should describe the other technical specifications used to meet each applicable EHSR.

The release reviewer should also check that user-facing documents match the technical file. Instructions for use, safety information, the EU declaration of conformity, or the EU declaration of incorporation for partly completed machinery must reflect the same product identity, applied standards, residual risks, and route decision.

If the route uses a notified body, the file should contain the body name and identification number, the selected module, application or certificate references, evaluation or audit records available to the manufacturer, conditions or limitations, additions or renewals, and any open corrective-action closure evidence before release.

Software and cybersecurity checks should be explicit for machinery with safety-related software, sensor-fed operation, remote operation, autonomous behavior, digital connectivity, or safety functions that could be affected by accidental or intentional corruption. The acceptance record should show which software is safety-related, how configuration and intervention evidence is captured, and whether any cybersecurity certificate or statement is being relied on for the Annex III corruption and control-system requirements.

Close the workflow with accountable signoff, not a meeting note. Product engineering, safety/risk, quality, regulatory, software or cybersecurity, and legal or compliance reviewers should each sign only the gates they own, with unresolved assumptions converted into release blockers or post-release surveillance actions.