The Audit Finding You Can Avoid by Tracking Battery Safety Certificates One Way

The audit findings that cost a program real time almost never come from a missing test. They come from a certificate filed against a product family instead of a pack SKU, a test report that stopped matching the cell inside the pack eighteen months ago, and a standard revision nobody wrote down. The fix is one controlled index that ties every certificate, test report, and UN 38.3 test summary to the exact pack SKU and revision it covers, records the standard edition and issue date behind each document, and gets re-checked every time the supplier changes a cell, a BMS, or a manufacturing site. Folder names, numbering schemes, and who owns the file all come after that decision, not before it.

I want you in the room where this goes wrong, because the failure is physical and it is boring.

It is 2:40 on a Tuesday. The plant conference room smells like the anodizing line two doors down. Across the table is a dangerous goods auditor sent by the carrier, and he has a stack of paper he printed himself, because he does not trust anyone's laptop. He flips to a page and turns it toward you. It is your UN 38.3 test summary. T1 through T8 down the left side, all passing. Construction section near the top. And in that construction section, one line describing the cell.

He taps it with a pen and says the sentence I have heard three times now: "This summary describes a battery. Show me it describes the battery in the box."

You open the shared drive. You type the pack model into the search bar and get four PDFs with almost the same name, two of them from a supplier that no longer exists, one of them a scan of a fax. You find the certificate. It lists a model number, an issuing lab, a standard, and a date. It does not list the cell. It does not list the BMS. It does not list the site that built it. The cell on the approved bill of materials ends in a different suffix than the cell on the test summary, because the supplier swapped cell vendors in the second year and told nobody in writing that mattered.

The auditor does not accuse you of anything. He just writes down that the test evidence does not reconcile to the shipped configuration, and your shipment sits while somebody three time zones away looks for a document that may or may not exist.

That day is why I stopped calling these things certificates and started calling them records.

A certificate is not a test report, and a test report is not a test summary

Most teams lose audits in the gap between three documents they treat as interchangeable.

A certificate is the narrowest of the three. It says that a specific model, as tested by a specific lab, met a specific edition of a standard. It usually does not name the cell, the protection circuit, or the manufacturing site. It is a claim about a moment in time.

A full test report is the data behind that claim. For UN 38.3 that means the construction and cell list, the description of the protection circuit, the test conditions, and the T1 through T8 results. For a product safety standard it means the evaluation of the enclosure, spacing, temperature rise, abuse conditions, whatever that standard covers. This is the document that tells you what was actually tested.

The UN 38.3 test summary is the condensed version that the dangerous goods rules expect to be available with the shipment. It is short, it is structured, and it is the one a freight forwarder's dangerous goods desk will ask for by name.

Add a declaration of conformity when the supplier issues one, and a BMS firmware record on top of that. Four or five artifacts, one pack, several hundred pages if you print them all.

None of them substitutes for another. When a carrier asks you for "the certification," they might mean any one of them, and the only way you find out at 3 p.m. is to have all of them ready under the same key.

What the index actually holds

Call the key the pack SKU plus revision. Everything hangs off that.

For each document in the file, I record:

• Customer part number, supplier part number, and the SKU revision letter
• Manufacturing site, by name and address, not by a three-letter code that changed meaning last year
• Cell manufacturer, cell model, and the suffix that keeps biting people
• BMS part number and firmware revision covered by the test
• Document type: certificate, full test report, UN 38.3 test summary, declaration of conformity
• Standard and edition, with the amendment year, not just the standard number
• Report number, issuing lab, issue date, and renewal or expiry date
• A pointer to where the file lives
• One column that asks a single question: does this document still describe the configuration we are shipping right now

That last column is the entire point. The rest is bookkeeping you can teach an intern in an afternoon.

Standards get revised, and your evidence ages quietly

UN 38.3 has been amended more than once. IEC 62133-2 has editions. UL 2054 has editions. A certificate issued to an older edition is not automatically dead, and I want to be honest about that, because the internet is full of people declaring that everything not issued to the newest revision is invalid.

It depends. It depends on whether the certifying body has published a transition for that standard, on whether your customer's specification pins an edition, and on what the carrier is willing to accept for the mode of transport you are using. What I can tell you is that you cannot make any of those calls if the index does not record the edition in the first place. I have watched a buyer spend a week chasing a certificate update that turned out to be unnecessary, and I have watched a different buyer ship on a certificate the customer had already stopped accepting. Both failures were the same failure: nobody had written the edition down next to the pack SKU.

So the field exists. The renewal date sits next to it. Somebody reviews the list once a quarter and flags anything within six months of expiring or issued to a superseded edition.

A change notification is a document event, not an email

Cell changes. BMS changes. Firmware changes. Moving production from one plant to another. Adding a second source for the same cell model. Every one of these can invalidate evidence, and none of them announces itself as a compliance event. It arrives as a line in a weekly update, or a phrase in a call: "we're qualifying a second cell supplier for that pack."

I do not try to make suppliers use special language. I do make sure one named person on my side reads every notification against the index and writes down a yes or no: does this change the tested configuration? If yes, the file gets a review flag the same week. If no, the notification gets filed next to the pack record with a date and a name, which is itself useful the next time someone asks why the test summary lists a cell that is no longer in the BOM.

That file-note habit has saved me more than any tool. An auditor who sees a dated note explaining a configuration question is looking at a controlled system. An auditor who sees nothing assumes there is nothing to see.

The firmware record nobody keeps

BMS firmware revisions belong in the same folder as the safety evidence.

Protection thresholds, over-discharge cutoffs, and charge termination behavior can live in firmware. If a supplier flashes a new revision after the safety test was run, you have a tested configuration and a production configuration that may not be the same thing. I am not going to tell you every firmware change requires retesting, because that is not true and treating it as true will get you ignored. I am telling you that you cannot have that conversation at all if the firmware revision at the time of the test is not written down somewhere you can find it.

One line in the index. Version string, date, and a link to the test report it pairs with.

What actually gets asked for on audit day

The carrier's dangerous goods desk, a customer's quality engineer, and your own internal auditor all converge on roughly the same packet:

• The certificate
• The full test report
• The UN 38.3 test summary
• The declaration of conformity
• Anything that proves the tested configuration matches what shipped, which in practice means the cell list and the firmware record

The measurement I care about is time to answer. If the request comes in at 9 a.m., I want the packet out before lunch, pulled by SKU and revision, with a note on any document that has a caveat. Two hours is a healthy program. Two weeks means the file is a folder, not a record.

Where this is overkill, and where it is not

If you build one pack, with one supplier, one cell, one site, and you have never changed any of them, a single sheet with a dozen rows is enough. Do not build a cathedral for one SKU.

The moment any of those variables multiplies, the sheet stops working. Two sites building the same SKU is the classic case, because the same certificate number gets used to cover product from two addresses and nobody notices until a customer asks which plant made their units.

The other honest limitation is access. Some suppliers will hand you a certificate and nothing else. You cannot index a test report you were never given, and pushing harder after the PO is signed rarely works. That makes the full test report and the test summary a sourcing requirement at the RFQ stage, listed with the other deliverables, so the answer arrives before you are committed.

The habit that keeps the file alive

Every document gets a home the day it arrives. Not the week the audit is scheduled. The day it lands in your inbox, someone opens the index, finds the pack SKU and revision, and either files it against a row that already exists or creates the row. Ten minutes. The reason this matters is that the alternative is a folder named Certs_OLD that nobody can defend.

How long you keep all of this is a question I stay out of, because it touches legal and contractual ground that is not mine to interpret. What I can tell you from the practical side is that programs that keep the file for the life of the program answer audits in an afternoon, including the ones that arrive four years after the last unit shipped, from a customer you had almost forgotten.

The pack SKU is the spine. The revision is the joint. Everything else is just paper clipped to it.