The Proven Decision Tree For A Supplier Change Notice

A supplier change notice arrives like every other supplier email, and that is the trap. For an intermediate that touches the API, the change described in that note can quietly re-write the impurity profile, the lead time, or the regulatory file. Once a buyer treats the notice as a tick-box, that same buyer ends up discovering the change six months later in a failed API batch or a regulator’s question.

A checklist does not work here. The call on a change notice is rarely binary — the same notice can be fine for one intermediate in one project and unacceptable for the same intermediate in another. What buyers need is a decision tree, not a list. The seven sections below walk that tree, branch by branch.

The decision starts with what the notice has to identify

Before any branch is taken, the first task is to extract five elements from the notice. If any of them is missing, the call is already made: the notice goes back to the supplier for more information.

From the manufacturer side, notices from direct customers tend to be cleanly written because the writer knows the buyer will file the notice under a quality agreement. Notices from third-party producers, where the relationship is thinner, are where the five elements get compressed. The reading habit that follows is to check the five elements first, before reading the body. This is also where which documents the change forces you to refresh starts to matter: a change without a document trail is a change a future buyer cannot audit.

Branch one: the notice you can accept as filed

The first branch is the simple case. Three conditions have to hold at the same time. The timing must allow a written response and a real incoming review. The change cannot reach a registered step or a registered specification. The supplier’s own data, or the pilot data submitted with the notice, must show the changed attribute stays within the existing control range.

If those three hold, the call is to accept the notice as filed, log it against the quality agreement, add the new version of the affected document to the register, and move on. This is also where how the CoA gets reread after a process change becomes routine, because the next incoming CoA is the first live signal of whether the change has altered the profile. Spot-check the CoA against the previous one. If assay, residual solvent, water content, and total impurities sit inside the historical range, the change has carried through cleanly.

Accepting does not mean discarding. One subfolder per intermediate, opening with the qualification documents and continuing chronologically with the change notices, lets any reader tell at a glance which set is live. One last check — whether the change shortens the retest window. A change to a packaging format or storage condition can shorten the retest window without shortening the labelled shelf life.

Branch two: the notice you have to contest with conditions

The second branch is the most common case in practice. A notice reaches it when any of the three acceptance conditions is partially met — timing tight, document set incomplete, or supporting data silent on at least one quality attribute. None of these is a refusal. All of them are a reply with conditions.

A reply with conditions has three parts: confirm what the buyer accepts, state the conditions to be met before implementation, and set a date by which the conditions have to be satisfied or the response reverts to a refusal. The third part is what most buyers skip, and it is what makes the difference between a working contest and a vague complaint.

Two real-folder examples show the kind of conditions that show up. A route change where the new route uses a different reagent supplier but the notice does not address elemental-impurity carry-over — the condition is to submit the assessment before the change takes effect.

A site change where the new site has not been audited against the same quality system — the condition is to share the most recent audit summary and to commit to incoming-CoA comparison for the first three commercial batches.

This is also where when a change breaks the basic compliance picture shows up. A change that quietly breaks that picture has to be escalated, not answered with conditions alone. If the escalation does not close before the effective date, the notice has to be refused regardless of how workable the change looks on paper.

Branch three: the notice you have to refuse

The third branch is rare but unavoidable. Three conditions lead here: the change modifies a registered step in the API synthesis and the regulator must be notified before implementation; the change introduces a new impurity, a new residual solvent above the ICH Q3C limit, or a new process hazard the supplier’s data does not cover; or the supplier’s internal review has not closed and the change is being announced in advance of their own quality decision.

Refusing is hard because it is the branch that breaks the commercial relationship in the short term. Two habits make refusals survivable: write the refusal in the same shape as a contest (name the conditions, set a date, keep the door open to re-evaluation), and back the refusal with a document, not a memory. A refusal based on memory has to be re-argued by the next reviewer; a refusal based on a document reappears on file the next time the supplier sends the same notice with a different date.

