One SAP data layer: questions about orders, margins and stock get one answer.
A governed semantic layer over SAP puts metric definitions at the source, so questions about orders, margins and stock return one answer that can be traced back to the row it came from. Pexon extracts, masks and models the data, then carries SAP authorisations into the retrieval layer.
The starting point
Two systems, two revenue numbers.
When an agent and the finance team calculate revenue differently, the wrong number arrives silently in board material. Free-text similarity search over exported spreadsheets cannot fix that — the definition has to be fixed where the data lives.
What we build
What the layer contains
- Extraction and modelling. Read-only extraction from ECC or S/4HANA, modelled into a semantic layer where each metric has exactly one definition and one owner.
- Masking and entitlements. PII masked in the pipeline, and SAP authorisation objects mapped into the retrieval layer so users see only what they may already see.
- Traceability. Every answer carries the record it came from, so finance and audit can follow a number back to its source row.
Architecture choice
Semantic layer versus the alternatives
| Dimension | Semantic layer | Data warehouse | Spreadsheet extracts |
|---|---|---|---|
| Where the definition lives | Once, at the source, owned by the business | Per project, copied out of SAP | Per analyst, in a file |
| Drift over time | One owner keeps it true | Each load can silently change it | Uncontrolled |
| AI readiness | Retrieval-safe: one number per metric | Needs its own governance pass | Not usable by an agent at all |
| Audit path | Answer to source row, always | Answer to warehouse table, if recorded | None |
The warehouse is not wrong — it is a different job. If the question is heavy analytical workloads over years of history, warehouse the data and put the semantic layer on top. If the question is one trusted number behind every AI answer, the layer is the deliverable and the warehouse is optional.
Why one definition matters
A number with two definitions is two numbers
The revenue example is not a corner case, it is the general rule: in an SAP estate, the same figure is frequently defined differently in different modules, and every downstream system picks the definition it happens to have. The cost shows up not in the source systems but in every conversation where two people believe they are quoting the same number.
Fixing the definition where the data lives means the semantic layer becomes the single place a metric is defined — and the retrieval layer, the BI tooling and every AI application ask the same layer, so they cannot disagree. That is the structural fix, and it is why the layer sits underneath your BI tooling rather than beside it.
The order matters as much as the layer. Extraction is read-only, so nothing in the source system changes; the model runs on a replica or a data-services account, and the first time the source is touched is when the business decides it wants write-back. That conservatism is deliberate: the layer earns trust by proving it reads correctly, and write access is a decision, not a default.
What changes
- Questions about orders, margins and stock resolve to one number with a visible source.
- Analysts stop rebuilding the same extract in spreadsheets.
- Audit can reconstruct how a figure was derived without asking the team that built it.
- An AI assistant can answer a finance question and point at the row it came from — which is the difference between a demo and a deployment.
How to start
Start with the Readiness Blueprint.
Two weeks, fixed price: we map your data landscape, assess the permission model and hand you a costed architecture plan. It is yours to keep, whoever builds the system.
What the blueprint is for: it establishes whether the join is even possible before anyone commits to a use case built on it. Incomplete data coverage is common and not automatically a blocker — the blueprint measures what exists instead of assuming it.
The honest case for not building this: if your AI use cases never touch financial or master data, a semantic layer over SAP is a solution looking for a problem. The blueprint will tell you that too, and it is a legitimate outcome.
More in Data foundation
SAP specifics
Do you connect to ECC or S/4HANA?
Both. The extraction path differs, but the semantic layer and the entitlement mapping above it are the same. We connect read-only by default and work from replicas where your Basis team prefers.
Does this replace our BI tooling?
No. It sits underneath it. The same governed definitions serve your existing dashboards and any AI application that needs to ask a question about operations.
Next step
Not a sales call. An architecture call.
Thirty minutes with the architect who would actually run the engagement.