Expense management software in construction is rarely the problem. The problem is what happens when it meets a construction site. Most platforms handle matching well in controlled conditions: a single purchase order, one delivery, one invoice, matching quantities and amounts. Construction breaks all of those assumptions simultaneously, and the software rarely adapts.
What most tools miss is the gap between how PO matching is designed and how construction procurement actually works. Sub-contract variations, partial deliveries, and split cost centres are the norm, not the exception. What to evaluate is whether your matching logic can handle those realities before invoices reach the ledger.
How PO Matching Is Supposed to Work
Two-way PO matching compares a supplier invoice against the original purchase order: quantities ordered versus quantities invoiced, unit prices, and supplier details. Three-way matching adds the delivery receipt or goods received note into the comparison. When all three documents align, the invoice moves forward for approval and payment.
In theory, this removes the need for manual cross-referencing and protects businesses from paying for goods not received, prices not agreed, or suppliers not on the approved list.
In construction, none of these assumptions hold cleanly.
Where Expense Management Software Meets Construction Reality
The Comparison That Matters First
Before looking at what breaks, it helps to see what finance teams are actually choosing between:
| Approach | How It Works | What It Misses | |---|---|---| | Spreadsheet or email-based matching | Manual cross-check of PO, invoice, and delivery note | Time-consuming, error-prone, no audit trail | | Accounting platform native (Xero/MYOB) | Basic bill-to-PO comparison at header level | Line-item variance, partial deliveries, variation orders | | Dedicated AP automation with PO matching | Automated line-level comparison with exception flagging | Requires clean data input and PO discipline upstream | | Construction-specific project management integration | Procore or Jobpac generates POs, invoices reconcile at project level | Integration gaps between project and accounting systems |Most Australian construction SMBs sit in the first or second row. The third is where the real operational improvement happens, but getting there requires understanding why the gap exists.
Partial Deliveries and Progressive Claims
A subcontractor delivers 40% of a concrete pour in week one and claims for that portion. The purchase order was written for the full job. The invoice references a progress claim number, not a line item from the PO. The accounting system sees an invoice for $28,000 against a PO for $70,000 and flags it as unmatched.
That flag is technically correct. But the invoice is also legitimate. Finance teams resolve this manually, every time, by checking the progress claim schedule, verifying the percentage complete, and adjusting the PO in the system. That process takes time, creates inconsistency, and generates no structured audit trail of how the decision was made.
Variation Orders and Scope Changes
Construction contracts change. A variation order is issued when scope expands: additional excavation, materials substituted, access issues that weren’t in the original scope. The subcontractor invoices for the original scope plus the variation. The PO in the system reflects only the original scope.
Three-way matching will flag every variation invoice as a mismatch, because it is. But the mismatch is authorised. The variation was approved by the project manager, possibly verbally, possibly in an email, rarely in a format that feeds back into the accounting system.
Finance teams end up with a stack of “legitimate mismatches” that require manual override. Each override bypasses the control the matching system was supposed to provide. Over time, the approval habit is to override first and verify later, which is exactly the habit that lets errors and fraud through.
Multi-Supplier Invoices and Cost Centre Splits
A single invoice from an electrical subcontractor covers work across three buildings on the same site, each with a different cost centre code. The PO was raised at the project level. Matching the invoice to the PO at the header level works. Splitting the invoice correctly across three cost centres for job costing purposes requires manual line-item allocation.
Xero and MYOB both handle bill splitting, but neither automates the allocation logic based on supplier history or project coding rules. The bookkeeper or financial controller makes that call each time. When the same supplier invoices across multiple months and multiple projects, the coding decisions compound. Automated line-item coding that learns from supplier history eliminates that inconsistency at the source.
The Genuine Operational Scenario
A site administrator at a Brisbane subcontracting firm manages invoices that arrive from Procore as PDFs into a shared email inbox. Each invoice is a progress claim tied to a project schedule, not a line item on a PO. The administrator manually cross-references the claim against the current schedule, codes it to the correct cost centre, and raises a bill in MYOB. The PO matching function in MYOB never triggers because the original POs were raised in Procore and don’t exist in MYOB as structured data.
The result is that PO matching, which should be the primary control for this business, is effectively switched off by the gap between the project management system and the accounting platform. Nobody designed that gap. It just exists because the two systems were purchased at different times for different purposes.
Why the Process Breaks: The Root Causes
PO discipline degrades under site pressure
Purchase orders get raised after work starts on urgent jobs. The PO number on the invoice doesn’t match anything in the system because the PO was created retroactively. Finance is then reconciling documentation after the fact, not before payment.
Supplier invoice formats are inconsistent
One subcontractor invoices using the PO number as a reference. Another invoices with a claim number. A third sends a tax invoice with a narrative description and no structured data at all. Automated matching requires consistent reference data. Construction invoices rarely provide it.
The approval chain and the matching chain are separate
In most construction AP workflows, the project manager approves the scope and the variation. Finance approves the invoice. These two approval events don’t share data. Finance is approving payment based on the invoice; they may not know whether the project manager approved the underlying variation.
This separation is where approval workflows need to bridge the gap: routing the invoice back to the project manager for variation confirmation before finance releases payment.
What Good Practice Actually Looks Like
Checklist for PO Matching in Construction
Before selecting or configuring any expense management software for construction, verify it can handle:
- Line-level matching, not just header-level totals
- Partial claim matching against a percentage-complete schedule
- Variation order exceptions with a structured approval override path and audit trail
- Multi-cost-centre allocation from a single invoice
- Integration with the project management system in use (Procore, Jobpac, or similar)
- Supplier invoice ingestion from multiple formats (PDF, email, structured data)
- Exception flagging that distinguishes a legitimate variation mismatch from an error
- A separate approval step for variation invoices before payment release
If your current setup doesn’t handle at least five of these eight, you have manual processes filling the gaps. Those manual processes are where errors and, eventually, fraud enter.
Questions to Ask Vendors
-
How does your platform handle progress claims where the invoice amount is correct but doesn’t match a line item on the PO?
-
Can variation order overrides be recorded with an approval audit trail, so finance can see who authorised the exception?
-
Does line-item coding work at the cost centre level, or only at the account level?
-
How does your platform ingest invoices from Procore or other project management systems?
-
When a PO is partially fulfilled across multiple invoices, does the matching logic track cumulative claimed amounts against the total PO value?
-
What happens when a supplier changes their bank details mid-project? Is there a validation step before payment is released?
-
Can approval limits be set differently for variation invoices versus standard invoices?
Who This Fits and Who It Doesn’t
| Business profile | What makes sense |
|---|---|
| Under 30 invoices per month, single project, few subcontractors | Manual cross-check with Xero or MYOB native bills is manageable |
| 50-200 invoices per month, multiple subcontractors, project-based costing | Dedicated AP automation with PO matching is worth the investment |
| Multiple entities, multiple projects, Procore or Jobpac in use | You need integration between the project system and accounting platform before matching works |
| Variation-heavy contracts (civil, fitout, infrastructure) | Standard matching logic will fail. You need exception workflows specifically for variation invoices |
The construction businesses that get the most value from structured PO matching automation are those where the invoice volume is high enough that manual cross-referencing is taking hours per week, and the average invoice value is high enough that an undetected mismatch is a meaningful financial exposure. |
The Downstream Impact When Matching Fails
When PO matching breaks down in construction, the first consequence is reporting lag. Job costing is inaccurate because invoices are held in the AP queue while someone manually resolves the mismatch. Project profitability reports don’t reflect actual committed costs.
The second consequence is payment delay. Subcontractors in Australia regularly face late payment issues: according to Xero Small Business Insights, 53% of invoices from SMBs to large businesses are paid late, on average 23 days overdue. When the matching process is broken, finance teams can’t confidently approve for payment, so invoices sit longer than they should.
The third consequence is fraud exposure. When variation invoice overrides become routine, the habit of bypassing the control becomes normalised. A fraudulent invoice constructed to look like a variation claim, with changed bank details, gets processed with the same manual override that legitimate variation invoices receive. The ACCC identifies construction as one of the sectors most targeted by fake invoice scams, specifically because of high transaction values and frequent invoicing.
What to Look For in the Configuration Layer
The software matters less than the configuration. A platform with strong matching logic configured against a process with poor PO discipline will still produce mismatches. The configuration questions are operational:
- Are POs raised before work starts, or after?
- Are variation orders captured in a structured format, or managed via email?
- Does the project manager have a step in the AP workflow, or are they outside the process?
Exception flagging should occur before an invoice reaches the ledger. Pulsify’s validation and exception review layer flags mismatches and anomalies before bills are published to Xero or MYOB, giving finance teams a structured review point rather than a post-payment reconciliation problem.
If your current setup is creating manual workarounds for legitimate variation invoices, that’s the signal that the matching configuration needs attention. A workflow audit can identify where the gaps sit before they become a payment problem.
Frequently Asked Questions
What is purchase order matching in construction accounting?
Purchase order matching in construction compares a supplier invoice against the original purchase order and, where applicable, a delivery or progress claim record. The aim is to confirm that what is being invoiced was ordered, approved, and received before payment is released. In construction, this is complicated by progress claims, variation orders, and multi-cost-centre invoices that don’t fit a standard matching model.
Why does expense management software often fail in construction environments?
Most expense management software is built for environments where invoices map cleanly to a single PO, a single delivery, and a single cost centre. Construction rarely works that way. Progress claims cover partial completion. Variation orders change the original scope. A single invoice often spans multiple cost centres. When the software can’t handle these variations natively, finance teams create manual workarounds that bypass the controls the system was supposed to enforce.
What is three-way matching and does it work for construction subcontractors?
Three-way matching compares the purchase order, the invoice, and the goods received note or delivery record. It works well in product-based procurement where goods are physically received and documented. For construction subcontractors invoicing progress claims, there is often no equivalent to a goods received note. The matching logic needs to compare against a progress claim schedule instead, which most standard accounting platforms don’t support natively.
How should variation invoice overrides be handled to maintain an audit trail?
Variation invoice overrides should require a structured approval step rather than a simple manual override. The person authorising the override (typically the project manager or financial controller) should be recorded against the invoice, along with the reason and any supporting documentation. Without this, the override history becomes invisible and the control function is lost.
Can Xero or MYOB handle PO matching for construction businesses?
Xero and MYOB both offer basic PO matching at the header level, comparing the total invoice amount against the total PO value. Neither handles line-level partial claim matching, variation order exceptions, or multi-cost-centre splits without manual intervention. Construction businesses with high invoice volumes and complex project structures typically need a dedicated AP automation layer that integrates with both the project management system and the accounting platform.