Marketing want to raise the price of a plan a million subscribers are already on, and change what it includes. What has to happen in the catalogue?

Three requests wearing one sentence

"Put the price up and change what it includes" is not one change, and answering it as one is the failure the question is designed to find. Separate it before you touch anything.

Pricing new sales differently is a catalogue operation and nothing else: from a stated date, the thing on sale costs more. Nobody's contract changes, and the work is confined to the catalogue and to whatever reads it.

Repricing the existing base is a commercial act performed once per subscription. It changes the terms of a live contract a million times over, it is constrained by whatever the contract and the regulator say about notice and about the customer's right to leave, and it lands on an invoice as a mid-cycle change with all the proration that implies.

Changing what the plan includes is both of those, and it is the one with the sharpest edge, because an allowance is consumed continuously. A subscriber halfway through a period whose included volume shrinks has already used some of an allowance that no longer exists at that size, and there is no defensible answer to that other than making the change effective at a period boundary.

Versioning for new sales, and where the boundary goes

The rule everyone recites is that a specification referenced by a live subscription is immutable, so you create a new version with its own validity interval rather than editing in place, and each subscription carries the version it was sold against. Recited on its own it earns nothing, because it is not where these programmes go wrong.

Where they go wrong is the extent of the version. The boundary has to enclose everything that determines what the customer pays, and a catalogue is a graph, so parts of that are one hop away from the offering. The price plan attached to the offering, obviously. The bundles and allowances it grants, because shrinking an allowance is a price change by another route. The discount and promotion rules that reference the offering, because a percentage discount defined against it silently reprices whichever version it resolves to. The eligibility and bundling rules, if a change in them alters what combination a subscriber ends up holding.

If the new version reuses a shared allowance object and someone edits its volume, both versions move, and every existing subscriber is repriced by an edit that touched nothing anybody was watching. That is the realistic defect: not an offering edited by mistake, but an object one level down that was never in scope for versioning because nobody drew the boundary explicitly.

Migrating the base is a per-subscription change with a date

Once you accept that repricing existing subscribers means moving them from one version to another, the shape of the work becomes clear and unglamorous. Each subscription gets an effective-dated change from the old version to the new one, produced by the same mechanism a customer-initiated plan change uses, because it is the same event. Reusing that path is what gets you correct proration, a correct audit trail, correct downstream notification to charging, and an invoice the contact centre can explain.

The date is not yours to choose freely. Notification obligations typically require a defined period of notice before the change takes effect, and the notice has to have actually reached the customer, so the effective date is derived backwards from when notification completed rather than from when the release is convenient. Cohorts whose contract protects them — fixed-term customers still inside their term, subscribers on a price-guarantee promotion — are excluded, and that exclusion must be evaluated from data in the subscription rather than from a spreadsheet, because a million-row exclusion applied by hand is a compliance incident waiting to be found.

Align the effective date with each subscriber's own cycle boundary if you can. It removes the proration lines entirely, which removes most of the contact volume, and the cost is that the change rolls out over a month instead of landing on one day. That trade is almost always worth taking.

The copies of the tariff that nobody versioned

The invariant holds inside the catalogue. It does not hold in the places the catalogue has been copied to, and enumerating those is what makes an answer sound like it came from an actual estate.

A vendor rating engine frequently keeps its own tariff store, loaded from the catalogue, and whether it holds versions with validity intervals or a current view is a question with an uncomfortable answer in many stacks. Front-end and channel systems cache offering data for latency. The data warehouse holds a dimension table with the product's attributes. Partner and dealer feeds publish a price list. Each of those is a point at which "the version that priced this subscription" can quietly become "the price we hold today".

Two controls make the difference visible rather than theoretical. Rated output stores the identifier of the tariff version that produced it, so the question "which version priced this call" has an answer six weeks later instead of an argument. And a reconciliation counts subscriptions per offering version before and after the change, so the number that moved is compared against the number that was supposed to move, with any difference investigated. A cohort of one is still a finding — it is one customer repriced without notice.

Prove it by pricing the base before you release

The strongest control here is cheap and skipped surprisingly often. Take the changed catalogue, run pricing for the entire subscriber base against it in a shadow environment, and compare the result subscription by subscription against the current catalogue's output for the same period.

Every subscription whose price changes should be in the intended cohort, and every subscription in the intended cohort should change by the intended amount. Anything else is a defect found before release rather than after: the shared allowance object that moved both versions, the discount rule that re-resolved, the promotion whose end date interacts with the new price, the handful of subscribers on a withdrawn offering from a decommissioned platform that nobody remembered maps onto this specification.

That comparison is only possible if pricing is a deterministic function of versioned inputs, which is the same property that lets you restart a failed bill run and defend a disputed line. It is worth noticing how much of catalogue governance reduces to one requirement: that the price of anything can be recomputed from stored, versioned facts rather than read from a mutable current state.

The invariant that matters is not "never edit an offering", it is that no change can reprice a subscription that was not deliberately selected for repricing, and the only way to know is to price the whole base twice and compare.