.svg)
PO matching compares a supplier bill against the purchase order, and often against a record of what was delivered, before anyone pays it. Two-way matching checks the bill against the PO. Three-way matching adds the receiving record. MakersHub does both at the line, so a bill that adds up correctly still gets held when one line is wrong. It works the same whether your receiving record is a warehouse scan or a delivery ticket photographed on a tailgate. MakersHub is built for complex businesses, not complex workdays: the matching happens on arrival, and your team only sees the lines that failed.
Almost every guide to this presents two-way and three-way as a choice you make, usually with a table and a recommendation to pick three-way because it is safer.
That is not really how it goes.
How your business buys decides whether you can run a three-way match. If your crew picks up pipe at the supply house on a Tuesday, there is no purchase order and no receiving record, and no amount of software changes that. If you issue POs but nobody logs deliveries, you have a two-way match whether you wanted one or not.
So the useful question is not "which type should we run." It is "which documents do we actually have, and what do we do about the spend that has none of them."
What two-way and three-way matching actually compare
Three documents can exist for any purchase. Matching is the act of checking them against each other before money moves.
| Type | What it compares | What it catches | What it misses |
|---|---|---|---|
| Two-way | Bill against PO | Wrong price, wrong item, quantity billed above what was ordered | You were billed for what you ordered, but only part of it showed up |
| Three-way | Bill against PO and receiving record | Everything two-way catches, plus short deliveries and goods billed but never received | Nothing structural, if all three documents are accurate and complete |
| No match | Nothing. Somebody eyeballs the bill | Whatever the person happens to notice | Most things, most of the time |
Four-way matching comes up occasionally, adding an inspection or quality record. It is real, and it is mostly a manufacturing and pharmaceutical practice. If you are asking which type fits your business, you are choosing between two and three.
The third document is the one you probably do not have
Every explanation of three-way matching assumes a receiving record exists. In a warehouse with a dock and a scanner, it does. On a job site, at a parts counter, or on a service truck, it often does not, and what stands in for it is a delivery ticket someone signed and left on a dashboard.
This matters more than a missing piece of paper, because accepting goods is a legal act with consequences. Under the Uniform Commercial Code, which governs the sale of goods in nearly every US state, acceptance happens when a buyer, "after a reasonable opportunity to inspect the goods," signals that the goods conform, or simply fails to reject them. The trigger is the opportunity to inspect, not the paperwork.
The same section adds a detail worth a second look: "Acceptance of a part of any commercial unit is acceptance of that entire unit." Take delivery of part of something and you have accepted all of it.
Federal contracting works the same way. The Federal Acquisition Regulation's inspection clause, the rulebook for government purchasing, requires supplies to be accepted or rejected "as promptly as practicable after delivery," and then states that acceptance "shall be conclusive, except for latent defects, fraud, gross mistakes amounting to fraud." A latent defect is one that could not reasonably have been found at the time.
Put plainly: somebody accepts the delivery whether or not anybody writes it down, and once accepted it is largely settled. The receiving record is not the acceptance. It is just the only evidence you will have later about what that person saw.
Start from the documents you have, not the match you want
Most spend falls into one of three patterns, and each supports a different kind of check.
| How you buy it | Documents you have | Strongest check available |
|---|---|---|
| Ordered on a PO, delivered to a yard or shop where someone logs it | PO, receiving record, bill | Three-way, at the line |
| Ordered on a PO, delivered straight to a job site or customer address | PO, bill, and a delivery ticket someone signed | Three-way if the ticket is captured, two-way if it is not |
| Picked up at the counter, or ordered by phone with no PO | The bill, and whatever the field wrote down | No match at all, unless the bill is coded and reviewed line by line |
That third row is where most of the money leaks in trades, construction and field service, and it is the row every guide skips. There is nothing to match against, so the only control left is whether the person who requested the material ever sees what was billed for it.
Which brings us to the part that matters more than the type.
Header-level matching is why a bill that adds up still hides an error
Matching at the header means comparing invoice totals. Matching at the line means comparing each item: the quantity, the unit price, the description or SKU, the unit of measure.
Header matching passes a bill whenever the arithmetic works. The arithmetic works more often than you would think. A supplier bills forty units of one item and thirty-two of another when the PO said thirty-two and forty. The total is identical. Header matching approves it and the wrong quantity of both items lands in your inventory and your job costs.
It also passes the more common version: a unit price that crept up since the PO was cut, offset by a quantity that came in short. Two errors that cancel each other in the total and cancel nothing in reality.
Line-level matching catches both, because it never looks at the total to decide. MakersHub validates quantity, SKU and unit price on every line against the PO and the receipt, holds the bill when a line does not reconcile, and flags exactly which line is wrong rather than telling you the document failed.
That only works if the lines get read in the first place, which is the part most people underestimate. Supplier bills arrive as clean PDFs, faxed scans, photographs, and eight-page statements with sixty items on them. MakersHub's WiseVision AI reads the whole document rather than just the header, pulling every line with its description, quantity, unit of measure and price, so there is something to match against before the comparison even starts. You set your coding rules once, and MakersHub applies them everywhere.
"Makershub has revolutionized our operations. The improvements in invoice entry, PO matching, and approval workflows are remarkable, leading to exceptional accuracy and efficiency. This platform has truly elevated our productivity to new heights."
Jacqueline Finnick, Purchasing Manager, Elite PoolsPartial deliveries are the normal case, not the exception
A PO gets filled across three deliveries over two weeks. Two suppliers bill against the same PO. One bill covers material for four different POs. In a warehouse these are edge cases. On a job site they are Tuesday.
Most matching tools assume one bill against one PO, and everything else becomes a spreadsheet. MakersHub reconciles many bills to one PO and many POs to one bill, adjusts against the remaining PO balance for a partial shipment, and carries the job and cost code on each matched line straight through to posting.
Carrying the code through is the difference between a matched bill and a useful one. Matching confirms you were billed correctly. Carrying the job and cost code through means the correct amount also lands in the right place, which is what line-level coding is for.
The flag is the easy part. Somebody still has to resolve it
Every vendor demo ends at the flag. A line does not reconcile, the system catches it, everyone nods. Then the demo stops, and in real life that is where the work starts.
A flagged line has three possible endings. The bill is wrong and the supplier owes you a credit. The bill is right and the PO was stale, usually because a price moved or someone added material on site. Or the delivery came up short and nobody told the office. Those are three different conversations with three different people, and only one of them is with the supplier.
So the useful question about any matching tool is not how it detects a mismatch. It is who it hands the mismatch to. If the system sends every exception to whoever runs AP, your control is really just a queue on one person's desk. And that person usually cannot answer the question, because the answer lives with whoever ordered the material.
MakersHub routes the exception the way it routes anything else, by vendor, job, cost code, project or entity, so a price discrepancy on the Oak Street job goes to the person running Oak Street. They comment on the bill, the supplier conversation happens with the context attached, and the record of what was decided stays on the document. Approvers use MakersHub without training. They approve from email in one click, and see only the bills that are theirs.
There is no per-user pricing and no cap on transactions, users or entities, which matters here specifically: exceptions only get resolved if the people who know the answer are in the system, and per-seat pricing gives you a reason to leave them out.
How to set this up without a receiving department
You do not need a dock and a scanner to get most of the benefit. You need the delivery ticket to survive the trip back to the office, and you need the bill read at the line.
- Decide who accepts. Somebody already does, legally, the moment they take the delivery. Name the person for each site or truck so it is a role rather than an accident.
- Make the ticket a photo, not a piece of paper. A delivery ticket photographed at the tailgate and sent in beats a perfect receiving process nobody follows.
- Get POs onto the counter purchases you can. Not all of them will convert. Standing accounts at one or two suppliers are usually the easiest win.
- Match at the line, always. A total that foots tells you the arithmetic works, not that the bill is right.
- Route the exception, not the bill. The goal is that your team only looks at the lines that did not reconcile, not at every document.
If you are earlier in the evaluation, our guide to the best AP automation software covers the wider category, and what an accounts payable system does across all seven stages puts matching in context. If the bottleneck is getting a sign-off rather than a match, approval software is a different comparison. Contractors can start with AP software for construction companies, and six customers describe the hours they got back, before and after.
Frequently asked questions
What is PO matching?
PO matching is the process of comparing a supplier bill against the purchase order it was placed under, and often against a record of what was delivered, before the bill is approved for payment. The purpose is to pay for what was ordered and received, at the price agreed. The check can happen at the invoice total or at each individual line, and that difference decides how much it actually catches.
What is the difference between two-way and three-way matching?
Two-way matching compares the bill against the purchase order. Three-way matching adds a third document, the receiving record, so you also confirm the goods arrived. Three-way is the stronger control, and it is only available if somebody records what was delivered. Most guides present this as a choice, but for a lot of businesses the documents decide it: if material goes straight to a job site and nobody logs it, you have a two-way match regardless of what you would prefer.
What is four-way matching?
Four-way matching adds an inspection or quality-acceptance record to the purchase order, receiving record and bill. It is used where goods have to be tested before they are accepted, mainly in manufacturing, pharmaceuticals and regulated production. For most contractors, distributors and service businesses it is more process than the purchase is worth, and the real choice is between two-way and three-way.
What is line-level PO matching?
Line-level matching compares each item on the bill to the corresponding item on the purchase order and the receipt, checking quantity, unit price, description or SKU, and unit of measure. Header-level matching compares only the totals. The distinction matters because a bill can foot correctly while individual lines are wrong, and header matching approves it. MakersHub matches at the line on every bill, holds anything that does not reconcile, and flags the specific line rather than the whole document.
Can you do three-way matching without a warehouse?
Yes, if the delivery gets recorded somehow. The receiving record does not have to be a dock scan. A signed delivery ticket photographed at the site and sent in serves the same purpose, and it is the version that actually happens on job sites. MakersHub reads that ticket the same way it reads the bill, so the match runs without anyone building a receiving department. Where no record exists at all, line-level coding and review of the bill is the control you have left, and it is a real one.
What happens when a bill does not match the PO?
In MakersHub the bill is held and the mismatched lines are flagged before anything moves to approval. You can adjust quantities, accept a partial match against the remaining PO balance, or send it back to the supplier, and nothing syncs to your accounting system until it is resolved. The useful part is that the flag points at the line, so somebody is reviewing one item rather than rechecking a multi-page document.
Can one bill be matched to several purchase orders?
In MakersHub, yes, in both directions. You can match many bills to one PO and many POs to one bill, which is what partial deliveries, split orders and staged invoicing actually require. Quantities reconcile against the remaining PO balance, so a shipment that arrives in three parts over two weeks does not need a spreadsheet to track. Ask any vendor about this specifically, because one-to-one matching is a common limit and it surfaces on the first partial delivery.
Does PO matching work with QuickBooks?
In MakersHub, yes. Bills tie directly to open purchase orders in QuickBooks Online and QuickBooks Desktop, pulling in line items, quantities and pricing, and approved bills sync back immediately on Online, or on the next run of the Web Connector on Desktop. The Web Connector is Intuit's own tool for linking a desktop company file to an online service. The same line-level matching runs against NetSuite, Sage Intacct, Xero and Intuit Enterprise Suite, plus other systems through Smart Data Connect, and every one of those connections is built and maintained in-house.
Does matching catch supplier fraud?
It catches the ordinary version, which is far more common than the dramatic one: duplicate bills, quantities that drift upward, unit prices that moved since the PO was cut. Those are usually errors rather than schemes, and they cost the same either way. MakersHub logs every match, adjustment and approval in a searchable audit trail, keeps bill approval separate from payment authorization, and is SOC 2 Type II certified, with Positive Pay protection on check payments and encrypted collection of vendor bank details.
Want to see it on a real bill? Get started with MakersHub and bring one that has a PO behind it.
Sources: the Uniform Commercial Code § 2-606 on acceptance of goods, published by Cornell Law School's Legal Information Institute, and Federal Acquisition Regulation 52.246-2, Inspection of Supplies. Customer results come from published MakersHub customer stories.