.svg)
Price and coding errors on vendor bills are cheapest to fix before payment. Supplier prices keep moving: construction input prices were 8.9% higher in August 2026 than a year earlier, according to Associated Builders and Contractors. A unit price above the quote, or a cost coded to the wrong job, tends to surface after the payment has cleared.
The fix is to check each line against the purchase order or quote, code it where the cost belongs, and have the cost's owner see it first. MakersHub is set up around how your business already works, and our team configures it with you.
Charley Howe, our co-founder and President, got to this problem by way of his six-year-old:
I spend every weekday morning battling my six-year-old to see the world my way: teeth, shoes, car, school.
I then spend much of the rest of the day battling AI search models to surface & describe MakersHub my way.
The six-year-old is going better.
In AI search, you’re trying to surface at the right time, be described the right way, and motivate searchers to act. MakersHub is good at the first. The second two need work.
Type "best AP automation software" into Google and the AI Overview gives you five companies, one line each. Ours this summer: "Best for operationally complex or high-volume businesses requiring deep line-item accuracy and 3-way PO matching."
This is an accurate representation of what we do and who we’re for. But I question whether anyone reads that and thinks “that's me!”
Who reads "operationally complex" and feels seen?
A buyer used to get a menu of links from Google and sort them. Now, the models carry that job further and do the sorting. For an early-stage company, or companies with limited internet presence, a few pages or a few specific words can carry disproportionate weight. This carries both challenge and opportunity.
So we read months of sales and demo call transcripts, looking for how customers describe the problem unprompted.
Controllers talk about coding: tools that only read the header of a bill, costs landing on the wrong project, one invoice split across three entities in a spreadsheet. That's where "line-item accuracy" came from.
Owners don't talk that way. A mechanical contractor found out weeks later that a supplier had raised the unit price by fifty dollars. "Once it's done, it's done. You're out of that money."
They all talked about money that was already gone by the time they found out where it went.
Every dollar has a job. Hold yours accountable.
In construction, margin is decided at the job. For a property manager it's the property, for a nonprofit the program, for a holding company the entity. If a dollar lands on the wrong one, you can't know what anything cost. Holding it accountable means checking before it's paid, not reconstructing at month-end.
Our product reads every line of every bill, codes it to the right job, checks it against what you agreed to pay, and puts it in front of the right person before payment. The owner buys the outcome. The controller relies on the proof.
Now the "who" – we hope – is something a reader can picture: organizations that track spend by project, location, program or entity.
The models will largely describe you accurately, in your words. Making sure a customer reading that sentence recognizes themselves is an age old marketing challenge that we still toil with.
His post is about how AI search describes MakersHub. This article is about the customer problem behind that description: where price and coding errors hide, why they turn up after payment, and what to check before the money leaves.
Why are price and coding errors usually found after payment?
Because most teams review a bill at the total. A bill arrives, someone checks that the vendor is real and the amount looks about right, and it gets approved. A unit price that went up, or a line coded to the wrong job, doesn't change whether the total looks plausible. It only shows up later, when someone compares a job's costs to its budget or closes the books for the period.
Many AP tools reinforce this with header-level coding, which means the software reads the vendor, the date and the invoice total but not the individual lines. A bill with twelve lines becomes one number with one code. Whatever happened on line seven is now invisible to every person who touches the bill after that.
A late catch is expensive, because getting money back is harder than never paying it out. Even the federal government struggles here. The Government Accountability Office estimated $186 billion in improper payments across 64 federal programs in fiscal year 2025, and about $153 billion of that was overpayments. In October 2026, the Treasury Department described its goal as moving "beyond 'pay and chase'" and catching problems "before awards are made and payments are issued." Pay and chase is the term for paying first and trying to recover the money afterward. A private company has fewer tools for the chase than a federal agency does.
What does a small unit price increase cost?
More than it looks like on one bill. The mechanical contractor in the post above found a fifty-dollar change weeks after it was paid. Here is how a change that size adds up when the item is ordered regularly. The numbers are illustrative:
| Agreed price | Billed price | Difference | |
|---|---|---|---|
| One case, one bill | $210 | $260 | $50 |
| 12 cases a month, across jobs | $2,520 | $3,120 | $600 a month |
| Twelve months | $30,240 | $37,440 | $7,200 a year |
That is one line from one supplier. A contractor buying from dozens of suppliers, across dozens of jobs, has the same exposure on every line where the price can move without anyone agreeing to it.
And prices are moving fast. The same Associated Builders and Contractors release shows input prices up 1.2% in August alone, based on Producer Price Index data from the Bureau of Labor Statistics. Prices for iron and steel, softwood lumber, switchgear, and copper wire and cable were each up more than 10% year over year.
“…ongoing input price escalation is likely to weigh on profitability over the next several months.”
Anirban Basu, Chief Economist, Associated Builders and ContractorsWhen supplier prices change every month, some of those changes reach a bill before anyone on your side has agreed to them. The question isn't whether a supplier is honest. It's whether anyone compares the billed price to the agreed one before paying.
What should a bill be checked against before it's paid?
What you agreed to pay, what you actually received, and where the cost belongs. Each check catches a different error, and each needs a different document:
| Check | What it catches | What you need |
|---|---|---|
| Bill vs. purchase order, line by line | A unit price or quantity that differs from what was ordered | A purchase order (PO) with line items and prices |
| Bill vs. receiving record | Charges for goods that were short-shipped or never arrived | A packing slip or receipt entered against the PO |
| Bill vs. quote or price agreement | A price change on items bought without a PO | The supplier's quote or price list, kept where AP can see it |
| Coding of each line | A cost on the wrong job, location, program or entity | Lines read individually, not just the total |
| Approval by the cost owner | Charges nobody ordered, or a price nobody agreed to | Routing to the person responsible for that job or budget |
Put the first two checks together and you have three-way matching: bill, PO and proof of delivery, compared line against line. The walkthrough of PO matching with and without receiving records covers which documents you need for each and how to start with the ones you already have.
The match has to happen at the line, not the total. A bill can match its PO total exactly while one line is overpriced and another is short-shipped, so the errors cancel out on paper. Checking the total confirms a number. Checking each line confirms the charges.
Plenty of purchases never get a PO: a counter purchase at the supply house, a phone order from the field, a rush delivery. For those, the agreed price lives in a quote, an email or someone's memory. The practical control is to send the coded line to the person who agreed to the price, so the one person who knows whether the billed price is right sees it before payment.
Why do coding errors hide the cost of a job?
Margin is decided wherever you track spend, and Charley's post names the usual places. A cost on the wrong one makes two numbers wrong at once: the job, property or program that should have carried the cost looks healthier than it is, and the one that absorbed it looks worse.
Coding errors are harder to spot than price errors because the dollar amount is right. The bill was real, the price was agreed and the vendor was paid correctly. It just landed in the wrong place. Three patterns show up again and again:
- One bill, several destinations. A supplier bill covers materials for three jobs, but header-level coding puts the whole amount on one.
- One vendor, several accounts. The same supplier bills two locations or two entities, and the bill gets coded by vendor name instead of by where the cost went. The guide to coding one vendor across multiple accounts covers this case.
- Splits rebuilt by hand. One bill gets divided across entities in a spreadsheet, then keyed in again, so every split is a chance to mistype. Provignage, a MakersHub customer, described coding the same vendor bill five times before automating it.
Every one of these is fixable at the moment the bill is coded, and expensive to untangle once the books for that month are closed.
Who needs to see a bill before it's paid?
The person who can tell whether it's right. That is rarely the person who approves by dollar amount alone. A site supervisor knows whether the delivery came, a property manager knows whether the repair was done, and a program director knows whether the cost belongs to the grant. Routing a bill by the job, location, program or entity it's coded to puts it in front of that person.
Owners and controllers want different things from the same check:
| Owner | Controller | |
|---|---|---|
| The question | Which dollars could do more somewhere else? | Can I close without re-checking every bill? |
| What the check gives them | Job, location or program costs they can trust while there's still time to act | Every line coded and reviewed by the person responsible, with a record of who approved what |
| What a late catch costs them | Margin they can't get back | Rework, reclasses and a slower close |
Approvers use MakersHub without training. They approve from email in one click, and see only the bills that are theirs. That matters here, because the person best placed to catch a wrong price is often the one least likely to log in to an accounting system.
How does MakersHub check price and coding before payment?
MakersHub is AP automation for organizations that track spend by project, location, program or entity. MakersHub reads every part of every bill, codes each cost to the right place and puts it in front of the right people before it's paid. Every check above happens before the bill reaches approval:
A line that doesn't match stops the bill where it is, with that line marked, so nobody approves a price they haven't seen. From there your team can correct the quantity, take a partial match against what's left on the PO, or return the bill to the vendor. Each of those decisions is recorded with who made it. The line-by-line PO matching page shows how it works, and line-level automated coding covers the coding side.
You set your coding rules once, and MakersHub applies them everywhere. MakersHub is transparent about where every bill sits and who is holding it. A bill waiting on a price question stays visible instead of disappearing into someone's inbox.
Payments follow the same discipline. Saying yes to a bill and sending the money are kept apart on purpose, so one click can't do both. MakersHub is SOC 2 Type II certified, with Positive Pay protection on check payments and encrypted collection of vendor bank details. SOC 2 Type II means an outside auditor tested those security controls over months, not on a single day. Positive Pay lets your bank refuse any check that doesn't match one you actually wrote.
MakersHub syncs both ways with QuickBooks Online, QuickBooks Desktop, NetSuite, Sage Intacct, Xero and Intuit Enterprise Suite, with Smart Data Connect for other systems. The accounting system integration hub has the details. Pricing isn't per seat, and there's no cap on users, entities or bill count, so adding every site supervisor as an approver costs nothing extra.
When is a manual review enough?
If you have a handful of suppliers on fixed prices, a few dozen bills a month and one person who knows every job, a careful review of each bill can catch most of this. The same goes for bills that never change, like a lease or a subscription.
The manual approach stops working when several things show up together: suppliers whose prices move, bills that split across jobs or entities, and approvers who aren't at a desk. That is as true of a 300-person distributor with buyers in three states as it is of, say, a 15-person electrical contractor with crews on six jobs. Company size isn't the variable. The number of places a dollar can land is. Our comparison of AP software for construction companies covers what to look for when it's time to automate.
Frequently asked questions
What is invoice price variance?
Invoice price variance is the difference between the unit price on a vendor bill and the price you agreed to, usually on the purchase order or a supplier quote. It's caught by comparing each line of the bill to the agreed price before payment. MakersHub compares each line's unit price to the PO and holds the bill when the two disagree.
How do you catch a vendor price increase before paying the bill?
Compare each line of the bill to the agreed price on the purchase order or quote, and route any bill without a PO to the person who agreed to the price. Checking the total alone misses a price change on a single line. MakersHub matches every line against the PO and receipt and flags mismatched lines before the bill reaches approval.
What is the difference between a price error and a coding error?
A price error means you were billed more than you agreed to pay. A coding error means the amount is right but the cost landed on the wrong job, location, program or entity. MakersHub checks both before payment: it matches each line's price to the PO and codes each line to the place the cost belongs.
Why are AP errors usually found after payment?
Most bills are reviewed at the total, and many AP tools code only the header, so a wrong unit price or a miscoded line doesn't change anything the approver sees. The error surfaces later, in job costing or month-end reconciliation. MakersHub reads every line and puts it in front of the person responsible for that cost before it's paid.
Can you recover an overpayment to a vendor?
Often, as a credit on a future bill. Whether you get it back depends on the vendor, your terms and how quickly you notice. MakersHub holds a bill with a mismatched line until someone resolves it, so the question comes up before the payment instead of after.
What does "every dollar has a job" mean in accounts payable?
It means each cost belongs to a specific job, location, program or entity, and should be checked before it's paid rather than reconstructed later. MakersHub applies that by checking each line's coding and price before approval. MakersHub is AP automation for organizations that track spend by project, location, program or entity.
A bill that's wrong on one line still looks right at the total, and the total is what a quick review approves. We built MakersHub so each line is checked and lands on the job it belongs to while the money is still yours to keep. If you'd rather catch the next price change or miscoded cost before it's paid, we'd like to show you how. Get started with MakersHub.
Sources: Associated Builders and Contractors, Construction Materials Prices Jump Again in August (September 2026); U.S. Government Accountability Office, GAO-26-108694, Payment Integrity (April 2026); U.S. Department of the Treasury press release, October 6, 2026. Unit price example values are illustrative.