The Certificate Check That Stops a Custom Battery Pack from Failing Qualification

Before a custom pack moves into qualification, pull the certificate packet and read it against the RFQ line by line: the certified part number or covered model family, the cell model and internal construction shown in the test report photographs, the BMS firmware revision that was actually tested, the standard edition cited, and the issuing laboratory's ISO/IEC 17025 scope for that specific standard all have to match the pack you intend to buy. One mismatch in that set is a stop, not a note for later.

I do this at a desk with the certificate open on one side of the screen and the supplier's RFQ response on the other, because reading them one after the other instead of side by side is exactly how the mismatches survive. The packet usually arrives as five or six PDFs with names like Certificate.pdf, Test Report Final.pdf, and UN38.3 Summary. The sales contact sends the one-page certificate because that is what they have been trained to send. The report with the construction photos and the firmware revision sits behind an NDA request. You have to ask for it by name, and you have to ask before the sample build, not after.

Here is what I am actually looking at when I open that first page.

The scope page tells you what was tested, not what the supplier sells

Most buyers treat the certificate as a yes or no question. Do you have UL? Do you have IEC? Filed, next. That reading is why packs fail qualification three months later when someone finally compares the paperwork to the build.

A certificate is a boundary document. It describes one tested configuration and everything inside that boundary is supported by evidence. Everything outside it is not. My first move is to find the model line and read it character by character. I have seen a certificate for a pack family listed as a base number while the RFQ called out a variant with a different suffix, and the supplier's position was that it was basically the same product. It might be. It was not certified. Those are different statements and only one of them belongs in a qualification file.

Some certificates cover a family of models with a table of ratings, cell counts, and enclosure options. That is legitimate and common. But the table is the thing you read, not the headline. If the family table lists a 10S configuration with an aluminum enclosure and your RFQ is 13S in a PC/ABS housing, the certificate does not reach your part. I copy the family table into the qualification file and mark which row we are buying. If there is no row for us, we are outside the scope and the supplier needs to test or we need to change the requirement.

One more thing on the same page: the certificate holder and the manufacturing site are often not the same entity. A brand owner can hold the certificate while a contract manufacturer builds the pack. Check that the site listed is the site you audited. If the certificate names a plant you have never seen, you have learned something about where your pack might actually come from.

The edition number is where quiet problems live

Standards get revised. A certificate that cites a superseded edition is not automatically worthless, but it is a question you now have to answer in writing: was this tested to the edition that is current, and if not, what changed between them that matters to your design?

I look for the full designation, including the year. On lithium pack work that usually means a pack-level standard, a cell-level standard, and often a transport standard, and each one has its own edition history. When a supplier sends a certificate with a year that is two revisions old, I do not argue about validity. I ask a narrower question: send the test report and tell me which edition the tests were run under. Sometimes the report and the certificate disagree, and that disagreement is the finding.

The same discipline applies to the cell. If the RFQ specifies one cell model and the certificate was issued against a pack built with a different one, nothing else on the page matters until that is resolved. Cell substitution is the single most common cost-driven change in this industry and the paper trails lag it by months.

Check the lab, not just the logo

Every accredited laboratory carries a scope document that lists which standards it is accredited to test. The scope is searchable and public. Find the lab named on the report, pull the scope, and confirm the specific standard and the specific test clauses appear there.

This is not a gotcha exercise. Most of the time it checks out cleanly and takes four minutes. The times it does not check out are interesting: the lab is accredited but the scope covers a related standard rather than the one cited, or the testing was performed at a different site than the accredited one, or the report was issued by a subsidiary whose accreditation does not extend to that work. None of that means the tests were not run. It means the evidence is weaker than the certificate implies, and you should know that before you write the qualification report, not after a field return.

The report photos are a build fingerprint

The test report should show or describe the pack as tested. Photographs of the opened pack, the cell arrangement, the interconnection method, the potting or lack of it, the insulation, the wrap, the hardware. I put those next to the supplier's build drawing and the photos from the factory audit and I look for the same things: same cell, same holder or bracket, same busbar or nickel strip, same enclosure material, same connector.

What I am doing is not spotting fraud. It is spotting drift. The most common failure mode I have run into is a pack that was certified honestly two years ago and then quietly optimized: a cheaper cell from a second source, a thinner gauge on the interconnect, a housing material swap for moldability. Nobody lied. The product moved and the paper did not. When you compare the photos to the current build drawing, the drift shows up.

The firmware revision nobody checks

On a smart pack, the protection thresholds, the balancing behavior, and the fault response live in the BMS firmware. The test report should record the firmware revision that was tested. Production should be running that revision or a revision you have reviewed for impact on the tested behavior.

In practice the report says something like rev 1.4 and the supplier's production line is on 2.0, and no one in the chain connected the two documents. I ask for the revision in writing as part of the qualification pack and I ask again at first article. If it moved, I want an engineering change note explaining what changed and whether it touches cutoffs, timing, or communication. If the supplier cannot tell you the tested revision, that is itself informative about their change control.

UN 38.3 is a separate document and it is not interchangeable

The transport test summary is its own artifact. It lists the battery model and the test results by test number, and a product safety certificate does not stand in for it. I have received a safety certificate in response to a request for a UN 38.3 summary more than once, and the reply was not dishonest, just unexamined.

Check that the model on the summary is the model you are shipping, at the watt-hour rating you are shipping. A summary for a 98 Wh pack does not cover a 160 Wh variant. If your pack ships as a standalone unit and also installed in equipment, you need the evidence to match how it actually leaves the dock.

Dates, surveillance, and the renewal conversation

Certificates have issue dates and expiration dates, and many certification schemes require periodic factory surveillance for the listing to remain in force. A certificate that is unexpired on paper but whose holder has missed surveillance is a conversation, not an assumption. I put the expiration date and the surveillance interval on the qualification tracker with a reminder lead time, because the certificate that is valid at pilot run can lapse before the second production order.

What I do when something does not line up

I write it down as an open item with the exact discrepancy and I send it to the supplier as a request, not an accusation: here is the certificate line, here is the RFQ line, please reconcile. Nine times out of ten the answer is a newer report they forgot to send or a variant that was certified separately. Occasionally the answer is that the change was never tested, and that is the outcome the check exists to produce, early and cheaply, instead of at PPAP or later.

I do not accept a letter of explanation as a substitute for a test report that covers the part. A written assurance from a supplier is a data point about their confidence, not evidence about the product. The file needs the document.

And when the check is clean, everything lines up, and the report photos match the build drawing, I still record the versions I verified: certificate revision, report number, firmware revision, edition years. Because the next time someone opens that folder, the question will not be whether it was checked. It will be which configuration was checked.