The Battery Standard Clause Most AGV Pack Specs Get Wrong

The clause that gets mangled most often in an AGV pack requirement is the one-line standards sentence — "pack shall comply with UN 38.3, UL 2271, and IEC 62133-2" — because it wraps three different scopes into a single claim, and none of the three can be verified from the other two. UN 38.3 attaches to the cell and to the pack as offered for shipment. UL 2271 attaches to a battery as installed in a light electric vehicle, which is why so many AGV and industrial vehicle customers name it. IEC 62133-2 attaches to the cell, the pack, or both, and only the requirement itself can say which. The fix is mechanical: split the sentence into one clause per standard, state the scope inside each clause, name which party holds the certification file, and require the evidence — a test summary, a certificate with a file number, a configuration description — to arrive with the quote instead of after the purchase order.

I keep a folder of quote packages like that, and the compliance tab is almost always one page. Last spring I had a 48 V, 30 Ah pack in front of me for an AMR class that runs two shifts, and page 41 of the quote said the pack complied with UN 38.3, IEC 62133-2, and UL 2271. Three logos in a row. No cell part number. No enclosure material. No file number. When I asked the sales engineer which configuration the UL listing covered, he didn't get defensive. He got quiet, then offered to check with engineering. That pause is the whole problem. He wasn't hiding anything — his template has one line for standards, and every customer before me accepted it.

The reason that line survives is that it looks finished. Logos read like stamps. They are not. A stamp tells you a document exists somewhere; it does not tell you what the document covers, who owns it, or whether it still describes the thing you are buying six months later. Those three questions are the entire job.

Three standards, three different objects

Before I write anything into an RFQ, I sort each named standard by what object it attaches to. UN 38.3 is a transport test. It applies to the cells and to the pack as offered for shipment, which means it is not a statement about how the pack performs in your vehicle across 4,000 charge cycles. It is a statement about what happens to the cell and to the pack when the shipment is subjected to the conditions the transport regime cares about. Different object, different purpose. If a supplier sends a certificate when I asked for a UN 38.3 test summary, that tells me the compliance person answered a different question than the one I asked.

UL 2271 is the one industrial vehicle customers write into their own equipment specifications, which is why it shows up in AGV and AMR programs so often — it addresses batteries for light electric vehicles. UL 2054 addresses the pack as a commercial battery, and it is a different scope with a different construction and abuse philosophy. A pack can carry one and not the other, and a customer who put UL 2271 on a drawing is not satisfied by a UL 2054 file, even if both are real and current. This is not a certification-body question. It is a scope question, and scope is decided by whoever wrote the requirement.

IEC 62133-2 is the one that trips people because it is genuinely ambiguous until you pin it. Customers placing the equipment outside the United States frequently name it, and depending on the program it lands on the cell, on the pack, or on both. Cell-level testing does not flow through to the pack, and pack-level testing does not cover the cell. If the requirement says "IEC 62133-2" and nothing else, you have left the most consequential word in the sentence blank, and the supplier will fill it in with whichever one they happen to hold.

Also worth writing into the clause: the edition year. Customers routinely cite "IEC 62133" with no revision, and an old file may not be the document their reviewer is holding. I ask the customer's engineering contact to confirm the edition they mean, in writing, and I put that edition into the requirement. Two minutes of email that saves a re-qualification argument later.

What I ask for with the quote

This is the part that changes behavior, because the artifact request has teeth. Nobody can produce a test summary in an afternoon if it does not exist.

For UN 38.3, I ask for the test summary for the cell and for the pack as offered for shipment. The summary is a specific document: it describes the cell and the pack, it lists results against the individual tests, and it carries a date. A logo is not that. I have had suppliers pull it out of a folder during the call, and I have had others go dark for two weeks. The quiet ones are informative, and they are cheaper to find now than after the tooling is committed.

For UL and IEC, I ask for the certificate plus the scope statement on it, and I ask for the file number.

The file number is the part people skip

