What UN 38.3 and UL Reviewers Expect From Your Cell Lot Records

A UN 38.3 test summary, a UL or IEC certification file, and a customer quality audit all resolve to the same three records: the pack serial, the cell lot code behind that serial, and the end-of-line test record for that unit. The summary and the certificate are pointers. The lot-linked build and test records are the evidence. A reviewer pulls on the pointer and expects the evidence to arrive with it, keyed by lot code, without a scavenger hunt.

Some version of this call comes around every quarter. A customer quality engineer shares their screen, opens a returned pack, reads the serial out loud, and asks what cell went into it. Then they ask for the end-of-line record for that same serial. It's two questions. The window on the second one is short, because they already told their program manager they'd have an answer before the meeting ends.

The first time it happened to me, I had a test summary, a certificate, and a folder of scanned PDFs with names like CellReportsfinal_v2.pdf. I had the answers. I did not have them in six minutes. I had them in two days, after emailing a cell supplier's sales engineer and asking him to go find somebody in quality.

That gap, between holding a record and being able to produce it, is the whole discipline. Everything below is about closing it.

The test summary is a statement about a type

The UN 38.3 test summary is short, and it's short on purpose. It identifies the tested cell or battery type, it points to the test report reference, and it describes the configuration that was tested. That's the document's job.

What it does not do is say anything about the cells in the box on your dock. Test reports cover a type. A production lot is a different animal. The only bridge between the two is your lot record: the document that says these serial numbers were built with cells bearing this lot code, from this cell part number, from this production source.

I picture it as a chain of custody with three links and no spares. Summary points at type. Lot record points at type. Serial points at lot. Break any link and the summary in your hand becomes a nice piece of paper about somebody else's cells.

Three records that have to travel together

The pull is always the same shape:

• the pack serial number
• the cell lot code, with cell part number and production source
• the end-of-line record for that serial, meaning the test data, the date, the station

When those live in three systems with three different key fields, you're doing archaeology under a clock. The cheapest fix I've found was not a new system. It was deciding the lot code is the primary key and building the folders around it.

A cell lot code is not a pretty key. It's whatever the cell maker decided to stamp that week: a date code, a line identifier, sometimes a suffix that quietly changed meaning when they redid their ERP. That's exactly why it has to be the anchor. It's the one identifier both your supplier and your customer's reviewer can point at.

So I keep a cross-reference table, pack serial range on the left, lot code and cell part number on the right, maintained as builds release rather than as audits land. When the call comes, I sort by serial, get a lot code, open one folder, and I'm reading the EOL data while the customer is still typing their next question. Boring table. It is also the entire difference between a good audit and a bad week.

Where this gets murky is unit-level versus lot-level. If the end-of-line station tests every pack, serial-level data exists and you can hand it over. If the line does sample-based testing, the best you have is the lot record plus the sampling plan, and I've had to say that out loud to a customer instead of dressing it up. Say it early. A reviewer who discovers later that "unit record" actually meant "lot record" will start doubting everything else you sent.

Scanned PDFs are where good records go to hide

All of the above assumes the records are searchable. A lot of shops store them as scans: signed, stamped, and useless, because a scanned end-of-line sheet has no text layer. You can't search it for a serial. You can't search it for a lot code. You can only open and read, one file at a time, which is survivable at four hundred files and hopeless at four thousand.

When I inherit a folder like that, I don't re-scan anything. I build a thin index alongside it, one row per lot, columns for serial range, lot code, cell part number, production source, and a path to the file. A few hours of work turns a two-day excavation into a ten-minute lookup. Nothing about the underlying documents changes. Only whether they can be found.

The certification file names specific parts, and the reviewer checks them

UL and IEC certification files describe critical components. That means the file names the cell, and it usually names the protection IC, the FETs, sometimes the separator or the enclosure material. Those aren't placeholders. They are the parts the file was built around.

So when a buyer swaps a cell for a supply reason, second source, cost, allocation, the reviewer's first move is to compare the cell on the lot record against the cell in the file. If they don't match, the file is stale, and the conversation stops being about your records and becomes about your file. Substituting a cell or a protection component generally means the certification body has to be notified so the file stays accurate, and until that loop is closed, the mismatch is the finding. I've watched a program lose a quarter to this. Not because the new cell was bad, but because the paperwork still pointed at the old one and nobody had told anyone.

Same pattern on the cell maker's side. Cell manufacturers move production between plants and lines more often than buyers expect. The type designation on the summary can stay identical while the plant of manufacture changes. If your lot record doesn't capture the actual production source, you can't answer "where was this made" in a way that satisfies a reviewer who is specifically checking it. The practical move is to expect a documentation refresh on those changes and ask for the source information in writing, because a verbal "same plant" ages badly.

Who owns the retention clock

Retention periods typically live in the quality agreement between you and the supplier, and the sensible anchor is the warranty and service period of the product. You want records alive for as long as somebody could plausibly make a claim or need a replacement. The clock generally runs from the last shipment of a lot, not the first, which is the detail that ambushes anyone filing by project start date. I don't write those clauses. I do read them, because they tell me how long I keep the lot folders and whether my supplier is on the hook for the cell-side records for the same window. If their obligation is shorter than mine, my folder is only as good as the last email I sent asking for the data.

The index is the deliverable

None of this is glamorous. The test summary is one page. The certificate is a PDF. The lot record is a spreadsheet row and a test file. The reviewer's question is two sentences long.

But the reason the question gets asked is that a summary and a certificate can't speak for themselves. They describe a type. Somebody has to demonstrate that the units in the field came from that type, and the only thing that does that is a lot record you can actually retrieve.

So I test mine the way a reviewer would. Pick a serial at random from last quarter. Pull the lot code. Pull the end-of-line record. Time it. Under fifteen minutes and the file is healthy. Over it, and I already know what next week looks like.

That's the whole test. Not "do we have the records." It's "can I produce them, in order, for one unit, without calling anybody."

One honest limitation, because it matters. A good index doesn't fix a missing link. If the end-of-line data was never captured for a given line, or the lot code was never recorded at receiving, no folder structure will rescue it. The index just tells you faster where the hole is. That's still worth something. You would much rather find the hole during your own weekly pull than have a customer's quality engineer find it on a Thursday afternoon.