The single most preventable category of SAP engine-metric overstatement is double-counting. A financial document posted in the FI engine, replicated to a BW engine for analytics, and queried by a HANA-based reporting layer can be picked up by three separate measurement extracts. The contract permits one count of the underlying business event; the default extracts return three. The cumulative effect of unaddressed double-counting on a typical mid-market estate is between fifteen and twenty-five per cent of the declared engine volume — material money in any audit context.
This guide identifies the five most common double-counting traps, walks through the contract carve-outs that exclude each one, and explains the reconciliation steps that produce a defensible single-count declaration.
Trap one — source system plus BW replication
The most common pattern. A business event is posted in the source system — ECC, S/4HANA, or a specialised module — and is picked up by the source-system engine metric. The same event is replicated to BW for analytical processing, and is picked up by the BW engine metric. A customer running the default extracts in both systems counts the event twice.
The contractual position is that BW replication of source data is not a separately chargeable event. The BW engine charges on data volume native to BW — typically external data sources, custom-built data marts, and operational data stores — but not on data replicated from a separately licensed SAP source. The carve-out is in the BW engine definition in every contract vintage we have reviewed.
The remediation is to exclude BW data flows that have an SAP source from the BW engine declaration. The exclusion requires the customer to maintain a current source-system inventory for the BW data flows, which is normally available from the BW administrator but rarely surfaced to the licence team. See the related treatment in our BW engine data volume trap analysis.
Trap two — primary posting plus correction posting
The FI engine and the related document-based engines normally treat correction postings as separately chargeable events under the default extract. A document posted in error, reversed, and re-posted correctly produces three FI documents in the extract. The contract definition for the FI engine specifies that the chargeable unit is the net business event, not the gross document count. Reversal documents and the documents they correct should net to zero, and the corrected re-posting is the single chargeable event.
The remediation is to apply the net-business-event filter to the FI extract before declaration. The filter is a small custom transaction normally available in any well-administered SAP environment, but it is rarely applied to the default measurement extract. The cumulative effect on a mid-market customer is typically a four-to-eight per cent reduction in declared FI document volume. See the deeper treatment in our FI engine document line analysis.
Trap three — production posting plus reporting-layer query
HANA-based reporting layers and embedded analytics engines that sit on top of the production system normally pull data from the underlying tables to serve queries. The HANA engine charges on compute consumption and data volume, and a customer running heavy reporting against transactional data can see the HANA engine consumption rise in lockstep with the FI engine consumption.
The contractual question is whether the HANA reporting workload is a separately chargeable event or whether it is a derivative use of the FI-posted data. The answer turns on whether the reporting workload is consuming a separately licensed HANA capacity — for example, a dedicated S/4HANA Embedded Analytics workload — or whether it is operating on the same database instance that hosts the FI engine.
The default extract treatment normally double-counts the workload. The defensible position is to declare HANA compute separately only where it represents a distinct workload not derived from FI postings, and to exclude the reporting-on-FI workload from the HANA declaration where it is operating on the FI engine's licensed capacity. See the wider HANA context in our SAP HANA topic page.
Trap four — intercompany document replication
Intercompany transactions normally produce a posting in the sending company code and a counterposting in the receiving company code. Both postings are FI documents in the default extract. The contractual position varies by contract vintage. The 2018 master agreement carved out intercompany counterpostings as derivative documents not separately chargeable; the 2014 agreement did not. Customers operating on legacy paper need to read the actual carve-out in their contract.
Where the carve-out applies, the declaration should exclude intercompany counterpostings from the FI engine count. The exclusion typically reduces the declared count by three to eight per cent depending on the customer's intercompany volume.
Where the carve-out does not apply, the declared count is the gross document figure. In that case the negotiating lever is to seek the carve-out at the next renewal, since current SAP commercial paper does include it as standard. The renewal-time correction is significantly cheaper than the audit-time correction.
Trap five — sales order plus delivery plus invoice
The OTC engine charges on a contractually defined unit — typically the sales order line, the delivery line, or the invoice line, depending on the engine subtype. Customers who run multiple OTC engines, or who have a hybrid OTC and SD engine licence, can find the same business event counted in all three.
A single sales order line that generates a delivery and an invoice is one business event for OTC engine purposes. The contract excludes the derivative documents from the chargeable unit. The default extract often returns all three, and customers who sum the three figures across the OTC, delivery, and invoice extracts have over-declared the position by a factor of three.
The remediation is to identify the contractually defined chargeable unit for the specific OTC engine variant the customer holds, and to declare only that unit. The chargeable unit is normally documented in the licence schedule attached to the master agreement. See our OTC engine explainer.
The reconciliation workflow that prevents the finding
A defensible engine declaration is built from five reconciliation steps that take a senior analyst between five and ten working days.
Step one is the contract-definition extraction. For each engine on the licence, pull the contractual definition of the chargeable unit and the explicit carve-outs from the licence schedule. The output is a one-page reference that the declaration analyst can apply to the raw extract.
Step two is the source-system declaration. Run the default extract for each engine at the source system level, with the contractual measurement window applied. Document the raw figure as the starting point.
Step three is the carve-out application. Apply each documented carve-out — net-business-event, intercompany, replication, derivative documents — to the raw figure, producing the adjusted declaration figure. Each adjustment should be documented with the line of contract paper it derives from.
Step four is the cross-engine consistency check. For engines that are at risk of double-counting against each other — FI against BW, OTC against SD, FI against HANA — run a consistency check that confirms each business event is counted in only one engine declaration. The check is normally a manual reconciliation but is straightforward once the source data is mapped.
Step five is the documented submission. The declaration goes back to SAP with explicit footnotes covering the carve-outs and the cross-engine reconciliation. The footnotes are the audit defence. See the broader process in our self-declaration process article.
Where the renewal lever lives
Customers approaching a renewal with documented historical double-counting have a specific commercial opportunity. The renewal-time correction is negotiated rather than audited, and the multi-year overdeclaration becomes the basis for a tier-down rather than a back-charge. The negotiation should include three components: a tier-down to the reconciled volume, a defined audit holiday on the affected engine, and a contract amendment that confirms the carve-out language for the renewal term.
For the broader engine-metric and renewal context see our contract negotiation service, the licence optimization playbook white paper, and the consumer goods engine reconciliation case file.