Purchase Order Intake Without Re-Typing It
Manufacturer sales teams re-type customer POs into SAP every day. An AI agent reads the email, maps buyer codes to SAP materials, and creates the order.
The Monday Morning PO Stack
A sales administrator at a UK precision components manufacturer arrives at 08:30 and opens her email. There are 31 purchase orders waiting, sent over the weekend by customers across three industries — automotive OEMs, aerospace MROs, and industrial equipment distributors. By the time she has cleared the inbox and entered all of them into SAP SD, it will be Tuesday afternoon.
The orders themselves are not complex. Each one says: customer wants these parts, in these quantities, delivered by this date. The complexity is in the intake.
One automotive customer sends a PDF with their own part numbers, none of which match the SAP materials catalogue. A translation table maps roughly 140 of their codes — the other 12 have to be looked up manually. An aerospace MRO sends their PO in feet, and the SAP material is priced in metres. An industrial distributor sends POs via email body text rather than a PDF attachment, so any automated extraction breaks entirely.
Each order takes eight to fifteen minutes to enter cleanly. Thirty-one orders: four to six hours of work before anything else can happen on Monday morning.
This is the baseline condition for most manufacturers selling to B2B customers on non-EDI channels — which is the majority of their customer base. EDI (Electronic Data Interchange) works well for the largest customers who invest in standardised connections. For the remaining 70 to 80 percent of customers who send orders by email, manual entry is the rule.
What Is Inside the PO Stack
Purchase order intake complexity falls into three categories that compound each other.
Format variation. Every buyer has their own purchase order template. Some send PDFs generated from their ERP system with machine-readable fields; most send PDFs that are essentially a form printed to file. A few send Excel attachments. A handful email the order as body text. An OCR tool that is tuned for one format produces noise on the others.
Code translation. The buyer's item code is their internal reference. The seller's SAP material number is theirs. These rarely match, and there is no universal cross-reference. A manufacturer with 400 active customers may maintain 400 separate translation tables — or not maintain them at all, leaving each lookup to institutional memory. When a product is discontinued and a substitute is released, translation tables need updating. When they are not updated, the wrong material gets entered.
Validation. Before a sales order can be created in SAP SD, several questions need answers: Is the price on the PO consistent with the agreed framework contract or pricelist? Is the requested delivery date achievable given current stock and lead time? Is the customer within their credit limit? Is this a product the customer is authorised to order, or does it require an export licence check? Each of these is a separate lookup in a separate SAP table, and none of them appear on the PO itself.
A human sales administrator does all of this from memory and experience. It is not difficult. It is just time-consuming and error-prone at volume.
Why OCR Stops Halfway
Optical character recognition solves the first part of the intake problem: it extracts text from a document. For well-structured PDFs with consistent layouts, modern OCR tools reach high accuracy on field extraction — customer name, order number, line items, quantities, requested dates.
OCR does not solve the translation problem or the validation problem.
Translating the buyer's item codes to SAP material numbers requires a mapping table. Maintaining that mapping table requires someone to update it every time a product is added, renamed, or discontinued. For a manufacturer with hundreds of active B2B customers, each with their own coding conventions, mapping maintenance becomes its own operational task. OCR reads the code on the PDF; it cannot resolve it to an SAP material number without a current, complete mapping in place.
Validation is even further outside OCR's scope. Checking whether the quoted price matches the framework contract requires access to the pricing condition records in SAP. Checking stock availability requires a real-time query against SAP MM. OCR extracts data from a document; it has no connection to the ERP system where validation happens.
The result is a hybrid: OCR handles the well-formed documents from the largest customers, and a person handles everything else, including the exceptions that OCR flags for review. For most manufacturers, this means OCR reduces but does not eliminate the manual workload.
What the AI Agent Does Differently
| Step | Manual entry | OCR alone | AI agent |
|---|---|---|---|
| Extract line items from PDF | Human reads and types | Field extraction, accuracy varies by format | Reads any format: PDF, image, email body, Excel |
| Translate buyer codes to SAP materials | Human looks up translation table | Not applicable — returns raw code | Maps against SAP materials master and customer-specific tables; flags unmapped codes |
| Validate price against framework | Human checks SAP pricing | Not applicable | Queries SAP pricing conditions; flags discrepancies |
| Check stock availability | Human runs SAP query | Not applicable | Queries SAP MM in real time |
| Create SAP sales order | Human enters VA01 | Not applicable | Writes to SAP SD (VA01) on confirmed lines |
| Route exceptions | Human resolves them | Flags document-level errors | Routes line-level exceptions with extracted context to named reviewer |
The agent reads the document regardless of format. It parses the line items. For each line, it queries the SAP customer master and materials master to find the matching material number — applying the same translation logic a human would use, drawn from the same mapping data, but without the lookup time. For lines where no mapping exists, it creates an exception task with the original buyer code, the document context, and a proposed nearest match for a human to confirm.
Once translation is confirmed, the agent validates each line: price against pricing conditions in SAP SD, delivery date against available stock in SAP MM, and customer account status against the credit management module. Lines that pass validation go directly to order creation. Lines with discrepancies — a price that is 3 percent below the agreed rate, a delivery date that falls before available stock — go to a human reviewer with the specific discrepancy highlighted.
The SAP sales order is created line by line, in the same transaction (VA01) that a human would use, applying the same mandatory fields: sales organisation, distribution channel, sold-to party, ship-to party, material number, quantity, unit of measure, requested delivery date, pricing condition. The agent does not bypass SAP validation — it completes it before submitting.
What SAP Integration Actually Requires
Connecting an AI agent to SAP SD is not the same as giving it read access to a report. Order creation requires write access to specific transactions, and write access carries risk if it is not properly scoped.
The minimum scope for an intake agent is:
- Read access to the customer master (XD03), materials master (MM03), and pricing conditions (VK13)
- Read access to stock availability (MM60 or the availability check in VA01)
- Write access to sales order creation (VA01), restricted to the relevant sales organisation and distribution channels
- No access to financial postings, billing (VF01), or credit master maintenance
Most SAP installations allow this scope through a custom role that mirrors what a junior sales administrator role would carry. The agent operates within those role boundaries, the same way a human user does.
The integration also needs error handling at the SAP level. When SAP rejects a proposed order — credit block, missing required field, plant-to-customer combination not permitted — the agent must catch that rejection, route the exception to a human with the full context, and not retry without confirmation. An automated agent that silently retries a rejected order can create duplicate records or escalate a credit situation that needed human attention.
The AI agents built for SAP order entry and email-to-ERP workflows that operate at scale in manufacturing environments share one characteristic: the integration design treats SAP's own validation as the authority, not as an obstacle to work around.
What Changes for the Sales Administration Team
The practical effect of automating the structured part of PO intake is not headcount reduction. For most manufacturers, it is a shift in what the team does with its time.
A manufacturer processing 150 purchase orders per week, of which 80 percent are well-formed and mappable, automates 120 of them. The remaining 30 — new customers with no established code mapping, orders with pricing disputes, customers on credit hold, products that require export licensing checks — still need a human. But the human is now handling 30 decisions rather than 150 data entry tasks.
The result is capacity freed for work that actually requires judgment: maintaining and expanding customer code mappings as the product catalogue evolves, managing the pricing exceptions that signal a customer is testing a rate renegotiation, identifying delivery date commitments that are systematically optimistic and causing fulfilment problems downstream.
This applies directly to the spare parts and consumables ordering channels that run alongside standard PO intake in most manufacturing operations: the same intake logic applies, and automating it at scale changes the operational rhythm without changing the structure of the team.
The EU Regulatory Backdrop
For manufacturers selling to customers across the European Union, e-invoicing is changing the structural context for order intake.
EU Directive 2014/55/EU has required public sector bodies across all member states to accept electronic invoices since 2019. Italy extended mandatory B2B e-invoicing to all VAT-registered businesses in January 2024. Germany and France are on implementation schedules that bring mandatory B2B e-invoicing into force through 2027 and 2028 respectively. The European Commission's VAT in the Digital Age (ViDA) proposal, adopted in principle in 2024, creates a framework for near-real-time digital reporting across EU member states.
These mandates address the invoice side of the transaction. They do not address the order side: how the purchase order, issued by the buyer before any invoice exists, reaches the seller's ERP. That intake problem remains unsolved by e-invoicing mandates — and for manufacturers whose customers include a mix of EDI-enabled accounts and email-based accounts, it will remain their operational challenge regardless of what happens to invoicing.
An AI agent that processes email-based purchase orders into SAP is a complement to e-invoicing adoption, not a substitute for it. The two address different parts of the order-to-cash cycle.
FAQ
What happens when a buyer changes their PO template?
The agent reads document content rather than relying on fixed field coordinates. A new layout from an existing customer produces lower confidence scores on some extractions, which triggers human review for that batch. The review resolves the new template, which the agent learns from. Template changes slow but do not break the automation for established customers. New customers with no prior documents require a supervised first run to establish the baseline.
Can the agent handle partial orders and blanket releases?
Yes, with configuration. A blanket purchase order — a framework that releases specific quantities against a pre-agreed total — requires the agent to check the outstanding balance on the blanket before creating each release in SAP. This is a standard SAP scheduling agreement (VA31/VA32) workflow rather than a standard sales order, and the integration scope needs to include scheduling agreement write access. It is a common configuration for manufacturers with automotive OEM customers.
What is the accuracy level we should expect?
Accuracy depends on document quality and how current the code mapping tables are. For well-formed PDFs from customers with established mappings, straight-through processing rates above 85 percent are achievable on correctly entered orders — meaning 85 in 100 orders create without human intervention. For customers with poor-quality PDFs or unmaintained mappings, the rate drops and exception handling increases. The right question is not "what is the accuracy?" but "how does the exception rate compare to the current fully-manual error rate?"
How does this interact with the credit management team?
Credit management in SAP is controlled by credit limit checks built into the sales order creation flow (OVA8 configuration). The agent does not bypass these checks. An order from a customer who has exceeded their credit limit will be blocked by SAP, the agent will log the block as an exception, and the credit management team will see it in their standard work queue — exactly as they would if a human had entered the order. The agent does not change the credit workflow; it submits to it.
How long does a deployment take?
For a manufacturer with SAP SD in place and an existing customer base, initial deployment — scoping the customer base, building the initial code mapping tables for the top 20 accounts, configuring SAP integration and testing — typically runs eight to twelve weeks. The first weeks of live operation are supervised: the team reviews every output and the exception rate provides a calibration signal. Straight-through processing typically reaches its operational level within four to six weeks of supervised live operation as mapping coverage is completed and edge cases are resolved.
Further reading: