VioPO Blog

Automating sales order entry from customer POs

2026-10-04T07:20:00Z

Most B2B suppliers receive the bulk of their orders the same way: a PDF attached to an email, sent to a shared mailbox. This article describes a workflow for getting those orders into your system without retyping them, and without losing the checks a good order desk applies.

The shape of the workflow

Collect the attachments from the order mailbox.
Read each one into structured data.
Match the customer and the products to your own records.
Decide: post automatically, or send to a person.
Create the sales order.
Keep a record of what happened to each order.

Steps 1, 3, 5 and 6 are ordinary integration work. Step 2 is the hard one, and step 4 is the one that decides whether you can trust the rest.

1. Collecting attachments

Most mail platforms can forward or expose attachments to a script. Common options are a rule that forwards to an automation tool, a scheduled job that reads the mailbox over IMAP or the Microsoft Graph API, or the attachment trigger in an integration platform you already use. Keep the original email with each order so a person can see the context if needed.

Skip what is clearly not an order: email signatures, logos, terms and conditions. File type and size filter most of these. A model will also tell you when a document does not look like an order; VioPO returns is_purchase_order: false in that case.

2. Reading the order

Send each PDF or image to the extraction API. With VioPO that is one request to POST /v1/extract, and the response holds the header, parties, addresses, lines and totals in a fixed format.

3. Matching to your records

The order tells you what the customer printed. Your system needs its own ids.

Customer. Match on VAT number or company number first, then on the account reference the customer uses for you, then on name. Names alone are unreliable: "Northgate Joinery Ltd" and "NORTHGATE JOINERY LIMITED" are the same customer.
Delivery address. Match against the customer's known delivery addresses by postcode, then by street. A new delivery address is worth a person's look.
Products. If the customer prints your part numbers, match on those. If they print only their own, keep a cross-reference table per customer. Build it as you go: each time a person resolves an unknown part number, save the pair.
Units. Convert the customer's unit to yours. Watch for pack sizes: "box of 200" against a product you sell each.

4. Deciding what to post

This is the step that makes automation safe. Post an order automatically only when all of these hold:

every arithmetic check passed (line amounts, lines to subtotal, total);
there are no warnings;
the customer, the delivery address and every product matched;
prices agree with your price list or the quoted prices, within a tolerance you choose.

Everything else goes to a review queue, with the PDF and the extracted data side by side, and the reason it was held. In most order books a minority of orders need a look, and the order desk spends its time on those instead of on typing.

5. Creating the sales order

Use your ERP's import or API. Put the customer's PO number in the field your system prints on delivery notes and invoices, so it flows through to the documents the customer expects.

6. Keeping a record

Store the request id, the decision and who approved it. When a customer queries an order months later, you want to see what was read, what was posted, and why.

Start small

Run the reading step alongside your current process for a week or two. Compare what was read with what your team keyed. You will see quickly which customers' orders read cleanly and where your matching tables need work.

VioPO is not open yet. You can see its output on three sample orders now, and join the waitlist to hear when you can send your own. The Free plan at launch reads 50 pages a month.

How to extract data from purchase order PDFs

2026-10-04T07:10:00Z

If your customers send purchase orders as PDFs, someone or something has to turn each one into data your order system can use. There are four ways to do it. Each has a place, and each fails in its own way.

1. Typing them in

The default. A person opens the PDF and keys the order.

It works on any layout, needs no software, and a good order desk catches odd things a machine would not, such as a price that does not match the quote.

It is slow, and it does not scale with volume. Errors are rare per field but there are a lot of fields: an order with 20 lines has well over 100 values to key. The mistakes that get through tend to be the costly kind, such as a transposed digit in a quantity or a delivery sent to the invoice address.

2. Templates

A template tells the software where each field sits on one customer's layout: the order number is in this box, the lines are in this table between these columns.

For a handful of large customers who send the same layout every time, templates are accurate and cheap to run.

They break when the layout changes, and layouts change whenever a customer updates their ERP, edits their form or exports from a different system. Every new customer needs a new template. With a long tail of customers, maintaining templates becomes a job of its own.

3. OCR plus rules

OCR (optical character recognition) turns the page image into text. Rules or regular expressions then look for fields: a number after "PO No.", a date near "Order date".

OCR is mature and reads clean print very accurately. The trouble is structure. Tables come out as lines of words with the columns lost, and two address boxes side by side are often read across, so their lines interleave. The rules that find fields are, in effect, templates written in a different way, and they fail in the same places.

