Creating a purchase order takes a minute and decides how much work the eventual invoice generates. Most fields are bookkeeping. Three of them are where future exceptions are set, and each is trivial to get right now and awkward to unpick once invoices are already arriving against a wrong assumption.
The supplier's legal entity
Groups bill from entities whose names differ from the trading name you deal with. An order against the wrong one produces invoices that cannot match, and the improvised fix of creating a second supplier record splits payment history and breaks duplicate detection. Confirm the entity once at supplier setup and it stops being a problem.
The unit of measure
Ordering by case and being invoiced by unit produces a quantity mismatch every time, and it is nobody's error. Agreeing the unit with the supplier and recording it on the order removes a permanent exception source with one conversation, and it is the most common avoidable mismatch in a payables queue.
What the price includes
Whether delivery, packaging and tax sit inside the unit price. An order silent on freight will mismatch every invoice that adds it, which presents as a tolerance problem and is really an unstated assumption. Being explicit lets tolerance stay tight enough to catch genuine price movement.
Questions people ask about create a po
What else must be on it?
A unique number, the date, lines with description and quantity, the delivery address and date, and your payment terms.
Can it be changed after sending?
Yes, as a dated revision rather than an overwrite, with re-approval above a threshold.
What if we do not know the price?
Use an estimate marked as such or a not-to-exceed value, so the match has something to compare against.