In most certification projects, the testing is not what causes the delay. The test plan is agreed in a day or two, the slot on the schedule is booked, and then the project sits still for a week because the manual is not finished, the BOM describes a different product from the samples on the bench, or nobody can find the antenna specification. The documents are the part of the project that clients underestimate, and they are the part that decides whether the report can be issued cleanly at the end.
This article lists the documents a laboratory normally asks for, explains what each one is actually used for - which makes the requests easier to answer - and describes what happens when one of them is missing or out of date.
The core document set
For almost every electronic product, regardless of market or directive, the laboratory works with these files:
| Document | What the laboratory uses it for | What goes wrong without it |
|---|---|---|
| Specification sheet / datasheet | Building the test plan: rated voltage, power, interfaces, operating modes | The quotation is built on guesses, and the scope changes once the real product is seen |
| User manual (final version) | Referenced by the test report and the technical file - accessories, ratings, warnings, intended use | The report cites a manual that no longer matches the shipped product, and the file has to be corrected later |
| Bill of Materials (BOM) | Identifying material groups for RoHS sampling, checking the tested configuration, worst-case analysis | Sampling misses parts, or the samples turn out to be a different product from the paperwork |
| Schematics and block diagram | Understanding circuits before EMC testing, and diagnosing a failure if one occurs | An EMC failure becomes a guessing game, and debugging time is billed while the lab probes blind |
| PCB layout drawings | Locating clock sources, switching regulators and antenna traces when emissions are high | Failure analysis takes far longer than it needs to |
| Label artwork | Checking mark, model number and responsible-company details against the applicable rules before the report is issued | A label problem is found after testing instead of before, when fixing it is still free |
| Product photos and full model list | Connecting the report to the product and covering every variant you intend to sell | A model you sell is not covered by the report, or the model numbers do not match what the buyer sees |
Two of these deserve a closer look, because they cause the most arguments.
The manual has to be the version that ships
The test report and the technical file reference the manual: the accessories listed in it, the input ratings, the warnings, the intended use. If the manual sent to the laboratory is a draft and the production manual ends up different - a new accessory added, a rating changed, a warning removed - the report is describing a product configuration that no longer exists. The fix is a file correction, which costs time and sometimes money, on a project that was technically finished.
A draft is acceptable for starting the project, as long as the laboratory knows it is a draft and the final version arrives before the report is issued. The failure mode is not "draft" - it is "final manual quietly changed and nobody told the lab".
The BOM and the samples have to be the same product
Laboratories test what arrives on the bench, not what the drawing says should arrive. When the battery, the display module, or the power adapter in the samples differs from the BOM, one of two problems follows: either the report describes the sample, which is not what production ships, or the mismatch is discovered mid-project and the configuration has to be resolved before testing continues. Both are more expensive than checking the BOM against the samples the day before they ship.
Extra documents for radio products
If the product contains a radio - Bluetooth, Wi-Fi, a proprietary 2.4 GHz link, cellular - the document set grows:
- Radio operation description: every radio mode the product supports, with frequency bands, modulation and transmit power. Every mode, not only the one you plan to market. A device that supports Bluetooth and a second 2.4 GHz mode is a two-mode product, and the file is incomplete until both are covered.
- Antenna specification: antenna type and gain. The antenna is part of the radio configuration, and a changed antenna changes the results.
- Module documentation: if a pre-certified radio module is used, its datasheet, the host board design guidance, and the module's own approval documentation. Using a certified module simplifies things, but it does not remove the product-level documentation.
- Firmware version: radio behaviour depends on firmware. The report will state the version tested, and a significant firmware change to the radio can require a reassessment.
The radio mode list is worth repeating. In real projects, the enquiry says Bluetooth, the sample turns out to run a second mode, and the project grows a test item in the middle. Declaring every mode in the first email is the single cheapest way to keep a radio project on its original quotation.
What actually happens when a document is missing
Nothing dramatic, which is why it keeps happening. The consequences are quiet and cumulative:
- The quotation is built on incomplete information. The scope is revised once the real configuration is visible, and the price moves. Documents sent with the first enquiry are the reason a first quote holds. (This is also why two quotes for "the same product" differ - see what a CE testing quotation actually pays for.)
- Testing pauses. EMC and radio engineers work from schematics and operation descriptions. When a failure appears - and with new boards, sometimes it does - missing schematics turn a one-day diagnosis into a week of probing.
- The report cannot be issued. A test report references the manual, the model list and the configuration. If any of them is unresolved at the end of testing, the report waits for the document, not for the test.
- The Declaration of Conformity cannot be signed correctly. The DoC lists the directives and standards applied to the product as described in the technical file. An incomplete file means the manufacturer cannot honestly sign it, and the buyer's compliance review will find the gap.
One reassurance on confidentiality: schematics and firmware are handled under the laboratory's standard confidentiality terms. Refusing to send them does not protect the design - it only guarantees that any EMC problem will be slower and more expensive to fix.
A one-message checklist to send with the samples
Everything a project needs can be sent in one email. Before samples ship, hand the laboratory:
- Specification sheet, and the full model list including every variant you intend to sell
- The user manual - marked as final or draft, so the laboratory knows which it is
- BOM, checked against the samples actually being shipped
- Schematics and block diagram (PCB layout if available)
- Label artwork, if it exists - a review before printing costs nothing
- Product photos
- For radio products: every radio mode with frequencies, modulation, transmit power, antenna type and gain, module documentation, firmware version
- For products with an adapter or battery: the exact adapter model and rating, the battery type and capacity
The same list, sent with the quotation enquiry instead of after it, is what makes a first quote accurate - and it connects to the other end of the process, because these are the documents a buyer or marketplace eventually asks to see. Our overview of certifications for selling electronics in Europe covers that side.
We review document sets as a standard part of every project - it is faster to fix a manual or a label before testing than after the report. The testing and certification services page shows the markets we cover, and if you want a second pair of eyes on your paperwork before the samples ship, the details are below.
If you are preparing a submission and not sure whether your document set is complete, send your manual, specification sheet and BOM before the samples ship.
We will check which documents are missing, which versions are out of date, and what the radio and power configuration will add to the test plan - so the project does not stop in the middle.