When the customer spec adds IEC 62619 on top of IEC 62133-2

When a customer spec adds IEC 62619 on top of IEC 62133-2, the work is a scoping job, not a document request. Build one combined test matrix before the RFQ goes out: map every requirement from both standards onto a single sample plan, pin the edition of each standard in writing, and name the exact evidence format the customer will accept. Done that way, the overlapping tests run once, the 62619-only tests get priced as NRE at quote stage, and the gap does not surface for the first time in an audit room.

The customer's spec is open on the left of my screen and the supplier's quote is on the right, and the distance between them is one line. Scroll with me to the section near the back headed Additional Requirements. Third bullet: IEC 62619. Now look at the right screen. The quote's scope line reads "compliant to IEC 62133-2," with an asterisk, and the asterisk resolves to "or equivalent."

Nothing in that quote is dishonest. The supplier quoted their default, because the pack specification I sent them listed one standard and the customer's specification listed two. That 62619 bullet was sitting in a PDF nobody had converted into a line the supplier was obliged to price, schedule, or build samples for.

That is the whole problem in one frame. The customer hands down a list. Somewhere between their document and the RFQ, the list shrinks. What comes back is responsive to the document I sent and not to the document they sent.

The requirement only exists where the RFQ puts it

A customer's standard list is a flow-down item. It travels from their specification into my pack specification, from my pack specification into the RFQ, and from the RFQ into the supplier's test plan, their NRE line, and their sample build schedule. Break the chain anywhere and the requirement quietly disappears, because no supplier volunteers a test they were not asked to run.

I stopped trusting a sentence for this. A sentence like "battery shall comply with all applicable standards" means nothing on a quote. What works is a table in the pack specification itself: standard, edition, evidence required, responsible party. When that table exists, the supplier's quote either addresses each row or it visibly does not, and I can see the shape of the program before anyone signs.

The other thing I do now is ask who actually owns the requirement on the customer's side. Sometimes the person who wrote the spec can tell you whether 62619 is a hard gate or an artifact of a template inherited from their own customer. That answer changes how much money the row is worth. It does not change whether it needs to be scoped, because a template artifact still has to be satisfied or formally waived in writing, and "we assumed it did not apply" is not a waiver.

Overlap is where the cost sits

The two documents ask for many of the same abuses. External short circuit, crush, thermal abuse, overcharge, drop, vibration and shock. The preconditions and sample counts are close but not always identical, and that word "close" is exactly where inexperienced programs lose money.

Run the two standards as two programs and you get two sample builds, two laboratory queues, two reports with different serial numbers and different build dates, and an argument later about which document is the governing evidence. Run them as one matrix and the same physical abuse satisfies both, provided the sample plan was designed to feed both sets of requirements from the start. Destructive tests consume hardware, so the sample count has to be settled as part of the matrix, not discovered when the lab asks for three more packs.

A rough shape of how the matrix looks in my spreadsheet:

Test	Called for by	Sample	Destructive	Evidence row
External short circuit	both	cell	yes	report section
Crush	both	cell	yes	report section
Thermal abuse	both	cell	yes	report section
Overcharge	both, different emphasis	battery	yes	report section
Drop	both	battery	sometimes	report section
Propagation	62619 only	battery plus trigger cells	yes	report section
BMS overcharge protection	62619 only	battery plus BMS	no	report section

I keep clause numbers out of that table unless I have pulled them from the standards myself that quarter. A wrong clause reference in an RFQ annex is worse than no clause reference, because the supplier will test to the number you gave them and nobody will check it until the evidence lands on a customer's desk.

The question I put to the lab is not "can you test both." Any lab says yes to that. The question is: can this be one sample plan and one test sequence, and if not, exactly which tests force a separate build? The answer is what tells me whether the quote carries one sample build or two.

Propagation is the line item that changes the schedule

Of everything on that matrix, the 62619-only block is where the surprises live. Propagation testing is destructive by design, it needs dedicated hardware and trigger cells, it consumes chamber time, and it can fail. A pack that passes every single-cell abuse test can still fail propagation, and the fix is mechanical or thermal — spacing, barriers, materials — which means a design change and a second round of samples.

That risk belongs in the quote, not in the four weeks before the first shipment. I want it as a separate, visible NRE line with its own schedule and its own pass criteria, so that when the program manager asks why the pilot slipped, the answer is a line item that was on page two of the quote from the beginning.

A standard the supplier has never been tested against is not a document request. It is engineering time, sample hardware, chamber hours, and a place in the lab's queue. Treating it as paperwork is how a two-week document task turns into a ten-week schedule problem.

Pin the edition, or the lab will pin it for you

Here is a small conflict that has cost me a week of my life. A specification pins IEC 62133-2:2017 with no mention of its later amendment. The laboratory tests to the current published requirements, because that is what an accredited lab does. The customer's receiving inspector checks the report against the edition text in their own specification. Now the evidence is correct, current, and formally non-responsive at the same time.

The fix is boring and it has to happen before the quote. Get the edition confirmed in writing, along with the amendment level, and get written acceptance of the current edition if the customer's document is behind. If they insist on the older text, that is a delta you can price. What you cannot price is finding out at the audit.

The same logic applies to the evidence format. A CB test certificate, a full test report, a declaration of conformity, or all three is a decision the customer owns, and they often have not made it. A certificate is scoped to a specific manufacturer's specific construction and model. A certificate covering the cell inside the pack is not evidence for the pack. I have watched a program with a perfectly good cell certificate and no pack evidence whatsoever, and the paperwork looked complete right up until somebody read the scope page.

One more thing that gets missed: the evidence is tied to a configuration. The cell part number, the BMS hardware revision, the firmware build. Change the firmware after the report is issued and the overcharge-protection evidence describes a product you are no longer shipping. On a custom robot pack the firmware moves. Somebody has to own the question of when a change invalidates the evidence, and that somebody is usually the buyer, long after the purchase order closes.

What the audit actually feels like

There is a version of this where it takes ten minutes. The auditor opens the customer specification, reads the standards list, and asks for the evidence for each one. I hand over one report with a cross-reference page at the front that maps each standard's requirements to the section of the report that satisfies it, one set of sample serials, one build date, one firmware revision. They check three sections, ask one question, and move on.

There is another version. Two reports from two labs, two sets of sample serials, a firmware revision in one report that matches nothing in the build record, and a certificate whose scope page names a cell rather than a pack. That version takes a day and ends in a corrective action, and the corrective action lands on the buyer, not on the lab, and not on the supplier who tested to the document they were given.

I have been in both rooms. The difference was not the quality of the battery. It was whether somebody built the matrix before the RFQ.

How I write it now

Every RFQ I send carries a one-page standards annex. Standard name, edition, evidence format, who builds the samples, whether the test is destructive, and whether it is an NRE item. Deviations and waivers go through the same page, in writing, with a name and a date attached.

It is one page. It takes me maybe forty minutes to build. It has saved more schedule than any other document in the program, because it turns a customer's list of standards into something a supplier has to quote against, a lab has to schedule against, and an auditor can check against. Same evidence, one program, priced once.