The file number matters because it is the only thing in the package you can check yourself. A certificate PDF can be cropped, re-dated, or simply old. A file number can be looked up in the issuing body's public listing, which is where you find out whether the file is active, what it covers, and which configuration it describes. I do not take a PDF as the end of the conversation. I take the number, look it up, and then compare the scope in the listing against the cell, BMS, and enclosure in the quote.

Then the ownership question, which is where I have seen the most expensive surprises. Sometimes the cell maker holds the file and the pack assembler does not. Sometimes the assembler holds it and the cell maker does not. Sometimes an integrator holds a file for a configuration that is close to yours but not yours. If the file sits with the cell manufacturer, its scope may explicitly exclude the assembled pack, and the pack builder may be relying on it as if it transfers. It does not transfer automatically. I want the quote to name, in plain words, which legal entity holds each file — and I want that named in the purchase agreement too, not just in the quote, because the quote has a shelf life and the file does not.

The configuration is frozen. Your program is not.

Every one of these standards was tested against a configuration that was frozen at the moment of testing: a specific cell part number, a specific BMS, a specific enclosure, a specific set of protection thresholds. Your program will change. A cell goes on allocation and someone finds a second source. A BMS gets a firmware revision. The enclosure moves from one material to another for cost or thermal reasons.

Any of those changes can put you outside the configuration the document describes. In my experience this is not usually dishonesty. It is a change-control gap: the supply chain team swaps a cell, the compliance file stays where it was, and nobody connects the two conversations until a customer audit connects them for you. The supplier is not being evasive on that call. They simply do not have a process that treats the certificate as part of the bill of materials.

So the requirement should say it out loud: no substitution of cell, BMS, protection thresholds, or enclosure without written notice, and no shipment of a changed configuration without the applicable documentation re-verified. I do not dictate the test method or how the supplier proves it — that is their engineering call, and it varies by program size. I dictate that the notification happens and that the file gets revisited. Who absorbs the cost of that revisit is a commercial term, not a technical one, and it is worth negotiating before there is a shortage forcing the question.

It depends, of course, on scale. For a twenty-unit pilot at a single site, I might accept a cell-level file plus a written statement from the pack builder on letterhead, and revisit at fleet scale. For a rollout across multiple sites over several years, I want the pack-level file, the file number, the named holder, and a change-notification trigger in the supply agreement. Same standard, different evidence weight, decided by how long the pack will be in service and how many places it will be.

Wording you can paste in, and then adjust

This is roughly what goes into my RFQs. It is short on purpose; long compliance sections get skimmed past.

> Pack shall be supplied with a UN 38.3 test summary covering the cell and the pack as offered for shipment, describing the configuration quoted. Pack shall carry [UL 2271 / UL 2054, as required by customer specification] listing; the file number shall be stated in the quote and the certificate scope shall name the cell part number, BMS revision, and enclosure specified herein. IEC 62133-2 applies to [cell / pack / both] per the customer requirement attached; certificate and file number to be provided. The party holding each certification file shall be identified in the quote. No change to cell, BMS, protection thresholds, or enclosure without written notice and re-verification of the above.

Three things about that block. First, the brackets are not laziness — the blanks are where the requirement actually does its work, and filling them requires a decision from you or from your customer, not from the supplier. Second, every clause has an artifact attached to it, so a supplier cannot answer the whole thing with the word "yes." Third, it fits on half a page, which means it gets read.

One more thing I do, because it has saved me twice. I ask the supplier for the name of the person who will answer questions about the file after the sale. Not the sales engineer. The compliance or quality contact. Sales engineers move accounts and change jobs, and the person who takes over has no memory of the conversation. Having a name in the file means that when the customer's reviewer asks a question eighteen months in, the question goes to someone who already knows the answer.

Why this sentence carries so much weight

Everything downstream reads back to the standards clause. The customer's safety review reads it. The site acceptance test reads it. The field failure investigation reads it — if a pack vents or a BMS locks out, the first question is what configuration was actually verified and against what. The clause is the only place in the entire specification where you recorded what you verified versus what you assumed.

That is a two-line fix on the front end and a very expensive reconstruction on the back end. I would rather spend an hour sorting three standards into three clauses than spend a quarter explaining why the certificate we filed does not name the cell we shipped.