If purchase requests arrive by email or text, get approved with a "yep, go ahead" reply, and are then retyped into Xero, MYOB or your job or stock system, your approvals are not really controlling spend. They are recording it after the fact, in someone's inbox. A working purchase order approval system gives each request one path: raised once, approved against clear rules, turned into a purchase order and later matched to the supplier's bill. For many businesses an approvals app connected to Xero or MYOB does that well. When the request starts in a job or stock system, or the approval depends on job budgets and site rules the accounts can't see, the problem sits between your systems and needs to be fixed there.
What it looks like day to day
Most finance managers will recognise some of this:
- A site manager texts the project manager: "Need the scaffold extended another two weeks, OK?" The reply is a thumbs up. Nobody raises a purchase order.
- A branch manager emails the operations manager a supplier quote. The operations manager replies "approved" from their phone. A week later someone in the office finds the email and keys a PO into the stock system, and again into Xero.
- The supplier's bill arrives with a different amount, a different reference or no reference at all. Accounts payable has to go looking for whoever ordered it.
- At month end, or when the auditors ask, the only proof that a purchase was approved is a forwarded email chain, and the person who approved it is on leave.
- Two people approve the same thing, or nobody does, because the rules about who can approve what live in people's heads.
None of this is carelessness. People approve things where they already are: their inbox and their phone.
Why it happens: the approval sits between systems
Spend approval touches at least three places, and they rarely talk to each other:
- Where the need starts. A job or project system, a stock or inventory system, a maintenance request, or simply someone's email.
- Where the approver decides. Usually their inbox, sometimes a phone call. To decide well they need the budget, what has already been committed, and whether the supplier is one you use.
- Where the money is recorded. Xero, MYOB or another accounting system, where the bill is entered, coded and paid.
The gap shows up in a few predictable steps:
- Request to approval. The request has no standard form, so the approver gets whatever detail the requester thought to include. They can't see the job budget or the money already committed against it.
- Approval to purchase order. The approval is in an email, but the PO has to be created somewhere else. Someone retypes it, sometimes into two systems, sometimes days later.
- Purchase order to bill. When the supplier's bill arrives, accounts payable needs to match it to the approved PO and, for stock, to what was actually received. If the PO was never created, or was created with different details, the match fails and it becomes a detective job.
- The audit trail. Who asked, who approved, against what limit and when should be stored with the transaction. In most of these businesses it is spread across inboxes.
When the request, the approval and the accounts each live in a different system, no single product fixes the PO approval workflow end to end.
The options, from simplest to a proper fix
1. Agree the rules first
Before any software, write down your approval rules, often called a delegation of authority. Who can approve what, up to what amount, for which sites, jobs or cost types, and who covers when they are away. Decide what needs a PO at all (for example, anything over a set amount, or any stock purchase) and what can go straight to a bill.
Every option below depends on this. Software will only automate fuzzy rules. If the current steps aren't written down anywhere, business process mapping is how to get them on paper.
2. Use what your accounting system already has
Xero has purchase orders with an approval step controlled by user permissions. MYOB has purchase orders too. If your purchasing is mostly done from the office, by a few people, for overheads, this may be all you need. The limits show up when you need different approvers by amount or site, approvals on the road, or orders that start outside the accounts. We cover the Xero side in more detail in Xero purchase orders when orders start in another system.
3. An approvals app connected to the accounts
Dedicated approval tools, ApprovalMax is a well-known example, sit on top of the accounting system. Requests, purchase orders and bills are approved on a phone or in a browser against rules you set up (by amount, supplier, tracking category or cost centre), with the approval history stored against the document. Many can also help match bills to POs.
An approvals app is usually enough when:
- Purchase orders are created in Xero or MYOB, or in the app itself, not in a job or stock system.
- Approval rules can be expressed with what the accounts know: amount, supplier, account code, tracking category.
- The approver doesn't need live job budgets or stock levels to make the call.
If that describes your business, buy the app, set up the rules carefully and stop there. Check the vendor's website for which accounting systems and plans it supports, because support differs between Xero, MYOB and others.
4. Approvals built into the system where the need starts
Many job management, construction and inventory systems have their own PO approval step. If your orders already start there, using it keeps the approval next to the job budget or stock level the approver needs. The question then is what that system sends to the accounts: the approved PO, only the bill, or just totals. Check that the job or cost codes, supplier and tax codes come across, and what happens with part deliveries and price differences.
5. Connect the job or stock system, the approver and the accounts
This is the proper fix when the approval genuinely depends on information spread across systems. Typical signs:
- The approver needs to see the job budget, what has been committed and what has been spent before saying yes, and those live in the job system, not Xero or MYOB.
- Requests come from several sites or entities with different approvers and limits.
- Stock purchases need to be matched to goods received in the inventory system before the bill is paid.
- You have an approvals app for bills, and a job system for POs, and they don't know about each other.
The work here is in the joins, not a new product:
- One request form that captures the job or cost centre, supplier, amount and reason, whether it starts on a phone, in the job system or by email.
- Routing by your rules, using the job budget and committed cost from the job system and the limits from your delegation of authority.
- One purchase order, created once in the system that owns it and passed to the others, so nobody retypes it.
- Matching of the supplier's bill to the approved PO, and to what was received, with differences flagged rather than quietly paid.
- The audit trail stored with the transaction: who requested, who approved, the rule that applied, when, and any changes after approval.
Sometimes this means a custom integration between your existing systems. Sometimes it means a purpose-built approval system that sits between them. Either way it should hand the accounts what they need and leave Xero or MYOB keeping the books. Our approval workflow systems page covers how we approach it, and problems between your systems explains the wider pattern.
A real example
Kenomont built a purchase order approval system for a large retirement living provider, and it has been in use since 2014. Purchasing there spans many sites, requesters and levels of approver, which is exactly where email approvals and retyped orders break down. The system gives each request one path from raise to approval to order, with the history kept alongside it. The same gaps appear in any organisation that spends money across several sites and teams, not just construction or wholesale.
What to check before you buy anything
Answer three questions: where does a purchase request start in each part of the business, what does the approver need to see to decide, and which system should own the purchase order? If every answer points to the accounting system, an approvals app is likely the right call. If the answers point to two or three systems, the gap between them is the real problem. Our business process improvement guide covers working through questions like these, and the procure to pay process post covers buying, receiving and paying as a whole.
Frequently asked questions
Can Xero do multi-level purchase order approvals?
Xero's purchase orders have an approval step controlled by user permissions, which works for simple setups. For different approvers by amount, site or cost centre, or several approval levels, businesses usually add an approvals app or build approvals into the system where orders start.
Is ApprovalMax enough for purchase order approvals?
Often, yes. If your purchase orders are created in the accounting system or in the app, and your rules can be based on amount, supplier and account or tracking codes, an approvals app is usually the simplest answer. It falls short when approvals depend on job budgets or stock data held in another system.
How do we stop people approving purchases by email?
Make the proper path easier than email: one simple request form that works on a phone, a notification approvers can act on directly, and a rule that suppliers are only paid against an approved PO. The rule has to come from the business.
How do we match supplier bills to approved purchase orders?
Create the PO once, with a number the supplier quotes on their invoice, and make sure the bill is entered against that PO rather than retyped from scratch. For stock, match the bill to what was received as well. When the PO lives in a job or stock system, the matching usually needs to happen there or through an integration.
If spend approvals in your business live in email and get retyped into two or three systems, book a free initial chat. We'll tell you honestly whether an approvals app will do the job or where the real gap is.