Choose which purchase orders need approval
Purchase orders don't only come from someone clicking Add Purchase Order. Forecast schedules, backorder purchasing, the demand plan and dropship sales orders can all create and open them for you. The Applies to rule on your purchase order policy decides which of those sources must wait for approval too, so automatic spend goes through the same sign-off as the purchase orders your team raises by hand.
Before you begin
- You need to be an administrator, or have a role with Approval Policies → Edit rules (which includes View rules).
- The purchase order policy must be on. Applies to appears on the Purchase orders tab only, under Rules, once Require approval for purchase orders is switched on. If you haven't built the policy yet, start with Set up purchase order approvals.
- Applies to has no equivalent for vendor deposits or bill payments. Every deposit and bill payment request goes through its policy when that policy is on.
Steps
-
Go to Settings → Purchasing → Approval Policies.
The page opens on the Purchase orders tab.
-
Scroll to the Rules card and find Applies to, labelled Where the PO came from.
-
Tick each source whose purchase orders should wait for approval, and untick the ones that shouldn't.
Manual (app and API) (always) is ticked and greyed out, because purchase orders your team creates are always covered. The sources marked (never) are greyed out too, and can't be ticked. The next section explains each one.
-
Click Save at the top of the page.
If requests are already waiting under this policy, the Save approval policy? dialog opens. Click Save to keep those requests with their current approvers. Save & re-route all starts every waiting request over and clears any approvals already given, which a change to Applies to doesn't need. See Change or turn off a policy.
What you'll see: the message Approval policy saved. The change applies to purchase orders created from now on. Purchase orders already waiting for approval stay in the queue until someone decides them, even if you untick their source.
What each source covers
| Source | Ticked when the policy is first set up? | Purchase orders it covers |
|---|---|---|
| Manual (app and API) (always) | Always | Purchase orders a person creates in the app or through the API. A purchase order you build by hand still counts as manual when it ships to an Amazon warehouse or sends components to a contract manufacturer. |
| Imports (purchase orders imported as Open) | Yes | New purchase orders that an import asks to open. See Imported purchase orders. |
| Auto-reorder and backorder purchasing | Yes | Backorder purchase orders that a supplier's PO Automation & Submission settings generate for you. |
| Forecast schedules | Yes | Purchase orders that a forecast creates as Approved, either from the Create Purchase Order dialog or from a schedule set to Approved or Approved & Sent to Supplier. |
| Unified plan orders | Yes | Purchase orders that Generate orders creates from a demand plan with PO status set to Approved (per policy). |
| Dropship POs from sales orders | No | Dropship purchase orders raised for a sales order. The hint under it reads Off by default — holding a dropship PO delays the customer's order. See Dropship purchase orders. |
| Amazon / AWD inbound (never) | Never | Purchase orders SKU.io creates for Amazon FBA and AWD inbound shipments. |
| Outsourced manufacturing (never) | Never | Purchase orders SKU.io creates automatically for a contract manufacturer. |
| Opening balances (never) | Never | Purchase orders recorded as opening balances. |
Hover over a (never) source to see why: Not subject to approval — internal transfers and historical records, not new spend.
A purchase order from a source you leave unticked opens the same way it did before you had a policy. Only the purchase orders a source would have opened are affected: if a source creates drafts, they stay drafts, and someone requests approval for them later like any other draft.
What happens to a covered purchase order
How a covered purchase order waits depends on whether a person or an automatic process created it.
When a person creates it
This covers the forecast's Create Purchase Order dialog, Generate orders on a demand plan, and approving a sales order that raises a dropship purchase order. When the person asks for the purchase order to be approved:
- If they can approve that amount under the policy, it opens straight away, as if they had clicked Approve themselves.
- If they can't, it's saved as a draft and sent for approval in their name. It appears in Orders → Approvals for the right approvers.
On a demand plan, the PO status list in Generate orders offers Approved (per policy) to anyone whose role can edit or approve purchase orders, with the hint Over your approval limit? Sent for approval instead. Everyone else can create drafts and request approval for them later.
When an automatic process creates it
This covers forecast schedules, backorder purchasing, and dropship purchase orders raised automatically. The purchase order is created as a draft waiting for approval, and nobody is named as the requester:
- The approval timeline on the purchase order reads Requested by System.
- The Approval Requested alert reads An automated process requested approval for…, followed by the purchase order, its amount and its tier.
- Because no person raised the request, the self-approval rule doesn't come into play. Anyone the policy lists for that amount can approve it.
- If the source was set to send the purchase order to the supplier, for example a schedule set to Approved & Sent to Supplier or a supplier that auto-submits backorder purchase orders, SKU.io sends it automatically once it's approved.
- If an approver rejects it, there's no requester to tell, so the Approval Decision alert goes to the approvers on that step and to your administrators instead.
Imported purchase orders
When you import purchase orders from the purchase orders list, the import dialog asks how to create new ones, under Import new purchase orders as:
- Draft, the default, saves them as drafts. Nothing is sent for approval: open each one and request approval as usual.
- Open asks for them to be opened on import. While the purchase order policy is on, anyone who can import can choose it, because the policy decides what happens next. Without a policy, it needs permission to approve purchase orders.
Purchase orders that already exist and are updated by the import keep their status. See Import purchase orders from a spreadsheet.
What Open does depends on the Imports source:
| Imports source | What choosing Open does |
|---|---|
| Ticked | Each new purchase order is created as a draft instead, and sent for approval. The person who ran the import is the requester, so the Self-approval rule applies to them, and the note on each request reads Imported as open. Approvers get one alert for the whole import instead of one per purchase order, for example 12 approvals waiting on you, with a link to the Approvals queue. It counts as an Approval Requested alert, so it's emailed to anyone who has approval emails turned on. |
| Unticked, or no policy | The new purchase orders open and are marked approved, ready to send to suppliers. |
Whichever option you choose, an import that changes a purchase order that's already approved is checked like any other edit, so a big enough change asks for approval again. See How re-approval works.
Dropship purchase orders
Dropship POs from sales orders is off by default, because a dropship purchase order that's waiting for approval holds up the customer's order. Tick it only if your dropship spend needs sign-off.
With it ticked:
- The sales order can't be fulfilled until its dropship purchase order is approved. Trying shows Dropship purchase order PO-0071 is awaiting approval under your approval policy — it can be fulfilled once it is approved. If nobody has requested approval yet, the message ends …needs approval under your approval policy before it can be fulfilled — request approval on the purchase order.
- Once the purchase order is approved, SKU.io sends it to the supplier automatically if the supplier is set to auto-submit dropship purchase orders.
- A dropship purchase order can close, for example once it's fully invoiced, without ever being approved. It then can't be reopened, sent or given a deposit. The tooltip reads This purchase order was never approved — request approval before reopening or sending it. Click Request Approval on the purchase order to fix it.
Purchase orders created before you had a policy, or before you ticked a source, aren't affected.
Next steps
- Get approval requests by email: automatic purchase orders raise requests at any hour, so make sure your approvers hear about them.
- Set approval rules: self-approval, reminders and the re-approval tolerance.
- Approve or reject a request
- Replenish stock on a schedule and Create purchase orders from a demand forecast
- How dropship and Amazon POs differ from a standard PO