If your PDFs come from software they usually have a text layer already, and you can skip OCR and read the text directly. The structure problem stays.

4. Vision language models

A vision language model takes the page image and an instruction, and answers in text. Asked to fill a fixed JSON structure, it reads the page much as a person does: it sees that a table has columns, that one box is labelled "Deliver to" and another "Invoice to", and that "Q-55120" next to "Your quote" is a quote reference.

The advantage is that there is no template. A layout the model has never seen is handled the same way as a familiar one.

The risks are different from OCR's:

It can be wrong with confidence. A model may put a value in the wrong field, or occasionally produce a value that is not on the page. Instructions help ("use null when a value is not present") but do not remove the risk.
Formats drift. Left to itself, a model writes dates and amounts however they appeared. You need a fixed schema and a step afterwards that normalises dates, numbers and codes.
Cost and privacy. Hosted model APIs charge per token, and send your customers' orders to a third party.

The fix for the first two is to treat the model's output as a reading to be checked, not as the answer. Purchase orders are good for this because they check themselves: quantity times unit price should equal each line amount, the lines should sum to the subtotal, and the subtotal plus tax and carriage should equal the total. A misread digit almost always breaks one of those sums.

Which to use

A few customers, steady layouts, low volume: typing, or templates.
Many customers, changing layouts: a vision model with a fixed schema, normalisation and arithmetic checks, and a person reviewing only the orders that fail a check.

That second approach is what VioPO does, with the model running on hardware we operate rather than a third party's API. It is not open yet, but you can see its output on three sample orders.

What is on a purchase order? The fields that matter

2026-10-04T07:00:00Z

A purchase order is a buyer's written offer to buy goods or services on stated terms. Once the supplier accepts it, it is the contract for that sale. Every later step leans on it: the warehouse picks against it, the delivery note quotes it, and the buyer's accounts team will not pay an invoice that does not match it.

No two companies lay one out the same way, but almost every purchase order carries the same few groups of information.

The header

The header identifies the order.

Order number. The buyer's reference. It is the single most important field, because the buyer will expect it on the delivery note and the invoice. Many accounts teams return invoices without a valid PO number unpaid.
Order date. When the order was raised. It matters for price validity and for matching later.
Revision. Some systems issue amended orders with the same number and a revision or change number. Treat a revised order as replacing the old one, not adding to it.
Quote reference. If the order accepts a quote you sent, it should say which. That is how you know the prices on the order should be the ones you offered.
Currency. Often only shown as a symbol on the amounts.
Requested delivery date. For the whole order, or per line.

The parties

The buyer is the organisation placing the order. Its name usually sits in the letterhead, often with a VAT number and company number. A person named beside "Buyer" or "Ordered by" is the contact, not the customer.

The supplier (or vendor) is you. The order may include your account number in the buyer's system, which you will need to quote back on the invoice.

The addresses

There are usually two that matter, and mixing them up is a common and expensive mistake.

Delivery address ("Ship to", "Deliver to"). Where the goods go. Often a warehouse, a site or a specific goods-in door, sometimes with delivery hours.
Invoice address ("Bill to", "Invoice to"). Where the invoice goes. Increasingly this is an email address for an accounts payable mailbox rather than a postal address.

When an order says "deliver to the address above", the delivery address is the buyer's own.

The lines

Each line is one item:

a part number, either the buyer's own code, yours, or both;
a description;
a quantity and a unit of measure: each, box, pair, case, metre;
a unit price, sometimes with a discount;
a line amount;
sometimes a tax rate and a delivery date for that line only.

Units cause more trouble than they should. "Box of 200" priced per box is very different from 200 screws priced each.

The totals

Subtotal, any discount, carriage, tax and the total. These are the figures the buyer expects to see on your invoice. They are also the easiest way to catch a mistake: if the lines do not add up to the subtotal, either the order is wrong or it was read wrongly.

Terms and instructions

Payment terms ("30 days end of month", "Net 45"), shipping method, Incoterms for international orders, and free-text instructions such as delivery windows or "quote our PO number on all invoices". These are easy to skip and often the reason an invoice is rejected.

Why the fields matter more than the layout

From the supplier's side, the job is to get these fields out of the document and into your own system without changing any of them. The layout around them changes with every customer; the fields do not. That is the idea behind VioPO: whatever the document looks like, the output has the same fields, in the same format, with checks that the figures add up.