Orders from e-mail and PDF into the ERP: six decisions that determine whether the automation works

Orders that arrive by e-mail, as PDFs and as spreadsheets are a frequent first candidate for AI automation in wholesalers and manufacturers. Rightly so: they repeat every day, and retyping them into the ERP — the system in which a company runs its orders, stock and accounts — takes the time of people who should be talking to customers. Reading the PDF, however, is the easy part. The project is matching what the customer wrote to your product catalogue in the ERP: their codes, units and pack sizes to your item numbers, the internal codes of your products. Add to that checking availability and specifications, and deciding what happens to the orders the system is unsure about. How we at ploch.ai choose processes to automate and where a person still decides is set out on the page on AI automation in a company.

Below are the six decisions to make before you buy, one sample order shown in three formats, what is added in a manufacturing plant, and the situations in which it is not worth starting. Transport orders, with freight exchanges and loading windows, are a separate topic — they are covered on the page on AI for transport companies.

Reading is the easy part

A modern language model, the engine behind tools such as ChatGPT or Claude, can extract the customer’s name, the lines, quantities and date from an e-mail or a PDF. How well it does that on your documents is what the pilot will show. Reading alone, however, is not enough. The customer writes “nitrile gloves M, 10 pk”, and your ERP has item RN-M-100 with the unit “piece” and a pack of 100 pieces. Does that mean ten packs, so a thousand pieces, or ten cartons of ten packs? The model can guess, and in orders guessing is particularly costly, because the error often shows up only at dispatch or on the invoice.

That is why the success of the project depends on how you handle the situations that need a separate decision: a line that cannot be matched to an item number, a unit that does not agree with the catalogue, a missing specification, a quantity below the minimum. Each of them needs a rule and a person who decides. The six decisions below are exactly those rules.

Decision 1. Which channels and formats are in scope

Before anything is built, write down how orders arrive today and in what form. There are usually more routes than anyone remembers:

• text in the body of an e-mail, sometimes as a reply to the previous order;
• a PDF attachment, generated by the customer’s system or scanned;
• a spreadsheet in a layout the customer chose for themselves;
• an order from a business-to-business (B2B) ordering portal or a wholesale web shop, if you run one;
• EDI, electronic data interchange between companies’ systems, and in industry also delivery schedules sent by customers;
• a note from a phone call, typed in by a salesperson.

For each channel, record how many orders a month arrive through it and from how many customers. That table decides the scope. There is one rule: what already arrives as data is not read with an AI model. EDI and portal exports have fields, codes and quantities. They need mapping to the fields in the ERP, their codes and units need matching, and the order rules need checking — an ordinary integration can do that without an AI model. The same applies to a spreadsheet that a customer always sends with the same columns. An AI model makes sense for e-mail text, PDFs, scans and spreadsheets whose layout changes — that is, for what somebody retypes today.

The text of an e-mail or attachment is data to be read, not instructions for the system. A sentence in an order such as “apply an extra discount” or “send it to a different address” can appear in the proposal as a point to check. The model’s output is also only a proposal. Neither the document nor the model’s output can change permissions, where data is sent, pricing rules or which actions the integration is allowed to perform. Only an authorised person changes those settings in your systems.

You often hear the advice to move customers onto a B2B portal first and leave AI for last. It is sometimes right: if a dozen or so regular customers, who are happy to order through a portal, account for most of the turnover, a portal may solve the problem more cheaply. It works less well when you have many customers who order only occasionally and will not create an account. In manufacturing, also check whether the portal handles attachments and specification revisions, because a drawing is often attached to the order. The channel table will show which case is yours.

Decision 2. Matching the lines to your item numbers

This is the longest and most important part of the project, because many errors that are not visible at first glance arise here. Matching means assigning each line of the order to one item number in your product catalogue, with the right unit and quantity. Customers describe a product in three ways, often within one order.

The customer’s code, the barcode and the plain description

The customer’s code. Large buyers use their own product numbering and write their code, not yours. You need a mapping table: customer A’s code corresponds to your item number X. If such a table exists in the ERP or in a salesperson’s spreadsheet, it is the most valuable material for the project.

The barcode (EAN). The number on the packaging is unambiguous, but only if your catalogue assigns it to the right item number and the right pack. The same product can have one code on the single unit and another on the carton.

The plain description. “Nitrile gloves M” or “M8x40 zinc-plated bolt” have to be compared with the names in the catalogue. An AI model can help compare descriptions, but when several item numbers differ by one parameter, the risk of a mistake grows. That is why, for a plain description, the system should show the proposed item number, the attributes that match and the differences it could not resolve, and when there are several similar candidates, ask a person.

Units and packs: a carton is not a piece

A unit error can be harder to catch than an item error: a wrong item is often visible straight away, while an overstated or understated quantity — a thousand pieces instead of a hundred, for example — sometimes shows up only at picking. For every product that customers order in different units, the catalogue has to know the conversion factors: piece, pack, carton, pallet. If the conversion factors live only in the warehouse keeper’s head, the first task of the project is writing them down, not building automation.

