How the OC Agent connects to your systems
From shared mailbox to ERP, end to end
The agent sits between the supplier inbound channel and your ERP. This article explains both sides of that connection and how an incoming confirmation becomes a thread.
ERP integration
The ERP, for example SAP S/4HANA, is both the source of your purchase orders and the target for confirmed values. Two integration modes are supported so the agent fits different IT landscapes.
| Mode | How it works | Typical use |
|---|---|---|
| API (SAP) | Direct API connection. Purchase orders are read and confirmed values are written back programmatically: delivery dates, prices, quantities, header terms, line items, cancellation and delivery complete indicators. | Customers with an accessible SAP API layer who want real time read and write. |
| SFTP | File based exchange. Purchase orders and confirmations are exchanged as files over a secure SFTP drop. The agent parses inbound files and produces write back files. | Customers who cannot expose a live API and prefer batch integration. |
The write back is field aware. Only fields that are read and write capable are pushed. Key fields and informational fields are never written.
Inbound confirmations via a shared mailbox
Order confirmations arrive by email into a shared inbound inbox, connected through the Microsoft Graph API. The agent:
- reads new inbound mail from the connected mailbox,
- extracts the confirmation document, usually a PDF attachment, and parses it,
- runs the matching gate to link the confirmation to the correct purchase order,
- sends outbound mail such as rejections, reminders, and clarifications from the same mailbox, with full reply and forward threading plus an audit record.
Connected mailboxes can be shared or personal, each with configurable send rights. Permissions, send authority, and data handling under GDPR are governed at the platform level.
The ingestion pipeline
Inbound email through Microsoft Graph, an attached PDF, or an SFTP file drop all feed the same pipeline: parse the document with LLM based structured extraction, then run the matching gate. Matched confirmations enter a comparison path and become a thread. Confirmations that cannot be matched land in the Unmatched inbox.
How matching works
The matching gate tries an exact purchase order number match first, then a supplier match, then a fuzzy fallback, and produces a match confidence score. Below the confidence threshold the confirmation goes to the Unmatched inbox, where you can assign the correct purchase order manually or dismiss the document with a reason.
One inbound email can reference several purchase orders. A collective confirmation is linked to each of them.
The shared data model
The confirmation is stored in the same data model as the purchase order and is filled independently. The confirmation side carries the same header and line item fields as the order side. Mapping the free form supplier document into that model is done by the LLM. There is no deterministic hard wiring of individual supplier layouts.
Extra items a supplier adds, such as freight, packaging, or surcharges, appear in the same data format as any other position. They are simply flagged as extra or not on the purchase order and filled only on the confirmation side.