Review a sales order before it hits your ERP

A sales order in your ERP is a promise to pick, ship, and invoice. A parsed PDF is a draft. The review in between is what keeps a bad line off the warehouse floor.

Do not post straight from a parser

People building their own pipelines say this plainly. On r/n8n, the pattern that survives is: read the PO, and send the lines you are sure of onward only after a check, with the uncertain ones in a queue a person can see. The failure mode they warn each other about is a parser that writes bad data with confidence.

The same warning shows up from the warehouse side. On r/SupplyChainLogistics, teams say a keyed order can look fine and still be wrong when someone tries to fulfil it. Address, part number, quantity, price. Fixing it there means a short pick, a reship, or a credit. Fixing it on the way in means a two-minute look.

What is worth a look before you confirm

• The customer is the account you think it is, not one with a similar name.
• The PO number is the one on their document, so you can trace the sales order back to it.
• Every line is one of your products. Their item code has been mapped. See customer part numbers.
• The quantity and the unit make sense for how you sell that product.
• The price matches their tier, or you recognise the difference and accept it. See price tiers.
• The ship-to is a place you already deliver, when the PO bothers to say.

What OrderWiz holds back

Nothing posts until you confirm. Lines that did not map to your catalog, and prices that do not match the customer’s tier, sit in needs review first. You can remap a line before you confirm. When you do confirm, the sales order posts into your ERP.

That is the whole product in one pass: read the purchase order, map it, check it, and let a person say yes. If that is the pile on your desk, tell us how the orders come in.