The supplier calls with a change of plan: half the order ships this week and the rest is canceled. The buyer updates the order. Receiving still sees the original quantity, and AP gets a bill for the first shipment. If the three teams are working from different versions of the PO, someone has to reconstruct the order before the bill can be paid.
Creating a PO is the easy part of purchase order automation. The harder part is keeping the approved version, the receipt, and the bill tied together through every change.
The PO lifecycle and what each step must hand on
| Step | What the next person needs |
|---|---|
| Requisition | What is needed, for which entity and cost center, and why |
| Approve the request | Supplier, price, quantity, delivery terms, and who authorized them |
| Issue the order | The exact version the supplier received and, where applicable, confirmed |
| Change the order | What changed, who approved it, and whether the supplier received the revision |
| Receive goods or services | Quantity or work accepted, date, and any rejected or outstanding portion |
| Match the invoice | Approved PO version, receipt evidence, and any unresolved difference |
| Close the order | Final quantities received and billed, and the canceled remainder |
Each row is a handoff, often between people in different departments or locations. Automation helps when it carries the evidence across each handoff; updating a status field alone does not.
Requisition and approval
Write the approval rule before configuring it. A common design routes on amount, category, and cost center, with a budget check against what has already been committed. The approver needs the business reason, the supplier, and the price basis: a quote, a contract rate, or a catalog price.
Decide which purchases need a PO at all. Common exemptions are utilities, rent, and small recurring services, routed as non-PO bills to a budget owner. Write the exemptions down. A “no PO, no pay” policy without a defined exemption list ends with AP holding legitimate bills and requesters raising after-the-fact POs to clear them. After-the-fact POs look like control but provide none, because the purchase already happened.
Issuing and confirming the order
Keep the version the supplier actually received. If the supplier confirms the order, keep the confirmation too. When the bill arrives, AP should be able to tell which price and quantity the supplier agreed to, not just what the PO says today.
Changing an order
A changed PO can require another approval. In Dynamics 365 Supply Chain Management, Microsoft documents how change management can route revisions for approval and how confirmation journals preserve the versions that were confirmed (Microsoft’s purchase order approval and confirmation guide). Check the rules in whatever ERP your buyers use.
Set a reapproval rule by type of change:
| Change | Typical rule |
|---|---|
| Price increase | Reapprove; buyer documents the reason |
| Quantity increase | Reapprove if it crosses the original approval limit |
| Quantity decrease or line cancel | Record; notify receiving and AP |
| Delivery date change | Record; notify receiving |
| Supplier change | Treat as a new order |
| Account or cost center change | Reapprove; cost ownership moved |
Whichever rule you choose, the supplier, receiving, and AP must all see the same current version.
Receiving
For goods, the receipt records quantity and date at the PO line level. Partial receipts are normal. Record rejected units separately from accepted ones so AP can match the bill to what was actually kept.
For services, decide who confirms the work and which record they use. A project manager’s email is evidence, but a receipt or service-entry record in the system is evidence AP can match against. If services are received only by email, expect AP to spend its time chasing confirmations.
Matching the bill
Two-way matching checks the bill against the PO. Three-way adds the receipt. The three-way matching guide covers line-level matching, tolerances, and receipts already used by earlier bills.
Two ERP details to test with your own configuration. For NetSuite, Oracle documents a limitation involving partially received items in its 3 Way Match Vendor Bill Approval workflow (Oracle’s matching workflow). For Sage Intacct, a bill entered in Accounts Payable and a transaction created in Purchasing follow different approval paths (Sage’s bill approval documentation), so check which one your PO-backed bills use.
If the bill arrives before the receipt, route it to receiving with the PO line and the missing quantity. When the receipt posts, the bill should pick up where it stopped rather than starting over.
Closing the order
Open POs that will never be filled distort committed spend, budget reports, and sometimes accrual reviews. Close an order when it is fully received and billed, or when the remainder is canceled. Review the open PO report monthly, oldest first, and ask the buyer to close or explain anything with no activity in your chosen window.
Worked example: the changed order (illustrative)
The original PO is for 400 units at $25.00, $10,000. The supplier ships 200 and cancels the remaining 200.
| Record | If the PO is updated | If the PO is not updated |
|---|---|---|
| PO quantity | 200 | 400 |
| PO value | 200 × $25 = $5,000 | $10,000 |
| Received | 200 | 200 |
| Billed | 200 × $25 = $5,000 | $5,000 |
| Open commitment | $0 | $5,000 |
| Bill status | Matches and closes the PO | Matches, but the PO stays open |
In the second column, budget reports show a $5,000 commitment that will never turn into spend. Worse, the open 200 units are available to match. If the supplier later sends a bill for the “remaining” 200 in error, a two-way match against the open PO passes. A three-way match stops it, because nothing was received, but only if the bill is matched three-way.
Now suppose receiving had recorded only 180 of the 200 shipped units. The bill for 200 × $25 = $5,000 is supported for 180 × $25 = $4,500, with $500 unsupported. Receiving gets the PO line and the 20-unit difference before the bill advances. Any receipt left unmatched at month-end goes into the GR/IR and receipt accrual reconciliation.
Segregation of duties
| Role | Should be able to | Should not also |
|---|---|---|
| Requester | Request goods or services | Approve their own request |
| Approver | Approve within a limit | Create the PO they approve |
| Buyer | Issue and change POs | Record receipts against them |
| Receiver | Record receipts | Change PO prices |
| AP | Match and post bills | Change POs or receipts to make a match pass |
Small teams cannot always separate every role. Where one person holds two, add a review: a weekly report of POs changed after receipt, or receipts recorded by the buyer.
Run a pilot on the problem you can observe
If AP repeatedly asks the warehouse for receipts, take a recent sample and measure how long bills wait for that evidence. Compare it with the time AP actually spends handling each bill. Those two numbers tell you whether you need to reduce entry work or fix the handoff.
| Case | Expected result | Who signs off |
|---|---|---|
| PO, receipt, and bill agree | Prepares the next authorized action with all three records | AP lead |
| Receipt missing or partial | Bill stays in review; receiving sees what to confirm | Receiving lead |
| Supplier changed the price | Buyer sees invoice price, approved price, and revision history | Buyer |
| PO changed after partial receipt | AP can tell delivered, billed, and canceled quantities apart | Buyer and AP lead |
| Posting fails and is retried | Only one accounting record exists | ERP administrator |
Run the sample in a sandbox or as a shadow pilot. Keep invoice approval and payment release with their current owners. Record which invoices were eligible, how many needed correction, and why, and include excluded cases when you present the results. The AP automation implementation guide has the full rollout sequence.
When you compare before and after, look at wait time, handling time, reopened items, and failed writes on the same invoice classes. Value released time separately from costs you can actually avoid, using a written quote that includes review and support. The AP ROI calculator and the AP pricing and ROI guide help with that comparison.
What goes wrong
- The buyer changes the PO, but receiving and AP still work from the original.
- After-the-fact POs are raised to clear non-PO bills, so the approval trail is fiction.
- Services have no receipt record, so every service bill becomes an email chase.
- Price changes are accepted on the bill but never reach the PO, so the next bill varies again. See purchase price variance.
- Old open POs stay open and quietly absorb invoices that should have been questioned.
Before the pilot
- Write the PO exemption list and the reapproval rule for each type of change
- Confirm the supplier, receiving, and AP can all see the current PO version
- Decide how services are received, and by whom
- Pull the open PO report and close or explain anything stale
- Run the changed-order case above in your sandbox
- Review roles against the segregation table and add a compensating report where needed