Order Processing 2026: From Email to Your System

A confirmed order arrives as a PDF attachment. The salesperson opens the attachment in one window and the accounting program in the other. Then the lines get typed across: customer, product, quantity, price, delivery date. For most small and medium companies order processing still starts there. A person copies data that was already typed once, in another company, into another system.

That step is worth looking at before anything else, because nothing about it is hard. The data is structured on the sending side and it is structured on the receiving side. What sits between them is a person reading one screen and typing into another.

Why does order processing still start with retyping?

Because the two companies never agreed on a format, and neither of them has to. Your customer exports the order from their system as a PDF or a spreadsheet, attaches it to an email and considers the job done. From their side it is done.

On your side the same order now has to be read by a person. They work out which of your product codes the customer's line names refer to. Then they check the quantity and the price against what was agreed, and enter the result. The same data then gets used again for the invoice and the delivery note.

Three different arrivals make this harder than it sounds. An order can come as a PDF generated by the customer's own system. It can also be a spreadsheet the customer fills in, or plain text in the body of an email. None of them is wrong, and all three need the same ending.

We wrote separately about how a price gets made from an enquiry (opens in new tab) in a manufacturing company. This article starts after that, at the point where the customer has already said yes.

Both ends of the order are already digital

The general figures say the same. In early 2025, 58.1% of Lithuanian companies bought cloud computing services (opens in new tab). Email as a cloud service was bought by 53.6%, and finance or accounting software by 43.5%. The figures come from the State Data Agency.

So the order leaves one system, travels through two cloud mailboxes and arrives at another. A person lifts it across the last two metres, and that is the part of order processing you can remove. The gap is not a technology problem. It grew because the sending company had no reason to care what happens next, and nobody designed it that way.

Nobody counts what the retyping costs, because it is spread across the day in ten minute pieces. The signs are orders entered late in the afternoon and a delivery note that disagrees with the order. Another sign is a salesperson who cannot take a week off without the queue backing up.

What does an AI system do with the email and its attachment?

An AI system reads the attachment in the shape it arrived and pulls out the order lines. It then proposes a match to your product codes and prepares a draft order in your system. A person confirms it. Where something does not add up, the order stops and waits for that person instead of going through.

This is where an AI system does something a rule-based import does not. An import needs a fixed column layout. It works for the one customer it was set up for, and breaks as soon as that customer changes their template. An AI system takes the same order from a PDF, a spreadsheet or an email body. It works from what the document says rather than from where the data sits on the page.

Matching the customer's line names to your codes is the harder half, and it is also where the hours go. The names in their spreadsheet were written by somebody who has never seen your catalogue. A first match gets proposed, a person agrees it once, and from then on that pair is settled. Inside one company the same problem turns up between the warehouse and the shop, and we covered that in what to connect first (opens in new tab).

What stays with a person?

The confirmation, and every case the system is not sure about. An order that matches cleanly arrives as a draft waiting for one click. A draft stops for three reasons. The product is not in your catalogue, the price differs from the agreed one, or the quantity is one nobody ordered before. It goes to a named person together with the reason, and an AI system stops precisely where a fixed template would have guessed.

That boundary has to be agreed before go-live rather than discovered after it. Who owns the queue of stopped orders is a staffing question more than a technical one.

For a sheet metal products company we reworked how custom orders arrive and get priced (opens in new tab). The team did not grow, and the administrative work around each order dropped by half for them. That was one company with one way of working, so the figure is not a promise for yours.

Five questions companies ask

Can a system write into our program, or only read from it?

Both are possible, and they are two separate permissions. Reading out of a program is usually the easy half. Writing into it depends on what the program exposes, and that gets checked before any date is promised. Where writing stays closed, the draft waits in a queue and a person posts it.

What happens when an order arrives in a form the system has not seen?

It stops and goes to a person with whatever could be read from it. A draft that was not guessed costs less than a draft guessed badly.

Our customers use their own product names, not our codes. Will the system cope?

Yes, and it is the normal case. Agreeing the matches is the main work in a project like this. It gets done once per customer rather than once per order.

How many orders make this worth doing?

Count the retyping rather than the orders, because order processing time comes from reading and matching. Twenty orders a month that each take half an hour are a stronger case than two hundred that arrive in one tidy format.

Who is responsible if a wrong line gets entered?

Whoever confirms the draft, exactly as today. The system prepares and flags, and nothing reaches the customer without a confirmation.

When retyping is not worth automating

Three cases where automating the retyping earns nothing.

Orders already arrive through a web shop or a portal. Where the customer enters the order themselves, the data is already structured and that gap does not exist. What is left is a connection between two systems, which is a smaller job.

Every order is negotiated from scratch. If the quantity, price and specification change in three emails before anything is confirmed, there is no stable document to read. The conversation has to settle first.

Volume is genuinely low. A handful of orders a week, all from the same two customers in the same format, does not justify a build. One shared mailbox, an agreed template and a tidy checklist will do the same work.

Where to start

Take the last twenty orders and sort them by how they arrived. There are three piles: a PDF from the customer's system, the customer's own spreadsheet, and text in an email. Then mark how many needed a question back to the customer before they could be entered.

The number of questions is what decides. Where most orders go in without a question, order processing is a connection problem. If most need a question, the matching between their names and your codes is what to fix first, and that is where a project like this begins.

Get in touch (opens in new tab) if your team is retyping orders that arrived in digital form, and we will look at where that can stop.