A UN 38.3 Test Summary for a Different Cell Is Not Evidence

The UN 38.3 test summary that matters is the one whose identifying fields match the product on the dock. A summary naming a different cell model, a different cell revision, or a different pack configuration than the one being delivered does not establish coverage for that shipment — it establishes coverage for something else that happens to share a supplier, a part number, or a folder. The question is never whether a UN 38.3 summary exists. It is whether the copy in your file describes the exact cell and the exact assembly being built this month.

I keep program folders the way a lot of buyers do: one for drawings, one for quality, one for commercial. The UN 38.3 summary almost always lands in the same email as three other documents the supplier wants acknowledged, and for a long time I read it like a certificate of compliance. Letterhead, report number, date, signature, close the file. The fields that decide whether it covers my shipment sit lower on the page, and those were exactly the ones I used to skim past.

Now I open the PDF next to the current pack build drawing and the PO line. Not in a separate window on a separate day. Same screen, same minute, because the whole point is the match.

The identifying fields, in the order I check them

The top of the summary names the cell. Not a category — a specific cell model, usually with a manufacturer name attached. I write that string down exactly as it appears, including any suffix.

Then it names the battery. Sometimes that's the pack part number with a revision; sometimes it's a description built out of nominal voltage and capacity. That second kind is the dangerous one, because it can be close enough to mine to feel like a match. If my pack is a 48 V assembly with a particular series and parallel count and the summary describes a lower-voltage pack built from the same cells, the summary is real and the test behind it is real — it just isn't mine.

Then there's the part people skip: what was tested. Cells, batteries, or both. That distinction carries a lot of weight when a pack uses a cell that was qualified inside a different assembly. Qualified there doesn't mean qualified here, because the assembly is part of what was tested.

And then the laboratory. Name, location, the lab's own reference number. I don't try to re-derive the tests themselves; that's the lab's document and the lab's job. My job is the trace.

Where the mismatch actually hides

It hides in revisions, and it hides in the gap between a cell model number and the cell.

Designs move. A cell maker changes a separator, adjusts the cathode blend, shifts production to another line, and the model number on the label stays the same while what's inside changes. A summary from two years ago describes the cell that existed two years ago. If nobody told you the cell changed, the summary in your folder still looks fine.

Then there's my side of it. The pack gets a new BMS, a different cell holder, more potting, a relocated vent, a different fuse. Every one of those is an assembly change. The configuration that was tested is now a configuration you used to build. The summary doesn't announce that. It sits there with an old date on it, and the date is the only clue you get.

I have watched a supplier answer a mismatch question with "it's the same cell." That sentence is doing a lot of work. It might be true in the sense that matters. It might mean the cell is identical and only a part number field on the summary went stale. It might mean the cell is the same family and the model suffix quietly differs. Those two cases look identical in a forwarded email and they are not the same case.

What goes in the purchase record

Once the fields line up, I make them part of the PO file rather than leaving them in a shared drive someone else can reorganize.

The report identity: report number, the revision of the summary itself, the summary's date, the page count. If there's a revision letter in the footer, that letter goes in. A later trace is only as good as the identifying string you captured on the day.

The exact cell designation as written on the summary, and the pack part number with its revision. I don't paraphrase these into a general description. If receiving later opens a carton and the label reads slightly differently, the trace has to be able to say whether that's a problem.

A short note on what the summary covers — cells, batteries, or both — plus one line about who confirmed the match and when. Not a conclusion about anything. Just: I asked, this person answered, here's the date.

When the mismatch is only paperwork

Sometimes it genuinely is. The cell is the same production item, the summary is the right summary, and a field on it is stale because a pack part number was reissued administratively after the test was run. Fixing that is a call and a written confirmation, and the confirmation goes in the file instead of in my memory of the call.

Sometimes it isn't, and the only honest answer is that the configuration on the dock has never been tested. That is not a document problem. That is a schedule problem, and it is much better found during supplier qualification than the week you're trying to book freight. Testing takes time, money, and a sample out of production, so if the assembly is genuinely new it belongs in the program plan as a line item, not as a surprise.

The reason I care this much is that the summary is the document that travels with the product while the full report stays with the laboratory. The summary is what a forwarder or an auditor is going to see. If the words on it point at a different cell or a different pack than the one in the carton, everything downstream gets harder for everyone. The classification call isn't mine to make. The trace is mine, and it either connects a delivered pack to a tested configuration or it doesn't.

So when a supplier sends the package, I don't ask whether they have a UN 38.3 summary. I open the file, read the cell field against the build drawing, read the pack revision against the PO, and check the revision letter on the summary against the letter I have on file from last time. Four fields. A couple of minutes. It's the cheapest two minutes in the whole program.