The short answer on 3-way matching
Three-way matching in accounts payable is a control that compares three documents before a bill gets paid: the purchase order (PO), which is what you agreed to buy; the receipt, which is what actually arrived; and the vendor invoice, which is what the vendor is charging you. When quantities and unit prices agree within the tolerances you set, the bill moves on to approval. When the numbers don’t reconcile, it stops for review.
That’s the whole idea. Three-way matching is rule-based, so once you know which documents get compared and how much variance you’re willing to accept, you can run it line by line on any bill that crosses your desk.
This guide is for AP managers and controllers on NetSuite who pay bills against POs and manage the exceptions when those bills don’t tie out. By the end you’ll be able to explain the match to an approver, set tolerances that stop the bills you want stopped, and know where an exception lives in NetSuite so the reason stays on the record.
Why AP teams need 3-way matching
AP teams rarely come to 3-way matching from a planning session. They come to it after the same thing has gone wrong more than once.
Someone in AP has three browser tabs open, the PO, the item receipt, the bill, and is reading quantities across them by eye. A second spreadsheet tracks how much has been billed against each open PO, because when four partial bills hit one single PO, nothing in the workflow tells you the cumulative total went over. A vendor was paid for 100 units when 97 arrived, and nobody caught it until the quarterly recovery audit. An approver asked, “why is this one flagged?” and the answer was in an email thread from three weeks ago.
None of that shows up as a line item on a budget. It shows up as days added to close, as credits chased after the money has already left, and as an auditor asking why a bill was approved and getting a shrug. 3-way matching is one of the simplest and oldest defenses against all of it, and against invoice fraud and overbilling.
The three documents behind every PO match
If someone asks what documents are used in a 3-way match, the answer is always the same three. The good news is NetSuite already holds all of them.
The purchase order. The PO is the agreement: what you ordered from your vendor, how many, at what unit price, and on what terms. It’s the only one of the three your company controls from the start, which is why it’s the reference point everything else gets measured against.
The receipt. The record of what you received, and in what quantity. In NetSuite it’s an item receipt, created when someone receives against the purchase order. Oracle’s help covers the steps in receiving orders. No item receipt means nothing confirms the goods showed up, so the match can’t complete.
The vendor invoice. What the vendor is charging you, entered in NetSuite as a vendor bill. It’s the document the other two get checked against.
Purchase order, receipt, invoice.
One catch: services and subscriptions usually have nothing to receive, so there’s no item receipt and nothing to match the third document against. For those bills, 2-way matching is the appropriate control, covered further down.
A 3-way match, worked through
Here’s an example you can run on paper. One purchase order, one item receipt, one vendor bill with three lines. The numbers and the tolerance settings below are illustrative, not recommendations.
PO 1042, Acme Office Supply.
Example settings: Price tolerance of 2%, quantity difference limit of two units.
| Line | Ordered | Received | Invoiced | Result |
|---|---|---|---|---|
| 1. Laptop stands | 100 at $10.00 | 97 | 100 at $10.00 | Hold. Billed for three units that never arrived, $30 over the receipt. Three units is more than the two-unit difference limit, so the line stops. |
| 2. Monitor cables | 50 at $4.00 | 50 | 50 at $4.06 | Pass. Quantity agrees; unit price is 1.5% over the PO, inside the 2% tolerance. The $3.00 difference posts to a price variance account |
| 3. Freight | Not on the PO | None | $85.00 | Hold. A line on the bill with no matching PO line and nothing received against it |
The bill totals $1,288. What the PO and receipt actually support is $1,173. The match found the $115 gap before anyone approved this bill.
Same bill, three different outcomes, and the rules made every call instead of someone reading across three tabs. Line 2 is a variance you already decided you could live with, so nobody has to look at it. Line 1 is one you wanted stopped. Line 3 is the one most teams miss. A header-level check compares bill total to PO total, which lets an unbilled shortage cancel out an unapproved addition and show a clean match.
What AP does next
The bill is on hold. There are three sensible paths, and the right one depends on the vendor and the item.
Wait for the short units. If the three missing stands are on a later delivery, hold the bill until the receipt is updated, then let it match.
Ask for a credit or a corrected invoice. The cleanest option when the vendor shipped short and billed full. The paperwork then ties out on its own.
Pay for what arrived. Pay the 97 units, note why, and close the PO line if the balance won’t ship.
Freight is a separate call. If the charge is legitimate, accept it as a non-PO line and write down why. If it shows up on every bill from this vendor, your tolerances should be allowing for it already.
Whatever you decide, write the reason on the bill itself. An email thread won’t help the auditor who asks about it a year from now.
Tolerances: How close is close enough?
A tolerance is the gap you’re willing to accept between the documents before a person has to look at the bill.
NetSuite uses two kinds, and the difference is exactly what tripped up the example above. A tolerance limit is a percentage, and it can apply to quantities or amounts. A difference limit is a fixed number of units, and it applies to quantities only. Both can be set on item records, vendor records, and subsidiary records, so the rule can be as broad or as narrow as you need. Oracle’s help covers the fields and where they live in matching tolerance settings.
There’s no correct number to copy. Keep tolerance limits tight on high-value or high-risk items, where a 1% price variance is real money or a quantity gap points to something worth investigating. Loosen it on low-value consumables, where chasing a few cents costs more than the variance is worth.
Where you set it matters as much as the number. If one vendor rounds freight differently every month, fix it on that vendor, or on that item. There’s no reason to loosen the rule for every vendor you pay.
One thing worth knowing about the variances that do pass: they don’t vanish. NetSuite can post quantity, price, and exchange-rate differences to their own variance accounts, so the small gaps you decided not to stop for are still sitting in the GL at close, where the controller sees them in aggregate even though AP never touched them individually.
That’s what tolerances buy you. You decide once, up front, which differences are worth someone’s time, and the rest just get recorded.
Why bills fail the match
Most exceptions come from a short list of causes:
- A partial delivery. The vendor shipped 97 of 100 units and billed for all of them.
- A price change nobody updated on the PO. The buyer agreed to it verbally; the record was never updated.
- A receipt the warehouse hasn’t entered yet. The bill has nothing to compare against, so it sits.
- A unit-of-measure mix-up. Cases billed against eaches.
- Charges that hit the bill but never hit the PO. Freight, tax, and landed cost will flag unless your tolerances account for them.
- Currency differences. When the PO is in one currency and the bill is in another, FX movement surfaces as a price variance even when the match is otherwise clean.
- A duplicate invoice. The same bill entered twice.
Exception handling should follow the same path every time. The bill should be placed on hold. Someone with context reviews it, either accounts payable, or the buyer who raised the PO. They fix the cause: update the PO, enter the receipt, request a credit, or approve it with a written justification. For more on routing, see how 3-way match simplifies your approval process.
When an invoice doesn’t match purchase order terms, the reason always belongs on the record.
Comparing 2-way, 3-way, and 4-way matching
Three-way matching is only one option of three. The difference between two-way and three-way comes down to a single document: the receipt.
| Match type | What it compares | When to use it |
|---|---|---|
| 2-way | Purchase order and invoice | Services, subscriptions, and low-value buys where nothing physical arrives, so there’s no receipt to compare against. |
| 3-way | Purchase order, receipt, and invoice | Physical goods, where you need proof the items actually arrived before you pay for them. |
| 4-way | Purchase order, receipt, invoice, and an inspection or quality check | Regulated or high-spec goods, where arriving isn’t the same as passing. |
Two-way matching is the same control with the receipt step removed: you check the invoice matches with what you agreed to buy, and that’s it. For a monthly software subscription, that’s the whole story.
How 3-way matching works in NetSuite
NetSuite already holds all three documents. The purchase order, the item receipt, and the vendor bill are separate records that link back to each other, so the comparison data sits in one place before anyone starts matching.
To run the check automatically, NetSuite uses Oracle’s 3 Way Match Vendor Bill Approval workflow, part of the NetSuite Approvals Workflow SuiteApp, an Oracle add-on. It compares each vendor bill against its purchase order and item receipt before payment, checking quantities and amounts against the limits you’ve set.
Bills inside the limits can be approved automatically. Bills outside the limits route to the employee’s supervisor for review, which is why setup depends on supervisor records and the approval routing preference being configured first. Oracle documents the required features and setup steps along with how tolerance limits and difference limits work on item, vendor, and subsidiary records.
One limit worth knowing before you build a process around it: the native vendor bill approval workflow doesn’t support partially received item receipts.
How to set up a 3-way match you can trust
Whether you’re reviewing native NetSuite functionality or looking at automation, five questions tell you whether a matching setup is a real control or just a gate:
- Does it match line by line, or only the bill total? A short-shipped line can hide behind an overbilled one when the check happens at the header.
- Can tolerances differ by vendor, item, and subsidiary? One percentage applied to every bill is going to be a bottleneck at some point; what is too tight for consumables is going to be too loose for high-value parts.
- Does the matching check as the bill is entered, or in a batch afterward? Variances are cheap to fix while AP is still looking at the bill, expensive after it’s saved and routed.
- Does the match calculate PO overages across every bill against that PO? Four partial bills against one PO is a common place for overspend to hide, and hard to find until the spreadsheet comes out.
- Can the approver see which line failed and why, at the moment of approval? A flag with no explanation can easily get approved anyway.
If the tool also uses AI, add seven more questions to ask any AP vendor.
How Charted Real-Time 3-Way Match works
Charted Real-Time 3-Way Match validates every invoice line against the purchase order and the item receipt as you work, right on the vendor bill. No post-save check, no separate exception screen to go hunting for. The manual comparison work disappears, and variances get caught while the bill is still open.
The practical difference is when the check happens. A post-save check tells you about the variance after the data is already in the GL, which usually means a reclass entry at month-end or a credit request chased after payment went out. A real-time check stops the variance at entry, while AP still has the bill open and the vendor still owes you a corrected invoice.
Native NetSuite 3-way match and Charted Real-Time 3-Way Match, side by side
| NetSuite-native 3-way match | Charted Real-Time 3-Way Match | |
|---|---|---|
| Validation timing | Post-save. Variances are identified after the bill is saved, so cleanup often means reopening or un-approving a record. | Real-time. Quantities, rates, and amounts are validated before the bill is saved. Discrepancies surface while the user is still on the record. |
| Matching depth | Header-centric. Line-item variances on complex multi-line POs are harder to isolate. | Line-level. Every bill line is matched against the PO line and the item receipt, catching the discrepancies a header-level check misses. |
| Overage logic | Transaction-based. Tracking cumulative overages across multiple partial bills on one PO usually falls to a spreadsheet. | Cumulative. Overage is calculated across all bills related to the PO, so partial shipments can’t add up past the commitment unnoticed. |
| Tolerances | Global and basic. Limited flexibility to set different thresholds for different types of spend. | Four levels. Global, subsidiary, vendor, and item, by percentage, amount, or quantity. |
| Exception handling | Manual and siloed. Exceptions sit in separate reports or need someone to route them for review. | Routed automatically. Variances trigger the right approval path, and justification comments are stored on the native record. |
| Automation handoff | None. Even a perfect match still needs a manual review step. | Touchless. Perfect matches feed straight into Touchless Invoice Processing for zero-click bill creation. |
Where partial billing usually goes wrong
A vendor ships one PO in three shipments and sends three invoices. The first looks fine. The second comes in 5% over. The third looks fine too. Reviewed one at a time, every bill passes. The cumulative total against the PO doesn’t.
Charted calculates overage across every bill tied to that purchase order, so the spreadsheet that tracks billed-to-date against open POs stops being necessary. If the running total breaches tolerance, the bill is automatically held.
Exceptions route to the person who actually knows the order
A variance over tolerance routes to an approver with the specific detail attached: which line, what kind of variance, quantity, unit price, or a line added to the bill that was never on the PO. Approvers act from email without needing a NetSuite license, which matters when the person with context is a buyer or a department head who doesn’t regularly work in NetSuite. The justification they write becomes a permanent part of the line-level audit trail on the record, where an auditor can find it a year later.
Because Charted runs natively inside NetSuite, it compares against PO and receipt data that’s already there. There’s no connector, no sync window, and no risk of matching against stale PO data.
One honest note on fit: this is built for PO-based AP where receipts for goods are recorded in NetSuite. Service POs and non-item POs without clean receipts are a weaker fit, and 2-way matching is usually the better control for that spend.
Two related reads: how 3-way matching reduces AP fraud exposure and best practices for PO matching in NetSuite.
See automated 3-way matching in your own NetSuite account
Frequently asked questions
What is the 3-way matching principle in accounts payable?
The process of 3-way matching means you don’t pay a bill until your three records (PO, receipt, invoice) agree. The purchase order shows what you agreed to buy, the receipt shows what arrived, and the vendor invoice shows what you’re being billed. When quantities and prices line up within your tolerances, the bill moves to approval. When they don’t, a person looks at it.
What is an example of a 3-way match?
You order 100 laptop stands at $10.00 each. The warehouse receives 97. The vendor bills for 100. That’s $30 billed for goods that never arrived, so the line is held for review instead of being automatically paid. On the same bill, monitor cables come in 1.5% over the PO price, inside a 2% tolerance, so that line passes and the difference posts to a price variance account.
What is the difference between 2-way and 3-way matching?
Two-way matching compares the purchase order and the invoice. Three-way matching adds the receipt, so you confirm the goods have actually arrived before paying. Use two-way for services and subscriptions where nothing is physically received, like software, and three-way for physical goods.
Why is 3-way matching important?
Three-way matching stops money from leaving the building for goods that never arrived. The match catches short shipments, unapproved price changes, duplicate invoices, and line items nobody ordered, before payment goes out, when a credit is still easy to get. It also leaves an audit trail showing why each bill was approved.
What documents are used in a 3-way match?
Three documents are needed for three-way matching: the purchase order, the receipt (NetSuite calls it an item receipt), and the vendor invoice. Each answers a different question, what you agreed to buy, what arrived, and what you’re being asked to pay.
Does NetSuite do 3-way matching?
Yes. Oracle’s 3 Way Match Vendor Bill Approval workflow, part of the NetSuite Approvals Workflow SuiteApp add-on, checks each bill against its purchase order and item receipt and routes out-of-tolerance bills to a supervisor for review.
What’s the difference between NetSuite native 3-way matching and Charted Real-Time 3-Way Match?
Timing and depth. The native workflow validates after the bill is saved, compares largely at the header, and applies broad tolerances. Charted Real-Time 3-Way Match validates line by line before the bill is saved, with tolerances set at the global, subsidiary, vendor, and item levels by percentage, amount, or quantity. The side-by-side table above breaks out all six differences.
How do I catch a PO overage spread across multiple partial bills?
Check cumulatively rather than per bill. Three invoices against one PO can each look reasonable while the running total breaches the commitment. Charted calculates overage across every bill related to the purchase order, so the breach is flagged on the bill that causes it instead of surfacing in a spreadsheet reconciliation later.
Can approvers review 3-way match exceptions without a NetSuite license?
With Charted, yes. Exceptions route by email with the variance detail attached, and approvers respond without logging into NetSuite. Their justification comments are written back to the vendor bill as part of the line-level audit trail, so the record stays complete even though the approver never had a license.
Does 3-way matching work with partial receipts?
It depends on the setup. The native vendor bill approval workflow doesn’t support partially received item receipts. Charted three-way matching handles partial receipts and calculates overages when multiple bills hit the same purchase order, which is the common case when receiving goods from distribution and manufacturing companies, where one PO ships over several weeks.
