Model deprecation and write-off risk
Updated: September 27, 2026
Model deprecation notices are filed as engineering changelogs and read as engineering notices. For a finance function they are an accounting event, because the decision to pre-commit spend against a model version creates an obligation that the vendor can withdraw from one side of the contract while the commitment remains on yours.
The liability hiding in a volume commitment
A pre-committed volume discount assumes you will still be running that version in the commitment period. If the model is deprecated, you face three outcomes, and only one of them was priced into the contract:
- The successor is behaviourally close. The commitment is honoured. This is the case people plan for.
- The successor needs re-evaluation. The commitment is honoured but the rollout slips, and the value of the commitment falls without the spend falling.
- The commitment is volume, not version. The discount survives the changeover and nothing is lost. This is the term to negotiate.
Only the third case is safe, and it is the case that has to be asked for in the contract rather than assumed at renewal.
What the deprecation notice should trigger
- Update the accrual assumptions. If the model behind a committed volume is being retired, the discount you accrued against that volume needs re-review before the quarter closes.
- Re-baseline unit economics. The successor's rate card is a different product. Cost per resolved outcome computed on the old model does not carry forward.
- Check the re-evaluation cost, not just the migration. A behaviourally different successor means the eval programme is part of the migration cost, and eval spend is recurring.
- Log the date in the renewal calendar. Deprecation dates are a scheduling input. A version retired two weeks after your renewal negotiation is a bad week to be holding.
Writing it off honestly
If a commitment was priced on the assumption of a version that no longer exists, the difference is a variance, and the useful thing is to recognise it early and label it as a deprecation effect rather than let it be absorbed into a general overspend line where it becomes invisible. A deprecation write-off that is explained in one sentence is a normal event. The same number buried in a run-rate overspend is a control failure.
Bottom line
Deprecation dates are an accrual input. Negotiate commitments against volume rather than version, re-baseline unit economics on the successor, and book the difference as a labelled deprecation variance instead of a generic overspend.