Does your robot pack need IEC 62133-2 certification?

A robot pack needs IEC 62133-2 when a customer specification, an insurer, or a global market-access plan names it — and from that moment the thing you are procuring stops being a test and becomes a document set: a current CB test certificate, the full report behind it, and a description of the exact configuration that was tested. The failure mode is almost never a pack that failed the standard. It is a buyer who filed the certificate once, kept releasing purchase orders against it, and never noticed that the scope lines stopped describing what was actually shipping.

I keep every pack I have bought in a folder tree organized by part number, and every one of those folders has an evidence subfolder. The certificate sits in there as a PDF. That is not the useful part. The useful part is a plain table I rebuild by hand whenever anything about the pack changes, and it has four columns: what the certificate says the product is, who it says manufactured it, where it says it was manufactured, and which edition of the standard the report actually tested to.

Open a CB test certificate and read those four lines before you read anything else. Not the certificate number. Not the issue date. The date is the line everybody checks first and the line that tells you the least, because a certificate can be perfectly current and still not cover the object sitting on your receiving dock.

The scope lines do the work

The product line is where people get caught first. IEC 62133-2 is the lithium-specific part of IEC 62133, and it is written in two halves — requirements for cells, requirements for batteries. A certificate will tell you which half was evaluated. A certificate covering the cell inside your pack is not a certificate covering your pack. I have watched that exact confusion survive three rounds of review because both documents say "IEC 62133-2" across the top and nobody read the scope paragraph underneath.

Then the manufacturer line. Not the brand. The legal entity the certificate was issued to. If your purchase order is going to a trading company while the certificate names the factory, you have a gap, and it is the kind of gap that only becomes visible when someone downstream asks you to produce the evidence chain.

The site line is the one that goes stale without anyone touching the design. Nobody issues an engineering change order to move an assembly line from one plant to another. It happens for capacity reasons, and the certificate still says the old address, and it still looks fine in the folder.

And the edition line. The base edition is IEC 62133-2:2017, with a later amendment. What was tested is what the report says was tested. If your specification says "latest edition" and the report says the base edition with no amendment, you have a mismatch that a reviewer will find even if you did not.

UN 38.3 is not a substitute, and it is not a companion

Both documents arrive in the same email, which is why they get filed as though they answer the same question. UN 38.3 comes out of the UN Manual of Tests and Criteria and it answers a transport question: can this article be offered for shipment. Passing it tells you nothing about in-use product safety. I have seen a program get three shipments deep with a UN 38.3 test summary in the part file and a blank space where the safety evidence should have been, because someone saw a test report with "lithium" in the title and stopped looking.

Keep them in separate subfolders. It sounds pedantic. It is the single cheapest way to stop the substitution from happening.

Why the certificate and not the lab report

The certificate is the deliverable because of what it can become. CB test certificates are issued under the IECEE CB Scheme by national certification bodies, and they exist to be converted into national certifications. In the United States, IEC 62133-2 has a corresponding UL adoption that an NRTL can issue as a national certification. That conversion path is why the RFQ evidence list asks for the certificate rather than a raw laboratory report, and it is why a supplier who can only produce a report and a shrug is not actually answering the question you asked.

So the evidence list I put in an RFQ has three items, not one:

• the current CB test certificate
• the full test report the certificate points to
• a description of the tested configuration, written by the supplier, specific enough that I can compare it against the part I intend to buy

That third item is the one suppliers push back on, and it is the one that saves the most time later. A test report describes a configuration. If you cannot tell from the paperwork whether the tested configuration had the same cell, the same construction, and the same enclosure as the part you are ordering, you have not verified anything — you have verified that something with a similar name passed.

The part file is where this actually lives or dies

Here is the part I would tell a new buyer on their first day, and it is the part most explanations skip entirely.

The certificate is not a milestone. It is a piece of state that has to stay true. I keep it as data, not as a document: a row in the part file that records the four scope fields, plus a revision column, plus a short note on what triggered the last re-check. When someone opens an ECO, the row is part of what they are looking at. When sourcing proposes a second cell source because allocation got tight, the row is part of what they are looking at. When the program decides to shift assembly, the row is part of what they are looking at.

Those three events — a cell change, a site change, a construction change — are the ones that quietly invalidate a certificate while the PDF keeps saying it is valid. Nothing expires. The scope simply stops matching the object.

I learned to write the check as a question rather than a rule, because a rule gets skipped and a question gets answered: does the evidence on file still describe the part we are about to buy? Three answers are possible, and only one of them is "yes." "Yes, and I can point to the line" is a good day. "It should still be fine" is not an answer, it is a feeling, and feelings do not survive an audit. "No, and here is what changed" is actually the best outcome, because you found it before the customer did.

It depends, and here is where

Not every pack needs this. If no specification, no insurer, and no market-access plan names IEC 62133-2, then the standard may simply not be in your program, and buying evidence you were never asked for is its own kind of waste. The uncomfortable version of that situation is when you discover it late — a customer program manager mentions it in a kickoff call and now it is on the critical path instead of in the RFQ.

The harder tradeoff is what to do when the scope no longer matches. Re-testing takes time and disrupts a build schedule, and it is not automatically the right call. Sometimes the change is genuinely outside what the certificate covers, and there is no path but new evidence. Sometimes the configuration is unchanged in every way the report cares about, and the honest move is to document why the existing evidence still applies. Sometimes the answer is a conversation with the customer about what they will accept. I have done all three, and the only version I regret is the one where I did not notice, because that version is not a decision. It is a surprise with your name on it.

What I actually check

Once a quarter, on any pack in active production, I open the table and read the four lines again. It takes minutes. I check it against the current revision of the drawing, the current supplier of record, and the current manufacturing site. If any of the four has moved, the row gets a note and the question gets asked.

That is the whole practice. The certificate is a procurement artifact with a lifecycle. It is born in a customer specification, it gets shaped by the RFQ evidence list, it lives in the part file, and its job is to stay true after the first production shipment — which is exactly the moment everyone stops looking at it.

The test happened once, in a lab, before you were involved. The certificate and the report are what you actually own, and they are only worth what they cover.