The project started on schedule. Samples arrived, testing began, and two weeks in there is an email: additional test items are needed, and the final cost will be higher than the quote. This happens often enough that it is worth understanding exactly why - because the causes are not all the same, and the right response depends on which one you are dealing with.
There are three legitimate reasons a scope grows after a project starts: the product configuration changed, the original scope missed something that was always in the product, or something failed and needs a retest. There is also a fourth situation that is not really a cost increase at all - the original quote was vague, so the "increase" is just the scope becoming specific. Each one calls for a different conversation with the laboratory.
Reason 1: the product changed after the quotation
This is the most common cause, and it is usually invisible from inside the project. Engineering and purchasing keep improving the product while the certification file is open - that is normal product development. But a test report can only describe the configuration that was actually tested.
A typical sequence: a mains-powered device is quoted with one specific power adapter. While testing is underway, the purchasing team finds a cheaper adapter and switches. Nobody mentions it, because from the product side it is a trivial change. From the testing side it is not - EMC and safety results are tied to the power supply arrangement, and a report that names an adapter which is not the one you ship is a document that will not survive your buyer's compliance review. Covering the new adapter means adding the affected test items to the scope.
The same logic applies to smaller changes than people expect: a new charging cradle, an added cable set, a second model variant that shares the same housing but not the same board, a firmware update that changes how the radio behaves. None of these require restarting the project. All of them require checking which test items the change touches.
The expensive part is not the additional testing itself. It is the timing: samples for the old configuration are already logged, the new configuration needs new samples, and the schedule stretches by however long it takes to notice, communicate, and retest. The cost was optional; the timing made it painful.
Reason 2: the scope missed something that was always there
Sometimes the product does not change at all, and the cost grows anyway - because what was quoted was not what the product actually is. Two versions of this come up repeatedly.
The undeclared radio. A device is quoted as a simple battery-powered product, then the engineer reviewing the sample finds a Bluetooth chip that the quote never mentioned - perhaps a firmware feature that was planned, disabled in early builds, and forgotten in the paperwork. A radio is an intentional radiator whether or not marketing currently uses it, and once it is in the product, it has to be covered by the authorization and the report. Adding a radio mode to an existing scope is real work, and it is far cheaper than discovering the gap after your customer asks why the Bluetooth report is missing.
The sample that does not match the paperwork. The BOM says one thing; the samples in the lab contain different components - a substitute IC from a second supplier, a different crystal, a power stage revision. Labs run into this constantly: the production line sources alternates, and the documentation sent with the samples reflects the original design, not the shipped one. When the discrepancy turns up during review, the scope has to be corrected to match reality - which can mean additional components to cover in the report.
Both of these are "the quote was right for what we were told" situations. The fix is not arguing about who is at fault; it is making sure the scope now describes the product you will actually ship.
Reason 3: something failed, and the fix needs retesting
A failure does not automatically increase cost - but the retest after the fix usually does, and that is fair: the retest is new laboratory time on a modified sample. What matters commercially is the size of the retest. A fix that changes only the failing area - added shielding, a filter adjustment, a firmware timing change - normally only needs the affected item retested, not the whole scope repeated. A fix that changes the configuration itself - a new adapter, a redesigned board, a different antenna - may pull more items back into the retest than the one that failed.
This is why the failure conversation should happen before the fix, not after. If the laboratory sees the intended fix first, it can tell you the retest boundary: which items the change affects and which it does not. Deciding the fix alone and shipping samples back turns the retest into a surprise. If you want the process side in detail, we covered what happens after a product fails a certification test separately.
The fourth situation: the original quote was never specific
Occasionally the "increase" is not new work at all. If a quote says "EMC testing" without naming the standards, the test items, the configurations covered, and the sample count, then any number produced later is a guess that got refined. A quote that names one configuration and the quote that covers three configurations are different projects wearing the same title.
If a laboratory comes back mid-project with additional items, the reasonable first question is not "why is it more expensive" but "which items were added, and were they in the original scope". A laboratory that can answer that precisely - item by item, with a reason for each - is doing scope management. One that cannot is showing you what the original quote left out. The line-by-line anatomy of a proper quote is covered in what is included in a testing quote, and the reason two laboratories can quote the same product differently is covered in why quotes differ.
How to keep the scope stable from quote to report
Most mid-project cost increases are preventable before the project starts, with a short checklist:
- Freeze the configuration before asking for a quote. Adapter, accessories, every model variant, sample count. If engineering changes are still landing weekly, quote after they settle - or quote a range and expect to refine it.
- List every radio and every firmware mode. Not the ones you plan to launch with - every mode the shipped firmware can operate.
- Declare the alternates. If your BOM has second-source suppliers for key components, say so at scoping. It changes what the report needs to cover.
- Flag the version status of documents. A draft manual is fine as long as the laboratory knows it is a draft - the failure mode is a final manual arriving that describes a different product.
- Tell the laboratory immediately when anything changes. Even changes that seem trivial. The laboratory's job is then to say "this affects nothing" or "this affects these two items" - both answers are cheap. Silence is what makes them expensive.
One more practical habit: agree in advance how changes are handled. A scope-locked quotation - fixed price for the named configurations, any engineering change re-scoped separately with written confirmation before it runs - removes almost all of the friction described above. You always know what is included, and the laboratory never runs unquoted work.
That structure is how we quote on our testing and certification services: the scope names the configurations, and additions only happen after they are quoted and confirmed. When scope discipline is in place, the cost at the end is the cost on the quote.
If your project has grown a charge since it started, send over the original quote and what changed - a new adapter, an added accessory, a firmware or radio change, a failed item with its fix.
We will tell you which test items are actually affected, which are not, and quote only the difference - no full-scope restart, no unquoted work.
Send your original quote and the change for a scope re-check