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. The building supply store on Monday is job 1042. The same store 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.
Then there 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.
- sk whether PMs can see and approve without a full ERP login.
A test you can run without buying anything: for one high volume vendor, require project on every PO for two weeks, 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.
Teams describe 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.
This applies to franchise style multi location operators and dealership groups too, whenever 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.
One implementation detail 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.
Putting the project code on the PO so the match inherits it
Finofo puts project and cost code fields on PO creation, matches the invoice to the PO and inherits that project context onto the bill, and gives project managers a narrow approval view so they confirm and approve without a full QuickBooks seat. For the restoration operator, the drywall invoice arrives, matches the PO raised for job 1042, and carries job 1042 into the approval and into QuickBooks, while the same supplier's invoice for job 1188 does the same against its own PO.
The moment that matters is inheritance at match time. The PO knew where the purchase was going when it was raised; the invoice should not have to rediscover it. Custom job cost reporting beyond that is ERP territory and stays there.
The deliberate choice: add fields and match inheritance, not a second ERP for jobs. Finofo is an AP, expense and purchasing platform, not a project management suite, and a construction PM module would have made it worse at the thing it is for. Scheduling and estimates belong to tools built for them. Coding the invoice to the right job belongs here.
The reason inheritance is clean is that purchasing and payables are the same engine. Finofo runs accounts payable, expense management and purchasing on one AI native platform, built in Calgary for Canadian finance teams, so the PO, the packing slip and the invoice meet on one object and the project code travels with it into the ERP. A card purchase for the same job gets the same code the same way.
What stays with your team
Some parts of this process belong with the finance team, by design. Finofo is built to keep them there.
PO discipline is yours, and it pays off directly. Where a PO exists with a project on it, the invoice inherits the project on match. Where a purchase happened without a PO, Finofo routes the bill through your coding policy instead: plain language rules, a required project field at intake, or a PM confirming the job before approval. Full project accounting, percent complete and WIP schedules stay in the systems built for them.
Bring this to any demo: 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. Finofo does it in the same session.
Receiving records are a second inheritance path. If your receiving team already stores job numbers on packing slips, that context is available to the match. The PO remains the preferred source of truth at buy time. Receipts confirm quantity; they do not invent a different project after the fact.
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. Finofo supports all three, so non PO spend still lands on a job before it posts.
**Do PMs need ERP licences?**
Not if your AP layer gives them a narrow view of the documents and fields they must confirm. Finofo's approver inbox does exactly that, with mobile approval and no general ledger access required.
**What if one invoice spans two jobs?**
That is an exception. Split lines or split documents. Inheritance assumes the PO knew the allocation, and where it did not, Finofo flags the bill for a reviewer to allocate rather than guessing.
About Finofo
Finofo is the AI native platform built in Calgary for Canadian finance teams. It brings accounts payable, expense management and purchasing onto one engine, on the cards, bank and ERP a business already uses, with line level extraction, Canadian tax handling and approval workflows designed for multi entity, multi province operations. Finofo does the verification. Finance keeps the judgment.
