A catalogue change mid-certification resets what you are filing

When a client adds or drops products while a file is open, the correct first move is to stop and re-scope. Not to amend the submission, not to email the change through, and certainly not to carry on because the application is nearly finished. A catalogue change alters what the application is actually describing, and everything already written was written about a different business.

This is uncomfortable because it usually arrives late, in passing, from someone who does not think they are telling you anything important. A client mentions on a call that they have started offering a new formulation. A monitoring check turns up a product page that was not there last month. The change is weeks old by the time it reaches you, and the file has moved on without it.

This is written for operators filing on behalf of others — agencies, telehealth platforms, MSOs, in-house teams managing a group of brands. If you are certifying your own business, you already know what you sell and when it changed, and the whole problem below is one you do not have.

Why a catalogue change is a scoping event#

An application is a description of a specific commercial activity. The product catalogue is not one field within that description; it is the thing the rest of the description is about.

Change the catalogue and you change the surface every other answer sits on. Clinical oversight answers were written for a set of products. Dispensing and fulfilment answers were written for a supply chain. Advertising and claims answers were written for what was being advertised. Site disclosure answers were written for pages that now have a sibling nobody reviewed.

That is why "we just added one item" is rarely just one item. The right question is not what was added, it is which existing answers the addition makes incomplete. Often none of them are wrong, exactly — they are simply narrower than the business now is.

Dropping a product deserves the same treatment for a different reason. A file that describes something the client no longer offers is inaccurate in a way that looks careless, and the fix is trivial if you catch it and awkward if you do not.

The open file and the live certificate are different problems#

If the application is still open, you are dealing with a document that has not settled. The work is to bring the file back into line with reality before it goes further, which means re-running the affected parts of your review rather than appending a note.

Expect this to cost more than it looks. A new product line typically pulls in fresh evidence, at least one new page on the client's site, and a re-read of two or three answers you had already signed off. It is a partial re-scope, and if your process cannot represent a partially re-opened file, it will get handled as an email addendum, which is how the inconsistency survives to submission.

If the certificate is already live, you are dealing with a settled description that has quietly stopped matching. The judgement is about scope: does the new activity sit inside what was certified, or beside it? That distinction is not yours to rule on definitively — LegitScript decides what its certification covers — but you can and should form a view, document your reasoning, and raise it rather than sit on it.

The disclosure instinct is worth building deliberately#

Teams new to filing at volume develop an instinct to minimise disclosure, usually out of a misplaced sense of protecting the client from complications. It is the wrong instinct and it compounds badly.

A change you raise yourself is an ordinary event in a file's life. A change found later is the same event plus a second, harder question about why nobody mentioned it. The first is a task; the second is a credibility problem, and credibility is the only asset an application-preparation service actually accumulates.

There is also a practical argument. When you raise a change, you get to describe it accurately — what it is, how it is supplied, what oversight applies. When it is discovered from a website, it gets interpreted from a product page written by a marketing team, which is almost never the most accurate description available.

Write the default down somewhere your reviewers can see it, because in the moment the pressure runs the other way. The client is anxious, the file is nearly done, and raising something feels like inviting delay.

Finding out late is what makes it expensive#

The cost curve here is steep and it is entirely about timing.

A change known at intake is a scoping input. It shapes the evidence request, the answers and the reviewer's mental model, and costs almost nothing beyond the work the file was always going to need. A change known mid-review costs a partial re-review and a round trip to the client. A change discovered after submission costs a correction, an explanation and whatever delay follows from it. A change discovered by somebody else costs all of that plus the conversation about why you did not know.

None of those steps are dramatic individually. Together they are the difference between a file that runs to plan and one that consumes three times the attention it was budgeted.

This is the practical case for monitoring a certified portfolio for drift even while files are open. Catalogue changes are visible on the client's own website long before anyone tells you about them, and a weekly diff on product listings turns a discovery into a notification.

What to capture the moment a change arrives#

When a change surfaces, the temptation is to react to it immediately. Capture it first — the reaction is better with the facts in front of you.

• What changed, in the client's words and in yours, with the specific product, dosage or service named rather than a category.
• When it went live, and whether it is currently being sold, listed as coming soon, or merely visible in a sitemap.
• How it is supplied and who provides clinical oversight for it, since these are the answers most likely to differ from the existing file.
• Which existing answers and pieces of evidence it touches, recorded as a list your reviewer can work through.

That last item is the one teams skip and the one that saves the most time. It turns a vague "the catalogue changed" into a bounded piece of work with a visible end.

Build the notification habit into the relationship, not the contract#

Every client agreement contains a clause about notifying you of material changes. Almost none of them work, because the person who adds a product has never read the agreement and does not know what material means.

What works is narrower and more human. Name a change contact at onboarding, and pick someone in operations or marketing rather than the executive who signed. Give them a short, concrete list of the changes you want to hear about — new product line, new dosage or formulation, new supplier or fulfilment partner, new service area, new site section. Ask for the notification through the same channel they already use with you, not a form they will have to find.

Then reinforce it. When a client tells you about a change, respond quickly and make the interaction pleasant, even when the change is trivial. A client who gets a warm, fast answer the first time tells you the second time. A client who gets a lecture about scope does not.

The structural version of this belongs in the front of your process rather than the back. If your intake already asks the catalogue question precisely, the client learns early that catalogue is a thing you care about — which is one of the arguments for designing intake as a pipeline rather than as a form. The same discipline pays again at renewal, where catalogue movement across a year is usually the largest single category of change you will find.

A change is an event on the case, not a new case#

Handling this well is mostly organisational. The tooling job is narrow: represent a change as an event attached to the case, re-open only the affected parts of the review, and keep the history so next year's reviewer can see what the catalogue looked like when the file was first written.

The VeriScripts platform does that as part of the case model — change events on the file, partial re-review without restarting the case, and catalogue snapshots retained alongside the submission record. If you have a single application to get filed correctly rather than a book of them to manage, our done-for-you service handles the preparation and submission end directly.