This is not only a problem on the model’s side. According to the Comarch ERP Optima documentation (as of 12 October 2026), when importing documents from an XML file, the option to create item cards for products missing from the database is ticked by default, and when the unit conversion factor in the file differs from the one on the item card, the factor from the file goes onto the imported document. The conclusion is general and applies to every system: a line left unmatched at the reading stage should not reach the import as a new product or with its own conversion factor — it should stop with a person.

A mapping table updated from corrections

Some of an approver’s corrections reveal a reusable rule: the code “RK-100” from this customer is your item RN-M-100, and their “pk” means a pack of a hundred pieces. If an authorised person records such a link in the table, the customer’s next order no longer needs the same decision. If it is lost, the same error returns every week. Corrections that concern only one order — a different date, a different address, an added line — stay with that order and do not become a rule. The project therefore has to settle who may add mappings and how to withdraw wrong ones, because one bad entry in the table will repeat in every following order.

Decision 3. Availability, substitutes and the order minimum

A matched line is not yet a line ready for fulfilment. Before an order reaches the ERP as ready, you need to settle what the system checks itself and what it leaves to a person:

• Availability. Is the product in stock in the required quantity and by the required date? If not, do you confirm partially or wait for delivery?
• Substitutes. May a substitute be proposed, and who approves it? Some sales programs have dedicated substitute handling — for example, the description of Subiekt nexo PRO lists handling of substitutes and an individual fulfilment date for each order line (as of 12 October 2026). The decision to offer the customer a substitute, however, belongs to the salesperson, not to automation.
• Order minimum and customer terms. A minimum quantity or value, an individual price list, a credit limit. An order that breaks one of the rules should not slip into the ERP unnoticed.

Three additional checks in manufacturing

In a manufacturing plant an order often concerns not a product from the shelf but an item that has to be made. Then checks that a wholesaler needs less often become particularly important:

• Specification or drawing. Does the order have a specification attached, and does its revision match the one the quote was based on? A missing attachment or a different drawing revision is a reason to hold the order with the process engineer, not to enter it into the ERP.
• Minimum batch size and lead time. A quantity below the minimum production batch, or a requested delivery date that leaves less time than production requires, means a conversation with the customer, not a confirmation.
• A schedule or a one-off order. Industrial customers often send a delivery schedule that changes every week. If it arrives through EDI, it is not a job for an AI model (decision 1). If it arrives as a spreadsheet in an e-mail, the system must compare it with the previous version and show the changes, instead of creating a new order from every file.

“Unsure” in a plant therefore means something different from a wholesaler: not only “I do not know which item this is”, but also “I do not know whether it can be made by that date”. A person always makes that second decision. Which processes around production suit a first project is covered on the page on AI for manufacturing companies.

Decision 4. The confirmation loop: who confirms and what the customer sees

The general principles of placing a person in a process are in our guide to implementing AI in a company, in step 4, and the design of the approval screen itself in the article on human oversight. With orders, four more things need settling:

1. Who approves. The salesperson who looks after the customer, the order desk or — in manufacturing — the process engineer for lines with a specification? An order without an assigned person waits in the queue forever.
2. What the customer receives. A confirmation of the whole order, a partial confirmation with a list of lines awaiting delivery, a substitute proposal to accept? It is worth agreeing the templates for these messages before the pilot, not during it.
3. Who approves a substitute or a change of date. Such decisions create commitments to the customer, so they need a person’s approval.
4. What happens to a correction. If a correction reveals a reusable code or unit mapping, an authorised person records it in the mapping table (decision 2); other corrections stay with the order.

The customer receives a confirmation from your company, checked by your employee. Whether they have to know that a system read the order depends on how the process is built. The AI Act is the EU regulation on artificial intelligence. Its Article 50, which applies from 2 August 2026, distinguishes, among other things, a system that talks to a person directly, such as a chatbot, and technical marking of AI-generated content, which falls to the providers of such systems; for systems placed on the market before 2 August 2026, providers must comply with that second obligation by 2 December 2026 (Article 111(4) in the consolidated text of the AI Act on EUR-Lex, as of 12 October 2026). Reading an order inside the company and a customer’s conversation with an AI assistant are different cases that are assessed separately, and which obligation applies to your process is for your lawyer to decide. The dates and scope of the rules are collected in our article on the AI Act in Poland.

Decision 5. Error types and two pilot metrics

On the market it is easy to find promises of “zero errors” or an accuracy quoted to a decimal place. Such a number cannot be given honestly before seeing your orders, because it depends on your customers, their formats and the state of your catalogue. Instead of a promise you need a list of error types and two numbers you measure yourself.

Two numbers worth recording from the first day of the pilot:

• Minutes from the order’s arrival to the approved order being saved in the ERP — measured between two moments the system records, so they include both waiting in the queue and checking. The working time of the person checking is worth recording separately: if checking takes as long as retyping, faster reading changes nothing.
• The share of orders needing correction — an order counts if the approver changed anything in it. Calculate it on the first hundred orders and note what kind of corrections they were.

