An LLM can technically create purchase orders or update records in SAP once the relevant BAPI or OData write operations are exposed as tools, but doing so safely requires more caution than read-only lookups. Every write action should run through the acting user's own SAP authorization roles rather than a broad technical service account, so the assistant can never create or modify anything that employee could not already do manually, and the request should pass standard SAP validation and workflow approval just like a manually entered transaction. For anything above a low-risk threshold, such as a purchase order over a certain value, a human confirmation step before the write executes is worth the extra friction, since a model can occasionally produce a plausible but incorrect field value, quantity or vendor reference. Comprehensive logging of the generated request, the approving user and the resulting SAP document number gives a clear audit trail if something needs to be reversed. Nanobase AI implements SAP write actions behind exactly this kind of approval and audit layer rather than allowing direct, unsupervised model-initiated transactions.
A risk tier for every write operation
Not every SAP write carries the same risk, and treating them uniformly either over-restricts low-risk operations or under-protects high-risk ones. A tiered model scales the safeguard to the actual exposure.
| Tier | Example | Required safeguard |
|---|---|---|
| Low | Saving a draft document, no posting | Standard logging, no extra confirmation needed |
| Medium | Submitting a purchase requisition under a defined value threshold | Human confirmation of key fields before submission |
| High | Submitting a purchase order above a value threshold, or any financial posting | Confirmation plus routing through existing SAP release/approval workflow |
| Critical | Master data changes, vendor bank details, pricing conditions | Confirmation, approval workflow, and a designated reviewer separate from the requester |
Defining these tiers before writing any tool code forces an explicit conversation about acceptable risk, rather than discovering the right threshold after an incorrect transaction has already posted.
The draft-then-confirm pattern
The safest general shape for any SAP write tool is a two-step interaction: the model proposes a fully populated draft document, showing every field it would submit, and a human reviews and explicitly confirms before the actual SAP transaction executes. This is not meaningfully slower than a direct write for the user, since reviewing a filled-in draft takes seconds, but it catches the specific failure mode where a model produces a plausible-looking but incorrect field that would otherwise post directly into SAP.
Idempotency prevents duplicate postings
A model or an agent retrying a failed or timed-out request is a realistic scenario, and without protection this can create duplicate purchase orders or duplicate postings from what was meant to be a single user action. Attaching an idempotency key, a unique identifier generated once per logical request and checked before executing, ensures a retried call recognizes the earlier attempt rather than creating a second document. This is standard practice in payment and transactional systems generally, and SAP write integrations benefit from the same discipline.
Reusing SAP's own workflow rather than bypassing it
SAP already has release strategies and approval workflows for purchase orders and similar documents, built up over years to encode a company's actual financial controls. An AI-initiated write should submit into that same existing workflow rather than being engineered to bypass it for the sake of a faster demo, since bypassing it means the AI integration is now operating with less oversight than a human user doing the identical transaction manually.
Frequently asked questions
What should happen if a write partially fails midway through?
The tool should surface the partial state clearly, including what SAP document number, if any, was created, rather than silently retrying or reporting simple success or failure, since a partial failure in a multi-step SAP transaction can leave a document in an inconsistent state that needs a specific correction rather than a blind resubmission.
Who should be able to approve a high-tier write?
Whoever already holds that approval authority in SAP for the equivalent manual transaction; the AI integration should not introduce a separate approval hierarchy but instead route into the existing one, so accountability and audit trails stay consistent with how the organization already operates.
Does logging the AI-generated request matter if SAP already logs the transaction?
Yes, because SAP's own transaction log shows what was posted but not necessarily the full context of what was asked, what the model proposed, and who confirmed it, which matters for reconstructing the sequence of events if a posting is later found to be incorrect.
How Nanobase AI helps
Nanobase AI implements SAP write actions behind exactly this kind of tiered, draft-then-confirm architecture, wired into existing SAP approval workflows rather than around them, with idempotency and audit logging built in from the first version rather than added after an incident. The broader integration architecture this sits within is covered in integrate-llm-with-sap.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.