Passing Both IEC 62133-2 and UL 2054 on One Pack Program

Settle the scope before you fund the testing. When a pack program has to answer both UL 2054 and IEC 62133-2, the expensive mistake is treating them as two lab orders instead of one requirement question: name one standard as primary in the specification, state whether evidence is needed at cell level or battery level or both, and get the customer's acceptance criteria for each in writing before anything is scheduled. A single lab can usually run both, but it issues separate reports and separate certificates, and neither one substitutes for the other.

There's a move I make every time a supplier writes "certified to both." I skip the certificate and open the test report to the scope section. The certificate is a one-page summary. The scope page is where the pack gets described down to the cell model and the protection board, and that's the page that tells you whether any of this applies to the thing you're buying.

You can do it in about ninety seconds. The scope section lists the product designation, the ratings, the cell manufacturer and model, the construction of the protection circuit, the fuse or PTC, and any limits the lab wrote down. Then it lists clauses tested and results. If the customer's requirement says IEC 62133-2 and your report carries an edition string without the current amendment suffix, you want to find that before the customer's engineer finds it. Same for UL 2054 — editions get revised, and a report to a superseded edition is one of the most common things I catch on a review pass.

The overlap is smaller than the table of contents suggests

Both standards contain a vibration test. Both contain temperature cycling, an external short circuit, and some form of abnormal charging. On paper that looks like a shared test matrix with a little extra bookkeeping around the edges. It isn't. The parameters differ — different acceleration profiles, different cycle counts, different short-circuit resistance and duration. You cannot staple one set of data to two reports.

What you can do is sequence the program so the harsher parameter gets run once and the lab confirms in writing that the result satisfies the corresponding clause in both standards. That is where the real savings live, and it requires the lab to map clauses to each other before the samples go in the chamber, not after. Ask for that mapping as a document. If a lab can't produce one, you're buying two independent programs whether they told you so or not.

The reports and certificates come out separate regardless. Different numbers, different letterheads, different revision histories. Plan the documentation set you'll hand to the customer at the end — usually a certificate plus a report per standard, plus the CB certificate if you're going that route — and check that the model designations match across all of them.

The level question sits inside each standard, not just between them

This is the one that burns people. UL 2054 is written to sit on top of cell-level testing, so a battery report assumes the cells underneath have their own evidence. IEC 62133-2 has cell clauses and battery clauses in the same document, which makes it easy to assume a cell report from that standard covers the pack. It doesn't. A cell report is evidence about cells. It is not evidence at the battery level in either standard.

When a customer names a standard, ask which level they want evidence at, and which cell-level standard they'll accept underneath it. A pack report that cites cell testing is only useful if it cites testing to the cell standard the customer's specification actually names. I've watched a program stall for a month over that single mismatch, with a perfectly valid battery report sitting in the file and nothing to put under it.

One more scope item worth a conversation with the lab: IEC 62133-2 carries the word "portable" in its title. Not every industrial pack is obviously portable, and a report that's out of scope isn't evidence of anything no matter how many pages it has. I don't resolve that question myself. I raise it with the lab early and get their position in an email I can forward.

What a CB certificate buys, and what it doesn't

Customers frequently accept an IEC CB Scheme certificate, with the accompanying test report and national differences, as evidence toward IEC 62133-2 compliance. That's the mechanism that keeps you from paying for the same work twice in three countries. Take it seriously as a cost lever, but understand what it is: a test-and-certify route, validated by an accredited lab, that many customers will accept at face value.

It is not a UL mark. UL 2054 certification with the mark carries Follow-Up Services — recurring factory inspections, a file held by whoever commissioned the testing, and an obligation to notify on construction changes. That recurring obligation is a real line item and it belongs in the supplier conversation at RFQ, not after the pilot build. The CB route doesn't carry it. If your customer's requirement is stated as "UL 2054 certified," ask specifically whether they mean the mark or the report, because the two have very different ongoing costs.

And neither one gets your pack on a truck. That's UN 38.3, a separate test with separate samples and a separate report. Buyers conflate them constantly.

Where the money actually goes

Testing fees are the visible cost. The ones that hurt are samples and schedule. Almost everything in both standards is destructive, so the packs that go into the chamber come out of your pilot build — and you need enough of them to cover the harshest test in each standard plus any retest reserve. I'd rather order extra samples at the pilot run than explain a four-week slip because the lab needed two more units.

The other cost is retest triggers. Change the cell vendor, the protection board layout, the fuse, or the firmware thresholds that govern protection cutoff, and you've changed the construction the report describes. Both standards care. So the second the design is frozen, that construction list becomes a control document, and any deviation from it should route through the change board with the test impact assessed before the change is approved, not after.

Which brings up the thing I always write into the spec now: a right to receive the full report, not just the certificate, plus any future revisions and notice of construction changes. The lab report is issued to whoever commissioned and paid for it. If that's your supplier, the certificate may be all you ever see — and the certificate won't tell you which cell model was actually tested.

Adding a standard after the design is fixed

This happens more than anyone admits. The customer's early correspondence mentions one standard; the purchase order or the letter of intent mentions two. By then the enclosure is tooled.

Treat it the way you'd treat any other requirement change, because that's what it is. Revise the specification, re-baseline the test plan, re-quote the samples and the schedule, and run it through the same change-control route a dimensional or firmware change would take. The failure mode I see is a program that absorbs a second standard as an informal favor to the customer, with no revision, no re-quote, and no schedule adjustment — then discovers at validation that the additional samples were never budgeted.

What I ask before I agree to fund two programs

Who names the primary standard, and does the specification say so in a line? If the customer names both, the spec needs a precedence statement: which one governs when the two standards apply different acceptance criteria to a similar test. Without that, you find out which one governs during a failure.

What evidence will be accepted for each — report, certificate, or CB certificate with national differences?

At what level, and citing which cell-level standard underneath?

Which edition and amendment of each?

Which lab, and is its accreditation scope current for both standards at both levels? A report from a lab that isn't accredited for the standard is worth less to some customers than no report at all.

Who holds the file, and do I get the report?

Put the answer in one paragraph of the spec

When all of this is settled, the resolution isn't two purchase orders at a lab. It's a short block in the specification: primary standard, secondary standard, precedence rule, level of evidence required for each, edition and amendment, accepted evidence type, and who holds the documentation. I've watched that paragraph end more arguments than any test result ever did — because when the customer's quality engineer asks why a report says one thing and a certificate says another, you're not defending a judgment call. You're reading them the requirement.