PI/PO orchestration claim, defended.

The PI/PO message-volume claim

The logistics provider ran SAP PI/PO as the global integration spine connecting its core SAP ECC and S/4HANA estate with hundreds of carriers, customs systems, customer EDI endpoints, and internal microservices. The PI/PO engine was licensed against a tier of 300 million annual messages. The 2024 self-declaration produced a figure of 412 million messages, triggering an $8.7M overage claim on the 112-million-message excess.

The declared figure was generated by the standard PI/PO message-count utility running against the engine monitoring tables. The integration team had submitted the figure on the assumption that the utility's count was the contractual count. No filtering was applied to distinguish productive business messages from system-monitoring traffic or internal handshakes.

We were engaged on a renewal-preparation basis because the next renewal was eleven months out and the procurement team wanted the licence position cleaned up before the renewal negotiation opened. The first observation was that the firm's actual EDI document volume for the year — carrier confirmations, customs declarations, customer order acknowledgments — was approximately 180 million documents. The gap between the EDI volume and the engine count was over 230 million messages, which suggested that more than half of the engine-counted messages were not business documents at all.

The opening position

SAP's opening position rested on the 412 million raw figure. The workpaper applied the tier-overage rate to the 112 million excess, producing the $8.7M claim. There was no message-type analysis or content categorisation.

We obtained the PI/PO message-history tables for the measurement year and applied a deconstruction. The breakdown produced seven categories: 178 million business EDI messages to external endpoints, 96 million internal handshake messages between SAP applications, 64 million heartbeat and monitoring messages generated by PI/PO itself, 38 million message-acknowledgment receipts, 22 million error-and-retry messages from failed deliveries, 12 million test-and-development messages from non-productive landscapes, and 2 million other.

Only the first category — 178 million external business EDI messages — matched the contract definition of a productive integration message. The remaining 234 million messages were either internal-to-SAP, system-generated overhead, retries of the same business event, non-productive, or technical artefacts. Each category required separate evidentiary treatment.

The defence

The defence ran on five workstreams. The first documented the categorical breakdown with PI/PO monitoring evidence, message-type filters, and per-category samples drawn from each integration scenario.

The second workstream addressed the internal handshake messages — the 96 million category. These were messages exchanged between SAP applications within the firm's own landscape, not external integrations. The contractual engine definition referenced "messages exchanged with external systems through PI/PO orchestration," and the internal handshakes were demonstrably intra-SAP. The exclusion was supported by source-and-target-system mapping evidence.

The third workstream addressed the heartbeat and monitoring messages — the 64 million category. PI/PO generates monitoring traffic to track integration health, with periodic heartbeat checks between connected systems. These messages are operational overhead, not productive business integration. SAP's own measurement note from 2018 addressed this question and supported the exclusion of monitoring-channel traffic.

The fourth workstream addressed the error-and-retry messages — the 22 million category. Under PI/PO behaviour, a failed delivery generates retry attempts that each appear in the message log. A single business event that requires three retries appears as four log entries. The contractual measurement should count the business event once, not the retry attempts. The fifth workstream addressed the test-and-development messages — the 12 million category. The firm ran a non-productive PI/PO landscape for testing and development, with monitoring data sometimes mixed into the productive measurement output. We separated the landscapes through the source-instance field and excluded the non-productive traffic from the engine count.

The settlement

Settlement closed at $2.3M against the original $8.7M claim. The contract was amended with a refined PI/PO engine definition that explicitly excluded internal handshakes, monitoring traffic, retries, acknowledgments, and non-productive landscapes. The forward tier was renewed at 220 million annual external business messages.

The amendment language was the durable outcome. The PI/PO engine measurement methodology was now governed by an explicit contractual definition with seven named exclusions. The integration team adopted the categorical filtering as a standard practice in the quarterly licence-position reviews. The next self-declaration cycle would run on the refined methodology.

Total elapsed time from engagement to executed settlement was twenty-one weeks. The reduction against opening was 74 percent. The renewal closed on the original schedule with the refined engine tier in place.

Five lessons for the next PI/PO engine claim

• The PI/PO message-count utility is not the engine measurement. The engine measures external business messages; the utility counts every entry in the message-history table.
• Internal handshake messages between SAP applications are not external integrations. The source-and-target-system mapping distinguishes them.
• Heartbeat and monitoring messages are system overhead, not productive integration. SAP's 2018 measurement note documents the exclusion.
• Retry attempts of a failed delivery are not separate business events. The retry-flag field enables the deduplication.
• Test-and-development messages from non-productive landscapes should never appear in the engine measurement. The source-instance field is the filter.

Further detail on the methodology behind the defence is set out in the Engine Metric Audit Playbook white paper. For the broader topic context, see the cluster pillar on Engine metrics, the cluster pillar and the deep dive on PI/PO process orchestration engine. The topic landing at Engine Metrics provides the broader category context.