Does That UN 38.3 Test Summary Actually Cover Your Battery Pack?

A UN 38.3 test summary covers your pack only when the model identification printed on it matches your pack part number and configuration exactly. If the document names a bare cell, or names a pack built with different cells, a different protection circuit, or a different mechanical layout than the one you are shipping, it is a perfectly valid summary for something else, and it does not cover what is sitting on your dock. Everything else about reading that document follows from that one match.

The first thing I do with one of those PDFs is not read it. I open it on the left half of the screen, pull the drawing or the purchase order up on the right, and go straight to the model identification block. Then I read the string one character at a time, out loud if the office is empty.

That sounds excessive until the first time a suffix bites you.

Read the model string before you read anything else

Suppliers write model numbers differently than buyers write part numbers. Their catalog number is usually the base design. Your part number is the base design plus whatever you changed: a connector, a cable length, a housing color, a firmware setting, an added NTC. So the summary says something like BP-4813 and your drawing says BP-4813-2, and now you have a question that nobody in the room can answer from the document itself.

The suffix is not automatically a problem. A connector change or a different wire harness generally does not disturb the cell, the protection circuit, or the mechanical structure that the tests actually stressed. A suffix that hides a cell change, a different protection IC, or a taller housing is a different conversation entirely. The summary will not label which kind of suffix you are looking at. You find out by reading the description line under the model number and matching it against your spec: nominal voltage, rated capacity, chemistry, cell form factor, and the cell manufacturer's model if it is listed.

I do the same thing with the description that I do with the model string. Character by character. A pack described as 48V nominal that you specified as 51.2V nominal is a different cell count, which is a different pack.

The document tells you what sat on the test bench

This is the distinction I keep coming back to with newer buyers. A test summary is not a statement about your product. It is a statement about a specific physical object that someone shipped to a lab on a specific date. The summary tells you what that object was. Your job is to decide whether your object is the same one.

So read the type line literally. If it says cell, the document is about a cell. If it says battery or battery pack, it is about an assembly. Those are not interchangeable in your file, and the fact that a pack is built from tested cells does not by itself turn a cell summary into a pack summary. There is a whole separate question about how a pack qualifies when its cells were already tested, and that question belongs to whoever signs your compliance paperwork, not to a summary PDF. What I need from the document is honesty about which of those two things was on the bench.

The three things that usually break identity

When I compare a summary to a pack I am about to ship, I am checking three things, in this order.

First, the cell. Same manufacturer, same model, same chemistry. A cell swap is the single most common reason a summary stops applying, and it is also the most common thing a supplier forgets to tell you about.

Second, the protection circuit. Different IC, different cutoff thresholds, different board layout. The board is what the short-circuit and overcharge tests stress, so a board change is not cosmetic.

Third, the mechanical build. Cell holder, potting, wrap, enclosure material, wall thickness. Vibration and shock results belong to a physical assembly, and if the assembly changed, the results describe something you are not buying.

Anything outside those three is usually worth a question but rarely worth a panic.

Reading the test rows without a test report

A summary typically lists the tests with a result and sometimes a date per row. I look for three things.

Blanks and not-applicable entries with no note attached. Some tests apply to cells and some apply to batteries, so a pack summary legitimately carries a few N/A entries. That is normal. An N/A with no explanation next to it is not normal, and it is exactly the thing a dangerous goods desk will ask you about at the worst possible hour.

Dates that do not line up. If seven rows are dated the same week and one row is dated four years later, you are looking at a partial retest. That is not disqualifying, but it tells you something changed and it tells you roughly when. Ask what it was. The answer is usually a cell revision or a housing change, and it is useful context for your own change-control file.

Rows that are missing entirely. I have been handed summaries that simply stopped at T5. Whether that is an oversight or a deliberate edit, the practical answer is the same: it is not a document you want to forward to a carrier.

And remember that what you are holding is a summary. The underlying test report has the actual measurements, the failure criteria, and the photographs of the sample. The summary is the front door. When a customer's safety team or a carrier's dangerous goods reviewer pushes back, the report is what closes the conversation, so make sure your supplier can produce it and that it references the same model number.

No expiry date does not mean nothing ages

Summaries do not carry expiration dates, and people hear that as permanent. It is not. The document does not expire; the configuration underneath it drifts. A five-year-old summary for a pack that is still built identically is fine. A six-month-old summary for a pack that quietly moved to a new cell supplier is worth nothing.

This is a supply agreement problem more than a document problem. I want a change notification obligation in the contract, in writing, covering cells, protection circuitry, and mechanical structure, with enough notice that a retest lands inside the program schedule instead of inside the week before first shipment. Retesting is a lead-time item. Discovered late, it becomes a shipment that does not leave.

Where the summary meets the shipping paper

The model string on the summary has to match the model string on the dangerous goods declaration and the shipping description. Not roughly. Not by family. Match. If the person preparing the paperwork is copying a part number off a commercial invoice while the summary says something else, you have two documents describing two different objects, and that is the kind of discrepancy that gets a shipment held while someone emails you.

Air transport adds a state-of-charge condition and handling documentation that the test summary does not address at all. Those live in your shipping instructions, and they are a separate checklist item from the summary. The summary covers the design; it says nothing about how the pack is charged when it goes on the plane.

What I do is boring and it works. The summary PDF gets a filename that contains the pack part number and the summary revision. It gets stored in the same folder as the dangerous goods declaration for that shipment, and the declaration references it. When a carrier's dangerous goods contact emails at an inconvenient hour, I send one file, not a scavenger hunt through a shared drive.

I also keep a register, one line per pack: part number, summary revision, date of the summary, what was tested, where the file lives, who confirmed the match, and the date of that confirmation. It takes ten minutes to set up and it has answered more questions than any other document in my folder.

What I do when it does not match

First, I ask for the specific thing that is missing, in writing, naming the part number and the configuration difference. Vague asks get vague answers.

Sometimes the answer is that the pack was tested but the summary was written before your part number existed. In that case the supplier's compliance owner needs to confirm in writing that your configuration was the one tested and to issue a document that says so with your part number in the model identification block. If they will not put their name on that, treat it as a no.

Sometimes the answer is a delta: your configuration differs in one of the three areas that matter, and the supplier will tell you what, if anything, was done to address it. That is a real answer and it belongs in your file even if it is not the answer you wanted.

And sometimes the answer is a retest, which is a sourcing timeline problem, not a shipping problem. The earlier you find that out, the cheaper it is in every sense that matters.

The summary is a one-page claim about one configuration. It is not a certificate of quality and it is not a warranty. Treat it the way you would treat a dimension on a drawing: check it against the part, and write down who checked.