What procurement-to-accounting integration does

Most specialty trade contractors have some version of this problem, even if they can't name it yet: their procurement tool sends data to their accounting system, and the data is wrong before it arrives.

Wrong in a specific, structural way that turns every invoice reconciliation into manual work, and stays invisible until AP has been burning hours on it for months.

This is an explainer on what procurement-to-accounting integration does when it works, why most versions of it don't, and what closing the gap requires.

The ERP ownership gap

CMiC-sponsored research via Dodge Construction Network surveyed 123 specialty trade contractors between $25M and $100M+ in revenue in 2025. The headline finding: 57% currently run a commercial ERP. Among contractors over $100M, that number rises to 69%.

That should mean most of these companies have working procurement-to-accounting integration. It doesn't. Only 39% of contractors with an ERP use its accounting functions; the rest rely on additional tools, manual workarounds, or parallel systems. Among contractors not yet on an ERP, 69% rate their need to improve accounting processes as high or very high.

The gap between "has an ERP" and "integration is working" is exactly where AP managers live. Owning the software is not the same as the data flowing correctly.

Steven Druin, SVP of Technology at Interstates Electric, puts it plainly: "A lot of companies say they integrate... when they truly don't, they're importing and exporting CSV files with minimal data flow at best. True integration is making API calls and pushing that data back and forth between the systems, automated."

The document precision failure

Here is the specific structural problem most integrations leave open.

When a purchaser creates a Purchase Request (PR) and converts it to a Purchase Order (PO), most procurement tools sync that PO to the accounting system. The PO reflects what the contractor originally asked for: item, quantity, price, delivery date.

The supplier then confirms the order, and that confirmation is a different document, the Sales Order (SO). The supplier's SO reflects what they actually committed to deliver: adjusted quantities, pricing substitutions, revised lead times, alternative part numbers when the original is backordered. These are real changes that happen routinely in electrical and mechanical supply.

Standard integrations never send the Sales Order to accounting. They send the original PO and stop there. The result is that by the time an invoice arrives, the document it needs to match to in accounting no longer reflects what was actually ordered, confirmed, and shipped.

AP gets an invoice that doesn't match the PO on file and reconciles it manually. Every invoice cycle. This is not an edge case; it is the default behavior of most mid-market procurement stacks.

If that reconciliation failure is familiar, the companion piece on procurement data never matches the books and covers the downstream accounting consequences in detail.

‍

Why 3-way match doesn't close it

Three-way matching is the standard accounts payable control: confirm the Purchase Order matches the receipt, and the receipt matches the invoice, then approve payment. It's a sound process when the underlying documents are accurate.

The problem is that a PO can match an invoice even when the supplier made changes at the Sales Order stage. If a supplier ships 18 units instead of 20, invoices for 18, and the PO said 20, the match fails. But if the supplier adjusts the PO quantity in their system without a formal SO confirmation reaching your accounting software, the mismatch either surfaces late or gets manually overridden.

Three-way match is built for a world where the PO is the authoritative source of what was ordered. When the supplier's confirmed Sales Order diverges from the original PO (and it routinely does), 3-way match either flags discrepancies AP has to resolve by hand or misses them entirely.

4-way match: What the fourth leg adds

The 4-way match in Remarcable adds a fourth document to the matching chain: the supplier's confirmed Sales Order.

The sequence is: Purchase Order → Sales Order confirmation → Proof of Receipt → Invoice. Each document is matched against the prior one before payment is approved.

The Sales Order step closes the gap the 3-way match leaves open. When a supplier confirms different quantities, substitutes a line item, or adjusts pricing, that change enters the matching chain immediately, before the invoice arrives and AP discovers the discrepancy. Exceptions surface early, with context attached, rather than landing on a desk as unexplained variances.

This is not an industry-standard term. The architecture is specific to Remarcable, built for procurement software that syncs the SO confirmation in real time rather than stopping at the PO export.

When native ERP software is sufficient

Not every integration is broken, and it's worth naming the specific stack configurations where the gap is reliably present versus where it isn't.

Some ERPs are built specifically for specialty trade contractors, purpose-built for electrical and mechanical contractors rather than general-purpose accounting systems adapted for construction, and do sync Sales Order confirmations natively. For contractors already running one of these systems with procurement functionality built in, the gap described above may not exist.

