Your Battery Supplier's UN 38.3 Summary May Not Cover Your Pack

A UN 38.3 test summary is evidence only when the model designation printed on it resolves to the exact pack on your purchase order — same cell, same BMS, same housing, same protection circuit — and when that designation traces to a report number and, if a UL mark is claimed, to a file entry whose Conditions of Acceptability your configuration actually meets. Without those two links the document is a cover sheet with a lab logo on it. It points at proof; it is not proof, and the audit is the act of following the pointer until it stops moving.

Here is the half hour where that gets decided. I have the pack datasheet in one window, the PO in a second, and the supplier's compliance PDF in a third, and I am looking for one string of characters in all three: the model. When they don't agree, I stop reading the results. Not because anyone lied, but because I can no longer tell what was tested, and a test I can't attach to a part number is a test I can't use.

The pattern repeats often enough that I've stopped being surprised by it. The summary line reads something like RBT-48100 Series. The datasheet and the PO say RBT-48100-2B. The supplier's engineer, when I ask, says the -2B is the same pack with a different connector and a revised BMS board, and yes, it's covered by the same summary. Maybe. That is exactly the question the rest of the audit exists to answer, and the answer is never in the summary itself.

The summary is thin on purpose

The first thing to internalize is that a one-page test summary is a transport document. The format exists so a forwarder or a carrier can see, quickly, that someone tested something to the UN Manual of Tests and Criteria. It is written to be handed out freely, which means it is written to leave out the construction detail — cell make and model, series and parallel count, BMS part number, housing material, protection topology — that would tell you whether your pack is the tested pack. Those details live in the full report, and the full report is usually marked confidential.

So when the summary is vague about configuration, that is not automatically evasive behavior. It's the document doing its job. What matters is what the supplier does when you ask for the next layer down.

What has to be on the page before the results mean anything

A usable summary identifies the cell model and the battery model separately, names the test laboratory, gives the test report number and date, and lists the eight tests with a result against each. I read those identifiers before I read a single pass line.

The lab name is doing real work. If it's a lab I recognize from other programs, I have a rough sense of how carefully the sample was characterized. If it's unfamiliar, I ask for the report number and whether the report is available under NDA, and I treat an unexplained refusal as information.

Then the T1 through T8 lines: altitude simulation, thermal cycling, vibration, shock, external short circuit, impact or crush, overcharge, forced discharge. On a pack-level summary, T6 and T8 usually don't apply to the battery itself. When I see them filled in with a pass anyway, I ask which report that line came from. Nine times out of ten it's the cell report, which is legitimate, but it tells me the summary was assembled from two documents rather than transcribed from one, and assembly is where the wrong model number gets pasted in.

I also ask for the cell's own UN 38.3 summary, because the pack summary normally cites the cell test report by number. Trace the number. If the cell report is for a different cell model than the one on the datasheet, the pack summary has just described a pack you are not buying.

The UL file is where the constraints actually live

A UL file number is the most useful twelve characters in the whole packet, and almost nobody checks it. Take the E-number off the certificate, open the UL Product iQ directory, and look up the file. You get the manufacturer of record, the model list, the standard, and — the part that matters — the Conditions of Acceptability.

Read those conditions slowly. They are the constraints under which the listing holds, and the language usually runs along the lines of a battery evaluated only with a specific charging circuit, or only with a named cell, or in an enclosure that was not part of the evaluation. If your robot puts the pack in a sealed aluminum cavity with the charger integrated into the vehicle harness, and the condition says the pack was evaluated with an external charger, you have found the gap before your customer's safety reviewer finds it.

Two other things fall out of the directory lookup. First, the manufacturer of record is often not the company you are buying from. That is normal in this supply chain — trading companies and integrators resell factory listings — but you need to know whose name is on the file, because that is who answers a question about the file three years from now. Second, the model list is short. If your part number isn't on it, the mark on the datasheet is being borrowed, and borrowed marks are the single most common finding in a pack audit.

Which standard applies is a scoping question, not a document question. UL 2054 covers household and commercial battery packs; UL 2271 covers batteries for light electric vehicles, and an AGV or a large AMR can reasonably be argued into either frame depending on how the site and the safety reviewer classify the machine. I settle that before the RFQ closes, in writing, with whoever is going to sign off on the installation. Discovering at FAT that your customer's reviewer expected the other standard is a schedule problem, not a paperwork problem.

IEC 62133-2 shows up separately, usually because an end customer or an overseas site mandates it. It is a different standard with a different scope and a different report. A supplier holding a valid IEC 62133-2 report for the cell does not automatically hold one for the pack, and the pack is what you are installing.

The tested pack was built once, by hand

Every compliance packet describes a sample. The sample was assembled for the test, possibly with a machined housing, possibly with a BMS from a pilot run, possibly with cells from a lot that no longer exists. The production pack is a different object with the same name, and the distance between them is the risk you are actually buying.

So I ask for three things beyond the certificates. A written configuration statement: cell manufacturer and model, cell lot traceability on the first production run, BMS part number and firmware revision, housing revision, and the protection circuit topology. A change log covering the last two years, with each change marked as evaluated or not evaluated for recertification, and a name against that judgment. And a plain answer to the question, asked out loud on a call: if you substitute a cell vendor next quarter, who decides whether the pack needs to be retested, and will you tell me before the shipment or after?

Firmware is the one people forget. A BMS firmware change can move the overcharge cutoff, the cell balance behavior, and the fault thresholds — all of which are inside the tested envelope. I want firmware revision in the configuration statement and in the receiving inspection record, not just on a sticker.

Revision control, and the radio hiding in the BMS

A compliance document that cannot be revised is a compliance document nobody owns. I want a document number, a revision letter, an issue date, a signature block, and a scope statement that says which models the document covers. A PDF with no revision history is a PDF that will still be circulating after the pack changes, and it will look exactly as convincing then as it does now.

If the BMS has any wireless function — telemetry, CAN-to-WiFi bridging, a cellular gateway for fleet data — there is an FCC authorization in the packet somewhere, and it needs the same treatment. Look up the FCC ID, confirm the grantee, confirm the module part number matches the board in the pack, and check whether the grant is a modular approval with conditions about the host enclosure and antenna placement. An AGV with a metal chassis and an antenna placed against it is a different RF environment than the test bench, and if the module was granted with conditions, the integrator is the one who has to satisfy them.

How I run the audit itself

I don't ask for a compliance package and read it. I ask for a screen share and have the supplier's engineer open the full test report while I have the directory entry and the datasheet open on my side, and we walk the construction section line by line against the configuration statement. It takes about forty minutes. It is uncomfortable the first time and routine by the third program, and it produces a specific, checkable answer instead of a folder.

Everything that comes out of that call goes into one folder per program: the summary, the report, a dated printout of the directory entry, the change log, the signed configuration statement, the FCC grant if there is a radio, and a short note on what we verified and what we accepted as a stated risk. Then, at each purchase order, I re-check the directory entry and the BMS firmware revision. Not the whole audit. Just those two, because those are the two that move without anyone telling you.

The thing I keep coming back to is that none of this is about catching a liar. Most suppliers hand you a real summary for a real test of a real pack. The gap is almost always a naming gap, a revision gap, or a condition of acceptability nobody read — quiet, administrative, and completely capable of putting a pack on a robot that no lab ever saw.