SAP Process Integration and Process Orchestration — PI and PO — sit at the centre of most SAP customer integration landscapes. Almost every B2B interface, every middleware-mediated EDI flow, every batch interchange with a third-party system, and every event-driven integration between SAP modules and the broader enterprise architecture passes through the PI/PO engine. SAP licenses PI/PO on a volume basis, measured in messages processed per period. The metric is mechanical, the measurement is transparent, and the audit exposure is large enough that no SAP customer with significant integration volume should be unfamiliar with it.
This guide explains how the PI/PO engine metric is structured, where the measurement trap lies, what the migration to SAP Integration Suite (Cloud Platform Integration) changes, and how to position for the next contract negotiation.
How the PI/PO engine metric is measured
The contractual metric for PI/PO is "messages per year", with tiered pricing bands typically at 1 million, 5 million, 25 million, 100 million, and 500 million messages annually. A message is defined as a single inbound or outbound integration event passing through the PI/PO message broker, regardless of payload size, complexity, or downstream processing.
What counts as a message
The contractual definition is broader than most customers assume. Each of the following counts as a separate message in the SAP measurement:
- A single inbound EDI document from a trading partner.
- The corresponding outbound acknowledgement to the trading partner.
- Each downstream forwarding of the same logical document to multiple SAP backend systems.
- Each retry attempt on a failed message, including automatic retries triggered by network or queue timeouts.
- Each acknowledgement message generated by the SAP backend systems in response to inbound processing.
A single logical business event, such as a purchase order received from a key trading partner, can therefore generate four to eight measured messages in the PI/PO engine count. The arithmetic compounds rapidly across high-volume integrations.
How the measurement extract is produced
The PI/PO engine measurement is extracted from the Monitoring and Performance tables in the PI/PO database. The extract is mechanically straightforward and entirely transparent to both SAP and the customer. Unlike named user measurement, there is no negotiation about what counts and what does not — the message log either records a message or it does not. The audit conversation is entirely about which messages should be excluded from the count under the contractual definitions.
The four messages that should not be counted
The PI/PO contract definition of "message" is broad enough that disputed exclusions move the needle on every audit. Four categories of message should be contested in the measurement reconciliation:
1. Internal SAP-to-SAP messages
Messages exchanged between two SAP backend systems where both endpoints are already separately licensed should not, in a defensible interpretation of the contract, count as PI/PO engine throughput. The PI/PO engine is acting as transport, not as the licensed system of record. This argument has been accepted in approximately 40% of the disputes we have advised on.
2. Acknowledgement and handshake messages
Protocol-level acknowledgements (EDI 997s, AS2 MDNs, SOAP acknowledgements) are mechanical responses to inbound traffic and arguably should not increment the engine count independently. The contractual position varies by vintage of the PI/PO contract; older contracts often have language that supports exclusion.
3. Retried messages
Failed messages that succeed on automatic retry generate multiple log entries for a single logical message. The contractual position on retries is contested; the negotiated outcome is typically to count only the successful attempt.
4. Test and development traffic
PI/PO instances in test and development environments are typically not licensed for production message volume, but the measurement extract treats them identically. Excluding non-production environments from the count requires explicit contract language.
The migration to SAP Integration Suite changes everything
SAP’s strategic direction for integration is the cloud-native Integration Suite (Cloud Platform Integration, formerly CPI). PI/PO is moving toward end-of-mainstream-maintenance, currently scheduled for 2027 with selected extended-maintenance options through 2030. Customers running PI/PO are being directed toward migration to Integration Suite as part of broader RISE or GROW deployments.
The Integration Suite metric is structurally different from PI/PO. Integration Suite licenses on "tenant connections" with a separate message-throughput cap per connection. The conversion from PI/PO message volume to Integration Suite connection count is non-obvious and almost always produces a higher converted cost on the default mapping. We have seen migration proposals where the existing PI/PO annual cost of $620,000 converts to $1.4M of Integration Suite subscription — a 2.3x increase for what is, functionally, the same integration workload.
The conversion negotiation
The Integration Suite conversion follows a similar pattern to the broader S/4HANA conversion. The default mapping is the most expensive outcome; the negotiation moves the cost down through three levers. First, the connection-count definition can be negotiated to consolidate multiple PI/PO interfaces under a single Integration Suite connection. Second, the throughput-cap can be raised per connection to absorb spike volume without requiring additional connections. Third, the existing PI/PO weighted-average discount can be grandfathered onto the Integration Suite line items for a defined period.
What to do before the next measurement window
Three concrete actions should be in place before the next PI/PO engine measurement is submitted to SAP.
First, run a baseline measurement extract internally and reconcile it against the production traffic profile. Anomalies — sudden volume spikes, retry-amplification incidents, test traffic leaking into production logs — should be identified and either explained or remediated before SAP’s extract is generated. Second, document the contract definitions of "message" as they appear in the current PI/PO agreement and the negotiated exclusions, if any. Third, prepare the four-categories exclusion argument as a draft response document, ready to deploy if the measured volume exceeds the entitled tier.
The migration-timing question
Customers facing a PI/PO engine over-volume finding have a strategic choice: settle the finding under the existing PI/PO contract, or use the finding as the lever to accelerate the Integration Suite migration on more favourable terms. The latter approach is increasingly common, because SAP’s commercial team has discretion to settle the engine finding at a substantial discount in exchange for a migration commitment.
For the broader engine-metric context, see our companion articles on engine metric double-counting traps and the engine self-declaration process. For the integration topic context, see our SAP S/4HANA topic page and the engine metric audit playbook. The global logistics PI/PO engine defence case file documents a $4.1M-to-$1.6M settlement on PI/PO over-volume.