Your supplier's certificate may not actually cover your pack

A certificate covers your pack only when the manufacturer name, part number, configuration, and issue date printed on it match the exact assembly you are buying. In practice, most compliance packets that land on my desk fail at least one of those four checks, and the failure is almost never visible from the cover email. Verification is not the same activity as collection: it means opening the PDF, reading the model string against your drawing or purchase order, confirming the lab that issued any test report is accredited for the method it cites, and checking that the revision in front of you has not already been superseded.

Last month I had four PDFs laid out across a hotel-room desk — a certificate of compliance on manufacturer letterhead, a UN 38.3 test summary, a safety data sheet, and a third-party safety report with a lab mark in the corner — a red pen in one hand and the purchase order open on the laptop beside them. The packet was complete. Complete is the least useful word in this line of work.

Here is how I go through it.

The model string decides everything

I start with the part number, not the company name. I read it out loud, character by character, against the model on the PO and the model on the drawing.

Say the PO reads 14S4P, 48 V nominal, 10.4 Ah, XT60, integrated BMS. The certificate says the model is BP-4810. No series/parallel designator, no capacity. That is where the first real decision happens: is BP-4810 the thing on the PO, or is it the family that the thing on the PO belongs to? Both are possible. Factories routinely run one internal model number across a family of configurations, and a certificate issued against the family number does not by itself cover a specific member of that family.

Family numbers can be made to work. What makes them work is a configuration list attached to the certificate that names your build — cell make and model, cell count, series and parallel arrangement, BMS part number, enclosure, connector, and any protection feature that has changed. If the certificate cites a family number and nobody will produce that list in writing, you are not covered, no matter how official the letterhead looks.

Most of the time the mismatch is not dishonesty. It is version drift. Someone swapped a cell for an equivalent one, or changed a connector, or went from 13S5P to 14S4P mid-program, and the paperwork stayed where it was because the product still carried the same name. The document did not lie. It just stopped describing the thing.

Dates do different jobs, and that is where people get caught

Every document in the packet carries a date, and each one means something different. A certificate has an issue date and sometimes a validity window. A test report has the date testing was performed and usually a report revision. A safety data sheet has a revision date and a revision number. A cell datasheet has its own revision level. Treating all of that as one date is how careful buyers get fooled.

The trap I see most often is a fresh certificate sitting on top of an old report. A supplier can generate a current one-page certificate of compliance today that points at a test report from two years ago, on a configuration that has since changed. New paper, stale evidence. The certificate is not wrong about itself; it just inherits whatever staleness is underneath it. I always follow the citation down to the report.

The safety data sheet is the other one that bites. Carriers and receiving docks look at the SDS revision before almost anything else in the packet. If the revision on the sheet does not match the cell actually in the pack — different chemistry, different watt-hour rating — it is the wrong document even if it is dated yesterday. The UN 38.3 test summary tends to hang off that same cell and configuration, so when one moves, the other usually has to move with it.

Checking the lab is a two-minute step people skip

Third-party reports come from accredited laboratories, and accreditation is scoped. A lab can hold accreditation for one test method and not another, which means the report number and the accreditation mark can both be genuine while the report still sits outside the scope it is being used to prove.

The routine is short. Find the accreditation mark on the report, note the lab's accreditation number, look that number up in the issuing accreditation body's public directory, and confirm the listed scope covers the standard the report cites. If the lab does not appear in the directory at all, you have your answer and you can stop. If it appears but the scope does not reach the method, you also have your answer.

Then read the device-under-test block. It usually lists the exact model, the ratings, and sometimes the cell. If the DUT says 13S5P and you are buying 14S4P, the report describes a different device, and no amount of same-sounding product name fixes that.

A self-declaration is evidence of a different weight

A supplier's declaration of compliance is a self-declaration. It is a statement about the product, made by the party that benefits from the product, and it carries a different evidentiary weight than a report issued by a lab that tested a sample. That does not make it worthless. Plenty of programs accept declarations for some documents, and sometimes a declaration is all that exists for a low-volume or benign build. It does make it a different object. I keep declarations in their own section of the register so that nobody accidentally treats a stack of them as a tested report six months from now.

The label on the pack is part of the file

Pack marking is not cosmetic. Model designation, voltage and capacity ratings, caution text, and manufacturer identification get read by inspectors, carriers, and customers against the test summary and the report. So on first-article inspection I photograph the label and put it on the same page as the DUT block from the report. When the label reads 48 V / 10.4 Ah and the report reads 48 V / 9.6 Ah, one of them is wrong, and it is usually the label, because a template got reused after the build changed.

Keep the register alive after the file is complete

Documents get requested years after shipment. A customer audit or a carrier question arrives long after the program engineer who sent the packet has moved on. Test summaries and reports are normally retained for the life of the program, and I keep a one-page register alongside them: document type, document number, revision, issue date, expiration if there is one, the configuration it covers, and where the file lives.

That register earns its keep on change orders. When we move a cell or swap a BMS, the register tells me exactly which documents just went stale, instead of me trying to remember. Name the files so the model and the date are in the filename. Nothing has ever been found faster because it was called Compliance Packet Final v2.

Where it actually breaks

Three patterns account for nearly everything I catch. A family part number with no configuration list behind it. A current certificate resting on a superseded report. A pack on the line that has drifted from the pack in the report.

None of those are automatically safety failures. They are documentation failures with a compliance consequence, and they all end the same way — with a buyer sending one sentence back: we need the current report for this exact build.

One honest limitation: not every build has an independent test report, and not every destination or customer requires one. Some programs accept a manufacturer's declaration and are fine doing so. The decision depends on the application, the destination, the carrier, and the customer's own specification. Verification is not a rule that says nothing short of a full report counts. It is knowing which document you are holding, what it covers, and what it leaves uncovered, before somebody else asks you the question on a schedule you did not choose.

Print the packet. Read the model string out loud. Twenty minutes, most days.