The UN 38.3 summary may not cover the pack you imported
A UN 38.3 test summary is a matching document, not a certificate. Its only job is to describe one specific battery as it was actually tested, and the buyer's job is to confirm that the battery described is the battery on the pallet — same cell, same protection circuit, same enclosure, same revision, same watt-hour rating. When any of those drift, the summary stops covering your pack even though the paper still looks official, and no amount of letterhead fixes that.
I learned to read it that way in a receiving bay at seven in the morning, box cutter in hand, pallet wrap still popping under my feet. The forklift had already gone back for the second skid. Somebody had taped the summary to the outside of the carton in a plastic pouch, printed at about seventy percent scale, so the model-number line was almost too small to read under the sodium lights. I held it up next to the label on the first pack, mostly out of habit, expecting them to agree.
They didn't. The summary said one model string. The label on the pack had a letter tacked on the end. One letter.
I called the account manager from the dock, which is not how anyone wants to start a Tuesday. "It's the same pack," he told me. I asked what the letter meant. There was a pause long enough that I could hear his office air handler. It turned out to mean a different protection board — same cells, same case footprint, new BMS. He genuinely thought that was a paperwork detail.
It is not a paperwork detail. It is the whole point of the document.
What the summary actually is
A test summary is short. That surprises people who expect a dossier. It names the cell and the battery that were tested, gives the watt-hour rating, lists the model numbers, states which tests were performed, and carries a test date. It's a declaration prepared by the test sponsor — usually the manufacturer or the assembler — who is expected to make it available to downstream customers on request.
What it is not is the test report. The report is the fat document with the plots and the chamber logs. The summary is the one-pager that tells you whether the report is even about your hardware. I've had suppliers send the summary and act like the conversation is over. The conversation hasn't started yet.
So I stopped treating arrival as a signing event and started treating it as a comparison event. Four things, in this order.
Cell identity
Which cell is named, and does it match what's in the pack? Cell changes are the most common silent substitution in this industry, usually for supply reasons, and they are exactly the kind of thing that doesn't get mentioned because it isn't anybody's idea of a design change. It is.
Construction
Does the summary's description of the battery match the battery in your hands? Enclosure, mounting, the mechanical arrangement. If the case got longer to fit a new connector, somebody changed the mechanical construction, and that's the third rail of this whole exercise.
Revision
Model strings carry revisions for a reason. The suffix I found on that dock was a BMS change. Other times it's a firmware or board revision that has nothing to do with the electrical safety of the cell and everything to do with the protection behavior of the pack. Either way, the tested article and the shipped article need to be the same article.
Date and scope
A test date tells you when the tested configuration existed. If the summary predates a model change the supplier has already told you about, that's not a stale document — that's a document about a different product.
The mismatch hides in the suffix
Nobody hides this stuff in a locked drawer. It hides in plain sight, in the part of the model string that sales treats as administrative and engineering treats as load-bearing.
I've seen a summary that listed eight tests and a label with a trailing revision that pushed the pack into a different internal build. I've seen a summary for a pack built around one cell and a current build sheet naming another, because the first cell went on allocation. In both cases the supplier's position was that the pack was functionally the same. Functionally is not a word that appears anywhere in 38.3.
Here's the sentence I use now, and it has saved me twice: "Please confirm in writing that the summary you sent describes the exact model, cell, and BMS revision that will ship on this PO." Not "is this pack tested" — that question gets a yes reflexively. Asking them to confirm the specific build is harder to wave through.
Which changes break the match
I keep three triggers at the front of my head, and I escalate on any of them without debating whether it's a big deal.
A change of cell. New manufacturer, new capacity, new chemistry variant, new format. Anything on the cell line.
A change to the protection circuit or BMS. Different board, different cutoff thresholds, different communication stack. That letter on the dock was this one.
A change to the mechanical construction that touches the enclosure. Different case, different wall thickness, different venting, different mounting hardware that alters how the pack is restrained.
When one of those lands, the old summary doesn't get amended. It gets superseded, and the pack needs its own evidence. I've watched procurement teams try to treat a design change as a delta to be waived, and I understand the pressure — a retest costs weeks you may not have. But the decision isn't whether the pack is safe. The decision is whether you can produce a document that matches your hardware at the freight forwarder, at customs, and eighteen months from now when someone asks why this pack is on your robot.
Cell-level and pack-level are two different claims
This one trips up people who are being careful but reading the wrong line.
A cell summary describes a cell. A battery summary describes a battery. They are separate documents with separate model numbers. A pack assembled from tested cells in a configuration that isn't the tested configuration generally still needs its own battery-level evidence, because the pack is a new article with its own protection circuit and its own enclosure and its own failure modes.
When I get a summary that turns out to be cell-level, I don't throw it back. I note it as partial, because it's useful — it tells me the cell question is answered — and then I ask for the battery-level document by name. Suppliers who know what they're doing send both without being asked. Suppliers who don't send whichever one they found first.
The eight-test check
I read the test list, not the cover. Subsection 38.3 covers altitude, thermal cycling, vibration, shock, external short circuit, impact or crush, overcharge, and forced discharge. A summary that lists five of those is not a shorter summary. It is an incomplete one, and I want to know which tests were skipped and why before the pallet goes anywhere.
I am not the person who decides whether a pack passes. That's the lab's call and the sponsor's claim. I'm the person who decides whether the description on the page matches the object on the dock. Those are different jobs and I stay in mine.
When the summary doesn't come
The document is expected to be made available to downstream customers on request. That's the norm the whole chain runs on. So a supplier who won't release one is telling you something, and it usually isn't that they're protecting trade secrets. It's more often that the summary exists for a different build, or the pack was assembled from cells whose paperwork they don't control, or the product was never taken through a battery-level test at all and the cell summary was carrying the whole sales conversation.
I don't escalate to a demand. I ask for three things in one email: the summary for the model on the PO, the name of the test sponsor, and the lab that ran it. If the answer comes back as a cell-level summary and a shrug, I have my answer, and it's a procurement answer, not an engineering one.
What I actually do with it now
The pallet doesn't get refused at the dock. Refusing freight you've already paid to move is an expensive way to make a point. It gets received, quarantined, and flagged, and the conversation moves to email where it can be documented. I write down the model string on the summary, the model string on the label, the cell named on each, and the test date — four lines, one page, on every lot. It takes ten minutes.
Ten minutes, against the alternative. I've seen a mismatch discovered at the forwarder, with air freight already booked, and the cost of that conversation had nothing to do with the document and everything to do with the schedule. The summary is cheap to read and expensive to skip.
So I read it the way I read a bill of materials, not the way I read a certificate. It's a list of claims about a specific build. My job is to check the claims against the build, and to say out loud, in writing, when they don't line up.
About the author
Lot Trace
Lot Trace is a byline shared by sourcing, quality, and compliance professionals who have spent their working lives on the buyer's side of custom battery pack programs. They have walked pack assembly lines in the Midwest and in Guangdong, reviewed cell lot records and UN 38.3 test summaries, and sat through PPAP reviews for robot programs built on both sides of the Pacific.