When the API policy forces integrations onto published APIs, the Digital Access document count becomes visible. Median exposure rises by a factor of two to four. The buyer side response to the intersection.
SAP API Policy v.4.2026 does not create new Digital Access fees. It does something almost as consequential. It makes the document count visible.
Every time a previously internal API integration is rebuilt onto a published API orchestrated through SAP Integration Suite, the SAP system knows the integration exists, knows which document types it touches, and knows the volume. Across thirty client estates we modeled the median exposure increase at a factor of two to four.
The buyer side response is to model the exposure before SAP does, negotiate the Digital Access Adoption Program credit against the increase, and carve out the integrations that should remain outside the document counting rules. Read the SAP restricted third party API access pillar for the broader policy context and the SAP Digital Access complete guide for the foundational model.
Key takeaways
SAP Digital Access counts nine document types. A document is counted when it is first created in the system through an indirect or external pathway. Subsequent reads, edits, or deletes do not add to the count.
List price per document is typically anchored between zero point three and zero point eight dollars at standard discount levels, before volume tiering. A single inbound purchase order with ten lines counts as ten documents.
The intersection with the API policy comes from where the documents are created. An integration that posts a sales order through a non published BAPI may have been creating documents for years without those documents being attributed to the integration.
The remediation pathway moves the integration to a published OData API exposed by SAP Integration Suite. That makes attribution explicit. SAP knows the source system, knows the message volume, and can produce a document count by integration on demand. Read the SAP indirect access and digital access primer for the conversion math.
The pre v.4.2026 audit pattern was discovery led. SAP would request an inventory of indirect integrations, the customer would produce the inventory, and SAP would assess the document count from the integration descriptions.
The customer had significant scope to argue down the count by challenging document type classification, line item counting, and actual volume. The post v.4.2026 pattern looks very different.
Pre and post v.4.2026 audit dynamics
| Dimension | Pre v.4.2026 | Post v.4.2026 |
|---|---|---|
| Document source | Customer disclosure | Integration Suite tenant log |
| Audit cadence | Discovery led | Log led |
| Counting authority | Negotiated, narrative | Mechanical, message volume |
| Classification defense | Open, wide latitude | Narrow, document type only |
| Median customer position | Far below SAP opening | Closer to SAP opening |
The Integration Suite tenant produces the actual message log. The published API surface produces the actual call log. SAP no longer has to ask the customer how many documents were created. SAP can read the log directly.
The shift from discovery led to log led audit reduces the customer's negotiation surface significantly. We have run three audit defense engagements in the first quarter of 2026 where the SAP audit team explicitly cited integration logs as the source of the document count.
The customer's only defense was to challenge classification of specific document types and to argue for line item rather than header level counting. Both arguments work, but the upper bound of the defense is much closer to SAP's opening framework than it was a year ago. Read the SAP Digital Access audit defense article for the live response framework.
The mechanical counting change comes from three places.
Customers who consolidate from multiple custom integrations into a smaller set of standard published APIs can see the count fall. That happens where consolidation collapses duplicate document creation paths.
The average direction across our client base in the first six months of 2026 is still upward. The negotiation play is to model the change before SAP does, present the model in the renewal conversation, and trade the visibility increase for an explicit Digital Access Adoption Program credit.
The Digital Access Adoption Program, often referred to as DAAP, was launched in 2019 and extended through 2024 and into the current commercial framework. The program offers a discount of up to ninety percent on documents converted from existing user metrics or shelved entitlements.
The conversion math depends on the customer's installed base, the proportion of documents already covered by existing licenses, and the credibility of the document count model. The program is the single most important commercial lever against the v.4.2026 visibility increase. It lets the customer convert the increase into a structured discount rather than absorbing it as a new compliance liability.
SAP account teams will not volunteer DAAP credit at the level the math supports. The customer has to drive the conversation, with the model, the timeline, and the proposed credit.
The negotiation move is to size the post remediation document count against the customer's existing license footprint, calculate the unlicensed delta, and present the delta as a structured DAAP conversion request. Read the SAP RISE Negotiation Guide for the broader framework and the SAP Contract Negotiation Playbook for the clause patterns.
The audit posture against the new visibility has three elements.
The cadence is the same governance discipline we recommend in the SAP audit defense framework.
Some integrations should not sit inside the document counting rules at all. The carve outs we negotiate fall into four categories.
Each carve out has to be written into the master agreement, not assumed from the architecture. Without the written carve out, the SAP counting logic captures the integration by default.
The buyer side response to the API and indirect access intersection has nine moves.
Read the SAP knowledge hub for the supporting articles and the SAP advisory practice for the engagement scope.
If you are inside a renewal conversation or an audit, the right next step is a forty five minute scoping call. Before that call, work the following sequence.
No. The policy does not change the per document price list. It changes visibility. Integrations that move onto published APIs in Integration Suite become countable by SAP from the message log, which raises the realised exposure for many customers by a factor of two to four.
Nine types count: sales, purchase, invoice, material, manufacturing, quality management, service and maintenance, financial, and time management. Sales and purchase documents count line items individually, so a ten line purchase order is ten documents.
DAAP offers up to ninety percent discount on documents converted from existing user metrics or shelved entitlements. It is the most important commercial lever against the v.4.2026 visibility increase, because it converts new exposure into a structured discount rather than a fresh compliance liability.
Four categories: SAP to SAP within the enterprise, read only flows, integrations covered by named user or package licenses that already include the use, and metadata or monitoring tooling. Each carve out must be written into the master agreement.
Build the integration register from the Integration Suite tenant and the published API call logs. Classify each integration by document type touched. Model the document count before and after remediation. Maintain the model on a quarterly cadence so it is current at audit time.
No. Customers who consolidate many custom integrations into a smaller set of published APIs can see the count fall. Most clients across our 2026 sample still see the count rise. The right answer is always to model it on your own data first.
The eight move negotiation playbook, the seven step remediation framework, the Digital Access intersection model, and the contract amendment patterns we use across more than five hundred enterprise software engagements.
Independent. Buyer side.
