Agentic purchasing should not bypass the business handoff. An agent may find products, compare information and prepare a proposal, but the handoff of an agentic order to ERP should happen only after customer identity, commercial terms, ordering authority and exception status have been confirmed. ERP can then receive an official transaction with a clear owner, an auditable record and defined processing rules.
In agentic purchasing, a user interacts with an AI interface that may help search an offer, build a basket or prepare purchasing data. This does not turn every proposal, click or structured data set into an accepted business order.
A business process should distinguish at least four states:
The boundary between the third and fourth states matters most. Before it, a system can show information, an estimate or a draft. After it, a record exists that is governed by sales, finance, warehouse, delivery and customer service rules.
In the available source context, UCP is described as a protocol for connecting commerce with AI surfaces. Further descriptions and documentation are published by Shopify - Universal Commerce Protocol and Google - Universal Commerce Protocol guide . The existence of a protocol does not establish support by a specific merchant, payment system or marketplace. Each form of support needs separate verification before a project decision, including applicability in the Croatian market.
ERP is the location of the official business record, not a repository for every piece of information collected by an agent. When an agent hands an order to ERP, the transfer needs enough context to answer several operational questions:
Without these answers, an integration may technically create a document while leaving the content and responsibility open to dispute. This is why control of agentic purchasing terms should precede the creation of a sales order, outgoing invoice, delivery order or another official ERP record.
A practical boundary can be simple: the agent may propose and prepare, while a business rule determines whether the proposal can become an order. That rule does not always require human intervention, but it needs to be explicit and verifiable.
No flow is universal, but the following sequence reduces ambiguity between a conversational interface and the business system.
The agent or connected sales interface collects items, quantities, delivery address, contact details, preferred payment method and the buyer's business identity where relevant. Every data point should have a source: the user, catalogue, contract, ERP master data or an external system.
A catalogue can support selection, but it should not independently become the source for individually agreed prices or credit restrictions. Those data points need validation in the system that owns them as business information.
Identity confirmation answers who is accessing the process. Authority confirmation answers whether that person may order for a specific legal entity, cost centre, project or contract account.
In a B2B process, these checks are often different. A person may have a valid sign-in but lack the right to accept a certain amount, item or payment term. The owner of the authority rule should be named clearly, for example commercial administration, customer management or another designated business owner.
Before the official handoff, the process needs an order version for confirmation. It includes at least items, quantities, unit and total amounts where applicable, currency, tax treatment, address, delivery method, delivery timing or a note about timing, payment method and terms that change the obligation.
A phrase such as "available" or "delivery within a timeframe" needs a business-defined source and status. If the information has not been confirmed from a reliable process source, the interface should present it as information requiring review, not as an accepted term.
Rules should classify an order as automatic acceptance, manual review, or rejection or return for completion. Reasons may include a customer mismatch, missing authority, price change, unavailable item, unclear tax treatment, payment restriction, incomplete address or a conflict with a contract.
The reason for the decision should be retained. A message such as "not possible" is insufficient for an operational team. A more useful status is "manual review - contract price not confirmed," together with the owner of the next action.
The handoff of an agentic order to ERP should contain the source request identifier, the confirmed version of terms, the acceptance decision, decision time, decision owner and links to relevant records where they exist. ERP then returns an official identifier and a received or rejected status.
An agent should not assume success merely because it sent a request. Only the response from ERP or an agreed intermediary layer confirms successful receipt. If the system rejects the request, the process should prevent duplicate submission and route the case to the responsible person or processing queue.
Consider an authorised user of a customer organisation who requests production consumables through an AI interface. The agent finds items, proposes quantities based on the entered request and prepares a basket. This is the preparation stage, not an order.
Before handoff, the system checks the customer's business account, the user's authority, the contracted price list, the plant address and the payment method. One item has no confirmed contract price list. Rather than creating a partly unclear order, the rule sends the full request for commercial review or separates that item according to a predefined rule. Once the terms are confirmed, ERP receives the order with the acceptance reason recorded.
This scenario is not a description of an actual implementation or confirmation that any integration is available. It is a decision framework: at which point does a business obligation arise, and who owns the decision at that point?
Automatic acceptance reduces manual work only for cases with reliable data and clear rules. Automation that is too broad can speed up entry while increasing later corrections, disputes or manual intervention. Rules that are too strict, on the other hand, send every request back to people and remove the benefit of preparation.
A sound design therefore does not choose only between "automatic" and "manual." It defines thresholds, allowed sets of terms and an exception path. Useful questions for the business decision include:
These decisions belong to the business process. Technology implements them, but cannot reasonably infer them in place of sales, finance, logistics and customer management.
Before building an integration or a pilot process, prepare a short list with owners and acceptance evidence.
Inputs and their owners
Decisions that need an owner
Exceptions to describe before go-live
Verifiable acceptance criteria
For organisations that are still defining the boundary between channels, people and ERP, a useful first step is Business process screening . ORKA's approach places daily collaboration and official ERP transactions in distinct but connected responsibilities. After such a review, a team can select a limited set of orders and exceptions for validation before broader automation.