The PR-vs-SO gap is reliably present in mid-market setups where procurement tooling was added separately from an existing accounting system: contractors running QuickBooks, Sage 50, or Jonas for accounting alongside a procurement tool that was not designed to sync beyond the PO.

In those environments, the accounting system never receives the Sales Order confirmation, and everything downstream (job costing, committed cost visibility, invoice matching) is built on a document that diverged from reality at the supplier confirmation step.

The committed costs problem

Job cost visibility depends on knowing what's been committed to spend, not just what's been invoiced. Committed costs are what you've ordered but haven't paid yet. Actual costs are what's hit the books.

The gap between them is where project budgets go wrong. When a PO is exported to accounting but the SO confirmation never follows, committed costs look stable right up until invoices start arriving with variances. By then the project is running, the budget is locked, and the variance shows up as a surprise.

Only 31% of construction projects come within 10% of their original budget (via Lumberfi, citing CFMA data). Poor data and miscommunication account for 52% of rework costs in construction (via US Glass Magazine). These are downstream effects of the same integration gap, not separate problems.

How the integration is supposed to work

When procurement-to-accounting integration is functioning correctly, five things happen in sequence:

1. Purchase Request creation. A field team member or purchaser creates a PR. It captures what's needed: item, quantity, job number, phase code, delivery address. This enters the accounting system as a committed cost immediately.

2. PO generation and supplier order. The PR converts to a PO. The order goes to the supplier directly, without a phone call or email export.

3. Sales Order sync. The supplier confirms the order. Their confirmed Sales Order, with actual quantities, pricing, and delivery commitments, syncs back to procurement and to accounting. Job cost reports are updated.

4. Receipt matching. Materials arrive on the job site or at the warehouse. Delivery is confirmed in the system. The proof of receipt becomes the third leg of the 4-way match.

5. Invoice matching and payment approval. The invoice arrives and is matched automatically against the PO, SO confirmation, and proof of receipt. If all four align, payment routes for approval. Discrepancies surface before the invoice is approved, with context attached.

That fifth step is where Guarantee Electrical landed after implementing this flow: "Now we don't have to do that [spot checking]. That is all done automatically through Remarcable. And if someone committed  a price to us, they're held at that price, and if we don't receive that price, we're alerted to it. So the checks and balances is something that really made our life infinitely easier."
‍

Three approaches to integration

Warning signs the integration isn't working

Each of the following points to the PR-vs-SO gap running in the background:

• AP spends more than a few minutes per invoice on reconciliation. If matching requires manual lookup or override, the documents don't agree at the source.
• Invoice variances surface as surprises. Supplier quantity and price changes should reach accounting at SO confirmation, before the invoice arrives.
• Job cost reports lag purchase orders by days or weeks. Real-time committed cost visibility requires SO sync, not a PO export alone.
• Three-way matching produces regular exceptions AP resolves manually. Those exceptions indicate where the SO confirmation step is missing.
• The procurement team and the AP team work from different versions of the same order. Procurement sees the SO; AP sees the original PO. They are two different documents.

What working integration changes for AP

When the SO confirmation is in the matching chain, invoice reconciliation stops being rework and becomes an exception process. The baseline expectation is that invoices match, and when they don't, the system flags it with enough context to resolve it quickly.

72% of contractors planning ERP adoption cite "less manual data entry" as the primary expected benefit (CMiC-sponsored research via Dodge Construction Network). That expectation is accurate when the integration is working. The reason it goes unmet in so many mid-market stacks is that the integration stops at the PO and leaves the Sales Order out.

Remarcable Intelligence reads each invoice against all four legs of the match (PO, SO confirmation, proof of receipt, and invoice) before approval is routed. When something doesn't align, the alert goes out before the invoice is paid. Field staff and office staff get time back because exceptions surface automatically instead of sitting buried in a stack of invoices waiting for review.

For a closer look at how the accounting layer connects, see invoice matching and job costing sync.

The real cost of discovering this late

The pattern in the field: contractors don't realize integration isn't working until AP is already behind and the problem has been running for months. By then, the manual reconciliation has become normalized as "just how AP works here." It's a structural gap in the integration, generating hours of rework on every invoice cycle.

Project timelines are compressing across specialty trade, and working capital tied up in unresolved invoice variances is a real constraint on capacity. The difference between an integration that syncs POs and one that syncs SO confirmations is the difference between an AP team doing constant reconciliation and one that only touches exceptions.

See how Remarcable connects to your ERP: remarcable.com/solutions/accounting.