Why retyping purchase orders goes wrong

The short answer. Retyping a customer's emailed PDF purchase order asks one person to read it, translate it into your item codes and units, and type it without a slip, which is where wrong items, wrong quantities or units, old prices, forced item matches, ship dates that can't be kept and missing PO numbers come from. The fix is to build checks into order entry rather than ask for more careful typing: look items up in a customer part number cross-reference, accept only item codes that exist, show the PO's price beside the customer's own price instead of copying it, compare the line count and PO total with the PDF, and check stock before promising a date. The electronic counterpart of an emailed PDF is the X12 850 Purchase Order transaction set, the standard for placing purchase orders for goods and services.

Most of a distributor's orders arrive the same way: a customer emails a PDF purchase order, and someone in the office types it into the order sheet. It feels like the safe way to do it, because a person is looking at every line. In practice it is where a lot of the week's mistakes start, and they tend to surface late, at the shelf, on the truck or on the invoice.

The reason is simple. Retyping asks a person to do three jobs at once: read the customer's document, translate it into your codes and your units, and type it without a slip. Each job has its own way of going wrong, and the person doing all three is usually also answering the phone.

Last reviewed: November 11, 2026

The mistakes retyping causes

These are the ones a fittings or supply house sees most, in roughly the order they cost money.

  • The wrong item. The customer writes their own part number, or a plain description like "1/2 in. brass elbow, 90 deg." Someone has to decide which of your items that is. A close match that isn't quite right ships the wrong part, and nobody finds out until the customer opens the box.
  • The wrong quantity or unit. A 10 becomes a 100, or a line for 5 boxes of 10 goes in as 5 each. Both look fine on screen.
  • An old price. Customers often send a PO from last year's quote. If the order takes the customer's price, you lose margin; if it takes yours without saying so, the invoice gets disputed.
  • A line that matches nothing. A product you don't carry gets forced onto the nearest item code instead of going back to the customer as a question.
  • A promise you can't keep. The order goes in with the requested date, and nobody checks whether the stock is on the shelf or already promised to someone else.
  • The missing PO number. Some customers won't pay an invoice without it, and it is the easiest field to skip.

None of these is carelessness. They come from asking a person to translate under time pressure, with no second look built into the process.

A worked example

Here is an illustrative week, with numbers made up to show the arithmetic. Say your office receives 30 emailed purchase orders a week with an average of 8 lines each. That is 240 lines typed by hand every week, or about 12,000 a year.

Every one of those lines has the chances above to go wrong: the item, the quantity, the unit, the price and the date. If even a small share slips through, you are looking at wrong shipments every month, each one costing a return, a second shipment, a credit and a phone call. The point is not the exact rate, which differs from office to office. The point is that the number of chances grows with every line you type, so the fix has to be in how the lines get entered and checked, not in asking people to type more carefully.

How to do it better, even in a spreadsheet

You can remove a good share of these mistakes without new software. It takes some setup, and it works best when one person owns it.

  1. Keep a cross-reference sheet. One row per customer part number, with the customer, their code, their description and your item code. Look items up from it instead of from memory, and add a row the first time you see a new code.
  2. Validate the item code. Use data validation so the order sheet only accepts codes that exist in your item list. A typo then stops at the cell instead of reaching the shelf.
  3. Check the price, don't take it. Put the PO's price in its own column beside your price for that customer, and flag any line where they differ. Decide on each flagged line; never copy the PO's price straight into the order.
  4. Count and total. Before saving, compare the number of lines and the PO total with the PDF. A missing or doubled line shows up at once.
  5. Mark what you weren't sure of. Add a column for "check this" and send those lines back to the customer before you confirm the order.
  6. Look at stock before you promise. Even a weekly count is better than none, but say on the order which count you used.

The limits are real, though. The cross-reference sheet only knows codes someone already added. The stock figure is as old as the last count. And the whole thing still depends on one person typing every line, so the spreadsheet catches some mistakes after they are made rather than preventing them.

How a system does it

A system changes the order of the work. Instead of a person typing and then checking, the system drafts and a person checks. The demo for Brightwater Fittings Co., a fictional fittings distributor, shows how that works.

The emailed purchase orders sit in a list, each with a button to draft the order with the AI helper. The AI reads the customer's PDF and returns the customer, the PO number, the dates and each line as the customer wrote it, with a suggested item code and how sure it is. Then the system takes over, because the AI reads but never decides:

  • the customer is matched from the sender;
  • every suggested code is checked against the catalog, and a code that isn't in the catalog is treated as no match;
  • the price comes from the customer's own price, and a different price on the PO is shown as something to check, not used;
  • the ship date is worked out from live stock and restocks.

Dana, the sample salesperson, then checks the draft with the PDF beside it. The lines the AI was unsure about are listed first. She corrects what needs correcting, sees what is on the shelf, what is already promised and what is free for each line, and confirms. Nothing becomes an order until a person with the right to enter orders confirms it.

The demo's three sample purchase orders are built to show the hard cases. One customer writes Brightwater's own codes, but one item is short on the shelf. One writes only its own part numbers and plain descriptions, and carries an old price. One is mixed, with a line for hose that matches nothing in the catalog. Each mistake from the list above is either caught by a rule or put in front of a person before the order exists.

Once confirmed, the order lands on the warehouse's shipping list, and the stock follows it.

Try it, and what it costs

The distribution page explains the whole system, from order entry to the owner's dashboard. The live demo lets you sign in with one click as Dana, with no account to create, and let the AI draft an order from an emailed purchase order. The data resets every night, so you can't break anything.

A typical build costs $8,000 to $25,000 at a fixed price, and hosting and support start at $350 a month.

Questions

What mistakes happen when retyping customer purchase orders?

The wrong item, the wrong quantity or unit, an old price taken from the PO, a line forced onto the nearest item code, a ship date promised without checking stock, and a missing PO number. They come from translating under time pressure with no second look, not from carelessness.

Should an order use the price on the customer's purchase order?

Not without checking. Customers often send a PO from an old quote, so put the PO's price beside your price for that customer and decide on every line where they differ.

How can a spreadsheet catch purchase order entry errors?

Use a customer part number cross-reference, data validation that accepts only existing item codes, a column comparing the PO price with your price, and a check of the line count and PO total against the PDF before saving.