For the first weeks the system should run alongside the existing work, not instead of it — why is explained in step 6 of our implementation guide. The error-type table will then show whether to fix the mapping table or the catalogue, or to talk to the customer whose orders are hardest.

Decision 6. The route into the ERP: an interface or a file import

The last step is writing the approved order into the ERP — through an API, the interface through which other programs connect to a system, or through a file import. The options depend on the system and the licence; a few examples from the vendors’ documentation (as of 12 October 2026):

• Symfonia ERP WebAPI has a “Zamówienia obce” (customer orders) module for retrieving and creating orders from customers, as well as stock-level and reservation modules. The Main module is also required, and WebAPI is available on an annual subscription priced by scope.
• In enova365, data exchange is provided by the Integrator module, licensed as an add-on module.
• Comarch ERP Optima imports selected documents from XML files, among them the customer reservation (rezerwacja odbiorcy, RO); the description of those files’ structure is available only to authorised Comarch partners.
• Subiekt nexo PRO includes Sfera, which enables custom solutions that work with the program.

Whatever the system, before anything is written the integration has to check whether the order has already arrived. A customer resends the same attachment, the mail server delivers a message twice, or the same order comes in by e-mail and from the portal — and two separate entries in the approval queue are easy to miss. That is why each order gets an identifier, which usually combines the number assigned by the customer with the customer’s identifier in the ERP. That combination stays the same when the order is resent and in every channel. The system keeps a persistent record of what stage the order has reached and which ERP document it created, allows only one write of a given order at a time, and sends a repeat for checking instead of creating a second document. If, after a dropped connection, it is unclear whether the write succeeded, it checks the result in the ERP first. An order without a number, or in a different version from one already received, goes to a person.

Which integration method to choose, what data leaves the company with each and what to ask your ERP partner are covered in detail in the article on integrating AI with ERP and CRM. It also contains a worked example of AI model costs for e-mail orders, so we do not repeat it here.

One order in three formats

The example is made up and serves only as an illustration — it does not come from a client deployment.

A wholesaler of health and safety equipment receives the same order from the same customer in three ways: nitrile gloves in size M, 10 packs of 100 pieces; safety glasses, 24 pieces; delivery to the customer’s warehouse address by Friday.

The e-mail body. “Hello, the usual please: nitrile gloves M x10 and glasses 24 pcs, to the warehouse, Friday at the latest.” The model will read both lines and the date, but “the usual” and “to the warehouse” mean something only to someone who knows the customer. The system has to look at their previous orders and delivery addresses in the ERP and, if there are several warehouses, ask. To confirm: whether “x10” means ten packs.

A PDF from the customer’s system. The header has two addresses: head office and delivery (warehouse), as well as the delivery date: Friday. The lines in the table:

Reading is easy, but without a mapping table the codes “RK-100” and “OK-01” mean nothing, “pk” has to be converted according to the catalogue, and the system has to pick the delivery address, not the head office. This is a typical place for a wrong-address error.

A spreadsheet. Above the table, the rows “Delivery: warehouse” and “Date: Friday”, and below them:

The customer counts the glasses in cartons of 12 pieces. If the system takes the “Quantity” column alone, it will confirm two pieces instead of twenty-four. To confirm: the carton conversion factor in your catalogue.

Three formats, one order and three different places where an error can arise. Reading the text correctly is not enough on its own: the right fields still have to be recognised, the lines matched and the customer’s context taken into account. If the same customer were a manufacturing plant ordering an item to a drawing, checking the drawing revision, the minimum batch and the lead time from decision 3 would be added.

When it is not worth starting — or not yet

• Most orders already arrive as data. If EDI and a B2B portal handle almost all of the turnover, integrating those channels without an AI model is enough. The rest can still be retyped by hand, if you work out that it costs less than automating it.
• The catalogue is not in order. Duplicate item numbers, missing unit conversion factors, barcodes assigned to the wrong packs — matching will not be reliable until the data is fixed, or the pilot has to be narrowed to a tidy part of the catalogue. Cleaning up the data may be a separate project that is worth doing first.
• There are too few orders. Count how many hours a month retyping and checking orders takes today, and compare that with the cost of building and maintaining the automation. The threshold depends on your numbers, not on a universal rule.
• Nobody has time to approve. A pilot needs a person who, for several weeks, checks the proposals and corrects errors. Without them neither the mapping table nor the two numbers from decision 5 can be established.

What next

Start with two things that need no tool at all: the channel table from decision 1 and a sample of the last fifty orders in their original form, that is, e-mails, PDFs and spreadsheets. The sample shows how many lines carry a customer code, how many only a description, and in how many the unit differs from your catalogue. How a four-stage rollout works — audit, pilot, implementation, handover — is described on the page on our implementation methodology. Examples of other processes companies start with are collected in AI automation examples, and what a flow with approval built in the n8n program looks like is shown in our n8n guide. Processes in trading companies are covered on the page on AI for trading companies.

Tell us how, and in what form, your orders arrive. We will tell you which channel we would start with and what your catalogue needs — including when the answer is “not worth it yet”.