What a Compliance Reviewer Checks in Your Pack Manufacturer's File

A compliance reviewer opens each certificate in a pack manufacturer's file and reads three fields before looking at a single test result: the applicant, the holder, and the covered configuration. If those three fields do not describe the cell, module, and pack you are actually buying, the document is not evidence for your program, however official the seal in the corner looks. Every other page in the file — the UN 38.3 test summary, the pack-level safety report, the cell certificate, the material declarations, the dangerous goods paperwork — was written for one specific build, not for a supplier in general.

The folder lands at 7:40 on a Tuesday, sixteen days before a build decision. Forty-one PDFs, half of them named something like scan_0043. I do not read them front to back. I drop them into a working folder and open the UN 38.3 test summary first, because if that one does not hold, the rest of the morning is a phone call instead of a review.

Read the top block before the test results

A UN 38.3 test summary is one page, and the whole page is a header plus a table. The header carries the manufacturer's name and address, a contact, a description of the battery, and the model numbers. The table lists T.1 through T.8 with a result for each, plus the report number, the testing lab, and the date. Most people scroll straight to the eight passes. I read the description line twice, because that line is where a document tells you what it is and what it is not.

A description that says lithium-ion battery pack, 48 V, 20 Ah has told me almost nothing. A description that names the cell part number, the cell arrangement, the enclosure, and the pack model has told me most of what I need before I reach the results. If the description is generic and the model numbers on the summary do not appear anywhere in the BOM sitting next to me, the summary is not covering my build. It may be covering something the supplier shipped two years ago. Those are different documents in practice even when they are the same PDF.

Configuration match is the thing that matters most, because UN 38.3 testing follows an article, not a supplier. A pack is a configuration: specific cells, a specific arrangement, a specific protection board, a specific enclosure. Change any of those and the tested article and the shipped article are no longer the same object. I do not decide whether a change requires new testing — that call belongs to the supplier and whoever they answer to. I decide whether the document in front of me describes the thing on my PO. If it does not, it goes back with a question attached.

Applicant, holder, and why the difference bites

Two names sit at the top of a test report and each means something different. The applicant is who commissioned the testing and paid for it. The holder is who owns the report and whose name is on it. Often they are the same company. Often they are not.

For a cell-level report, the cell maker is usually both, and that is normal. The trouble starts when a pack-level document shows a holder with no connection to your supply chain. If the report is held by the cell maker but the pack in your RFQ is built by a third-party packer, the packer may be using a document it has no rights to. That is not automatically a problem, but it is a question. Ask for the letter or agreement that gives the packer the right to reference the report. If there is none, the document does not belong in your compliance file — it belongs in a notes column with a date and a name attached to it.

I have had suppliers answer this with a screenshot of an email from the cell maker telling them to use the report. I keep that email in the file, and I also write down that the underlying report was not reviewed by us and that the reference is by permission. Later, when somebody else audits the program and opens the file, at least the story is intact.

What a summary is not

The test summary exists so a document can travel with the shipment. That is its job. It is not the report.

A full test report contains the tested unit's photographs, the test conditions, the sample preparation, the cell specification sheet used at the time of testing, the number of cells, sometimes the number of cycles on the cells that went in. The summary contains the headline: what was tested, by whom, with which result.

There are situations where the summary is not enough and I ask for the report:

• The configuration description on the summary is vague enough that I cannot tell whether it covers my build.
• Something changed — cell, BMS, enclosure, terminal, capacity — and I need to see the tested configuration in detail to size the delta.
• Our customer's own compliance or quality team is auditing the program and wants primary evidence rather than a one-page extract.
• The summary lists a model number that appears in no BOM, no drawing package, and no label file.

If the report is under NDA, there are still ways through: a redacted copy, an on-site read at the supplier or the lab, or a letter from the holder naming the report number, confirming the covered configuration, and confirming the right of reference. I note in the file which of those I got, because they are not equivalent. A redacted report still lets me see the tested unit. A letter is somebody's word in writing, which is better than nothing and worse than a photograph.

Cell documents and pack documents are not interchangeable

This is the mistake I see most often in files that otherwise look tidy. The file contains a certificate with a good report number and a current date. Everyone relaxes. Then you read the scope line and it is a cell.

UL 2054 is written around a battery pack — the assembled article, with its enclosure and its protection circuitry. UL 62133-2 and IEC 62133-2 are written around cells and, depending on the edition, small batteries. That is a scope difference, not a quality difference. A cell document follows a cell. When that cell is built into a pack with a protection board, a wire harness, a connector, and a plastic or aluminum enclosure, the assembled article is a different subject than the one the cell document describes.

I do not declare that a pack complies or does not comply. That is not my call, and it is not the call of anyone reading a PDF in a procurement office. What I do is state the subject of each document in my register: this report covers the cell, this report covers the module, this report covers the pack. When somebody downstream asks a pack-level question, I can point at the pack-level document or say out loud that we do not have one.

Read the cell line inside a pack report too. Pack reports list the cells used in the build. If the report predates a cell change, it lists the old cell, and the document describes a pack that no longer exists in your supply chain.

A design change is a document event

Every program has them. The BMS firmware moves a revision. The cell runs short and sourcing adds a second source. The enclosure gets a vent. The connector changes because the first one was on a fourteen-week lead time.

Each of those is a document event, not just an engineering event. I put a one-page delta form in front of the supplier and require a sentence for each change: what changed, the part number before and after, and which document covers the new build. The answer is allowed to be that the change falls within the tested configuration per the supplier's engineering review. It is not allowed to be silence.

What I will not accept is a report that predates the change being quietly carried forward. That happens for boring reasons — nobody is being malicious, the program is late, the file gets copied from the last build. The report number stays the same, the date stays the same, and the pack underneath it is different. That is exactly the failure the register is built to catch.

Lock the file to a BOM revision

A compliance file is not a folder of certificates. It is a folder of certificates attached to a build.

Every document in my register gets a row with the same fields: document type, applicant, holder, report number, revision or issue date, the covered configuration copied verbatim from the document rather than paraphrased, the BOM revision it was accepted against, the acceptance date, and who accepted it. Nothing gets accepted against the product in general. It gets accepted against a BOM revision.

When the BOM moves from one revision to the next, every row flips to unverified until someone re-reads it. That sounds heavy, and on a small program it can be a ten-minute job, because the register tells you which documents even mention the parts that changed. What it prevents is the quietly reused obsolete report, which is the single most common finding when a program gets audited three years later and the original buyer has moved on.

Superseded documents get moved to an obsolete folder rather than deleted. Name them with the date they were superseded and the reason. Delete nothing. An auditor who finds an old report in a current folder will ask hard questions. An auditor who finds the same report in a folder marked obsolete in 2023 will not.

What I write at the end of the review

The review ends with a short memo, usually half a page. Three lines matter: what we hold, what it covers, what is still open. The open list is the honest part. It names the missing pack-level document, the report still under NDA, the cell change with no coverage statement back yet. If what we have is a summary and a permission letter, that is what the memo says — not documents complete.

The file is never finished. It is only current as of the last build. That is why I open the applicant and holder fields before the test results, and why the register hangs off BOM revisions instead of off suppliers. The documentation can never be more certain than the build it describes.