What an AI execution layer really looks like

Key takeaways

• The ERP is not missing features. What is missing is anything that owns the coordination between the ERP and the inbox.
• An execution layer reads unstructured input, extracts the entities, reconciles them against the record and then acts. Creating a task for a person to act is the old behaviour.
• It has to be event-driven. A nightly reconciliation job tells you about yesterday, which is the problem restated rather than solved.
• Roll out one document type first, then the steps around it, then move from proposing to acting. At Klöckner, 81% of order lines now book with zero human edits across 150 suppliers and more than 1,100 lines a week.
• If your inbound is already structured, or your volumes are low, or three teams disagree about master data, this is the wrong purchase until that changes.

The work that sits between systems

Across modern supply chains the binding constraint is rarely a missing feature in the ERP. It is the work that happens between systems: reading emails, updating spreadsheets, reconciling data that disagrees, and chasing clarifications across teams and time zones. People act as the connective tissue between procure-to-pay and order-to-cash, and they keep the flow moving at the cost of speed, accuracy and any hope of scaling it.

The reason this is hard to budget for is that it never appears as a system. It appears as a person who knows that this supplier sends confirmations as scanned PDFs, that this customer's portal has to be checked on Thursdays, and that the freight surcharge on that account is always disputed. Costed properly, with handling and rework counted in, one manual touchpoint in these processes usually lands between $30 and $50.

An AI execution layer takes that role. It does not replace the systems of record; it sits over them, listens to signals from email, chat, portals and APIs, and executes the next action. For a large manufacturer or distributor that means thousands of small decisions a day: matching a delivery note to a purchase order, moving an expected arrival date, resolving an invoice discrepancy, flagging an order that should not go out.

What makes an AI execution layer different

Workflow tools have automated supply chain steps for twenty years. The difference is what the layer can accept as input. A workflow engine needs a form; an execution layer takes a supplier's free-text email, a scanned attachment or a portal message and works out what it means. Language models handle the reading, and document understanding handles the layouts nobody templated.

The second difference is that it learns the house. Which SKU a supplier means by an inconsistent description, which cost centre an invoice line usually codes to, which date changes your planners wave through and which they escalate. That knowledge currently lives with whoever has been doing the job longest, and it leaves when they do.

The third difference is the one that matters commercially: it acts. A tool that reads a document well and then creates a task for a person to key the result has moved the work, not removed it. The same idea travels under other names, agentic automation and autonomous enterprise among them, and the substance behind all of them is whether the software writes to the system of record or hands you a to-do.

The systems and channels it has to connect

Designing the layer starts with an honest map of what it must talk to. The system of record is usually an ERP: SAP, Oracle or Microsoft Dynamics. Around it sit a transport management system, a warehouse system, a sourcing platform, and a sprawl of mailboxes, shared drives and chat channels that no architecture diagram admits to. The layer has to speak all of it, and to keep those connections working as each one changes.

At the edge of the process are the channels where work actually appears. A purchase order change arrives as a PDF on a reply-all. A shipment delay shows up as a message in a customer portal. A dispute lands as an attachment in a shared mailbox. The layer has to read those, pull out the entities that matter, order number, SKU, quantity, date, price, and reconcile them against what the ERP currently believes.

That reconciliation is the step worth dwelling on, because it is where most projects are won or lost. Extraction accuracy is easy to demonstrate and rarely the constraint. Knowing that the quantity on this confirmation refers to a line the buyer already amended twice is the constraint, and it needs the record and the correspondence read together.

Orchestration, and why it has to be event-driven

Once the information is normalised, orchestration decides what happens: which system to update, who to notify, and whether this case matches a pattern the layer is allowed to close or one a person should see. A supplier pushes back a delivery date. The layer can check which customer orders depend on that delivery, work out what it does to the promised dates, and put up the options: expedite an alternative source, reallocate stock, or tell the customer.

