How approvals work
An approval policy is a set of amount bands, called tiers, that says who has to sign off on a document before it can go any further. This page explains how SKU.io picks the tier for an amount, how the steps in a tier decide who can approve, and how a request starts. Read it before you set up purchase order approvals.
The example used in this chapter
Every page in this chapter uses the same small team:
| Person | Role in the business | Can approve |
|---|---|---|
| Priya Shah | Purchasing manager and administrator | Purchase orders up to $10,000, every vendor deposit, every bill payment |
| Dana Reyes | Buyer | Nothing. Dana raises purchase orders, deposits and bill payments. |
| Sam Turner | Owner and administrator | Anything, and he's the only approver above $10,000 |
| Jordan Lee | Finance lead | Nothing in their own right. Jordan isn't on any policy, and covers for Priya while she's away. |
Because Priya and Sam are administrators, they also change the policies, override stuck requests and re-route them. Dana and Jordan aren't administrators.
Their policies look like this:
| Policy | Tier | Step | Approvers | Requires |
|---|---|---|---|---|
| Purchase orders | Up to $10,000 | Approval | Priya Shah, Sam Turner | Any one |
| Purchase orders | Over $10,000 | Approval | Sam Turner | Any one |
| Vendor deposits | All amounts | Approval | Priya Shah, Sam Turner | Any one |
| Bill payments | All amounts | Approval | Priya Shah, Sam Turner | Any one |
Here is the purchase order policy as a picture. The amount picks a tier, the tier has one step, and the step lists who can approve:
One policy for each kind of document
There are three policies, one on each tab of Settings → Purchasing → Approval Policies. You turn each one on or off separately, so you can require approval for purchase orders without touching deposits or bills.
| Policy | While it's on | The amount it checks |
|---|---|---|
| Purchase orders | A purchase order must be approved before it's opened, sent to the supplier, or paid a deposit. | The purchase order total, including tax and other charges |
| Vendor deposits | A deposit must be approved before a payment can be recorded. | The deposit amount |
| Bill payments | A supplier bill must be approved before a payment can be recorded. | The bill's outstanding balance |
A policy that's off changes nothing. To see what happens without one, see Without a policy.
Tiers: how an amount finds its approvers
A tier is an amount band. Each tier has an Up to limit, and the last tier has No limit. The first tier starts at $0, and each later tier starts one cent above the limit of the tier before it.
Limits are inclusive. In the example, a purchase order of exactly $10,000.00 falls in Up to $10,000 and goes to Priya or Sam. A purchase order of $10,000.01 falls in Over $10,000 and goes to Sam only.
A few rules follow from this:
- Amounts are compared in your base currency. The page subtitle says so, for example "Amounts are compared in your base currency (USD)." A document in another currency is converted at its own exchange rate when approval is requested, rounded to the cent, and then matched to a tier. A €9,500 purchase order that converts to $10,300 goes to Sam only.
- A request keeps its tier. The tier is fixed when the request is raised. A later change to the policy, or to the exchange rate, doesn't move a request that's already waiting. To learn what happens when the document itself changes, see How re-approval works.
- A $0 purchase order still needs approval, unless its tier is an auto-approve band.
- An auto-approve band skips approval. You can mark any tier Auto-approve this band, for example so that purchase orders up to $500 need no sign-off. Documents in that band show Not required instead of Needs approval.
You can have up to 10 tiers. The tier's name comes from its limits, such as Up to $10,000 and Over $10,000, and that name appears on chips, in the queue, and in alerts.
Steps: who has to approve within a tier
Each tier has one to three steps, and they run in order. Step 2 starts only once Step 1 is approved. Each step lists its approvers, either people or roles, and has a Requires setting:
| Requires | What it means |
|---|---|
| Any one | One approval from anyone who can approve the step finishes it. |
| Any 2, Any 3… | That many different people must approve. |
| All (N) | Everyone listed on the step must approve. A role counts each of its current members. See A step that requires All. |
Most policies need nothing more than Any one, as in the example. How approvals count on a step:
- Nobody counts twice on one step. A person and their delegate together still count as one approval.
- A delegate counts as the person they cover for. When Priya hands her approvals to Jordan Lee while she's away, Jordan's approval on her behalf fills Priya's place, and is labelled On behalf of Priya Shah.
- Later steps can require a fresh pair of eyes. From Step 2 onward, the box Must be someone who hasn't approved an earlier step is ticked by default.
Who can approve
No role permission lets anyone approve. While a policy is on, you can approve a step only if one of these is true:
- You're listed on the step, by name or through one of your roles.
- You're on the final step of a higher tier, and the step requires Any one or Any N. Higher approvers can approve smaller amounts. In the example, Sam is on the final step of Over $10,000, so he could approve PO-0064 for $4,280 even if he weren't listed on Up to $10,000. Higher authority never fills an All step.
- Someone listed on the step has handed their approvals to you for a while. See Hand off approvals while you're away.
Priya isn't on the Over $10,000 tier, so she can't approve PO-0065 for $18,650.00. She sees:
Over your approval limit — the "Over $10,000" tier needs Sam Turner.
Roles are checked at the moment someone acts. A person who joins a listed role can approve at once, and a person who leaves the account drops out at once.
The Approval Policies permissions on a role only let people view or change the policies, or override and re-route stuck requests. View rules and Edit rules both say "Doesn't let anyone approve." For the full list, see the Approval permissions reference.
Approving your own request
By default, the person who raised a request can't approve it, unless nobody else can. Then they can, and the approval is labelled Self-approved. You can make this stricter or looser with the Self-approval rule.
Approving your own draft in one click, as a listed approver, isn't self-approval: no request goes out first, and nothing is labelled Self-approved. Only a Self-approval rule of Never turns it off. See How self-approval works.
How a request starts
A request starts in one of three ways:
- An approver approves in one click. If your approval alone would satisfy the policy, you see Approve instead of Request Approval, and the Approval card says You can approve this directly. One click raises the request and approves it. This works when you can approve every step, each step needs only one approval, and Self-approval isn't set to Never. In the example, Sam can open any draft purchase order and approve it outright.
- Someone else requests approval. Everyone else who can edit purchase orders sees Request Approval on a draft purchase order. On a deposit or a bill, submitting the payment sends the request instead. The request goes to the approvers for that tier, who get an Approval Requested alert. In the example, Dana requests approval for PO-0064, and it waits on Priya or Sam.
- Another source creates the purchase order. When the policy's Applies to setting covers a source, the purchase order is created as a draft and sent for approval instead of opening. Purchase orders that SKU.io raises on its own, from auto-reorder and backorder purchasing, forecast schedules or automatic dropship, are requested by System. An import, or the forecast's Create Purchase Order and a demand plan's Generate orders dialogs, are requested in the name of the person who used them. See Choose which purchase orders need approval.
A document can have only one open request at a time. Once the last step approves:
- A draft purchase order opens. If an automatic source asked to send it, it's sent to the supplier.
- A vendor deposit is approved and ready to pay.
- A bill is approved to pay its outstanding balance.
Under a purchase order policy, sending an approved purchase order to the supplier needs the Purchase Orders → Edit permission. Purchase Orders → Approve alone isn't enough, because under a policy the right to approve comes from the policy, not from a permission. An approver who can't edit purchase orders can approve one, and then a buyer such as Dana sends it.
If an approver rejects the request, it ends there, and later steps aren't asked. The requester fixes the document and requests approval again, which starts a new request.
You decide in the app, not from an email
Approval alerts and emails tell you something is waiting. They show the amount, the tier and any note from the requester, with a Review & approve button that opens the document. You always approve or reject in SKU.io, on the document's Approval card or under Orders → Approvals, so the decision is checked against what you're allowed to do right now. Replying to an email does nothing.
Every approver gets an in-app alert, but email for approval alerts is off until it's turned on. See Get approval requests by email.
Special cases
Most teams never meet these. They matter once a policy uses All steps, more than one step per tier, or a policy is off.
A step that requires All is a list of named places
On an All step, every person listed on that step must approve, either themselves or through their own delegate. Nobody else can fill a place on it, not even someone who can approve larger amounts.
For example, in a variation of the example policy, suppose the Up to $10,000 tier had a second step that lists Priya and Jordan Lee, with Requires set to All (2). Jordan has approved, and Priya is on holiday. Sam approves the larger tier, but he can't fill Priya's place, and he sees:
This step needs every listed approver — waiting on Priya Shah. An administrator can override it.
Priya's place can be filled by Priya herself, or by a delegate she hands her approvals to before she leaves (someone other than Jordan, who already holds a place on that step). If a listed person can't approve at all, someone who can override finishes the request. See Override or re-route a stuck request.
Self-approval on an All step
Unless the policy's Self-approval rule is Allow, the person who raised the request doesn't hold a place on an All step, so the step finishes once everyone else listed has approved. If Priya raised the request in the variation above, Jordan's approval alone would finish the step. See Set approval rules.
One click can finish two steps
When an approver can also approve the next step, one approval can satisfy both, and the timeline shows Also satisfied Step 2. This never happens on a step that needs a different person, or more than one approval.
When nobody can approve
If nobody is left who can approve the current step, for example because the only approver left the account, the request shows No eligible approver. Administrators and anyone with Approval Policies → Override & re-route get an alert that the approval is stuck. That alert goes out even when reminders are turned off. They can then approve it by override, or re-route it to the current policy. See Override or re-route a stuck request.
Without a policy
While the purchase order policy is off, purchase orders work as they always have: anyone with the Approve permission for purchase orders can open and send them, and anyone else can ask for approval from everyone who holds it.
While the vendor deposit or bill payment policy is off, deposits and bills follow Settings → Purchasing → Payment Approvals. Once you turn a policy on, the policy decides who approves, and the Default payment approver on that page is only told when a deposit or bill is approved and ready to pay.