Why PO Approval Status Should Be Checked Before a Subcontractor Invoice Is Paid

An invoice can be correct and still not be ready for payment.
That is the part many construction businesses miss. The numbers may add up. The supplier may be genuine. The work may have been carried out. But if the purchase order is still pending approval, or the value was never formally accepted, the invoice is not ready for accounts just because it has arrived.
In a small or mid-sized contractor, that distinction matters. If approval status is vague, the office ends up chasing directors, project managers, and site teams just to work out whether a subcontractor invoice should be paid, queried, or parked. Meanwhile job costing becomes less reliable because the business is trying to manage commitments from memory instead of from a live record.
Why approval status is not admin detail
Approval status tells the business whether a cost has actually been authorised.
That sounds basic, but many teams still treat the status as a side note. They look at the invoice amount, compare it loosely with the order, and move on. The problem is that “raised”, “sent”, “seen”, “approved”, and “rejected” all mean different things commercially.
If those states are not clear, a subcontractor invoice can slip through at the wrong stage. Accounts may assume the job manager has approved it. A site lead may assume the office has already checked it. The director may assume someone else has confirmed the value.
What you end up with is a gap between what the business thinks it authorised and what it is actually paying.
The statuses that matter
A workable workflow does not need lots of complicated labels. It needs a few that everyone understands.
The core statuses are:
- Draft
- Awaiting approval
- Approved
- Rejected
- Revised
- Part-paid
- Closed
Each one should mean something concrete.
For example, “awaiting approval” should mean the order or variation has not yet been accepted as a commitment. “Approved” should mean the agreed value can be matched against an invoice. “Revised” should mean the original commitment changed for a specific reason, with the old value still visible.
If the team uses vague labels like “in progress”, the commercial meaning gets lost.
What goes wrong when status is hidden
If approval status is buried in inboxes or chat messages, the invoice check becomes a detective job.
Common failure modes include:
- A subcontractor starts work from a verbal go-ahead, but no PO was approved.
- The original PO was approved, but the variation was never signed off.
- The invoice lands with the correct total, but no one can see whether the revision was approved.
- The office sees the invoice before the project lead has seen the order.
- A partial invoice is paid because the total looks small, even though the remaining commitment is still open.
None of those problems are rare. They are what happens when the approval record and the invoice record are separated.
A clean subcontractor invoice rule
The simplest rule is this:
If the PO is not approved, the invoice is not payable.
That does not mean every invoice needs a long meeting. It means the business needs a visible decision path. The office should be able to see whether the relevant person has approved the value, whether any variation has been accepted, and whether the invoice matches the approved commitment.
A practical rule set looks like this:
- The site or project team raises the subcontract requirement.
- The buyer or office creates the PO with the job reference and scope.
- The approver confirms the value, supplier, and any exclusions.
- The PO status moves to approved only when the commitment is real.
- The subcontractor invoice is matched against the approved record.
- Any mismatch is queried before payment.
That sequence protects both cash flow and job costing.
Why invoice value alone is not enough
An invoice can match the order total and still be wrong.
It may be wrong because:
- The approval was never given.
- The value was approved only for part of the scope.
- The invoice includes an extra charge that was never agreed.
- The work was done under a revised instruction that was not recorded.
- The order was approved on one job, but the invoice has been coded to another.
This is why the approval record needs to travel with the order, not sit in someone’s memory.
When the office can see the approval status, it can check the right questions instead of just checking the maths.
Keep variations visible against the original PO
Variations are where approval discipline usually breaks down.
On site, they are often described in plain language:
- “Can you add that bit on?”
- “Just do it and send the extra later.”
- “We’ll sort the price after the job.”
That approach is quick, but it makes accounts blind.
If the original PO stays visible and the variation is logged as a separate approved change, the business can see the commercial history:
- what was originally agreed
- what changed
- who approved the change
- when the revised value became live
That makes the final invoice easier to check and gives directors a proper view of open commitment.
What accounts should check before payment
Before a subcontractor invoice is paid, accounts should not only ask whether the supplier is real and the arithmetic is correct.
They should also ask:
- Is the PO approved?
- Does the invoice match the approved value?
- If not, is there a signed-off revision?
- Is there an open balance left on the order?
- Has the work been accepted for this stage?
- Is the invoice coded to the right job?
If any of those answers are unclear, the safest response is to query the invoice rather than force it through.
That is not being difficult. It is protecting the job.
Why this matters to job costing
Job costing only works when commitments are visible before cash leaves the business.
If the invoice is paid before approval status is confirmed, the job may look further along commercially than it really is. The opposite can also happen: a team may think a job still has budget left when approved commitments have already eaten into the margin.
That is why approval status is a control point, not just an admin flag.
It tells the business:
- what has been authorised
- what is still waiting
- what has changed
- what is open
- what can be paid now
Without that, the reports are late and the decision-making is reactive.
How BuilderDash helps
BuilderDash keeps the PO, approval, job reference, and invoice check in one place.
That means the office can see whether a subcontractor invoice is tied to an approved commitment before payment runs are built. Site teams do not have to rely on screenshots or message threads. Directors get a clearer view of what has actually been authorised across live jobs.
The point is not to add more admin. The point is to make the approval record usable before the invoice reaches accounts.
A quick check for your team
Ask these questions:
- Can you see the approval status without chasing someone?
- Can you tell the difference between a requested order and an approved one?
- Are variations logged as revisions, or just discussed?
- Can accounts tell whether an invoice is payable before month end pressure kicks in?
- Can directors see open commitments by job?
If the answer to any of those is no, the workflow is probably too dependent on memory and inbox searches.
The practical takeaway
A subcontractor invoice should only move forward when the PO approval status is clear.
That one rule helps a contractor avoid paying unauthorised costs, keeps job costing honest, and saves the office from rechecking the same approval three times in different places.
Suggested internal links
- How to control purchase order overspend and variations in construction
- What construction businesses should standardise before automating accounts
- How to handle disputed supplier invoices without losing cost control
- How to spot partial subcontractor invoices before they hit bookkeeping
Suggested call to action
If your subcontractor invoices still depend on email threads and remembered approvals, use BuilderDash to keep the approval status attached to the PO before the invoice reaches accounts.
Run your projects properly with BuilderDash.
One system for every enquiry, job, quote and invoice — built for project-based trades, not reactive call-outs.


