IBM software audit penalties, the math behind the demand letter.

IBM audit penalties are not a number on a schedule. They are three line items stacked together. License shortfall at current list, back support across the non compliance window, and the loss of sub capacity that forces full capacity math. The buyer side wins on the second and third lines.

Read this with the IBM Audit Defence Guide, the IBM Knowledge Hub, and the companion software audit defence 2026 article. The IBM audit conversation always starts with a number. The buyer side question is how that number was built.

This guide walks through the three line penalty stack, the math behind each line, the levers that move each line, the Red Hat differences, and the actions to take in the first two weeks of an IBM audit notification.

The IBM penalty stack

Every IBM audit settlement is built from the same three components. Most demand letters present a single number. The buyer side first move is to ask for the breakdown.

Three lines, three negotiations

Line one is license shortfall. Line two is back support. Line three is sub capacity loss. Each line uses a different math, and each line bends to a different argument.

• License shortfall. Quantity gap multiplied by current list price.
• Back support. Twenty two percent of the shortfall, multiplied by the back period in years.
• Sub capacity loss. Difference between sub capacity math and full capacity math, applied to the affected products.

Why the anchor matters

IBM presents a single anchor number on the first call. The anchor frames the negotiation. Decline the anchor. Ask for the breakdown by component, by product, and by year. Real numbers replace anchor numbers.

• Decline the anchor. Do not accept the headline number on the first call.
• Demand the breakdown. Per component, per product, per year.
• Verify against the contract. Each line item must point to a contract clause.

License shortfall math

License shortfall is the simplest line. IBM finds installations that exceed the licensed quantity, prices the delta at current list, and presents it as license demand. The math is mechanical. The arguments live in the inputs.

The three inputs to verify

Deployed PVU count, licensed PVU count, and price list reference. Each input has a buyer side argument waiting if the audit team did not lay the groundwork.

• Deployed PVU. IBM uses processor inventory data, often from agent scans.
• Licensed PVU. The contract entitlement, the sum across orders, with any swap or convert events applied.
• Price list. The IBM passport advantage price list at the audit settlement date, not the original order date.

Levers on the license line

Three levers. Discount the list reference using deal benchmarks. Reduce the deployed count by stripping out non production, decommissioned, or correctly licensed instances. Push for entitlement aggregation across the enterprise rather than per site.

• Discount benchmarking. A ten to twenty five percent discount off list is achievable.
• Inventory clean up. Strip non production, decommissioned, and licensed already instances.
• Entitlement aggregation. Sum across the enterprise, not per site, when the contract allows.

Back support math

Back support is twenty two percent of the licensed shortfall, multiplied by the back period. The back period is the contested input. IBM wants the longest period it can justify. The buyer side wants the shortest period the deployment evidence supports.

The back period argument

IBM typically claims back support to the start of non compliance. The buyer side anchors the start later using deployment dates, migration events, server change records, and ILMT history. Every six months of pull back equals eleven percent off the back support line.

• Server commission dates. When did the affected workload actually go live.
• Migration events. Hardware refreshes, virtualization changes, cloud migrations.
• ILMT history. The first ILMT quarter that shows the over deployment.
• Audit notice date. Many contracts cap back support to a defined window before notice.

Sub capacity loss

Sub capacity loss is the biggest cost driver in most IBM audits. The math is simple. ILMT or equivalent compliance allows licensing by virtual capacity. ILMT non compliance forces full physical capacity. The delta can multiply the shortfall by three to ten times.

What triggers sub capacity loss

ILMT not installed on the eligible virtualized hosts. Reports not generated quarterly. Reports incomplete or showing gaps. ILMT version below the minimum required for the IBM products in scope. Any one of these triggers a sub capacity loss claim.

• ILMT missing. The most common and most expensive failure mode.
• Reports missing. ILMT installed but quarterly reports not generated or retained.
• Report gaps. ILMT data inconsistent or incomplete.
• ILMT version. Below the documented minimum for the product family.

Recovery and protection

Sub capacity reinstatement after a failed audit requires two clean quarters of ILMT reports plus IBM written acceptance. Reinstatement does not retroactively reduce the audit settlement, but it does protect the next renewal cycle.

• Two clean quarters. Two consecutive full quarters of compliant ILMT reports.
• Written acceptance. IBM written acknowledgement of compliance restoration.
• Forward only. Recovery applies to future entitlement, not past audit math.

“Sub capacity is not a discount. It is a discipline. The day ILMT stops running cleanly is the day the audit becomes a full capacity conversation, and the math triples.”

Buyer side levers

