Finance Index
How do I create a purchase order - what is the standard process for raising a PO?
Reference guide to how to create purchase order, including request intake, purchasing controls, approval routing, vendor coordination, and finance visibility.
The standard flow: an approved purchase request is converted into a PO - vendor, line items, quantities, rates, coding, and currency carried over - the PO routes through its own approval if required, and is then issued to the vendor. The two rules that matter most: POs should be born from approved requests (not created cold), and they should exist before the purchase, not after.
At a Glance
| Aspect | Short Answer | Why It Matters |
|---|---|---|
| Create a purchase order | The standard flow: an approved purchase request is converted into a PO - vendor, line items, quantities, rates, coding, and currency carried over - the PO routes through its own approval if required, and is then issued to the vendor. | Keeps vendor records and payment decisions reliable. |
| Who should be allowed | Restrict PO creation to a small set of trained roles - procurement specialists, purchasing admins, or designated finance users - and let everyone else feed them via requests. | Keeps spend controlled before the commitment is made. |
| Related terms | Code at the PO (or earlier, at the request) and inherit forward. | Keeps accounting records aligned with the ERP. |
| Spend control | Buyer and vendor identity, PO number and date, line items with descriptions, quantities, unit prices, and extended amounts, currency, ship-to and bill-to, delivery expectations, payment terms, and any terms and conditions. | Reduces payment errors, timing issues, and reconciliation cleanup. |
| The types of purchase | Standard POs cover a defined one-time purchase; blanket POs set a ceiling for repeated releases over a period; contract POs reference master agreement terms without committing quantities; planned POs schedule future releases against forecast needs. | Keeps vendor records and payment decisions reliable. |
Who should be allowed to create POs - requesters, a purchasing admin, or finance?
Restrict PO creation to a small set of trained roles - procurement specialists, purchasing admins, or designated finance users - and let everyone else feed them via requests. The PO is a commitment document; broad creation rights are how duplicate, mis-coded, and unauthorized POs happen. Requesters ask; specialists commit.
What GL coding should happen at PO creation vs at invoice time?
Code at the PO (or earlier, at the request) and inherit forward. Coding at commitment means budget impact is classified correctly from day one, the approver sees where the spend lands, and invoice matching can carry the coding automatically instead of AP re-deriving it. Invoice-time coding is a fallback for non-PO spend - not the design for PO-backed spend.
What information must a purchase order contain?
Buyer and vendor identity, PO number and date, line items with descriptions, quantities, unit prices, and extended amounts, currency, ship-to and bill-to, delivery expectations, payment terms, and any terms and conditions. Plus internal data the vendor never sees: coding, budget line, approver trail.
What are the types of purchase orders - standard, blanket, contract, planned?
Standard POs cover a defined one-time purchase; blanket POs set a ceiling for repeated releases over a period; contract POs reference master agreement terms without committing quantities; planned POs schedule future releases against forecast needs. Mid-market teams live mostly on standard and blanket.
How do I set up PO numbering - best practices across entities?
Use system-generated sequential numbers, never manual ones, with an entity prefix where multiple entities issue POs. The only real requirements are uniqueness and traceability - resist encoding meaning (department, year, category) into the number itself; that's what fields are for.
How do I create a PO from an approved requisition automatically?
In a connected system this is a conversion, not a re-entry: the approved request's lines, vendor, coding, and amounts populate the PO form, the specialist reviews and adjusts, and the link between request and PO persists for audit. If your process re-keys requisition data into PO screens, that's the automation gap to close first.
How do I create POs in my ERP vs in a procurement tool that syncs to the ERP?
Native ERP PO entry keeps everything in one system but typically requires ERP licenses, training, and IT-managed workflows. A procurement front-end creates POs in a friendlier workspace and syncs them to the ERP as the system of record. The deciding factors are who creates POs (specialists can handle ERP screens; distributed teams can't) and how rigid your ERP's approval routing is.
Should POs be created in the ERP or in a front-end procurement system that syncs?
If only a trained central team raises POs and your ERP workflows suffice, native works. Choose a front-end when you need request intake, flexible approvals, budget visibility, or PO creation by people who will never log into the ERP - with the non-negotiable that POs sync back so the ERP remains the source of record.
How do I handle POs in foreign currencies?
Issue the PO in the vendor's transaction currency with the currency explicit on every line, and let your system handle conversion for budget and reporting views. Matching should compare in transaction currency with a rounding tolerance for FX precision.
How do I add shipping, freight, and tax lines to a purchase order?
Add them as separate lines or header-level charges rather than burying them in item prices - visible freight and tax estimates on the PO prevent predictable match exceptions when the invoice arrives with them. If they're unknown at PO time, set tolerance rules that accommodate them at matching.
Our POs are created after the purchase already happened ("confirming POs") - is that bad and how do we fix it?
Yes - a confirming PO documents spend but controls nothing, and auditors discount it accordingly. Fix the upstream cause: the sanctioned request path is slower or less known than buying directly. Make requesting fast, route approvals automatically, and reserve the after-the-fact path for logged, reviewed emergencies.
What is a retroactive or after-the-fact PO, and why do auditors hate them?
A PO created after the commitment (often after the invoice) to satisfy a policy requirement. Auditors flag them because they prove the control didn't operate - authorization is supposed to precede commitment, and a backdated artifact can't fix that.
How do I attach quotes, contracts, or specs to a PO?
Attach them at the request stage and let them follow the record through PO, receipt, and invoice - approvers should see the quote in context, and the audit file assembles itself. Attachments bolted on after issuance rarely survive for the auditor.
How do I copy or template POs for repeat purchases?
Use reorder-from-previous or saved templates so recurring buys start pre-populated - and pair them with blanket POs where the purchase repeats on a schedule. Templating is also an accuracy control: repeat POs inherit correct coding instead of being rebuilt from memory.
Stampli perspective
In Stampli, a PO is generated from an approved purchase request in a single step, carrying over header fields, line items, vendor, budget, and currency, with Stampli AI assisting line-item creation from request context, item history, and uploaded item lists. Stampli POs and ERP POs coexist in one workspace: ERP POs import automatically on a schedule, and Stampli-created ERP POs export back to the ERP on approval - so the ERP stays the system of record without procurement working inside it.