How to Build an SAP AI Agent

SAP is where the transactions live, which makes it the most valuable place to apply an AI agent and the place where carelessness is most expensive. An agent that posts a wrong document into a financial system creates a correction, an audit finding, and a difficult conversation, and the controls that prevent that were built for human users. This guide covers integrating an agent into an SAP estate properly, drawing on FISTA Solutions' AI agents delivery in ERP environments. It complements how to build an erp ai integration and the AI in ERP modernization whitepaper.

What integration options exist?

Option	Fits	Caution
OData services (S/4HANA)	Modern estates, read and write	Coverage varies by module
BAPIs and RFCs	ECC and mixed estates	Requires careful error handling
Event streams and CDS views	Reactive agents, read-heavy analysis	Setup effort in older systems
Integration middleware	Estates with existing integration layer	Adds latency and a dependency
Screen automation	Nothing	Breaks on patches, bypasses authorisation

The last row matters. Screen-level automation is tempting because it needs no Basis involvement, and it fails predictably: every support pack breaks it, it runs under a borrowed user identity, and it bypasses the authorisation checks that make an SAP action auditable. Agents built this way become unmaintainable within two quarters.

How is the agent authorised?

With its own service user and authorisation objects scoped to its role, exactly as a human user would be. The common shortcut, copying an existing power user's profile, gives the agent far more capability than its function requires and makes the blast radius of any malfunction the whole estate.

Scoping should be transaction-level and organisational-unit-level: this agent may display and change purchase orders in these company codes and plants, and nothing else. The authorisation is reviewed in the organisation's normal access review cycle, and the reviewer should be able to explain why the agent holds each object.

Where an agent acts on behalf of a specific user, its effective authorisation should be the intersection of its own and that user's, so it cannot be used to exceed the requester's entitlements. See how to design tool permissions for ai agents.

Which workflows should come first?

Exception queues, because they have volume, a measurable backlog, and a natural human approval point.

Accounts payable exceptions. Invoices blocked on price or quantity variance, missing purchase orders, or coding questions. The agent gathers the purchase order, goods receipt, contract terms, and prior history, proposes a resolution with reasoning, and routes to an approver. See digital fte for accounts payable.

Sales order blocks. Credit blocks, delivery blocks, and pricing discrepancies, where the agent assembles the customer context and proposes release or escalation.

Goods receipt mismatches. Quantity and quality discrepancies against purchase orders, with supporting documentation retrieved.

Master data preparation. Extracting vendor, customer, or material data from source documents, checking for duplicates, and preparing the change for steward approval.

Each of these is read-heavy with a single controlled write at the end, which is the right risk profile for a first agent.

What should not be automated first?

Anything that posts financially without review, anything touching period close, and anything in a process where a segregation of duties conflict would arise. Payment runs, journal postings, and vendor bank detail changes deserve particular caution, because they are established fraud targets and an agent with those capabilities is an attractive one.

How is segregation of duties handled?

By placing the agent in the segregation matrix as a user. An agent that can create a vendor and also release a payment holds a conflict that no amount of model quality resolves, and an auditor will identify it immediately.

Where a process genuinely requires both capabilities, split them across separate agents with separate service users and an approval step between, exactly as the process would be split between two people. This is more engineering work and it is the correct answer.

What does the audit trail need?

Two layers. Inside SAP, every document the agent creates or changes carries a reference identifying the agent and the initiating request, so an auditor examining a document can see it was agent-created and trace it.

Outside SAP, the agent's own log holds the full interaction: the inputs, the retrieved context, the reasoning, the proposed action, the approval if any, and the result, retained for at least as long as the SAP document. That external log is what answers the question of why the agent proposed what it did, which the SAP change document cannot show. See how to build an ai audit trail.

How are errors and retries handled?

Carefully, because SAP interfaces fail in ways that matter. A BAPI call that times out may have committed or may not have, and an agent that retries blindly can create duplicate documents.

The disciplines that prevent this: idempotency keys carried through every call so a retry is recognised; explicit commit handling rather than relying on defaults; verification reads after writes for anything consequential; and a dead-letter path where an ambiguous failure routes to a person rather than being retried automatically.

How is it tested?

In a client that mirrors production configuration, with test data that includes the exception cases the agent will meet. SAP behaviour depends heavily on configuration, so an agent validated against a sandbox with different settings will behave differently in production.

Evaluation should cover proposal accuracy against resolutions that experienced users validated, the rate of proposals accepted without change, and the rate of incorrect proposals that were approved, which is the number that measures whether the approval step is genuine or a rubber stamp.

What does the rollout look like?

Suggest-only first, where the agent proposes and a person executes, for long enough to measure proposal quality on real volume. Then act-with-approval, where the agent executes after a person confirms. Autonomous execution only for well-understood cases within tight value limits, and only after the earlier stages produced evidence.

Most SAP agents should stay at act-with-approval permanently for anything financially material, and that is a reasonable end state rather than a failure to progress.

What does this cost and return?

Cost sits in integration and authorisation work more than in the model, particularly in older estates where BAPI coverage is uneven. Return is measured in exception backlog, cycle time, and touchless processing rate, all of which SAP operations teams already track.

The return compounds if the integration layer is built as a reusable component rather than per agent, since the second and third agents reuse the connection, authorisation pattern, and audit logging. See erp ai integration cost.

How FISTA Solutions helps

FISTA Solutions builds SAP agents through supported interfaces with scoped service users, segregation of duties preserved, idempotent error handling, and dual-layer audit trails, starting with exception workflows that carry a natural approval point, through AI enablement, AI agents, and forward deployed engineers working with Basis and process teams. The record behind the approach is 150+ projects for 50+ companies with 99.9% uptime.

To put an agent into an SAP estate safely, message FISTA on WhatsApp, or read how to build an erp ai integration.