Do You Need PO Automation If You Already Run SAP?
SAP is your system of record and automates the structured, in-system steps of procurement well. What it doesn't do is read the unstructured supplier communication before data lands in it: the emails, PDFs and Excel confirmations your team still processes by hand. That gap is where the hours go. You don't replace SAP to close it; you add an AI layer on top, with no migration.
If you already run SAP, the honest question isn't "should we switch" but "does SAP already cover this, or is there a real gap?" Here's where the line actually falls.
Key takeaways
- SAP automates the part of the cycle it can see: the MRP run creates the requisition, the requisition becomes a PO, output determination sends it. What comes back by email was never part of that cycle.
- An acknowledgement arriving as an EDI ORDRSP posts itself onto the PO item. The same acknowledgement as a PDF gets read and typed in by a person.
- SAP lists every PO still missing an acknowledgement. It cannot open the one in your mailbox.
- Closing the gap means a layer on top, over the mailbox and a lightweight API: no migration, no master-data cleanse, no waiting for S/4HANA.
- At Klöckner that layer books 81% of order lines with zero human edits, across 150 suppliers and 1,100+ PO lines a week.
What SAP does well
Start with the part that runs by itself. An MRP run turns demand into a purchase requisition. The requisition converts into a purchase order, automatically where the material and vendor are set up for it. A release strategy holds anything above the value threshold until the right person approves. Output determination pushes the finished PO to the supplier by email, print or EDI. That is genuine SAP procurement automation, and it runs unattended as long as nothing unexpected comes back.
Where SAP is already enough
Ask "does SAP automate purchase orders" and the accurate answer is that it automates the ones that stay structured end to end. When a supplier returns an acknowledgement as an EDI ORDRSP, the inbound IDoc updates the confirmation on the PO item, planning sees the new date, nobody touches it. Downstream works the same way: invoice verification matches invoice against PO and goods receipt, and your tolerance keys block whatever falls outside the configured price and quantity limits.
SAP is strong once data is clean and inside the system: it holds master data, enforces approval logic, records transactions, and gives you a system of record with a full trail. If your orders arrived as clean, structured EDI feeds that matched your master data exactly, you'd need very little on top of it.
What SAP leaves to your team
They don't. Supplier confirmations arrive as free-text emails, PDF attachments and spreadsheets that match no template. A planner creates the PO in SAP, emails the supplier, gets an unstructured reply, reads it, and re-keys the changes into SAP by hand. SAP can't read that email, decide what it means, or book it. The work falls to a person. Multiply that across confirmations, follow-ups, delivery changes and invoice exceptions, and you have the "messy middle" that consumes hours without requiring real judgment.
Watch what the person does with one of those replies. They open the PDF, work out which PO it belongs to (the supplier quotes their own order number, not yours) and go down the lines. The supplier's article code has to resolve to your material number. Pieces have to convert to metres. A confirmed 480 against 500 ordered needs a judgment: partial delivery with the rest to follow, or a shortfall worth an email today. Then the confirmed quantity and date go onto the confirmations tab of each item, one item at a time.
SAP is not blind to the gap; it simply can't cross it. The confirmation control key on the PO item tells the system an acknowledgement is expected, and a monitoring report lists every item still missing one. It's a useful report. It also stops where the work begins: the acknowledgement it asks about is sitting in a shared mailbox as an attachment, and SAP cannot open it, interpret it, or write the result back. Chasing the ones that never arrive is somebody's calendar reminder.
That is the ERP automation gap in plain terms. It isn't a missing SAP module but a class of input SAP was never built to consume. Volume is what makes it expensive rather than hard: Klöckner moves 1,100+ PO lines a week across 150 suppliers, Oatly takes in around 2,500 orders a month. At the $30–50 a manual supply-chain touchpoint commonly costs, a few hundred re-keyed lines a week is a budget line, not an annoyance.
Why SAP's own AI stops where it does
Even SAP's own AI features summarize or act on data already structured and inside the system. They don't autonomously process the inbound, unstructured communication that creates the manual work in the first place.
Where SAP purchase order automation stops, line by line
Mapped across the life of one order line, the split is easy to see.
| Step | Handled inside SAP | Handled by a person |
|---|---|---|
| Demand to requisition | MRP run creates the requisition | Nothing |
| Requisition to PO | Automatic conversion where material and vendor allow it | Manual conversion for everything else |
| Approval | Release strategy by value and org unit | Nothing |
| Sending the PO | Output determination by email, print or EDI | Nothing |
| Acknowledgement over EDI | Inbound ORDRSP updates the item confirmation | Nothing |
| Acknowledgement by email or PDF | Nothing | Read it, match it, judge it, key it in |
| Date change mid-flight | Nothing until someone records it | Read the mail, update the item, warn planning |
| Acknowledgement never arrives | Report lists what is outstanding | Write the chaser, track the answer, escalate |
| Invoice mismatch | Three-way match and tolerance blocks | Investigate the block and resolve it |
The middle column runs itself. The right column is your team's morning.
Why the answer isn't "replace SAP"
It never is. Ripping out years of SAP configuration to solve an inbox problem is the wrong-sized response, and it invites exactly the switching cost and risk you'd want to avoid. The right-sized response is an operational layer on top of SAP that reads the unstructured input, matches it to your SAP master data, and books validated transactions back. That leaves SAP as the system of record it's meant to be.
GeneralMind does this over your existing mailbox and a lightweight API. It works on heavily customized SAP (ECC today, S/4-ready), reading and writing through the interfaces your instance already exposes. No migration, no data cleanse first, no six-month project. Nothing is written to SAP below your confidence threshold; those cases escalate to an operator with a drafted response, and every action is logged.
The connection is deliberately dull. We adapt to the interfaces your instance already exposes and maintain them as your system changes, so a release upgrade is our maintenance rather than a line on your roadmap. Matching runs against your live material master and open order book and scores every line, so an operator confirms or corrects a filled-in booking rather than reading the PDF from the top.
That is what "AI on top of SAP" has to mean to be worth buying: no ERP modification, no parallel master data, no second system for planners to learn. The same layer runs on Microsoft Dynamics, Oracle, Infor and 100+ connected systems, tuned across roughly 20 enterprise order-intake deployments on SAP. Hosting is in Frankfurt with disaster recovery in Stockholm, under ISO 27001:2022, ISO 27701 and SOC 2 Type II.
What this means for your S/4HANA plan
Most SAP shops have a migration somewhere on the roadmap, and the instinct is to wait for it. Waiting buys nothing and costs every hour in between, because the inbox problem is identical on ECC and on S/4. It lives outside both. Start on ECC. The connectors carry over, and the thresholds and supplier-specific rules you tune this year keep working after the migration.
What the first six weeks look like
Go-live is a mailbox rule and a service user, not a programme. The layer starts on real documents in shadow mode: it proposes bookings, an operator confirms or corrects each one, and every correction teaches it your material master, your unit conventions and the habits of individual suppliers. Extraction on an unfamiliar supplier mix is right around 85% of the time on day one and reaches 93–95% within weeks.
From there the share of SAP order processing that goes straight through without a human edit climbs. Past 90% on full autopilot in roughly six weeks is the typical pattern rather than a promise, and it depends on how consistent your supplier base is. Oatly runs around 2,500 orders a month with 80% on Autopilot. Teams get back about 60% of manual processing time in the first three months, and it goes into escalations and expediting, the work that needs a buyer's judgment.
How to tell if you have the gap
Ask your team to log one week of work that happens outside SAP: reading confirmations, chasing missing dates, reconciling mismatches, re-keying supplier changes. If that log is thin, SAP is enough. If it's hours per person per week (the usual finding), that's the gap, and it's exactly what an AI layer closes. At Klöckner, that layer books 81% of order lines on top of SAP with zero human edits.
Two counts sharpen it. Of the POs you sent last month, how many came back over EDI and how many came back as a mail a person had to read? Then count the chasers: every "any update on PO 45xxxxxxx?" someone typed by hand. The second figure in each pair is your gap, and multiplying it by what a touchpoint costs gives you the business case without a workshop.
When not to buy
The unflattering version deserves saying out loud. If you run one plant, send forty POs a week to a dozen suppliers who all return an ORDRSP, and nobody in purchasing can name a confirmation they typed in last week, an AI layer is overhead. Set your confirmation control keys properly and spend the budget elsewhere. The case only holds when that week's log comes back thick: hours per person, across confirmations, date changes and chasers, on documents whose format nobody on your side chose.
Frequently Asked Questions
It automates the structured, in-system steps. It doesn't read or act on unstructured supplier emails, PDFs and Excel files, which is where most manual PO work lives.
No. GeneralMind works on customized ECC today, with connectors that carry over to a later S/4 migration.
No. It's an operational layer on top. SAP stays your system of record; GeneralMind feeds it validated data from the unstructured communication it can't process itself.
Ariba handles structured, network-based procurement; suppliers not on the network still send unstructured email. GeneralMind covers that, alongside Ariba. (See the GeneralMind vs SAP Ariba comparison.)
Over the mailbox your suppliers already write to, plus a lightweight API against the interfaces your SAP instance already exposes. There is no ERP modification and no parallel master data, and we adapt to those interfaces and maintain them as your system changes. Reads go against your live master data and open order book; writes happen only above the confidence threshold you set, and every action is logged with a timestamp and the reasoning behind it.
No. Each line is scored against the master data you have, and anything below your threshold escalates to an operator instead of being posted, so gaps surface as escalations rather than bad bookings. Accuracy on an unfamiliar supplier mix starts around 85% and reaches 93–95% within weeks as corrections teach the system your material numbers and unit conventions.
