Blog
Accurate table extraction isn't enough for accounts payable; the real work lies in three-way matching lines to purchase orders and receipts. Learn how Artificio automates complex AP exception handling.
On a Tuesday morning, an invoice lands in the AP inbox of a mid-sized equipment manufacturer. It comes from Harbor Industrial Supply, it is numbered HIS-20931, and it totals $777.90 across six lines. Bolts, nuts, washers, cable ties, a case of threadlocker and a freight charge.
The document parser does its job perfectly. Every line comes out in the right row. Quantities sit in the quantity column, unit prices sit in the price column, and the description that wrapped onto two lines in the PDF gets stitched back together. Nothing is shifted. Nothing is merged by mistake. The total at the bottom adds up.
Then someone on the AP team opens it anyway and spends the next twenty minutes on it.
She is not fixing extraction errors, because there are none. She is doing something else entirely. She pulls up purchase order 4500018827 and finds that the bolts were ordered as 500 individual pieces, while the invoice bills five boxes. She opens the receiving records and sees that the nylon lock nuts arrived in two separate deliveries a week apart. She notices that the cable tie part number on the invoice ends in "-UV" and the one on the PO does not. She spots a freight line that appears nowhere on the purchase order. And she catches that the threadlocker costs 70 cents more per bottle than the price the buyer negotiated.
That twenty minutes is the actual work of accounts payable. Almost none of it has anything to do with reading a table.
Give credit where it is due. Five years ago, getting a clean line-item table out of an invoice was a real fight. Tables split across pages lost their headers. Descriptions that wrapped onto a second line turned into phantom rows. Merged cells, crooked scans and suppliers who used tabs instead of gridlines all broke things in creative ways.
That picture has changed. Modern parsing tools, whether they come from cloud providers, open-source projects or specialist vendors, now handle most of these cases well. Multi-page tables stay connected. Column headers carry forward. Wrapped text gets reassembled. Layout-aware models understand that a number sitting under "Qty" is a quantity even when the gridlines are missing.
This progress is real and it matters. It has also created a blind spot in how companies evaluate AP automation. Vendors compete on extraction accuracy, buyers compare field-level accuracy scores, and the conversation stops there. The quiet assumption is that once the data is out of the PDF, the rest is plumbing.
It is not plumbing. A perfectly extracted table is a well-organized list of claims a supplier is making. Whether those claims are true, and whether you agreed to pay for them, is a completely separate question. Answering that question is where AP teams spend their days.
Think of it like a restaurant bill. Reading it accurately tells you what the restaurant says you ordered. It does not tell you whether your table actually ordered the second bottle of wine, whether the dessert that never arrived is on there, or whether the prices match the menu. You have to hold the bill up against your memory of the evening. In accounts payable, that memory lives in two other documents.
Most companies that buy physical goods follow some version of three-way matching. The idea is simple. Before you pay, three documents should agree.
The purchase order records what you agreed to buy, how much of it and at what price. The goods receipt records what actually showed up at your dock, entered by someone in receiving who counted the boxes. The invoice records what the supplier says you owe.
When all three agree, you pay. When they do not, someone has to figure out why.
The phrase "three documents should agree" hides a lot of difficulty. Agreement is not checked at the level of the whole invoice. It is checked line by line. Each invoice line has to find its partner on the purchase order and its partner or partners in the receiving records. Only then can anyone compare quantities and prices.
That pairing step, deciding which line belongs with which, is exactly where clean extraction stops helping. The three documents were written by different people, in different systems, for different purposes. The supplier describes items the way its own catalog does. Your buyer describes them the way your item master does. Your receiving clerk records them in whatever form the receiving screen asks for. Nobody coordinated, and nobody ever will.
Here is what a single line from invoice HIS-20931, the stainless steel bolts, looks like in each of the three places.
The parser read all three of those documents perfectly. They still do not say the same thing.
When AP teams talk about exceptions, they usually mean invoices that could not be matched automatically and landed in someone's queue. In most teams, very few of those exceptions trace back to bad extraction. Most come from one of the situations below, and every one of them can happen on an invoice that was parsed without a single error.
The supplier writes "SS HEX BOLT M8X40 A2." The PO says "Bolt, hex head, stainless, M8 x 40mm." The receiving record shows only your internal material number, 100045821.
A person knows instantly that these are the same bolt. A rules engine looking for an exact text match sees three unrelated strings. Fuzzy text matching helps a little, but it also produces confident wrong answers. "M8X40" and "M8X45" are one character apart and they are different parts. If the same supplier also sells an M8 x 40 bolt in zinc-plated steel, string similarity alone cannot tell you which one arrived.
Getting this right takes context. Has this supplier billed this description against this material number before? Does the supplier part number appear in your vendor catalog? Is there only one open PO line from this supplier that could plausibly be a stainless M8 bolt? Those are reasoning questions. They are not reading questions.
The invoice bills 5 boxes at $38.00 per box. The PO ordered 500 each at $0.38. The goods receipt logged 500 each.
These agree perfectly once you know that a box holds 100 bolts. Without that conversion, the quantity check fails because 5 is not 500, and the price check fails because $38.00 is not $0.38. That is two exceptions on one line, and both are false alarms.
Unit mismatches are everywhere. Suppliers sell by the case, the roll, the pallet, the pound or the linear foot. Buyers order in whatever unit the ERP item master uses. Conversion factors live in item masters, supplier catalogs and previous invoices. Sometimes they live only in the head of the person who has been doing this job for eight years.
The invoice bills 500 nylon lock nuts on a single line. Receiving logged them as two separate goods receipts, 300 on September 3 and 200 on September 9.
A simple match looks for one receipt with a quantity of 500 and does not find it. The correct match recognizes that both receipts belong to the same PO line and together add up to the billed amount.
The reverse happens too. A supplier ships 1,000 pieces in one delivery and bills them across three invoices. Or a supplier delivers 500 against a PO for 800, then bills the full 800 before the rest ships. Matching has to keep a running ledger of what has been ordered, received and billed on every PO line, and then decide which portion this particular invoice is claiming.
The threadlocker on HIS-20931 costs $14.60 per bottle. The PO says $13.90. That is 70 cents a bottle, $16.80 across 24 bottles, and about 5% over the agreed price.
Is that a problem? It depends on your tolerance policy. Many companies accept small variances automatically, because chasing a few cents costs more than the cents are worth. A 2% tolerance on this line would flag it. A 10% tolerance would let it through.
Real tolerance policies are rarely one number. They differ by supplier, by category, by dollar amount and by direction, since an invoice below the PO price is usually fine and one above it usually is not. Some companies use a percentage and a dollar cap together and apply whichever is smaller. Applying those rules correctly means knowing which rule covers this supplier, this line and this amount.
Freight. Fuel surcharges. Pallet fees. Small-order fees. Restocking charges. Environmental fees. These lines show up on invoices constantly and almost never have a matching PO line.
A strict three-way match flags every one of them. A sensible process asks whether the charge is allowed. Maybe the PO terms say "freight prepaid and added, not to exceed $60." Maybe the supplier contract includes a fuel surcharge schedule. Maybe this supplier has never charged freight before and this is something new.
The parser extracts "FREIGHT - GROUND $45.00" perfectly. Deciding whether to pay it requires reading the PO terms, knowing the contract and checking the supplier's history.
The PO lists the cable ties as part CT-300-BK. The invoice bills CT-300-BK-UV. Same length, same color, same price. The supplier simply replaced the old part with a UV-resistant version over the summer.
Substitutions and replacement part numbers are routine in distribution. Sometimes they are fine. Sometimes they are not, as when a supplier ships zinc-plated bolts against an order for stainless. That difference matters a great deal, and telling the two cases apart takes product knowledge, the supplier catalog and often a note the receiving clerk left on the goods receipt.
The PO has five lines. The invoice has six, in a different order. One invoice covers two POs. One PO line gets split into two invoice lines because the supplier bills backorders separately. A credit memo arrives that refers to an invoice from last month.
None of these break extraction. All of them break any matching logic that assumes invoice line 3 lines up with PO line 3.
Most AP automation built over the past two decades handles matching with rules. Match on PO number at the header. Match lines on part number. Check that quantity is within X. Check that price is within Y. Send anything that fails to a person.
Rules work well on the easy invoices, the ones from a supplier with EDI, clean part numbers, a single delivery and no freight. On those, the rules match everything and nobody touches the invoice.
The trouble is that each of the seven situations above needs its own rule, and each rule needs its own exceptions. Unit conversions need a lookup table for every supplier and item pair. Replacement part numbers need a cross-reference that someone has to maintain by hand. Freight needs a different rule for each contract. Split receipts need allocation logic. Teams keep adding rules, the rules start to conflict, and eventually nobody remembers why rule 147 exists.
At that point, the exception queue stops shrinking. The invoices that land there are the long tail of situations nobody wrote a rule for. Those are exactly the invoices that take twenty minutes each.
There is a second, quieter problem. When a rule fails, it usually says only that it failed. "Quantity mismatch on line 1." The AP specialist then repeats the whole investigation from scratch to discover that it was a unit issue all along. The system did the easy work and handed over the hard work with no head start.
An AI agent approaches matching the way an experienced AP specialist does. Instead of running a fixed sequence of checks, it reasons through each line using the same evidence a person would look at. Then it records what it concluded and why.
For every invoice line, the agent works through five decisions.
First, it works out which item this is. It compares the invoice description and supplier part number against open PO lines from that supplier, the vendor catalog, your item master and the history of past invoices from that supplier that were matched and approved. If "SS HEX BOLT M8X40 A2" has been billed against material 100045821 eleven times before, that is strong evidence.
Second, it reconciles the unit of measure. If the invoice says BX and the PO says EA, it looks for the conversion factor in the item master, the supplier catalog or prior matched invoices. It converts both quantity and price and checks that they still agree.
Third, it confirms receipt. It finds every goods receipt posted against the PO line, adds them up, subtracts anything already billed on earlier invoices, and checks whether the remaining received quantity covers what this invoice is claiming.
Fourth, it checks the price against the right tolerance. It finds the policy that applies to this supplier, category and amount, and decides whether the variance falls inside it.
Fifth, it decides whether any unmatched line is allowed. For freight and fees, it reads the PO terms and the supplier contract, looks at billing history, and decides whether the charge is permitted.
Then it does the thing rules engines do not do. It writes down its reasoning. Each line gets a status and a short explanation with the evidence attached. When something needs a person, that person gets a head start instead of a blank screen.
Here is how that plays out on invoice HIS-20931.
Line 1, stainless hex bolts. Billed as 5 BX at $38.00. The agent identifies the item from the supplier's billing history and finds PO line 10 for 500 EA at $0.38. The item master says 1 BX equals 100 EA. Converted, the invoice bills 500 EA at $0.38. A goods receipt from September 3 shows 500 received. Matched, with the unit conversion noted.
Line 2, nylon lock nuts. Billed as 500 EA at $0.12. PO line 20 matches the item, quantity and price. Two goods receipts, 300 on September 3 and 200 on September 9, add up to 500, and nothing has been billed against them before. Matched across both receipts.
Line 3, flat washers. 1,000 ordered, 1,000 received, 1,000 billed, all at the PO price. The easy one. Matched.
Line 4, cable ties. Billed as CT-300-BK-UV, 10 packs at $8.25. The PO lists CT-300-BK. The supplier catalog shows the UV version replaced the original in July with identical size and pricing, and the receiving clerk noted the new part number on the goods receipt. Matched, with the new part number flagged so the item master can be updated.
Line 5, threadlocker. Billed as 24 bottles at $14.60. PO line 50 says $13.90. The variance is 5.0%, or $16.80 on the line. This supplier's tolerance for this category is 2%. The agent routes the line to the buyer who placed the PO, with the PO price, the invoice price, the variance and the tolerance rule attached. The other five lines stay matched and ready, so only one decision waits on a person.
Line 6, ground freight. $45.00 with no PO line. The PO header terms say freight is prepaid and added, capped at $60. The agent also checks that this supplier's previous freight charges ran between $38 and $52. Accepted under the PO terms.
Five lines cleared with no human involvement. One line went to the one person who can actually decide it, with everything they need on one screen. The buyer either accepts the new price or calls the supplier. Either way, it becomes a two-minute decision instead of a twenty-minute investigation.
Look at where the value came from. Extraction was never the issue. The parser got every character right on the first pass. Everything useful in this example happened after the table was read.
It is easy to treat matching as a back-office detail. It is not one. The quality of matching shows up directly in cash, controls and supplier relationships.
Many suppliers offer terms like 2/10 net 30, which means a 2% discount if you pay within 10 days. An invoice that sits in an exception queue for a week over one missing unit conversion misses that window. On $2 million a month in spend with suppliers who offer the discount, 2% is $40,000 a month. Fast, accurate matching is what makes capturing that money realistic.
The threadlocker variance on HIS-20931 is $16.80. Small on its own. Across thousands of invoices a month, small price creep adds up, and it is precisely the kind of thing a tired reviewer approves just to clear the queue. Line-level matching with tolerance rules that fit each supplier catches it every time, without making people chase pennies nobody cares about.
The same logic catches duplicate billing. When the agent keeps a running count of what has been received and billed on every PO line, an invoice that bills the same 500 nuts a second time fails the receipt check immediately.
Auditors want to know why an invoice was approved. In a manual process, the answer lives in someone's memory or on a sticky note. With an agent, every line carries a recorded decision showing which PO line it matched, which receipts it used, which conversion it applied, which tolerance rule it checked and what evidence supported each step. That record exists for every invoice, not just the ones someone remembered to document.
The goal is not to remove people from AP. The goal is to stop using skilled people as human lookup tables. Once the routine reasoning around unit conversions, split receipts, replacement part numbers and allowed freight is handled, the team can spend its time on supplier disputes, pricing negotiations, process fixes and the genuinely ambiguous cases that need judgment.
Suppliers notice when invoices get paid on time, and they notice when invoices get disputed for no good reason. A false exception over a unit mismatch delays payment and triggers a phone call that wastes everyone's afternoon. Fewer false exceptions means fewer of those calls and a lot more goodwill.
If you are comparing AP automation tools, the usual demos focus on extraction. A vendor uploads a messy invoice, the fields light up, and everyone admires the accuracy. That demo tells you almost nothing about matching.
Ask for a different demo. Bring ten of your own invoices from the exception queue, along with the POs and goods receipts behind them. Pick the ones that took your team the longest. Then watch what happens after the table is read.
A handful of questions will separate real matching capability from extraction with a rules engine bolted on.
What happens when the invoice unit differs from the PO unit? Does the system find the conversion on its own, or does someone have to build a lookup table first?
How does it handle one invoice line covering two goods receipts, or one goods receipt split across two invoices?
Can tolerances differ by supplier, category and amount, and can the system tell you which rule it applied?
What does it do with freight and fee lines that are not on the PO? Does it actually read the PO terms?
When it routes an exception, what does the person see? A failure code, or an explanation with evidence?
What happens when your team corrects a decision? Does the system use that correction next time?
And measure the right number. Header-level touchless rates can look impressive while hiding line-level problems. The figure that tells you how much work is left for your team is the share of invoice lines matched correctly without a person, alongside the share of routed lines that genuinely needed one.
Artificio was built around the idea that documents are inputs to decisions, not ends in themselves. Our AI agents do extract invoice data, and they do it well. But extraction is the first step in our accounts payable workflow. It is not the product.
After an invoice is read, Artificio's agents match each line against purchase orders and goods receipts using the same evidence your team already relies on, including item masters, supplier catalogs, receiving records, PO terms and past matching decisions. They handle unit conversions, split receipts, replacement part numbers and allowed charges. They apply tolerance policies at the level of detail you actually work at. Every decision comes with a written explanation, so exceptions arrive with context and audits arrive with answers.
When your team corrects a decision, that correction becomes evidence for the next one. A supplier who always bills by the box only needs to be explained once.
For years, the AP automation industry treated invoice processing as a reading problem. Get the characters right, get the table right, and the rest would follow. The reading problem is now largely solved, and AP teams are still working through exception queues.
That is because the work was always in the connections. This invoice line belongs to that PO line. These two receipts add up to that quantity. This freight charge is allowed under those terms. This price increase needs a buyer's sign-off.
A parser can tell you exactly what Harbor Industrial Supply wrote on invoice HIS-20931. It cannot tell you whether you should pay it. That takes reading three documents, connecting them line by line and explaining the result in a way that both a person and an auditor can follow.
The next time someone shows you a perfect table extraction, ask them what happens to line 1.
All company names, document numbers and figures in the HIS-20931 example are illustrative.
Head IT Operations - Co Founder of Artificio
See it in your SAP environment
Bring us a document, a process, or a bottleneck. We'll show how Artificio captures, validates, and posts into SAP — then scale from there.
Security & compliance
ISO 27001:2013 certified, SOC 2 Type 2 compliant, GDPR and HIPAA ready. Every agent action is logged, auditable, and runs in isolated environments.
