IBM Audit Defence: Florida Logistics Operator Reduces $18.2M Claim to $940K

Client Background and IBM Footprint

The client is a third-party logistics (3PL) operator headquartered in the Tampa Bay area with distribution centres across five southeastern US states. The company runs a complex hybrid infrastructure to support time-critical supply chain operations, including warehouse management systems, fleet routing platforms, and real-time inventory tracking applications built on IBM middleware.

The core IBM product estate at the time of audit included IBM WebSphere Application Server, IBM MQ (Message Queue), IBM Db2 database, and IBM Sterling Supply Chain Suite. The entire application stack ran on VMware vSphere virtualisation across three data centres, with an additional workload migration to a private cloud hosted in a co-location facility completed approximately 18 months before the audit notice was received.

The company had operated under a Passport Advantage Agreement for eight years and had maintained a generally consistent IBM product footprint, though the virtualisation infrastructure had expanded significantly during the logistics boom period of 2020 and 2021 as order volumes surged.

The Audit Trigger and IBM's Initial Approach

The audit notice arrived in October 2021, requesting a software inventory covering all IBM products deployed across the company's production, pre-production, and disaster recovery environments. IBM's letter was accompanied by a data collection tool request and an invitation to schedule a preliminary call within two weeks.

The company's IT team, unaware of the strategic implications of responding without preparation, scheduled the initial call and began preparing an inventory response based on their CMDB. This is a common mistake in IBM audit responses — the initial call with IBM's audit team is not a routine administrative formality. It is an opportunity for IBM to gather intelligence about your environment, identify scope expansion opportunities, and establish a precedent for your willingness to cooperate on IBM's terms.

Redress Compliance was engaged four days before the scheduled initial call. We intervened immediately, postponed the call, and took over all communications with IBM's audit team.

IBM's Preliminary Findings: The $18.2 Million Claim

After negotiating a 70-day data collection window, the company submitted a carefully scoped infrastructure inventory covering the agreed audit perimeter. IBM's preliminary findings, delivered in January 2022, totalled $18.2 million across the following claim categories:

• WebSphere Application Server full-capacity exposure: $9.4 million. IBM asserted that the company's virtualised WebSphere deployment required full-capacity PVU licensing because ILMT agent coverage was incomplete. IBM identified 14 virtualised servers running WebSphere without active ILMT agents, which IBM argued invalidated sub-capacity eligibility across the entire WebSphere estate for the full four-year audit period.
• IBM MQ full-capacity exposure: $4.1 million. IBM applied the same full-capacity logic to IBM MQ deployments, using the ILMT coverage gaps as grounds to assert full-capacity pricing across all MQ instances.
• IBM Db2 deployment overage: $2.8 million. IBM identified Db2 instances on servers added during the 2020–2021 infrastructure expansion that were not covered by existing entitlements. IBM's calculation used full-capacity PVU values for all instances, including those on servers that were subsequently brought under ILMT coverage.
• IBM Sterling miscellaneous components: $1.9 million. IBM claimed that certain Sterling Supply Chain Suite modules had been deployed beyond entitlement boundaries based on its interpretation of the suite's licence terms.

Defence Phase 1: ILMT Remediation and Evidence Construction

The foundation of IBM's $18.2 million claim was the assertion that ILMT gaps across 14 servers invalidated sub-capacity licensing for the entire virtualised estate. This is a common but legally aggressive position — IBM's Passport Advantage terms require ILMT deployment for sub-capacity eligibility, but they do not necessarily mandate that a single gap invalidates sub-capacity rights retroactively across all products on all servers for the full historical period.

Understanding the ILMT Gaps

The 14 servers identified by IBM without ILMT agents had been added to the infrastructure during the Q3 2020 expansion. Investigation revealed that the ILMT agent deployment process had not scaled automatically with the infrastructure provisioning workflow — new servers were being added faster than the ILMT deployment team could manually configure agents. This was an administrative gap, not a deliberate attempt to avoid sub-capacity compliance obligations.

This distinction matters enormously in IBM audit negotiations. IBM's full-capacity assertion carries more weight when ILMT gaps appear to be structural or long-standing. When gaps can be demonstrated to be caused by rapid, legitimate infrastructure growth, IBM is considerably more receptive to alternative remedies — including retroactive sub-capacity treatment supported by vCenter telemetry.

The vCenter Evidence Package

For every server on which ILMT agents were absent during the gap period, we extracted vCenter performance data showing the actual CPU core allocation to each virtual machine running IBM software. This data demonstrated that even during the gap period, the IBM middleware workloads were consuming a fraction of the physical server's total capacity — in most cases, two to four VPC equivalents per server rather than the 16 to 32 that full-capacity pricing would have assumed.

