The Cost Forecast Tied to a Pricing Tier You No Longer Qualify For

The usage curve barely moved. The bill went up 38%.

That is the email the finance lead at a mid-sized fintech opened on the first Monday of the quarter. Three months earlier, the engineering org had renegotiated their LLM inference contract and shaved a sizeable percentage off the negotiated unit price by committing to a volume floor. The finance model rolled the new unit price into the FY forecast. Nobody bookmarked the footnote in the pricing schedule that said the discount would lapse if monthly usage fell below the floor for three consecutive months. The seasonal traffic dip in April-May did exactly that. The provider re-tiered the account back to list price. No notification reached engineering, because the notification went to the procurement inbox that nobody had read since the contract was signed.

The forecast was not wrong about how many tokens the product would burn. The forecast was wrong about what those tokens cost, because it assumed a pricing tier that the account no longer qualified for. That distinction — between "we mis-predicted usage" and "we correctly predicted usage at a unit price that no longer applies to us" — is the one most finance models silently get backwards. The unit price is treated as a constant in the spreadsheet, when in fact it is a stateful property of the account that depends on the account's recent behavior.

Vendor pricing tiers are a runtime state, not a contract constant

When the contract gets handed off from procurement to finance, the negotiated unit price gets transcribed into a cell in a spreadsheet. From that point forward, it behaves like a constant. The forecast multiplies expected tokens by that constant, the budget is sized against the resulting number, and the variance reports compare actual spend against a baseline that assumes the constant still holds.

But the negotiated unit price is not a constant. It is the steady-state value of a function whose inputs include your trailing twelve-month spend, your monthly commitment satisfaction, whether you are within the discounted region of a quantity-break schedule, and in some contracts whether you have hit a specific product mix across embeddings, inference, and batch. The unit price is the output of a small state machine that the provider runs against your account. The state machine has transitions that you can cross without anyone telling you, because the transitions fire on your usage hitting thresholds you set in a document months ago and stopped looking at.

If you wrote production code that read a configuration value from a remote service and never re-read it after startup, you would call that a bug. The cost forecast does exactly this. It reads the unit price once, when the contract is signed, and then treats the value as fixed until the next contract negotiation. The provider's billing system, meanwhile, evaluates the eligibility predicates every billing cycle and emits whatever price comes out. The forecast and reality are guaranteed to diverge the moment the predicates start firing differently — which they will, because the inputs include your own usage and your own usage is not flat.

The downgrade clause that lives in the pricing-schedule footnotes

Read a typical AI-vendor enterprise pricing schedule and the downgrade clauses are almost never in the main term sheet. They are in the appendix that defines the tier structure, often as a paragraph that begins "Customer's eligibility for the [Tier Name] unit prices shall be maintained for so long as ..." followed by a list of conditions. The conditions are usually written as a floor — a minimum monthly token count, a minimum monthly spend, a minimum number of active workloads. There is then a sub-clause describing what happens when the floor is missed: re-tiering to the next-lowest tier, sometimes with a grace period of one or two months, sometimes without.

The footnote will frequently specify that the re-tiering is automatic, that the provider will provide reasonable notice, and that no refund or true-up is owed for the discounted period preceding the downgrade. That last bit matters. Once you are re-tiered, going back to the discounted rate often requires you to re-qualify on a new trailing window — three or six consecutive months above the floor — not just a single month of recovery. So the bill jump isn't a one-month spike. It's a new baseline that persists until you can prove sustained recovery, and you cannot prove sustained recovery during a quarter you are also trying to plan against the wrong forecast.

The structural problem here is that the people who read this footnote during procurement are not the people who own the forecast. Procurement reads it to red-line risk during negotiation. They successfully removed a few of the worst clauses, accepted the ones that looked manageable, and signed. Finance read the term sheet that procurement summarized for them. Engineering read whatever procurement asked them to validate — usually the rate limit schedule, not the volume-floor schedule. By the time the contract is in force, the only place the downgrade condition is recorded is the PDF in the contract repository, and the only system that consults it on a monthly basis is the vendor's billing engine.

Tier-aware forecasting models the floor probability, not the floor

The fix at the forecasting layer is not to update the unit price in the spreadsheet whenever it changes. The fix is to stop treating the unit price as a number and start treating it as a function of expected usage relative to the contractual threshold.

The minimum viable version of this is a forecast that produces two numbers per period: the expected token volume, and the probability that the volume falls below the contractual floor. The expected cost is then a piecewise function — discounted unit price multiplied by volume when above the floor, list unit price multiplied by volume when below. The probability-weighted blend of those two regimes is what the forecast should report, not a single point estimate computed from one of them.