Three levers move every IBM audit settlement. Forward license trade, back support discounting, and entitlement aggregation. Order matters. Apply them in this sequence.

Forward license trade

IBM cares about forward revenue more than back collection. A buyer side commitment to a multi year forward license deal often unlocks twenty to forty percent off the back support line. The math has to work both ways.

• Multi year commitment. Three year forward license commits.
• Cross product bundling. Mix WebSphere, Db2, Cognos, MQ, and the audited family.
• Cloud Pak conversion. Convert perpetual to Cloud Pak for Integration or Cloud Pak for Data where the architecture fits.
• Red Hat tie in. Red Hat subscription commitments can be part of the trade.

Back support discount

Back support is the most negotiable line. Twenty to forty percent settlements are common when the buyer side argues period, scope, and product mix.

• Period reduction. Pull back the start date using deployment evidence.
• Scope reduction. Strip retired products or shut down workloads.
• Mix discount. Volume discounts apply across the back support span.

Entitlement aggregation

Many IBM contracts allow entitlement aggregation across the enterprise. The audit team often runs per site to maximize exposure. The buyer side first move is to sum entitlement across the enterprise and net out the over deployment with under deployment elsewhere.

• Enterprise sum. Total entitlement across all sites and contracts.
• Net out. Apply under deployment in one site against over deployment in another.
• Contract verification. Confirm the contract permits aggregation before relying on it.

Red Hat differences

Red Hat audit penalties run on a different math. No PVU, no sub capacity, no back support at twenty two percent. The math is subscription gap multiplied by list price multiplied by the back period at the subscription rate.

The Red Hat math

Subscription gap is the count of nodes, sockets, or cores running Red Hat without active subscription. List is the published Red Hat subscription price. Back period is the time the gap was open. The simplicity of the math makes it harder to argue.

• Gap count. Active Red Hat nodes minus active subscriptions.
• List price. Standard Red Hat subscription tier list.
• Back period. Days the gap was open, typically capped at the audit window.

Red Hat levers

The Red Hat audit levers are different from IBM. Convert from per node to per socket where the math is friendlier. Move to the Smart Management tier only where required. Strip out dev test and CI workloads where the Developer subscription applies.

• Per socket conversion. Per socket pricing often lower than per node on dense hosts.
• Smart Management scope. Only where Satellite or Ansible Automation Platform is required.
• Developer subscription. Free Developer entitlement covers many CI and dev test workloads.

What to do next

1. On audit notice day, lock down ILMT reports, contract files, and deployment evidence.
2. Demand the IBM breakdown by component, product, and year before any response.
3. Reconstruct the deployment timeline using server commission and migration evidence.
4. Run the buyer side math in parallel with the IBM math.
5. Identify the forward license trade that unlocks the back support discount.
6. Confirm entitlement aggregation rights from the master agreement.
7. Set the sub capacity recovery plan in motion, even if the current audit is lost.
8. Contact Redress Compliance to scope an audit response engagement.

Frequently asked questions

What does IBM count as an audit penalty?

IBM counts three things. First, license shortfall priced at current list. Second, back support on the shortfall for the period of non compliance, often two to four years. Third, loss of sub capacity if ILMT is not compliant. The three combined drive most audit settlements.

Is there a fixed penalty schedule?

No. IBM does not publish a fixed penalty schedule. Settlement math is built up from list price multiplied by the shortfall quantity, multiplied by the back period for support, with sub capacity adjustments stacked on top.

How far back can IBM go on back support?

IBM typically claims back support from the date the non compliance started, often capped at the audit period of two to four years. The buyer side lever is to argue the start date down using deployment evidence.

Can sub capacity be reinstated after an audit?

Sometimes. Sub capacity reinstatement requires a clean ILMT install, two full quarters of consistent reports, and IBM written acceptance. The reinstatement does not retroactively reduce the audit settlement.

What is the discount range on audit settlements?

IBM audit settlements typically discount the back support component by twenty to forty percent, the license shortfall by ten to twenty five percent, and the sub capacity loss is harder to negotiate.

Do penalties differ between IBM and Red Hat audits?

Yes. Red Hat audits focus on subscription coverage gaps and node count true ups. There is no PVU concept. Sub capacity does not apply to Red Hat.

Should we self report a shortfall before the audit closes?

Only with a clear plan. Self reporting can accelerate settlement and improve tone, but it removes the buyer side option to argue scope and start date.

What is the single biggest cost driver in an IBM penalty?

Loss of sub capacity. A full capacity recalculation on a large WebSphere or Cognos footprint can multiply the shortfall by three to ten times.