A morning of purchase orders
The order office opens the shared inbox to find a stack of POs. Each customer's buying system produces a different layout. One uses its own item codes, one uses yours, one uses a description. Quantities are in units, bundles or pallets. Some quote an old price. One references a spec version that changed last month.
Each PO is read, the product found, the price checked if there is time, and the order keyed into the MIS. Mistakes happen, and some mismatches are only discovered when the invoice is queried.
Every buyer's PO looks different
Customers' purchasing systems are built for their own needs, not for your order entry. Their codes and descriptions, units of measure and price references differ from yours. The order office bridges the gap by knowledge and memory, which is slow and depends on experienced people.
- PO layouts differ between every customer.
- Customer item codes must be translated to yours.
- Units of measure vary between units, bundles and pallets.
- Prices on POs are not always checked against agreed prices.
- Spec version references are rarely compared.
Where retyping costs you
Retyping takes skilled staff time that grows with every new customer. Keying errors produce the wrong product or quantity, which is costly to put right once the job is on the floor. Price mismatches that are not caught lead to invoice disputes and delayed payments. And the knowledge of how to read each customer's PO lives with a few people.
The timing matters too. A PO keyed in the afternoon misses the planner's cut off for that day, so a job that could have started tomorrow starts the day after. Across a year, that small delay on every order adds up to a lot of lead time your customers never needed to wait.
PO reading we build
- Purchase orders sent to your order address are read by an extraction step designed for PDFs and emails, with a language model to handle unfamiliar layouts.
- Customer item codes and descriptions are mapped to your products, and the mapping is learned as the order office confirms new ones.
- Each line is checked: quantity against minimums and unit of measure, price against the customer's agreed price, delivery date against lead time, and spec reference against the current version.
- Clean orders are created in your MIS through its import or API, and an acknowledgement goes to the customer.
- Lines that do not match go to an exception queue, showing the PO, what was expected and what differs, for a person to resolve.
- Customers who send EDI are handled through the same checks, so there is one process.
| Check | Done now | Done with PO reading |
|---|---|---|
| Product code | Translated from memory | Mapped and learned |
| Price | Checked if time allows | Checked every line |
| Unit of measure | Converted by hand | Converted and checked |
| Spec version | Rarely compared | Compared with current |
| Order entry | Retyped | Created in the MIS |
An order office that handles exceptions
The order office spends its time on the orders that need attention, not on keying. Price and spec mismatches are raised with the customer before production, not after invoicing. Orders are entered sooner, which helps planning. And new customers can be added without adding keying work.
Is your order office retyping POs?
- Customer POs are keyed into the MIS by hand.
- Customer codes are translated from memory.
- Price mismatches are found at invoicing.
- Orders have been made to the wrong spec version.
- Order entry depends on one or two experienced people.