The document set is the product in a medical power program: certificates and test reports establish what was tested, and batch records establish what shipped. The fastest way to evaluate a supplier is to review that set against three things — the certificate, the model and the configuration. This guide explains the difference between certificates and test reports, the model-match rule, a ten-minute review sequence, batch traceability, and a document checklist template.
Key takeaways
- Certificates summarize the tested configuration; test reports contain the results.
- The model-match rule — every document naming the exact SKU and configuration — is the core check.
- Batch records connect the certificate to the shipment that actually arrived.
Content updated: August 2026 — confirm current standards editions and model-specific details before ordering.
Scope note: This guide is industry information, not regulatory, legal or certification advice; standards applicability is confirmed per configuration.
Certificates vs Test Reports: Know the Difference
A certificate states that a configuration passed the applicable tests and names the standard edition; a test report contains the detailed results behind that statement. Both are needed for an audit: the certificate gives the summary, the report gives the evidence.
The distinction matters because a certificate without a report is a claim, and a report without a certificate is data without a conclusion. Buyers should request both, and check that they name the same model and configuration.
In practice, the two documents are produced at different moments and by different parties. The test report comes from the laboratory that ran the tests; the certificate is issued on the basis of that report. That is why the report is the deeper evidence: it contains the measured values, the test conditions and the configuration under test. A buyer reviewing only the certificate is reading the summary; the report is where the details live, and the details are what an audit asks for.
The date on both documents matters as well. Standards are revised, and the edition cited in the report must match the edition the market requires. An old report with a current certificate, or the reverse, should trigger a conversation about currency before the configuration is accepted.
The Model-Match Rule Every Buyer Should Use
The model-match rule is simple: every document must name the exact configuration you are buying — ports, plugs, output profiles and standard edition. A certificate for a similar model is context, not evidence, because certification describes a tested configuration.
Three checks apply the rule:
- Model number on the certificate matches the SKU.
- Configuration — ports, plugs, output — matches the order.
- Standard edition matches the market requirement.
When any of the three fails, the document set does not cover the product, and the order should not proceed on that evidence.
The model-match rule is easy to state and easy to skip under schedule pressure. The skip is where the risk concentrates: a certificate for a similar model, a configuration with an extra port, a plug variant that was not tested. Each skip looks small at order time and becomes a compliance gap at audit time. The rule is enforced by habit, and the habit is built by checking the three fields on every document, every time.
The rule also applies to reorders. The configuration may have been updated since the first order, and the certificate may have been refreshed for a new edition. The reorder check is the same three fields against the current documents, not a repeat of the original review.
Reviewing a Certificate Package in 10 Minutes
A ten-minute review follows a fixed sequence:
| Minute | Check |
|---|---|
| 1–2 | Model number and configuration match the SKU |
| 3–4 | Standard edition and market requirement match |
| 5–6 | Test report covers the same model and configuration |
| 7–8 | Isolation, leakage and EMC results align with the classification |
| 9–10 | Batch records exist for the shipment or reorder |
The sequence turns a folder of documents into a decision. What fails the sequence is what should stop the order.
The ten-minute review works because it does not attempt to re-verify the engineering; it verifies the alignment between the documents, the configuration and the market. Engineering verification is the laboratory’s job; alignment verification is the buyer’s job. Keeping the two separate is what makes the review fast and reliable.
The same sequence serves as a supplier self-check. A supplier that packages the document set in this order — certificate, edition, report, results, batch — makes the buyer’s review trivial and shortens the sales cycle. The document set is part of the product, and a well-packaged set is a competitive advantage.
Batch Traceability and Reorder Evidence
A certificate describes a design; batch records describe a shipment. The two are connected by traceability: the batch number on the shipment should link to the records of what was tested and inspected for that batch.
For reorders, the same evidence should travel: batch records, shipment inspection results and a confirmation that the configuration matches the approved sample. A reorder without fresh evidence is starting over, not continuing.
Traceability also feeds the change-management story. When a field issue appears, the batch number connects the affected units to their records, and the records show what was tested and when. Without the link, every unit is a candidate for the problem and every customer conversation starts from scratch. The traceability chain is the program’s memory, and it is built one shipment at a time.
The chain is only as strong as its weakest record, which is why the batch records are reviewed at receipt rather than filed unread. A batch number that cannot be matched to records, or records that name a different configuration, is the same warning sign as a certificate that names a different model. The review habit is the same in both cases: verify the match before accepting the shipment.
A Document Checklist Template
The checklist for a medical power program:
- Type-test certificate naming the exact configuration and standard edition.
- EMC test report for the same configuration.
- Isolation and leakage data matching the classification.
- Risk-management evidence appropriate to role and contract.
- Batch records for the specific shipment.
- A change log showing what changed and who approved it.
The template is the same across programs; the documents inside it must be program-specific.
The template doubles as a gap detector. When a program walks the checklist and finds a missing item, it has found the risk before the audit does. The answer is rarely “skip it” — it is to ask for the item, or to document why it does not apply to the configuration. Either way, the checklist turns a vague document folder into a named, verifiable set.
Keeping the template versioned helps programs compare candidates on the same basis. When every supplier is asked for the same set, the comparison is apples to apples, and the choice is a decision rather than a negotiation of what evidence is enough.
The template also supports the reorder process. A versioned checklist from the approved order becomes the baseline for the next order: the same fields are checked against the current documents, and any drift is caught at the review instead of at the audit. Programs that treat the checklist as a living file find that reorders become repeats rather than new projects, which is the difference between a program and a series of purchases.
The documentation discipline described here is the same discipline that runs through the medical power cluster: certificates and reports name the configuration, batch records connect the design to the shipment, and the file is kept current. When that discipline is in place, the document set stops being paperwork and becomes the program’s evidence, available for audits, reorders and field issues alike.
When the next step is document review, the GaN Charger Category at WECENT provides the platform map by power and ports to anchor the request, and the Quality Control page describes how production testing and records work at the factory level. To review the document set for a candidate configuration, request it from WECENT’s project engineering team — share the device list and target markets, and the review returns the model-specific certificates and reports that apply to your exact program.
Frequently Asked Questions
What is the difference between a certificate and a test report?
A certificate summarizes the tested configuration and standard edition; a test report contains the detailed results. Both should name the same model and configuration.
Why does the model number on the certificate matter?
Because certification describes a tested configuration. If the certificate names a different model or configuration, it does not cover the product you are buying.
How long does it take to review a certificate package?
With a fixed sequence, about ten minutes per package: model match, standard edition, report coverage, results alignment and batch records.
What should I do if a document is missing?
Do not proceed on partial evidence. Ask for the missing item, or for a written explanation of why it does not apply to the configuration — then decide.
Do batch records matter for every reorder?
Yes. A certificate describes a design; batch records describe a specific shipment. Reorders need their own records to stay traceable.