Read-only first: connecting agents to SAP S/4HANA

APIs expose data; they do not replace your process

SAP documents OData services for S/4HANA business objects through the API Business Hub and gateway documentation. Services describe entities, keys, and authorisation concepts; your tenant activates only the APIs your basis team releases. Stellitron does not claim SAP certification — we integrate with the interfaces you approve during a pilot, including file-based IDoc or extract paths when OData is not yet exposed.[1][2]

Read-only first is a governance choice, not a technical limitation. OData can support updates, but ProcureAI pilots deliberately separate read access from posting until match logic is trusted on real document keys. That mirrors how internal audit teams prefer to see new tooling: observe, explain, then — with a named approver — write the smallest possible status change back.[1][2]

Entities and keys to agree in discovery

Anchor on the same keys AP already uses: company code, purchasing document, item, material or service line, vendor, fiscal year, and invoice document number. Typical read entities include purchase orders, goods movements or receipt references, supplier invoice headers and items, and vendor master attributes needed for duplicate detection. Your basis team confirms which published OData services match your activation and whether ECC versus S/4 naming differs in your landscape.

If OData is not available in week one, a scheduled extract to a secure landing zone is acceptable. The agent logic is the same; only transport changes. Document the refresh cadence so reviewers know whether a case used last night’s snapshot or a live pull.

FinanceAI scenarios on the same ERP — for example clearing accounts or open items for reconciliation — follow the same read-first rule. Keep procurement and treasury scopes separate so least-privilege reviews stay understandable.

Timeline from sandbox to optional write-back

Phase A (sandbox): map ten representative documents per object type, including at least one intentional mismatch your AP team remembers. Validate that ProcureAI holds cite the same PO and invoice lines SAP displays. Phase B (shadow): run the pilot batch daily, compare agent holds to your existing workflow, and log connector errors without posting. Phase C (narrow write): enable one approved action — often a payment block or invoice hold code — through the API or BAPI your team selects, with maker-checker in SAP unchanged.

Hold codes and status updates are the most sensitive writes. Treat them as a separate security ticket from read access. Document which SAP roles may still release payment after an agent-suggested block so you do not accidentally create a parallel approval chain.

On-premise ECC and private S/4 instances usually add VPN, reverse proxy, or cloud connector requirements. The agent behaviour does not change; network and credential storage do. Secrets stay in your vault; connector code runs in the region you designate.

What to measure before expanding entities

Measure field mapping accuracy and match outcomes independently. A wrong plant or company code mapping will poison every narrative. Track unexplained agent findings the verifier removed — that is a health signal, not noise. Compare time to clear exceptions for the pilot batch against your baseline, including reviewer corrections.

Expand read scope only when the batch is stable: add more company codes, intercompany POs, or service POs without GRN after written agreement on evidence rules. Do not enable write-back for bulk posting or automatic GR creation; those are outside the complement-not-replace positioning.

Timelines depend on sandbox access and security queues, not marketing slides. A focused read-only feed for one entity set often takes a few weeks once credentials exist; each additional write path adds its own test cycle. This is planning guidance from Stellitron pilot practice, not a fixed delivery promise.