Revvly
Docs
Guide

Two prices, two override paths.

A subscription’s bill is made of a base price and zero or more Variable Component charges. Each has its own override mechanism — they don’t share a code path, and a Custom Pricing Agreement never touches the base price.

Two different targets

The base price comes from the catalog: module → bundle → region → pricing rule. Variable Component prices come from the scope resolver, most-specific first (Subscription → Bundle → Module → Global default), with a Custom Pricing Agreement able to sit above all of it. Overriding one has no effect on the other — they are separate calculations that happen to land on the same invoice.

Base price override
Sets the subscription’s base price directly, replacing whatever the catalog (module → bundle → region → pricing rule) would otherwise calculate. Lives on the subscription itself as a basePriceOverride snapshot — the pre-override list value, the override value, the effective mode, and the effective date are all recorded.
Component rate override
Writes a SUBSCRIPTION-scoped Variable Component Price for this subscription. It doesn’t touch the subscription document at all — it slots into the same resolver chain used everywhere else, at the most specific scope. Because it wins that chain outright it must carry the component’s whole price, not just the figure you want to change.

A Custom Pricing Agreement’s overrideScope: PRICE axis only ever reaches a Variable Component. If you need to change the base price for one customer, use the base price override on their subscription instead — it is a separate flow, found on the subscription’s edit screen rather than in the Custom Pricing Agreement editor.

What a component rate override has to carry

A scope replaces the resolved price. It does not merge into it.

A Variable Component splits in two: the component owns the structure of its model — tier and step boundaries, included units, committed quantity, the commission percentage — and a Variable Component Price owns the money. A Subscription-scoped override is a whole price at the most specific scope, so it stands in for the catalog row it beats rather than patching it. That means it has to carry every monetary field the component’s model bills on:

Flat rate
One price per unit.
Volume tiered · Graduated tiered
One rate per tier, in the component’s tier order — all of them. A single rate is not a tier schedule, and one missing row is not a price.
Stairstep
One flat fee per step, one for every band the component defines.
True overage
One overage price per unit.
Committed overage
Both halves — the committed price per unit and the overage price per unit.
Commission
Nothing is required: the percentage rate is structural, living on the component itself. The fixed fee, minimum, and maximum per transaction are optional adjustments.
Promotional
A fixed-amount promotion needs its discount amount. A percentage one is fully described by the component and needs no money at all.

The override surfaces — the create-subscription wizard and the edit-subscription modal — render the inputs for whichever of these the component needs, so a tiered component asks for a rate per tier and a stairstep one asks for a fee per band. A partly filled grid blocks the save; it is not billable, and storing it would only fail later, on every invoice and every revenue calculation that touched the subscription. The same check applies to prices authored at the Bundle, Module, and Global default scopes.

Allowances are a separate edit. Changing only a component’s included units or free allowance on a subscription leaves its price alone. It does not rewrite the resolved rate back as an override — which, for a tiered or stairstep component, would collapse the whole schedule into whichever single rate happened to apply.

When it takes effect

Both override paths support the same two effective modes.

Prospective
Takes effect at the subscription’s next renewal. The current cycle bills as already scheduled.
Immediate, prorated
Takes effect right away. A correction invoice is generated for the remainder of the current cycle, prorated the same way a mid-cycle expansion would be.

Immediate, prorated overrides emit a real correction invoice through the same expansion machinery as a mid-cycle upgrade — there is no separate "override invoice" type, it is simply an expansion whose cause is the price change rather than a plan change.

No catalog guardrails

Overrides are an explicit escape hatch: there is no minimum, maximum, or sanity check against the catalog list price. Setting a base price override to $0, or a component rate override far above or below the published rate, is allowed. Use a discount instead if you want a bounded, named, auditable percentage or fixed reduction rather than a raw rate replacement.

Next up