Can Your UN 38.3 Test Report Prove Which Cell Lot Shipped in Your Battery Pack?
No. A UN 38.3 test report proves that a cell model — and often one specific test sample of it — passed the test sequence. It cannot tell you which cell lot went into the pack that shipped in March. What answers that is your own chain of records: the lot code captured at receiving, the work order that consumed it, and the pack serial that carries it out to a customer. The test report becomes evidence about your product only when those records exist and line up.
I keep a folder for exactly this question, and it is thinner than people expect.
The report describes a design. The pack has a serial. Different objects.
Open a UN 38.3 report and read the title block before the results. Lab, report number, date, applicant, and a description of what was tested — cell manufacturer, model designation, chemistry, nominal voltage, capacity. That description string is the anchor for everything downstream. In a UL 2054 file, the same cell description reappears inside the construction description the file is built on, next to the pack-level parts that matter: the protection circuit module, the wiring, sometimes the enclosure material. A UL 62133-2 or IEC 62133-2 file for international markets works the same way, and it is also where traceability earns its keep — an overseas buyer who wants to know the certified cell is still the cell in production is asking about your records, not your certificate.
Then read your own side. The PO says "18650 3.6V 3500mAh high drain." Receiving logged "ABC 35E." The sleeve printing on the cell says something else again, with a date code beside it that nobody wrote down. Three names for one cell, and nothing in those three documents joins on a string. That is usually the moment someone discovers the chain is broken — a customer's quality engineer emails a serial number and asks what is inside it.
The fix is an hour of work. Build one controlled identity block per cell you buy: legal manufacturer name, the model string exactly as the certificate writes it, the model string exactly as it is printed on the cell, and your internal part number. One row. Put it somewhere the compliance owner and the buyer both can open. After that, every document uses those strings and nothing else.
Receiving is where traceability actually begins
I do not trust a packing list. I trust what is printed on the box and on the cell. At goods-in, the receiver writes the lot code off the box label, matches it against the supplier's certificate of conformance, and opens one box to photograph the sleeve printing and date code on the cell inside. Date-stamped photos, two minutes. Eighteen months later, when someone asks whether that shipment matched its C of C, you have an answer instead of a memory.
A date code is not a lot code, though. It tells you roughly when the cell was made. It does not tell you which batch of electrodes it came out of. If a date code is the only traceability you have, every containment window you draw will be wider and more expensive than it needed to be.
The work order is the joint
Between receiving and shipping sits the piece most people forget to check: does the traveler actually record the lot code consumed, and does it split the serial range when two lots run in one shift? Often it does not. It says "500 pcs built" and the serial range is one block, and now a lot-specific question covers the whole shift whether it should or not.
If you buy from a supplier with a real MES, the lot-to-serial join happens in software, and your job is to verify it exists and survives an audit. If you buy from a supplier whose traceability is a whiteboard and a marker, your job is to write the requirement into the quality agreement and check it on a plant visit, because it will not survive contact with a busy week on its own.
The lot change that isn't a certification event
This is where I see buyers overcorrect. A cell lot change, by itself, is normally not a certification event. The certificate covers the model and the construction. The cell maker is supposed to build that model consistently, and a new production lot is the ordinary output of doing so. Nobody re-tests for every lot that comes off the line, and nobody should.
What a lot change does is move the burden onto your records. The certificate cannot tell anyone what is in the box; your lot register can. That is the trade. You either pay for lot-level testing or you pay for lot-level records. Skip both and you own a certificate and an indefensible product.
The changes that do cross the line are the ones that make the certified article a different article: a different cell model, a different cell manufacturer, the same model out of a different cell plant, a different chemistry or capacity, a different protection circuit or BMS, a pack construction the file does not describe. Any of those and your evidence describes something you are no longer shipping. That is a scope problem, not a traceability problem, and no amount of recordkeeping repairs it.
When something fails
If a field failure or a failed test sample shows up, work backward: serial to shipment date, shipment date to work order, work order to the lots consumed, lots to every pack built from them, then forward to every customer who received one. Both directions need the lot code as the join key.
I have watched a containment take a week longer than it had to because the lot code was written in marker on a traveler and the traveler went into a box in a warehouse. The data existed. Nobody could get to it.
What I put in the quality agreement
A notice window for product change notification, with a written critical-component list attached. Not the principle — the list, because you and the supplier will disagree about whether a BMS firmware revision or a second cell plant counts, and it is cheaper to have that argument now. No substitution without written approval, and "equivalent" is not a category. Cell lot code on every shipment and on the C of C. Records access on request. A retention period for lot-level records that outlives the supplier's next ERP migration, which is the specific failure that kills these files: the ERP gets replaced in year three and the lot codes from the first two years of shipments are simply gone.
One limitation worth weighing honestly. If your supplier buys cells through distribution and the distributor will not pass lot codes upstream, you may not be able to get them at all. That is not automatically a dealbreaker, but it caps how tight any future containment can be, and it belongs in your risk model now rather than in a recall later.
The register
The thing I actually maintain is a lot register, one row per lot received: lot code as printed, date code, the controlled cell model string, supplier, quantity, receiving date, whether the C of C is on file, the report or certificate number it links to, and the PO. Downstream of that, the serial ranges built from each lot.
Nothing about it is sophisticated. It just happens to be the only artifact that answers the question in the title. The test report is a claim about a model. The lot register is a claim about a shipment. When a customer asks what is in a pack, only one of them is talking about the pack.
