Reducing the true up before you submit

The true up is a count you submit, not a bill you receive. The window before you submit it is the cheapest place to cut your annual demand, because everything you correct now is a number that never enters the invoice.

Most true ups are overpaid for a simple reason. The figure is treated as administrative, a box to clear before the agreement year closes, so it is assembled quickly from whatever counts are easiest to pull and submitted without challenge. Yet the true up is the one Microsoft number that you assemble yourself, before anyone else has counted. That sequence is an advantage, and this article is about using it. If you understand how the demand is built, covered in how Microsoft sizes a true up, the next task is to bring your own count down to the defensible figure before it is locked in.

Start from a recount, not from last year

The most common way a true up inflates is that it inherits the prior year. Someone takes last year's submission, adds the projects everyone remembers, and files it. That method only ever moves the number up. It never recovers a license that was reassigned, a deployment that was decommissioned, or a product that was counted on the wrong metric. The only way to find those is to recount the estate from current evidence, as if you had never submitted before.

A recount means pulling the actual deployment and active use data for each licensed product, mapping it to what you are already entitled to hold, and treating the gap as the candidate true up quantity. It is more work than copying last year, and it is the work that pays. The gap you find from real evidence is almost always smaller than the gap you would have assumed.

Clear the false positives first

Before you price anything, work through the deployments that look like growth but are not. These are the items that quietly inflate a true up, and each one removed is a direct reduction in the demand. The recurring categories are predictable.

• Servers that were decommissioned during the year but still appear in management tooling because the record was never retired
• Software discovered on machines where it is installed but not used, which many metrics treat as a deployment regardless
• Licenses reassigned from leavers to joiners, counted as net new when the entitlement already existed
• Editions or versions mapped to a higher cost product than the one actually running
• Test, development, or disaster recovery instances that carry different rights than production

None of these is exotic. They are the ordinary residue of a year of change in a large estate, and they are exactly what an unexamined count carries straight into the invoice. Clearing them is not aggressive. It is accurate.

Count on the right metric

A single product can be licensed several ways, and the metric you count on changes the figure materially. SQL Server counted per core behaves very differently from SQL Server under a server plus client access license model. A product entitled under one program may be deployed in a way that a different program covers more cheaply. The recount is where you confirm that each product is measured on the metric that matches both its deployment and your entitlement, rather than the metric that happens to be easiest to extract.

This is the same discipline that governs an audit defense, where the counting methodology decides the result. The difference in a true up is that you are applying it to your own submission, on your own timetable, with no auditor in the room yet.

A worked reduction

The pattern is easiest to see with numbers. The figures below are indicative and exist only to show the shape of a typical recount, not to predict any specific result.

Indicative only. Actual reductions depend on your estate, your agreement, and the evidence you can produce for each line.

The reduction here did not come from negotiation or from disputing a rule. It came from counting carefully before submitting. Every line removed was a line that would otherwise have been priced and paid.

Document the evidence as you go

A lower count is only useful if you can stand behind it. As you clear each false positive and confirm each metric, keep the evidence that supports the position: the decommission record, the usage data, the reassignment trail, the entitlement that already covered the deployment. This serves two purposes. It lets you submit a defensible figure with confidence, and it prepares you for the case where the true up later draws scrutiny or sits alongside a broader review. A reduction you can document is a reduction that holds. A reduction you cannot explain is a question waiting to be asked.

Where this sits in the wider defense

Reducing the true up before you submit is the same buyer side principle that runs through every Microsoft engagement, applied at the one moment you control the count outright. The full method for managing the annual demand and the formal review that can follow it sits in our pillar, the Microsoft Audit Survival Guide. To complete the picture, read how Microsoft sizes a true up for the data behind the figure, and the true up demand letter explained for what happens if Microsoft pushes back on your submission. Download the guide below for the full recount method and the evidence checklist.

If you would rather not face that alone, we challenge inflated counts through our EA true up defense work.