The methodology challenge that cuts claims by seventy percent.
Most audit findings are not wrong about what is installed. They are wrong about how it should be counted. Challenging the methodology behind the number, rather than disputing line items one at a time, is where the largest reductions are won. On one manufacturing estate it reduced the claim by 71 percent.
Line items versus the method behind them
There are two ways to argue an audit finding. You can dispute individual lines, conceding most and contesting a few, or you can challenge the method that produced every line at once. The first approach treats the auditor's framework as correct and negotiates at the margins. The second asks whether the framework itself holds, and when it does not, the correction flows through the whole count rather than a handful of entries.
Methodology challenges work because IBM findings are built on assumptions that are often defensible to dispute. A discovery tool defaulted to full capacity because it did not see clean sub capacity evidence. A processor value unit rate was applied at the wrong per core value. A bundled entitlement was counted as a standalone deployment. Each of these is not a single line error but a systematic one, repeated across every affected product, and reversing the assumption reverses every instance of it.
The challenges that move the number
- Full capacity defaulted in error. Where corrected ILMT evidence shows sub capacity should apply, the count drops from the whole physical host to the virtual cores actually running the software.
- Wrong PVU per core. Applying the correct processor value unit rate for the actual chip can change the count materially across every core.
- Bundled rights miscounted. Deployments covered by a bundle counted as separate licenses are removed once the bundle scope is proven.
- Metric misapplied. A product counted on the wrong metric, such as capacity where a resource based count applies, is recalculated on the correct basis.
How the 71 percent reduction happened
On a manufacturing estate running WebSphere and Db2, the finding rested on incorrect processor value unit values and denied sub capacity. Rather than negotiate the figure down line by line, the position was rebuilt from clean ILMT evidence and the correct per core rates, which reversed the assumptions the entire count depended on. The claim fell by 71 percent. That is one of three engagements we cite with a hard number, and it stands because the reduction came from correcting the method, not from IBM conceding individual lines. Most outcomes stay directional, but the mechanism is the same: challenge the framework and the count follows.
The biggest reductions are not won line by line. They are won by challenging the method that produced every line, then proving the correct basis with evidence. When the framework is wrong, fixing it cuts the whole claim at once. That is the Challenge step in practice, and on the right estate it is the difference between a marginal concession and a 71 percent reduction.
Is the finding wrong about the method, not the math?
Our Audit Negotiation engagement rebuilds the count from clean evidence and challenges the methodology behind every line. On average, challenges land thirty to fifty percent of findings, and we fold forward terms into the settlement.
See Audit Negotiation →The IBM Audit Brief
Audit triggers, ILMT pitfalls, and settlement tactics for IBM software buyers.
Independent, buyer side IBM software audit defense and negotiation. Not affiliated with IBM Corporation.