For products with strong seasonality, the floor-crossing probability is wildly different across the year. A retail-adjacent workload will sail above the floor in November-December and trip the floor in February-March. A consumer product that runs on a weekly publication cadence will spike on the publication day and droop in the middle of the week. A B2B workload with US-business-hour skew will dip across major holidays and during the slow week between Christmas and New Year. Each of these has a different floor-crossing probability per month, and a forecast that averages them all out produces a confidence interval narrow enough to convince finance that the discounted rate is structural, when in fact it is contingent.

The next layer is to add a "tier transition cost" line to the forecast: how much additional spend gets unlocked the month the downgrade fires. This is the line that makes the issue visible to anyone reading the forecast, because it is a single material number tied to a specific risk. Without that line, the downgrade scenario is buried inside a wider error bar and never gets discussed in the budget review.

Monitor the threshold, not the absolute spend

The usage-monitoring alert that catches this kind of issue is not the alert your AI infra team probably already has. The team has an alert on "monthly spend exceeds plan by X%." That alert fires after the downgrade has already happened, because the downgrade is the thing that causes the spend to exceed plan. By then it is too late to do anything except eat the higher rate.

The alert that actually helps fires on the leading indicator: monthly token consumption falling below the contractual floor for the first month of the qualifying window. It is a per-tenant or per-product alert, owned by whichever team controls the workload that pushes the account above the threshold. The signal is unambiguous: "you have one month before the discounted rate is at risk and two months before it lapses." The response is to either accelerate eligible workloads onto the contract before the window closes, or to flag the impending re-tier to finance so the forecast can be adjusted before the bill arrives.

The threshold-tied alert has to be encoded somewhere a human-readable. The contract repository is the wrong place, because nobody runs alerts off PDF files. The right place is the same source-of-truth where the rate limits and the SLOs live: a service catalog entry for the vendor account, with the contract's structural parameters — floor, window, transition price — as fields that the monitoring system reads. When the contract renews, the catalog entry changes, and the alerts auto-adjust. When a teammate inspects the entry to debug a cost question, the contract conditions are right there next to the rate limit and the latency target, which is where they belong.

Contract structure: ratchets, grace periods, and quarterly reviews

The contractual fix is to add a downgrade ratchet to the next renewal. A ratchet is a clause that prevents automatic re-tiering for a defined grace period — often one or two quarters — even if the floor is breached. The provider doesn't love this clause, because it pushes the risk onto them, but it is a standard ask at the enterprise tier and frequently granted in exchange for a marginally higher floor or a longer initial term. The trade is reasonable. You get a buffer against seasonality and incident-driven dips, the provider gets a slightly stronger commitment.

The next ask is a notification clause that names a specific role on your side — not just "Customer" — to receive thirty-day warning of an impending downgrade. The role should be tied to a function, not an individual: "Director of Platform Engineering" rather than "Jane Smith." The vendor's customer-success function can usually deliver this without escalation, because it is in their interest to give you time to course-correct before they lose your business at renewal.

The procurement-side practice that closes the loop is a quarterly contract review co-owned by finance and engineering. The agenda is short: read the trailing-twelve-month usage curve, compare it to the contractual floors and ceilings, identify any tier transitions in the upcoming quarter, and adjust the forecast accordingly. The meeting is dull, which is the point. The contracts are stable, the curves are mostly predictable, and a fifteen-minute review every ninety days catches the kind of slow-burn issue that otherwise gets discovered in a CFO email about a 38% variance.

Treat the contract as production infrastructure

The leadership reframe is that the procurement contract is a piece of production infrastructure. It is not a one-time legal artifact that gets filed when the deal closes. It is a configuration document whose state drives a cost line on the income statement, whose footnotes are SLOs you have to monitor, and whose renewal cycle is a deploy you have to plan against. The people who treat it that way recover from seasonality without surprises. The people who treat it as a static spreadsheet input keep getting blindsided by bills that are technically correct under terms they technically agreed to.

What this looks like in practice is that the contract has an owner on the engineering side — not just on the procurement side — and that owner is the one who signs off on the cost forecast. The forecast itself encodes the contract's state machine rather than its steady-state value. The monitoring stack alerts on the contractual threshold rather than the resulting spend. The renewal calendar drives a quarterly review whose attendees include the people who own the workloads, not just the people who own the line on the budget. None of this is heroic engineering. It is the cost-engineering version of treating a config file with a deploy schedule as code, which most teams already do for every other piece of production state. The contract is the same kind of object. It is overdue to be governed like one.