The architecture has to be event-driven rather than batch. A nightly job that reconciles yesterday's data produces a report about a problem that has already reached the customer. Responding when the message arrives is what makes the difference between visibility and history, and it is the single design decision most likely to be got wrong because batch is easier to build.

Security and data governance are design inputs rather than a procurement afterthought, because this layer touches financial and operational data by definition. That means SOC 2 Type II and ISO 27001:2022, hosting in a region that satisfies your data residency position, granular access control, and an audit trail that records what changed, why, and under which policy. GeneralMind hosts in Frankfurt with disaster recovery in Stockholm, and carries ISO 27001:2022, ISO 27701 and SOC 2 Type II.

That record is what makes the layer reviewable rather than merely capable. An auditor asking why a price changed on a given order gets the document it came from, the policy that permitted the change and the confidence score at the time. In regulated environments that trail is the precondition for moving anything to autopilot at all, which is why it belongs in the design rather than in a later hardening phase.

How to roll it out without betting the process

Nobody sensible starts with end-to-end autonomy. The pattern that works is one document type, well bounded, with real volume: purchase order confirmations or remittance advices are the usual entry points. One document and its workflow is enough to test extraction on your own data, the integration into your own ERP, and what happens when something fails, which is the part that never gets rehearsed.

From there the scope grows outward rather than upward. Once confirmations process reliably, the same layer can chase the ones that never arrived, re-plan deliveries when dates move, and tell the affected people. A deployment that starts with cash application grows into collections: drafting the outreach, proposing the payment plan, flagging the account that has stopped answering.

The other half of the rollout is the frontline, and it is the half that gets underfunded. Planners, buyers and order management teams need to see why the layer did what it did. That is what a co-pilot phase is for: the system proposes, the practitioner decides, and the reasoning is visible in each case. As the edit rate falls, scenarios move from proposing to acting, and they move one at a time.

The numbers behind that curve are steady enough to plan against. Day one lands near 85% straight through. A few weeks of learning the master data and the local exceptions takes it to 93 to 95%. Autopilot above 90% arrives around week six, and about 60% of the manual handling time is back inside three months. Klöckner is the reference at scale: zero human edits on 81% of order lines, 150 suppliers, over 1,100 lines every week, on the SAP install they already had. Oatly sits at 80% autopilot across roughly 2,500 orders a month.

Where an AI execution layer is the wrong purchase

If your inbound is already structured, most of this does not apply. A business whose partners all send ORDRSP IDocs over EDI has solved the reading problem, and a layer on top of clean structured data is cost with no return. What stays worth looking at is the long tail: the partners too small to onboard, who between them generate most of the exceptions.

Volume decides the rest. Below a few hundred documents a month the layer has too little repetition to learn from quickly, and the coordination being removed adds up to well under a week of one person's time. At that size a hire is the better answer, and that is what we will tell you. Timing works the same way. Mid-migration to S/4HANA, wait: automating against interfaces that already have a replacement date is buying the same work twice.

The case worth naming plainly is governance. If finance, sales and operations maintain customer or material master data differently, a layer writing into that record will propagate the disagreement faster and make it harder to trace back. No amount of language modelling fixes an ownership question. That one gets settled by people first, and then this becomes worth buying.

What changes when the coordination disappears

None of this needs a rip-and-replace. Layering over the ERPs and communication tools already in place is what preserves the investment already made in them, and it is also the only version that gets approved. GeneralMind runs over a mailbox and a lightweight API, fitting whatever interfaces each system already publishes and keeping those fittings working as they change.

The outcome to hold the programme to is not autonomy for its own sake. It is faster order cycles, lower days sales outstanding, fewer manual touchpoints and better data going in, each of which can be measured before and after on one workflow. Anchor the business case in those and the staged rollout pays for the next stage as it goes.

What that adds up to is not science fiction. It is a supply chain where routine coordination stops being anybody's morning, and the people who used to do it spend their time on the supplier relationships, the exceptions that need judgment and the resilience planning that never fits in a day that starts with a queue.