A common version of this branch is when the buyer has been living with an undocumented tolerance — a parameter operating outside the registered specification but tolerated because the data sat inside the historical range.

A change notice arrives that would formally widen the registered tolerance, and the buyer realises the tolerance has been quietly broader than registered for some time. This is where when accepting the change starts a switching project comes into view. The right answer depends on whether a second qualified source is ready to pick up the volumes at the same registration.

Logging the call is the audit trail that survives the next inspection

Once a call is made, the next inspector, supplier audit, or internal handover will reach for the file. What is in the file determines whether that reader can re-construct the call. A call without a log entry is a call that was effectively never made.

A working log entry carries at least eight fields: the date the notice was received, the supplier’s and buyer’s references, which of the five elements from the first section were present or missing, the branch the call was made under, the reasoning in two or three sentences, the decision-maker and approver names, the deadline for any conditional reply, and a link to the storage location of the new document versions. These can be a structured template or free text covering the same items.

The audit value of the log is how the change feeds into the supplier scorecard, not the log itself. Scorecards work because the log gives them data. Without the log, the scorecard becomes a sentiment. The log also drives the additional tests the change puts on incoming QC. A single additional gravimetric test on incoming is cheap insurance when the change leaves the intermediate in spec but raises a dust-related extractable.

When the change quietly is a discontinuation, the tree branches wider

One branch deserves its own section because it shows up more often than buyers expect. A change notice is not always about change — sometimes it is the first signal that the supplier intends to discontinue a particular intermediate. The language is identical; the underlying driver is different.

The way to spot it is to read the notice in the context of the supplier’s broader pattern, not the change in isolation. A supplier replacing a reagent or a process solvent with no change to the impurity profile is doing continuous improvement. A supplier consolidating two intermediates into one route, switching from a dedicated campaign to a shared reactor, or moving from in-house to contract-manufactured production is signalling something closer to when the change quietly is a discontinuation.

Neither observation is in the notice itself. They come from the buyer’s running picture of the supplier, built up over multiple change notices across multiple intermediates. A buyer who keeps the log integrated with a supplier-level view starts to see these signals a year before the eventual discontinuation letter.

This is the branch where the decision tree connects to two larger projects: the moment the change makes the backup source urgent, and the wider risk register across the buyer’s portfolio. Both become the active plan once a discontinuation pattern is visible. The single most expensive mistake on this branch is treating the notice as a one-off change.

Put the change-notice clause into the next quality agreement review

The decision tree ends at a single, durable place. Each call has to be supported by a quality agreement clause that backstops the call for future notices. Without that backstop, every call is a negotiation; with it, the call is a routine exercise of a pre-agreed procedure.

Five short clauses do most of the work: a notice-period clause, a categorization clause requiring the supplier to classify the change as minor, moderate, or major with supporting data for major changes, a documentation clause listing the five elements as required content, a document-update clause tying implementation to the buyer’s receipt of updated versions, and an escalation clause naming the contact, medium, and timing for a formal rejection.

A clause buyers sometimes forget is the records clause. The supplier keeps the change-notice file accessible to the buyer for as long as the intermediate is in the buyer’s API qualification, and the buyer has the right to audit that file during the supplier’s internal audits. With this clause, the buyer’s quality agreement can be cross-referenced with the supplier’s folder during joint reviews, and the decision tree becomes a routine operation rather than a fresh negotiation each time.

The next supplier review is also the moment to ask how the supplier handles change notices from their own suppliers. Suppliers with a clean internal process write cleaner notices, and the buyer’s incoming folders benefit directly.

Running a decision tree over change notices turns a routine inbox task into a governed process. The clauses belong in the quality agreement, the reasoning behind each call belongs in the log, and the wider picture belongs on the buyer’s file at the level of the supplier. A change notice that arrives tomorrow is then routine — the kind of procedure that protects the next six months of API supply without depending on the buyer’s memory.