The index-linked increase billed is not the increase the lease describes

An indexed increase has 4 inputs: which published series, which base period, which comparison period, and what floor or cap sits around the result. Get any of them wrong and the arithmetic still completes and still returns a plausible percentage. Only the fourth ever announces itself.

So the diagnosis is not a search for a broken formula. It is a recomputation of one period from the exact wording of the clause, followed by a look at the shape of the difference — constant, drifting, or present in one period only — because the shape identifies the input.

Recompute one adjustment from the clause, not from the abstract

1. Copy the escalation clause verbatim out of the executed lease. An abstract's summary is a paraphrase, and every failure below lives in a word the paraphrase dropped.
2. Name the series in full: population coverage, geography, item scope and whether it is adjusted. CPI on its own identifies nothing, and 2 series for the same month routinely differ.
3. Pull the base-period and comparison-period values from the publisher, and record the release each figure came from along with the date you retrieved it.
4. Compute the ratio, then apply the clause's rounding rule where it states one, then apply any floor or cap in the order the clause sets out. Order matters when both a floor and a cap are present.
5. Apply the result to the component the clause names, from the base the clause names — the original rent or the rent as currently escalated.
6. Compare with the billed figure, then repeat for the previous adjustment. One period tells you there is an error; 2 tell you its shape.

Which index, for which population, in which place

The commonest cause is also the most boring: the calculation used a different published series from the one the lease names. In the US alone the choice runs across CPI-U, CPI-W and the chained C-CPI-U, across the national U.S. city average and individual metropolitan-area series, and across all-items and narrower item groupings. Elsewhere the same trap has local names — the UK publishes CPI, CPIH and RPI, the euro area publishes HICP, India publishes rural, urban and combined CPI series alongside a separate wholesale index.

Two practical points follow. Local-area series are built from smaller samples than national ones and move more erratically, which the publishing agency will usually say plainly in its own documentation — worth reading before a clause commits a 10-year lease to one. And index programmes are reformed: the UK has an announced reform of RPI, so check the current position with the ONS rather than assuming the series a lease named in 2016 still behaves the way it did. Confirm the definition of any series on the statistical agency's own pages before building a calculation on it.

The base period is a single month, and off-by-one leaves no trace

Clauses rarely say January. They say the index for the month 2 months preceding the commencement date, or the last index published before the adjustment date, or the average of the 3 months ending on the anniversary. Each of those resolves to a different month, and picking the neighbouring month produces an error of a fraction of a percent that nothing flags and that persists for the whole term.

Publication lag is what makes this hard rather than careless. An index for a given month is published during the following month, so a clause referring to the index for the month immediately before the adjustment date may be uncomputable on the adjustment date itself. Systems handle that by estimating and billing on time — which is fine — and then fail to restate when the real figure appears, which is not. If you estimate, record that the figure is provisional and schedule the restatement.

The number was correct when it was published and is not the number now

Treating an index value as a constant is the mistake underneath 2 separate failures. Revision is the first: for series that are revised, the figure read in March is not necessarily the figure read in September, so an increase recomputed a year later disagrees with the one billed even though nobody made an arithmetic error.

Rebasing is the second and it is worse, because it produces a number that is wrong by a large factor rather than a small one. Index series are periodically referenced to a new base period, and a ratio taken with the base month expressed on one reference base and the comparison month on another is meaningless without a conversion. The defence is the same for both: store the index value, its reference base, the release it came from and the date you retrieved it, as an immutable record beside the calculation. Then a later recomputation reproduces the billed figure exactly, and a genuine revision becomes visible as a revision rather than as a mystery.

A floor hides an input error for years and then reveals it

Where a clause reads the greater of 3% and the index movement, the index stops mattering in every period where movement runs below 3%. That is not only a commercial term; it is a diagnostic hazard. An error in the series or the base month can sit undetected through several low-inflation adjustments and appear in the first period where the index breaks through the floor, at which point the fault looks new and is not.

• Order of operations. A cap on the percentage increase and a cap on the resulting rent are different instructions, and they diverge as soon as the increase is applied to an already-escalated figure.
• Cumulative wording. Some caps allow unused headroom from earlier periods to be carried forward, which turns a single-period rule into a running balance the system has to hold.
• Collars with both ends. Where a floor and a cap are both present, apply them in the order the clause specifies rather than the order that is convenient, because the two orders produce different answers.
• Recompute the whole history when a floor is involved. Testing only the current period tells you nothing about the periods where the floor was doing the work.

The percentage was right and the money was still wrong

The last input is what the increase is applied to. Base rent alone, or base rent plus items the lease defines as additional rent. The original rent, or the rent as it stands after previous increases — simple against compounding, which produces a small first-year difference and a large one by year 8. Billing systems default to compounding on the current figure because that is the common case, and a clause drafted the other way is quietly overridden by the default.

The arithmetic is never the hard part. The hard part is that 3 of the 4 inputs are wrong in ways that still produce a number somebody is willing to pay.

Read the shape of the difference and it names the input

Two boundaries are worth naming before this becomes an automated control. Recomputation verifies arithmetic; it does not verify that the charge was owed, which is the same limit that governs what a system can and cannot verify on a paystub. And a correction changes downstream figures rather than just this month's invoice, because the schedule finance holds is derived — see producing a straight-line rent schedule from an abstract.

Timing matters more than the size of the error. An indexed increase usually arrives alongside the recovery statement, where the same discipline applies as in checking a true-up before you pay it, and rights to object to a computed amount are frequently time-limited, which is the whole subject of what to check before the audit window closes. A correct recomputation delivered after that window has closed is a lesson rather than a recovery.

The durable fix is a small service rather than a spreadsheet: a stored escalation definition per lease, an index cache that keeps values with their release and retrieval date, a job that recomputes on publication and flags variances above a threshold, and a restatement queue for provisional figures. That is ordinary AI agents and automation work, and where the leases themselves cannot leave your environment for clause extraction, the deployment options are the ones in private LLM deployment. This page sits in lease administration, obligations and critical dates, part of real estate and proptech software.

• rent escalation
• lease administration
• price index
• reconciliation