We also documented the ILMT deployment history across the estate, showing that agents had been deployed to 78% of the qualifying server inventory throughout the audit period, with the gap limited to the 14 newly provisioned servers. We constructed a timeline demonstrating when each new server was provisioned, when the ILMT agent was eventually deployed, and the actual IBM workload running on each server during the gap window.

Defence Phase 2: Entitlement Reconciliation and Db2 Challenge

IBM's Db2 claim of $2.8 million was based on a straightforward but incorrect premise: that all Db2 instances on servers added during the expansion period were unlicensed. The reconciliation workbook we built revealed a more nuanced picture.

The company held both PVU-based perpetual Db2 licences from historical purchases and newer Db2 entitlements acquired as part of an IBM Cloud Pak for Data subscription initiated in 2020. IBM's audit team had not credited the Cloud Pak for Data VPC entitlements against any of the Db2 deployments, treating all Db2 instances as requiring separate PVU-based licensing.

IBM Cloud Paks bundle included IBM software products — in this case, Db2 was a core component of the Cloud Pak for Data subscription. The restricted-use OpenShift entitlement within the Cloud Pak was not in dispute, but the failure to credit Db2 entitlements from the Cloud Pak subscription against the audit findings was a significant methodological error in IBM's claim construction. Correcting this reduced the Db2 exposure from $2.8 million to approximately $310,000 in genuine shortfall for non-Cloud Pak Db2 instances.

IBM Sterling Scope Challenge

The IBM Sterling claim of $1.9 million related to IBM's assertion that certain Supply Chain modules had been deployed outside the scope of the company's Sterling entitlement. Our review of the licence terms, the original purchase agreements, and the deployment configuration demonstrated that the modules in question were covered under the Sterling suite licence the company held. IBM withdrew this claim element entirely after we provided the supporting contract documentation.

Defence Phase 3: Structured Negotiation and Settlement

With the evidence package complete, we entered formal negotiation with IBM's commercial team in February 2022. IBM's revised position after reviewing our submissions dropped from $18.2 million to $6.1 million — an acknowledgement that our ILMT evidence and the Cloud Pak credit were valid, but still applying a penalty multiplier to the residual PVU shortfall.

Using IBM's Fiscal Calendar

IBM's fiscal year ends on December 31. The negotiation was taking place in February and March 2022, which sits at the beginning of Q1 — the period when IBM's commercial teams are under pressure to build pipeline for their annual targets rather than close historical audit settlements. This created an interesting dynamic: IBM wanted the settlement closed but had limited urgency to offer aggressive discounts in Q1.

We structured our negotiation to include a new Passport Advantage agreement that extended the company's IBM relationship, providing IBM with forward revenue in exchange for a significantly reduced retrospective settlement. IBM account teams respond positively to structures that convert a dispute into a forward commercial relationship — it counts toward their quota in a way that a pure penalty payment does not.

Final Settlement Terms

The settlement reached in late March 2022 covered:

• Retrospective licence fees for the verified Db2 shortfall and the acknowledged WebSphere gap period, calculated at sub-capacity rates using the vCenter evidence: $540,000.
• A new two-year IBM Passport Advantage subscription covering the current IBM estate at negotiated rates, representing the remaining $400,000 of the settlement value.
• An audit moratorium clause prohibiting IBM from conducting a further audit for 30 months following the settlement date.
• No penalties, retroactive support fees, or punitive elements — the settlement was structured entirely as licence acquisition and renewal.

Total settlement value: $940,000 against IBM's opening claim of $18.2 million — a reduction of 95%.

Root Cause and Post-Settlement Compliance Programme

The underlying vulnerability that created this audit exposure was the absence of automated ILMT agent deployment in the company's infrastructure provisioning workflow. When new servers were added to the VMware environment, ILMT agent deployment was a manual step that had no enforcement mechanism and no alert when it was missed.

Following settlement, we worked with the company's ITAM team to implement three structural changes. First, ILMT agent deployment was integrated into the VMware provisioning template as a mandatory step — new virtual machines could not be moved to production without a confirmed ILMT agent registration. Second, a monthly ILMT coverage reconciliation report was automated and sent to the ITAM director and CIO, flagging any server showing IBM software without an active agent. Third, an IBM entitlement register was established with quarterly reconciliation against ILMT output, ensuring that future infrastructure growth was matched against entitlement thresholds before IBM's fiscal year end in December.

For further information on IBM audit defence services, ILMT implementation support, or sub-capacity licensing advisory, visit our IBM Knowledge Hub or IBM Advisory Services page.