An insurance restoration operator on QuickBooks Online, about forty users, runs the same suppliers across job after job. Drywall, cleanup, materials, equipment rental. The SKUs repeat. The vendor names repeat. What changes is the project. Memory based invoice coding that only knows "this vendor usually hits materials" cannot pick which job owns the cost. Today the path is familiar: get the PO or job context somehow, key into QuickBooks, upload to SharePoint, wait on a project manager and a supervisor.
When the same vendor and the same SKU appear on twenty active jobs, coding has to ride on the purchase order. The invoice should inherit the project, not ask AP to remember which basement flood this shipment was for.
This matters most if you are in construction, restoration, or field services with repeating vendors across jobs, if project managers should not need full ERP seats, and if your close depends on job cost accuracy more than on vendor defaults.
Why vendor memory fails on purpose built ambiguity
History based coding is good at stable patterns: the same cleaning company always hits the same overhead account. It is bad at intentional ambiguity. Restoration and construction create that ambiguity every day. Home Depot on Monday is job 1042. Home Depot on Tuesday is job 1188. A model that copies last time will be confidently wrong.
Approvers feel the failure as noise. Project managers get bills for the wrong job, bounce them, and AP rekeys. Or worse, the bill posts to a default project and job margin lies until someone notices in a weekly review.
The second problem is access. Giving every PM full QuickBooks access so they can code invoices creates licence cost, training cost, and accidental changes to lists you wanted locked. Teams want PMs to confirm project context without living in the ledger.
Benchmarks for invoices that never go touchless
Ardent Partners' Accounts Payable Metrics That Matter in 2025 cites 32.6% average touchless processing and $9.40 average cost per invoice among 212 AP professionals surveyed. Project coded invoices with repeating vendors sit stubbornly outside touchless rates when the only intelligence is vendor history. They are not exotic exceptions. They are the volume.
If you track touchless rate, split it: percentage touchless among unique vendor patterns versus among repeating vendor and SKU pairs that should have inherited a project from a PO. The second number is the one that tells you whether PO level project coding is optional.
Practical design test for your own stack
- List your top twenty vendors by invoice count last quarter.
- For each, count distinct projects or jobs those invoices hit.
- Where the count is greater than one, ask whether the PO carried the project at creation time.
- Ask whether matching the invoice to that PO could have inherited coding without a human guess.
- Ask whether PMs can see and approve without a full ERP login.
Reader usable without buying: for one high volume vendor, require project on every PO for two weeks and ban AP from changing project after match unless exception coded. Measure how many invoices still need edits. That is your process gap, not a software slogan.
What buyers say when they are careful with scope
Restoration and construction buyers often split the wish list. They want end to end automation for PO based invoices. They also know some service streams will stay manual longer. The useful move is not to pretend every invoice is PO backed. The useful move is to make the PO backed majority inherit project correctly so AP capacity frees up for the messy remainder.
We have heard teams describe roughly hundreds of invoices a month across entities, with SharePoint still in the approval path and project managers in the loop. In that volume, even a modest wrong job rate creates a standing rework queue. You do not need a fabricated before and after metric to see it. Count the reclasses into job cost last month. That number is already on your books.
Who this applies to includes franchise style multi location operators and dealership style groups only when the same vendor catalogue spans jobs or sites that must remain distinct in the P&L. If every bill is company overhead, vendor defaults are enough and this post is optional reading.
Implementation detail that saves pain: decide whether project is header level, line level, or both before you migrate open POs. Matching inheritance follows that shape. Changing your mind after go live means rework on every open document.
What we built as the implementable slice
We are an AP and payments product, not a project management suite. The implementable slice is project or cost code fields on PO creation, invoice match that inherits that project context, and optional PM facing views so approvals happen without handing out full QuickBooks access. Staging verifies PO and packing slip linking on invoices, which is the mechanical home for inheritance during match.
The product wow is inheritance at match time. Custom job cost reporting beyond that is implementation and ERP territory. We rejected building a full construction PM module to win restoration deals. That would dilute the product and still lose to tools whose job is scheduling and estimates.
Deliberate choice: add fields and match inheritance, not a second ERP for jobs.
Where this does not help
If you do not create POs, there is nothing to inherit from. Service only invoices with no purchasing step need a different coding policy, maybe NL rules or forced PM coding at intake. Full project accounting BI, percent complete, and WIP schedules are out of scope. If your buyers refuse to put project on the PO, software cannot invent discipline after the truck has left.
Vendor questions for demos: create a PO with project, match an invoice, show the inherited code, then show a second PO for the same vendor with a different project and prove the invoice does not steal the first job. If the vendor cannot do that live, you are still buying memory.
One more operational tell: if your receiving team already stores job numbers on packing slips or receiving records, that is another inheritance path into match. The PO remains the preferred source of truth at buy time. Receipts should confirm quantity, not invent a different project after the fact.
Close on the repeating SKU
The materials are familiar. The job is not. Put the job on the PO while the purchase still knows where it is going. Let the invoice inherit. Then AP stops playing memory games, and PMs stop living in the ledger just to keep margin honest.
Frequently asked questions
**Can service invoices without POs still get project codes?**
Yes, but not by PO inheritance. Use intake rules, forced fields, or PM coding before approval.
**Do PMs need ERP licences?**
Not if your AP layer gives them a narrow view of the documents and fields they must confirm.
**What if one invoice spans two jobs?**
That is an exception. Split lines or split documents. Inheritance assumes the PO knew the allocation.
