ACF Connector Specification — SAP
1. Purpose
This specification defines how the ZAYAZ Accounting Connectivity Framework (ACF) integrates with the SAP enterprise ecosystem, with SAP S/4HANA as the primary ERP source family and SAP Business Technology Platform / SAP Integration Suite as the preferred integration fabric where appropriate.
SAP is materially different from smaller accounting platforms.
A customer may operate:
- SAP S/4HANA Cloud Public Edition;
- SAP S/4HANA Cloud Private Edition;
- SAP S/4HANA on-premise;
- legacy SAP ECC;
- SAP BTP;
- SAP Integration Suite;
- SAP Event Mesh;
- SAP Cloud Connector;
- custom CDS views;
- custom business objects;
- customer-specific extensions; and
- combinations of these in the same enterprise landscape.
The first task of ACF is therefore not:
Connect to SAP.
It is:
Determine which SAP landscape exists, which released interfaces are authoritative, which organizational context each record belongs to, and which source path can be governed safely.
The connector is intended to support:
- accounting ingestion;
- procurement;
- supplier analysis;
- material-flow analysis;
- asset analysis;
- project and cost-center allocation;
- physical activity discovery;
- emissions calculation;
- PEF/LCA enrichment;
- circularity;
- reporting prepopulation;
- audit evidence;
- assurance;
- group reporting; and
- continuous sustainability operations.
2. SAP is a connector family
Unlike a small SaaS accounting package, SAP is not represented by one universal API.
The ACF SAP connector therefore behaves as a connector family.
SAP
│
┌────────────┼─────────────┐
│ │ │
S/4HANA Cloud S/4HANA Legacy ECC
Public Private /
On-Prem
│ │ │
└────────────┼─────────────┘
│
▼
SAP integration layer
┌─────────────┼─────────────┐
│ │ │
APIs CDS Events
│ │ │
└─────────────┼─────────────┘
│
SAP BTP / Integration
where required
│
▼
ACF
The resulting customer-specific definition is stored in:
ACF-SAP-CUSTOMER-PROFILE
3. SAP landscape discovery
Before ZAYAZ retrieves accounting data, it must determine the landscape.
The profile should identify at minimum:
SAP product
deployment model
release
system ID
client
API host
logical system
company codes
controlling areas
plants
communication scenarios
communication arrangements
released APIs
released CDS views
custom extensions
event capability
BTP connectivity
This prevents ZAYAZ from treating all SAP environments as equivalent.
4. Clean-core integration principle
The SAP connector should be designed according to a clean-core principle.
The preferred hierarchy is:
Released SAP API
↓
Released SAP CDS
↓
Released extraction interface
↓
Approved custom CDS API
↓
Approved BTP integration
↓
Governed legacy interface
The standard connector should not depend directly on internal SAP database tables.
This is important because internal implementation structures can change independently of the integration contracts SAP deliberately publishes.
5. SAP Business Accelerator Hub
SAP Business Accelerator Hub is one of the primary source catalogs for the connector.
It exposes published:
- APIs;
- CDS views;
- event objects;
- integration content;
- business-object interfaces; and
- related integration artifacts.
ACF should use this information during connector definition and compatibility review.
However, public documentation does not prove that a particular customer system has enabled the same capability.
That must still be verified against the customer's actual landscape.
6. Communication scenarios
SAP S/4HANA Cloud Public Edition APIs are typically associated with communication scenarios.
A communication scenario defines the integration contract, including relevant:
- services;
- authorizations;
- communication direction; and
- available authentication mechanisms.
The configured customer instance then uses a:
Communication Scenario
↓
Communication System
↓
Communication User
↓
Communication Arrangement
ACF must preserve the communication-scenario identity for interfaces on which production processing depends.
7. Communication arrangements
The fact that SAP publishes an API does not mean the customer's ZAYAZ connection can call it.
Effective capability depends on:
API published
+
scope enabled
+
communication scenario
+
communication arrangement
+
technical authentication
=
callable customer API
This is another example of why ACF capability cannot be represented by a single Boolean.
8. Authentication
Authentication is communication-scenario dependent.
Modern SAP integrations can support mechanisms including:
- OAuth 2.0;
- client certificates;
- technical communication users; and
- principal propagation in appropriate user-context scenarios.
For ZAYAZ machine-to-machine processing, the preferred model is:
technical identity
+
least privilege
+
OAuth / certificate
where the SAP scenario supports it.
Plain user-password integrations should not become the preferred production architecture.
9. SAP BTP
SAP Business Technology Platform provides the enterprise platform surrounding many modern SAP extension and integration patterns.
For ACF, its most relevant capabilities include:
- Integration Suite;
- API management;
- event handling;
- connectivity;
- extension applications; and
- integration governance.
ZAYAZ should not require every SAP customer to deploy BTP merely to connect.
But where BTP already exists, ACF should respect and integrate with the customer's existing enterprise architecture.
10. SAP Integration Suite
SAP Integration Suite can provide:
SAP systems
+
non-SAP systems
+
APIs
+
events
+
transformations
+
routing
↓
governed enterprise integration
For a large enterprise customer, the correct architecture may therefore be:
SAP S/4HANA
↓
SAP Integration Suite
↓
ZAYAZ ACF
rather than:
SAP S/4HANA
↓
ZAYAZ directly
Both models should be supported.
11. Cloud Integration
SAP Cloud Integration can execute integration flows across cloud and on-premise landscapes.
It can provide:
- routing;
- transformations;
- protocol adaptation;
- mappings;
- orchestration;
- error handling; and
- enterprise integration monitoring.
Where a customer already maintains authoritative transformations in Integration Suite, ACF should avoid silently duplicating them.
The transformation origin must remain visible in provenance.
12. API Management
SAP API Management can govern enterprise APIs through:
- authentication;
- authorization;
- traffic policies;
- API products;
- monitoring;
- lifecycle governance; and
- controlled consumption.
A customer may therefore expose a governed SAP API to ZAYAZ through API Management rather than directly through S/4HANA.
ACF records both:
logical source = SAP S/4HANA
and:
integration route = SAP API Management
13. SAP Cloud Connector
SAP Cloud Connector is particularly relevant to Private Edition and on-premise landscapes.
It establishes a secure customer-managed connection from the private SAP environment toward SAP BTP.
The customer determines which internal resources are exposed.
The preferred pattern is:
ZAYAZ
↓
SAP BTP
↓
Cloud Connector
↓
Customer SAP
rather than exposing an internal SAP system directly to the public internet.
14. SAP system identity
A SAP source record cannot be identified by business document number alone.
The minimum identity can require:
SAP system
+
SAP client
+
business object type
+
source key
and frequently:
company code
fiscal year
line item
plant
as additional context.
These identities must be retained in TrustGate.
15. SAP client
SAP client context is fundamental.
Two records with apparently identical business keys in different SAP clients are not the same source object.
Therefore:
SAP system + client
is part of the source namespace.
16. Company code
Company code is one of the most important SAP concepts for ZAYAZ.
It is the central external-accounting organizational unit for which a complete set of accounts can be prepared.
A company code often corresponds to a legal entity.
But that equivalence must not be assumed universally.
The mapping is:
SAP company code
↓
legal-entity assessment
↓
ZAYAZ organization
↓
E-C-O Number
17. Company code is not automatically legal entity
SAP permits company codes to represent structures that are not strictly independent legal entities.
Therefore this would be unsafe:
company code = legal entity
The correct model is:
company code
↓
legal entity candidate
↓
validated mapping
This distinction matters for:
- CSRD scope;
- GHG organizational boundaries;
- consolidated reporting;
- audit evidence; and
- group-level calculations.
18. Controlling area
SAP Controlling introduces a separate organizational context.
A controlling area can contain multiple company codes.
It governs internal accounting concepts such as:
- cost centers;
- internal allocations;
- cost objects; and
- management accounting.
Therefore:
controlling area ≠ legal entity
ACF preserves it as a management-accounting context.
19. Cost centers
Cost centers are highly useful ESG allocation dimensions.
For example:
SAP cost center
"NO-OSLO-OPS"
↓
semantic mapping
↓
ZAYAZ organizational unit
↓
ESG allocation
Potential uses include:
- office emissions;
- departmental travel;
- shared utilities;
- procurement allocation;
- administrative footprinting; and
- business-unit analysis.
20. Profit centers
Profit centers provide another management dimension.
These may correspond to:
- product groups;
- business units;
- geographic operations;
- operating divisions; or
- other management structures.
They should not automatically become ESG reporting units.
A governed semantic mapping is required.
21. Plants
SAP plants are especially important for ESG.
A plant often provides operational or logistics location context.
Potential uses include:
- manufacturing site;
- warehouse;
- distribution center;
- operating facility;
- material valuation context; and
- inventory location.
Once mapped to a physical facility, the plant can drive:
location
↓
jurisdiction
↓
electricity grid
↓
transport context
↓
facility ESG allocation
22. Plant mapping
A SAP plant identifier is not enough.
ACF should resolve:
SAP plant
↓
facility identity
↓
address / geolocation
↓
country / region
↓
E-C-O organization
before using the plant for location-sensitive ESG calculations.
23. Storage locations
Storage locations provide more detailed inventory context below or around the plant structure.
They may help identify:
- warehouse zones;
- inventory locations;
- stock movements;
- material ownership; and
- operational flow.
The exact semantic meaning remains customer-specific.
24. General ledger
SAP's released G/L CDS models can expose rich journal-entry information.
Useful fields can include:
- ledger;
- company code;
- fiscal year;
- accounting document;
- line item;
- G/L account;
- cost center;
- profit center; and
- other reporting dimensions.
This makes SAP highly suitable for financial ESG screening.
25. General-ledger use
A G/L record can support:
- spend-based emissions;
- financial reconciliation;
- cost-center allocation;
- company-code allocation;
- materiality screening;
- supplier resolution; and
- audit tracing.
But:
A financial posting is not automatically a physical environmental activity.
26. Journal-entry identity
Journal-entry lineage should preserve:
SAP system
+
client
+
company code
+
fiscal year
+
accounting document
+
line item
where these keys are applicable.
This creates a stable bridge between financial evidence and ESG calculations.
27. Suppliers and Business Partners
SAP S/4HANA uses Business Partner concepts extensively.
Supplier information can support:
- supplier identification;
- spend aggregation;
- country resolution;
- CSDDD workflows;
- supplier questionnaires;
- supplier risk;
- primary-data requests;
- product-footprint requests; and
- Scope 3 analysis.
Supplier identity remains separate from supplier ESG evidence.
28. Supplier invoices
Supplier invoices can provide substantially better ESG context than ledger records alone.
Potential source fields include:
- supplier;
- invoice;
- company code;
- G/L account;
- cost center;
- controlling area;
- profit center;
- purchase-order reference; and
- item information.
This allows the chain:
financial posting
↓
supplier invoice
↓
purchase order
↓
material / service
to improve classification progressively.
29. Purchase orders
Purchase orders can be one of SAP's most valuable ESG sources.
They can provide:
- supplier;
- material;
- material group;
- quantity;
- unit;
- plant;
- price;
- currency;
- account assignment;
- project/WBS; and
- asset context.
This means SAP can sometimes move ESG analysis beyond monetary spend even before an invoice arrives.
30. Purchase-order account assignments
Purchase-order account assignments are especially valuable because they can relate expenditure to:
- cost center;
- WBS element;
- asset;
- internal order; or
- another cost object.
ACF should preserve this assignment rather than flatten procurement into a generic supplier-spend record.
31. Goods receipts
Purchase orders describe what was ordered.
Goods receipts can describe what physically arrived.
That distinction is important:
Purchase Order
100 tonnes ordered
↓
Goods Receipt
92 tonnes received
For some ESG calculations, the second quantity may be the more appropriate activity signal.
32. Material documents
Material documents provide a particularly strong SAP source for physical activity.
Released SAP extraction content can expose material-document information and support delta extraction.
Potential information includes:
- material;
- document;
- document item;
- plant;
- stock type;
- movement context;
- physical quantity;
- units; and
- reference objects.
This can make SAP materially stronger than accounting-only connectors.
33. Material movement as ESG signal
Consider:
Financial source
EUR 250,000 steel purchase
This could support DQ1/DQ2.
A material document showing:
Steel
48,200 kg
Plant DE01
Goods receipt
may support a DQ3 candidate.
The second source is closer to the physical activity.
34. Movement type semantics
A quantity cannot be interpreted without movement context.
For example:
10,000 kg
could represent:
- purchase receipt;
- consumption;
- transfer;
- return;
- reversal;
- scrap;
- production receipt; or
- another stock movement.
Therefore ACF resolves:
quantity
+
unit
+
material
+
movement semantics
+
direction
+
plant
↓
environmental activity candidate
35. Materials
SAP material identity can become one of the strongest canonical ESG identifiers in an enterprise.
A material may link:
- procurement;
- supplier;
- purchasing;
- inventory;
- manufacturing;
- sales;
- logistics;
- product data; and
- sustainability evidence.
This is strategically important for ZAYAZ.
36. Material to Carbon Passport
A future path could be:
SAP Material
↓
ZAYAZ canonical product/material
↓
supplier evidence
↓
LCA / PEF model
↓
product carbon footprint
↓
Carbon Passport
The SAP material number remains the source business identity.
The environmental model is governed separately.
37. Material groups
Material groups can provide useful category signals.
For example:
material
+
material group
+
supplier
+
plant
+
purchase order
may offer much stronger classification than G/L account alone.
Material-group mappings should be versioned.
38. Units of measure
SAP has structured units of measure across procurement, inventory and manufacturing.
This is extremely useful for ESG.
However:
Quantity = 500
Unit = KG
still requires understanding what the 500 kg represents.
Unit validity does not establish activity semantics by itself.
39. Semantic Activity Resolution
The SAP connector reinforces the ACF activity-resolution model:
SAP object
↓
business quantity
↓
unit of measure
↓
material / activity meaning
↓
movement / transaction meaning
↓
location
↓
method compatibility
↓
emission-factor eligibility
Only then should MICE consume the quantity as environmental activity.
40. Procurement evidence ladder
SAP supports a particularly powerful evidence ladder:
G/L posting
↓
Supplier invoice
↓
Purchase-order item
↓
Material
↓
Goods receipt
↓
Physical quantity
↓
Supplier-specific evidence
This can progressively improve the quality of a calculation without breaking lineage.
41. Manufacturing
Manufacturing-enabled SAP landscapes could provide even richer ESG source data.
Potential sources include:
- production orders;
- material consumption;
- production receipts;
- yield;
- scrap;
- work centers;
- plants; and
- production quantities.
These sources could support:
- product footprinting;
- PEF;
- LCA;
- mass balance;
- circularity;
- scrap analysis; and
- production efficiency.
Manufacturing integration should be profiled separately because SAP implementations vary substantially.
42. Material balance
A future manufacturing flow could look like:
Input materials
↓
Production order
↓
material consumption
↓
production output
↓
scrap / waste
↓
product footprint allocation
This is a major strategic opportunity for ZAYAZ.
43. Fixed assets
SAP asset accounting can provide:
- asset identity;
- company code;
- asset class;
- acquisition value;
- depreciation;
- profit center;
- segment; and
- financial history.
This can support:
- capital-goods screening;
- facility mapping;
- machinery inventories;
- asset population checks; and
- financial reconciliation.
Physical characteristics may still require enrichment.
44. Projects and WBS
SAP project structures can provide fine-grained allocation.
WBS elements can support:
- infrastructure projects;
- construction;
- engineering;
- customer projects;
- project procurement;
- capital expenditure;
- project travel; and
- project footprinting.
The WBS hierarchy should remain intact rather than being reduced to free text.
45. Project sustainability
A project footprint may combine:
WBS
+
purchase orders
+
goods movements
+
supplier invoices
+
assets
+
travel
+
external activity data
↓
project ESG result
This could become a powerful enterprise feature.
46. Custom fields
SAP customers often add custom fields.
These may contain high-value ESG information such as:
- facility;
- material category;
- contract;
- vehicle class;
- supplier classification;
- product family;
- sustainability category; or
- environmental reference.
ACF should discover these fields.
It should never silently assume their meaning.
47. Custom CDS Views
SAP allows customers to expose approved custom CDS views as external APIs.
This is a very elegant solution where a standard released API does not provide the exact enterprise dataset ZAYAZ needs.
Example:
Released SAP CDS sources
↓
Customer Custom CDS
↓
External OData API
↓
ZAYAZ
This can remain clean-core aligned if governed properly.
48. Custom CDS governance
A custom CDS interface must register:
- name;
- version;
- primary source;
- associated sources;
- fields;
- calculations;
- filters;
- API purpose;
- authorization;
- owner; and
- TrustGate identity.
A view should never be treated as an anonymous data pipe.
49. Custom CDS performance
Custom external APIs should not be used indiscriminately for unrestricted mass extraction.
The connector should use filtering and pagination.
Where high-volume replication is required, released extraction interfaces may be more appropriate.
50. CDS data extraction
SAP provides released CDS views specifically enabled for data extraction.
Some support:
FULL
and:
DELTA
extraction.
Delta-enabled views can use change-data-capture mechanisms.
This is extremely attractive for ACF.
51. High-volume procurement extraction
SAP publishes extraction models for procurement domains including areas such as:
- supplier invoices;
- purchase orders;
- purchase-order items;
- purchase-order history; and
- account assignments.
This allows ZAYAZ to avoid turning transactional OData APIs into data-warehouse extraction interfaces.
52. Delta extraction
For supported released views:
Initial full load
↓
delta subscription
↓
source changes
↓
continuous extraction
can potentially be more efficient than repeated API scans.
ACF must record the extraction contract and subscriber state.
53. Custom extraction caveat
Standard SAP extraction views and customer-created custom CDS extraction views do not necessarily have identical capabilities.
In particular, delta support must be checked independently.
ACF must never infer:
CDS extraction = delta
without source confirmation.
54. ODP
SAP's Operational Data Provisioning architecture supports extraction and replication scenarios with delta mechanisms for appropriate sources.
Customers with established enterprise extraction infrastructure may already use ODP-compatible pipelines.
ACF should be able to coexist with these architectures instead of unnecessarily creating a competing extraction layer.
55. Business events
SAP S/4HANA can publish business events through Enterprise Event Enablement.
The architecture can be:
SAP business object change
↓
Business Event Handling
↓
Enterprise Event Enablement
↓
SAP Event Mesh
↓
ZAYAZ
This provides near-real-time change detection.
56. SAP Event Mesh
Event Mesh allows applications to publish and consume business events asynchronously.
For ACF, events can trigger:
- source refresh;
- recalculation;
- supplier updates;
- procurement updates;
- project updates;
- evidence refresh; or
- reconciliation.
The exact available event objects must be discovered for the customer system.
57. Events and authoritative state
As with our other ACF connectors:
Events optimize freshness. Reconciliation establishes completeness.
An SAP business event may trigger ZAYAZ to retrieve the authoritative business object.
The event itself is preserved as lineage.
58. Event lineage
TrustGate should be able to show:
SAP business event
↓
event topic
↓
source object ID
↓
API/CDS retrieval
↓
changed source state
↓
affected ESG calculation
This explains why an ESG value was recalculated.
59. Reconciliation
Periodic authoritative reconciliation remains mandatory for material ESG data.
Reconciliation should detect:
- missed changes;
- deleted objects;
- reversed documents;
- altered postings;
- changed purchase orders;
- changed material movements;
- changed mappings; and
- event-delivery gaps.
60. Reversals
SAP frequently represents corrections through business-document reversal rather than destructive deletion.
ACF must preserve:
original document
↓
reversal relationship
↓
replacement / corrected state
rather than simply treating the original source record as if it never existed.
61. Closed-period changes
Financial periods may be reopened or historical documents adjusted.
A change after an ESG result has been reported should produce:
SAP historical mutation
↓
DaVE detection
↓
TrustGate event
↓
affected calculation
↓
revalidation
The previous ESG result remains auditable.
62. Intercompany transactions
SAP group structures can generate large numbers of intercompany transactions.
Without controls, these can cause group ESG double counting.
ACF must preserve:
- originating company code;
- receiving company code;
- trading partner;
- document relationship; and
- elimination context where available.
63. Financial consolidation versus ESG consolidation
This distinction is fundamental:
SAP financial consolidation
is not necessarily:
GHG consolidation
or:
ESRS reporting perimeter
ZAYAZ applies the appropriate sustainability boundary independently.
64. Spend-based emissions
SAP provides rich classification context for spend calculations.
A result might use:
G/L account
+
supplier
+
supplier invoice
+
purchase-order item
+
material
+
plant
+
cost center
+
project
↓
classification
↓
spend factor
↓
tCO2e
This is considerably stronger than G/L-only screening.
65. Activity-based emissions
SAP can sometimes provide direct physical activity.
Examples include:
goods receipt quantity
material consumption
production quantity
purchase quantity
inventory movement
These can support DQ3 where their semantic meaning matches the selected calculation method.
66. Example — material procurement
Suppose SAP shows:
Supplier: Steel Supplier GmbH
Material: STEEL-HRC-01
PO quantity: 50,000 kg
Plant: DE01
and a goods receipt confirms:
48,200 kg received
ZAYAZ may have several methodological choices.
For actual received material:
48,200 kg
↓
material classification
↓
supplier / geography / product evidence
↓
appropriate factor
↓
tCO2e
could be materially better than a monetary estimate.
67. Example — unsafe quantity interpretation
Suppose SAP shows:
Quantity: 250
Unit: EA
Material: MACHINE_COMPONENT
ZAYAZ cannot automatically interpret:
250 EA
as mass, energy, distance or another factor-compatible activity.
Additional material or product information is required.
68. Plant-specific factors
Once SAP plant identity is mapped to a physical facility, it can influence factor selection.
For example:
Plant SE01
↓
facility Stockholm
↓
Sweden
↓
location-sensitive energy methodology
This is exactly the sort of source context that can prevent generic-factor misapplication.
69. Data-quality hierarchy
ACF applies its common five-level hierarchy.
ACF-DQ1 — Accounting-only estimate
Typical SAP source:
- journal entry;
- G/L account;
- supplier;
- spend.
ACF-DQ2 — Invoice/procurement-level data
Typical SAP source:
- supplier invoice;
- purchase order;
- material;
- project;
- cost center.
ACF-DQ3 — Activity data
Typical SAP source:
- goods receipt quantity;
- material movement;
- production quantity;
- validated operational quantity.
ACF-DQ4 — Supplier/product-specific data
Examples:
- supplier-specific emissions data;
- product carbon footprint;
- plant-specific primary data;
- material-specific primary data.
ACF-DQ5 — Verified primary data
Primary information has undergone the required verification or assurance.
70. Progressive source upgrade
SAP is particularly well suited to progressive quality upgrades:
G/L amount
DQ1
↓
Supplier invoice
DQ2
↓
PO + material
DQ2
↓
Goods receipt quantity
DQ3
↓
Supplier-specific product data
DQ4
↓
Verified product data
DQ5
The previous calculations remain in lineage.
71. PEF and LCA opportunity
SAP may become one of the strongest ACF sources for Product Environmental Footprint and LCA.
Relevant enterprise data can include:
- material identity;
- purchased quantities;
- suppliers;
- manufacturing plant;
- production quantities;
- material consumption;
- scrap;
- inventory movements;
- product hierarchy; and
- logistics references.
This means ACF can eventually connect ERP transactional reality to the ZAYAZ PEF/LCA engine.
72. Circularity opportunity
Material documents and manufacturing flows can also support circularity.
Potential future signals include:
virgin material input
recycled material input
production consumption
scrap
return
transfer
rework
finished output
With appropriate semantics, these can support material-flow and circularity models.
73. Carbon Passport opportunity
SAP's stable material and product identifiers make it a natural enterprise source for Carbon Passport identity.
Conceptually:
SAP material
↓
ZAYAZ product identity
↓
supplier chain
↓
material flow
↓
PEF / LCA
↓
verified footprint
↓
Carbon Passport
SAP remains the enterprise transaction source.
ZAYAZ remains the sustainability intelligence and evidence layer.
74. Evidence linkage
A sustainability result might resolve through:
ESRS / VSME / PEF output
↓
ZAYAZ result
↓
MICE execution
↓
validated activity
↓
SAP material document
↓
purchase order
↓
supplier invoice
↓
supplier
↓
company code / plant
This can create extremely strong audit evidence.
75. ZARA behavior
ZARA should be able to explain:
- which SAP system supplied the value;
- which interface was used;
- whether the interface is SAP-released;
- which company code owns the record;
- which plant supplied the physical context;
- which supplier and material were involved;
- whether the quantity is activity-valid;
- why a factor was selected;
- whether a CDS or API produced the source;
- whether a custom extension was used; and
- what data-quality tier applies.
76. ZARA source distinction
ZARA must distinguish at least:
SAP source-native value
SAP released analytical view
customer custom SAP extension
ZAYAZ-normalized value
ZAYAZ classification
ZAYAZ calculation
external enrichment
These categories must never collapse into one opaque answer.
77. FOGE behavior
FOGE can use SAP data to prepopulate reporting requirements where the evidence is sufficient.
For example:
SAP material movement
↓
validated physical activity
↓
MICE
↓
calculated emissions
↓
reporting requirement check
↓
FOGE
But ERP data does not automatically satisfy narrative or governance disclosures.
78. COSE behavior
COSE evaluates whether available SAP evidence meets the applicable requirement.
For example:
Required:
facility electricity consumption
Available:
SAP utility spend only
Result:
activity evidence missing
Where SAP contains:
validated plant-specific kWh
the result may be different.
79. DaVE behavior
DaVE monitors:
- communication failures;
- interface changes;
- API deprecation;
- CDS changes;
- custom-view changes;
- event gaps;
- delta extraction gaps;
- unmapped company codes;
- unmapped plants;
- unit-semantic failures;
- suspicious quantity changes;
- historical mutations; and
- reconciliation differences.
80. TrustGate behavior
TrustGate preserves the chain:
SAP system
↓
released source interface
↓
source record
↓
canonical mapping
↓
classification
↓
activity resolution
↓
calculation
↓
reporting
↓
verification
This lineage survives source corrections and methodology changes.
81. MICE behavior
MICE should receive already governed source inputs.
A SAP-origin calculation can include:
- SAP system;
- SAP client;
- company code;
- plant;
- source business object;
- source object ID;
- source line item;
- quantity;
- unit;
- material;
- supplier;
- currency;
- normalized classification;
- method;
- factor;
- factor version;
- reporting period; and
- quality tier.
This supports deterministic reproducibility.
82. API Hub behavior
API Hub acts as the SAP source router.
It decides whether the requested source should use:
released API
released CDS
delta extraction
business event
custom CDS
BTP integration route
legacy interface
based on the customer connector profile.
Downstream engines should not contain SAP-specific routing logic.
83. Source routing example
A request for:
supplier invoice
may route to a standard API.
A request for:
large population of G/L line items
may route to a released CDS/extraction interface.
A request for:
customer-specific sustainability field
may route to an approved Custom CDS API.
This routing belongs in ACF/API Hub.
84. Data minimization
SAP enterprise systems contain enormous amounts of information.
ZAYAZ must not ingest indiscriminately.
A calculation that needs:
company code
supplier
material
quantity
plant
amount
currency
does not justify retrieving unrelated:
employee HR data
CRM contacts
all customer master fields
all SAP documents
ACF should use source filters and field selection wherever possible.
85. High-volume extraction
Large SAP customers may have millions or billions of source records.
Transactional APIs should not be misused for bulk replication.
Where appropriate, ZAYAZ should use interfaces designed for:
- extraction;
- delta replication;
- analytical reading; and
- enterprise data movement.
This architecture must be selected during connector profiling.
86. SAP ECC compatibility
Some large customers will still operate SAP ECC or mixed ECC/S/4 landscapes.
ACF can support this as a compatibility profile.
Possible mechanisms include:
- Integration Suite;
- IDoc;
- RFC;
- OData where available; and
- customer-controlled extraction.
But the architecture should make migration possible.
87. IDoc
IDocs remain relevant in many established SAP landscapes.
Where a customer already exposes authoritative business events or transactions through IDoc, ACF may consume them through a governed integration path.
The IDoc must retain:
- message type;
- basic type;
- sender;
- receiver;
- logical system;
- control record;
- business object identity; and
- source payload reference.
88. RFC
RFC should be treated more cautiously.
It can be appropriate in controlled legacy/private environments.
But new ZAYAZ capability should prefer released service contracts over deep coupling to ABAP implementation functions.
89. Migration-aware connector design
A customer may move:
ECC
↓
S/4HANA Private
↓
S/4HANA Cloud
The ZAYAZ canonical model should survive this migration.
Only the source adapter should change.
That is a core reason for ACF.
90. Recommended production architecture
For a modern enterprise SAP customer:
SAP S/4HANA
│
┌──────────────┼──────────────┐
│ │ │
APIs CDS Events
│ │ │
└──────────────┼──────────────┘
│
SAP BTP / Integration Suite
where appropriate
│
▼
ZAYAZ API HUB
│
SAP landscape profile
│
▼
TRUSTGATE
│
▼
ACF
┌───────────┼───────────┐
│ │ │
normalize validate classify
│ │ │
└───────────┼───────────┘
▼
CANONICAL DATA MODEL
│
┌───────────┼───────────┐
▼ ▼ ▼
MICE FOGE ZARA
│ │ │
└───────────┼───────────┘
▼
GOVERNED ESG DATA
91. S/4HANA Cloud Public Edition implementation
For Public Edition:
- identify the required SAP scope and released APIs;
- identify communication scenarios;
- configure communication systems;
- configure technical identities;
- configure communication arrangements;
- record API host and service URLs;
- identify released CDS/extraction views;
- determine business-event availability;
- map company codes;
- map plants;
- map financial dimensions;
- generate the ACF SAP customer profile;
- perform controlled source ingestion;
- reconcile source state; and
- validate TrustGate lineage.
92. Private Edition implementation
For Private Edition, ZAYAZ additionally evaluates:
- private network placement;
- BTP;
- Cloud Connector;
- released S/4 interfaces;
- customer extensions;
- event enablement;
- existing Integration Suite flows; and
- enterprise extraction architecture.
The safest route may differ from customer to customer.
93. On-premise implementation
For on-premise SAP:
Customer network
│
SAP S/4HANA
│
Cloud Connector
│
SAP BTP
│
ZAYAZ
is often preferable to making the SAP server internet-accessible.
Existing enterprise middleware may also be retained where governed.
94. Event-driven implementation
An event-driven deployment can use:
SAP business object
↓
business event
↓
SAP Event Mesh
↓
ZAYAZ
↓
source reread
↓
affected ESG object
↓
recalculation
Periodic reconciliation remains active.
95. High-volume implementation
For high-volume source domains:
Released extraction CDS
↓
full initialization
↓
delta change capture
↓
ACF ingestion
may be more suitable than API-by-API polling.
The selected source interface must be explicitly registered.
96. Hybrid ESG implementation
SAP should be treated as the enterprise operational backbone rather than the only sustainability source.
A high-quality result may combine:
SAP
│
├── company code
├── supplier
├── purchase order
├── material
├── quantity
└── plant
+
supplier primary data
+
meter data
+
logistics
+
LCA dataset
+
verified evidence
↓
ZAYAZ ESG result
97. Limitations
97.1 SAP is not one uniform product
Deployment and release must be discovered.
97.2 Customer configuration varies substantially
Company structures, custom fields and integration architecture differ.
97.3 Public API availability does not prove customer availability
Communication arrangements and authorizations must exist.
97.4 Not every CDS view is an external integration contract
Release and supported capability matter.
97.5 Not every extraction view supports delta
Delta capability must be confirmed.
97.6 Quantity does not automatically equal environmental activity
Business semantics remain necessary.
97.7 Company code does not automatically equal legal entity
Explicit mapping is required.
97.8 Plant does not automatically equal ESG facility
Physical mapping is required.
97.9 Events do not remove reconciliation requirements
Freshness and completeness are different controls.
97.10 SAP ERP data cannot satisfy every sustainability disclosure
Policies, governance and many narrative requirements require other evidence.
98. Connector activation gate
A production SAP connector should not activate until:
SAP landscape profile PASS
System / client identity PASS
Release identification PASS
API host PASS
Authentication PASS
Communication arrangements PASS / N/A
Released interface validation PASS
Company-code mapping PASS
E-C-O Number mapping PASS
Plant mapping PASS / N/A
Canonical mapping PASS
Custom extension governance PASS / N/A
TrustGate registration PASS
Initial reconciliation PASS
Monitoring PASS
Where events are used:
Event channel PASS
Event catalog PASS
Subscription PASS
Durable processing PASS
Reconciliation PASS
Where delta extraction is used:
Extraction interface PASS
Released state PASS
Delta capability PASS
Initialization PASS
Delta continuity PASS
99. Definition of done
The SAP connector is production-ready when ZAYAZ can demonstrate that it can:
- identify the customer's SAP landscape;
- distinguish Public, Private, on-premise and legacy profiles;
- resolve SAP system and client identity;
- resolve API hosts and integration routes;
- authenticate through approved technical mechanisms;
- discover communication scenarios and arrangements;
- identify released APIs;
- identify released CDS views;
- identify extraction-enabled views;
- identify delta-enabled views;
- identify relevant business events;
- discover custom fields;
- govern custom CDS APIs;
- avoid standard dependencies on unreleased SAP tables;
- resolve company codes;
- map company codes to ZAYAZ organizations and E-C-O Numbers;
- resolve controlling areas;
- map plants to facilities where required;
- preserve cost centers and profit centers;
- retrieve G/L and journal information;
- retrieve supplier relationships;
- retrieve supplier-invoice information;
- retrieve procurement information;
- preserve purchase-order account assignments;
- retrieve material and goods-movement information;
- preserve physical quantities and units;
- distinguish candidate quantities from validated environmental activity;
- map projects and WBS structures;
- process fixed assets where required;
- operate event-driven integrations safely;
- operate delta extraction safely;
- reconcile source state;
- detect historical changes;
- prevent unmanaged intercompany double counting;
- map source records into the ZAYAZ canonical model;
- normalize and validate deterministically;
- execute ESG screening without inventing activity;
- upgrade calculations when higher-quality evidence becomes available;
- retain previous results and provenance;
- support PEF/LCA and circularity enrichment where source quality permits;
- support ZARA, FOGE, MICE, COSE, DaVE and TrustGate;
- prevent cross-client, cross-company-code and cross-tenant leakage; and
- reproduce any material ESG result from SAP source to final output.
100. Source references
This connector specification is based primarily on current official SAP documentation covering:
- SAP S/4HANA Cloud Public Edition;
- SAP Business Technology Platform;
- SAP Integration Suite;
- SAP Business Accelerator Hub;
- SAP communication scenarios and arrangements;
- authentication and connectivity;
- SAP Cloud Connector;
- released SAP APIs;
- released CDS views;
- custom CDS external APIs;
- CDS data extraction;
- Operational Data Provisioning;
- business events;
- Enterprise Event Enablement;
- SAP Event Mesh;
- company codes;
- controlling areas;
- G/L line items;
- supplier invoices;
- procurement;
- material documents; and
- asset accounting.
The customer's actual SAP release, communication configuration, released interfaces and extension landscape remain authoritative for implementation.
The ACF customer connector profile must be reviewed or regenerated when material changes affect:
- SAP release;
- deployment model;
- system or client;
- communication scenarios;
- communication arrangements;
- authentication;
- APIs;
- CDS views;
- extraction contracts;
- business events;
- BTP integration;
- Cloud Connector;
- company codes;
- plants;
- custom fields;
- custom CDS views;
- custom business objects; or
- canonical source mappings.
Runtime Provider Extension
The provider-specific runtime contract for this connector is maintained separately from the common ACF connector frontmatter.
It contains machine-actionable provider semantics that are intentionally not part of the common ACF schema, including authentication lifecycle, provider object revision semantics, change-capture constraints and provider-specific capability rules.
schema_id: zayaz.acf.provider-extension.v1
extension_version: 1.0.0
connector_id: ACF-SAP
provider:
namespace: sap.s4hana
name: SAP
product: SAP S/4HANA
runtime:
source_contract:
public_cloud_primary_profile: true
private_cloud_supported: true
on_premises_supported: true
released_apis_preferred: true
released_cds_views_preferred: true
odp_odq_supported: conditional
btp_integration_suite_preferred_for_mediated_integration: true
source_identity:
company_code:
candidate_id_class: ECO
automatic_legal_entity_resolution_allowed: false
cost_center:
candidate_id_class: EBU
automatic_resolution_allowed: false
profit_center:
candidate_id_class: EBU
automatic_resolution_allowed: false
wbs_element:
candidate_id_class: EBP
automatic_resolution_allowed: false
plant:
source_context: facility
governed_scope_identity: false
change_capture:
business_events_supported: true
event_mesh_supported: true
odp_odq_delta_supported: conditional
reconciliation_required: true
capability_rules:
released_interface_required_for_standard_profile: true
communication_arrangement_may_gate_effective_capability: true
source_semantics:
goods_movement_quantity:
activity_status: candidate
requires_movement_semantics: true
requires_unit_resolution: true
material_master:
pef_lca_bridge_candidate: true
evidence:
source_documents_and_postings_may_form_evidence_relationships: true
extensions:
extraction_authority:
released_standard_preferred_over_unreleased_tables: true
governance:
status: active
last_verified: 2026-08-30
review_interval_days: 90
change_control_required: true
source_basis: connector_specification