Talking to your SAP data: where AI helps in reporting — and where it doesn't

For the past two years the same question has come up in almost every customer meeting: how can we use AI on our SAP data? It is the right question, but the answer is more detailed than most presentations suggest. AI genuinely makes a large difference in certain reporting tasks — and in others it is either unnecessary or risky.

Below we draw that line based on what we saw while building our own product, Confiq, and in customer projects.

Where it works: turning a question into a query

The data is in SAP, but reaching it requires technical knowledge: which table, which field, which transaction. A finance manager's question — “which customer group lost margin last month?” — today turns into a request form and a wait of several days in most companies.

This is exactly where language models are strongest: translating a natural-language question into the right data query. The person asking no longer needs to know table names, and the technical team is freed from repetitive report requests. The gain is not speed but access: questions that were never asked start being asked.

Where it works: noticing the anomaly first

A stock item rising unexpectedly, a supplier price creeping up quietly, a customer's payment behaviour shifting — these are usually seen in the monthly report, weeks after the event.

Pattern detection is the classic area where machines beat people. Here the job of AI is not to decide but to direct attention: to say “these 12 items show unusual movement.” The expert still makes the call, but while looking in the right place.

Where it doesn't: statutory and exact calculations

Areas such as VAT calculation, depreciation, inflation adjustment and statutory reporting are rule-based and have a single correct answer. Handing these to a language model is the wrong choice: even when the result looks right, the method is neither auditable nor repeatable.

This work belongs in SAP's own logic, solved with rule-based development. AI's contribution here is not to perform the calculation but to explain its result and highlight deviations.

Where it doesn't: when data quality is poor

This is where we see disappointment most often. An AI layer built on duplicate customer records, inconsistent material groups or empty fields will present flawed data faster and more convincingly.

That is why we recommend starting AI projects with a master data picture. Solutions built before data quality is addressed are the fastest route to losing trust: nobody asks a second question of a system that once returned a wrong number.

So where does the data sit?

The second most common enterprise question concerns security: will our data leave the building? Our approach is that the data stays in your own system, with a reading and interpretation layer added on top. Authorisation remains exactly as it is in SAP; a user cannot see through AI what they could not see directly.

Simple as this principle sounds, it is decisive in practice: solutions built by bypassing the authorisation model are impressive in the short term and unsustainable in the long run.

Getting started

For companies wanting to try AI on the SAP side, our advice is to start with one real question rather than building a broad platform: a question the team asks over and over, which today takes days to answer. Solving that end to end teaches more than leaving ten scenarios half-finished.

That is how we built Confiq: we first solved the most repeated field questions by hand, then productised them. The enterprise value of AI shows up not in polished demos but where it removes recurring work.