A Cancelled Contract Is Usually a Renamed One

Contract exports look like simple diffs. Compare this month's export to last month's, and the rows that disappeared must be spend you lost or tools you exited. Often they are neither.

In one reconcile, three large contracts showed up as cancelled. Two of them had simply been replaced: the same vendor, the same scope, a new contract number, still active. Only one was a real exit. Read naively, the export would have reported three exits and sent three applications toward retirement.

The reconcile, step by step

1. Diff on the contract number. Added, removed and changed, on the fields that matter: vendor, amount, end date, renewal date and state.
2. Trace a successor before declaring a loss. For every removed or cancelled contract, search the vendor's remaining contracts for an active one with overlapping scope. Conclude "exited" only when there is none.
3. Let procurement own the contract record. Architecture does not rewrite contracts. It reflects the change downstream: disposition, cost of ownership, and registration of any new vendor or application.
4. Record it once, with a date. One register is the home of the finding, and the affected application pages link to it.

A cancelled contract is a question, not an answer. The answer is whether it has a successor.

One contract, one application

The second rule: each contract line maps to its own business application. If there is a line item, there is a thing you bought, and it deserves its own record.

The temptation is to fold a contract into a parent platform because the same team runs both, or because the procurement system already labels it with the platform's name. Resist it. A synthetic-monitoring subscription tagged with an observability platform's name is still its own product with its own renewal. Worse, several things can share one name: a vendor's SaaS product, a self-hosted open-source stack and a third vendor's tool can all read as "observability". Group related applications under a portfolio instead of collapsing them into one.

Why the portfolio cares

• Disposition. A contract ending is a Migrate or Eliminate trigger, but only if it actually ended.
• Cost of ownership. Collapsing contracts into a parent hides what each application costs.
• Registration. A new contract with a vendor that has no application on record is usually an unregistered application.

Copy this: the contract reconcile rule

## Contract export reconcile (every new export)
1. Diff on contract number vs the prior export:
   added / removed / changed (vendor, amount, end, renewal, state).
2. Successor-trace every removed or cancelled contract:
   same vendor + overlapping scope + active = renamed, not lost.
   Only "no successor" means exited.
3. Procurement owns the contract record. Architecture reflects changes
   downstream: disposition, cost of ownership, new registrations.
4. One contract line = one business application. Never fold a contract
   into a parent platform because of a shared team or label.
5. Record each finding once, dated, in the contract register; link it
   from the affected application pages.