Upload a purchase order and, later, the invoice that claims to fulfil it, and the app lines the two up automatically: same PO number, same line items, same quantities, same prices. Anything that does not agree is flagged with the difference stated in plain numbers before a payment goes anywhere.
The app embedded on this page is the CSV Import Tool, a real Taskade Genesis build you can load rows into right now. Getting structured lines into a Project is half of what a matching desk needs, and it is the half you can stand up first. Click "Use this app" to clone it in about ten seconds, then add the two upload forms, the reading step, and the comparison described below.
The build has two intake paths feeding one comparison. A Purchase Orders Project holds one row per PO with supplier, PO number, order date, and a connected list of ordered lines. An Invoices Project does the same for bills. Both come in through a published form with a File field, and the Convert File to Text step reads whichever shape the document arrives in, which matters because POs are usually clean typed PDFs while the invoice is often a scan. An Ask Agent step pulls PO number, supplier, line description, quantity, unit price, and line total from each document. A comparison step then matches on PO number and reports three outcomes: matched, quantity variance, price variance. Every variance carries the ordered value, the billed value, and the difference, so the conversation with the supplier starts from a number rather than a feeling.
The matching state reads clearly in several layouts:
- Table view for the side-by-side ordered against billed grid
- Board view to move documents through Matched, Variance, and Resolved
- List view for a short daily exceptions queue
- Plus Calendar, Mind Map, Gantt, and Org Chart across the 7 project views
Automations turn a mismatch into a conversation. With Taskade automations, a price variance above your tolerance notifies purchasing in Slack and drafts the query email to the supplier with the two figures already in it. A clean match moves straight to approved. Across 100+ bidirectional integrations, Gmail pulls supplier documents in while Slack and Google Sheets push results out. The AI agents inside the app carry 34 built-in tools with persistent memory, so the agent learns which suppliers habitually bill a rounding difference and which ones never do.
Set your tolerances explicitly and keep them as fields. A percentage tolerance on unit price and an absolute tolerance on line total behave very differently on small orders, and having both is worth the five minutes it takes to add them. Keep the tolerance high while you learn, then tighten it once you can see which suppliers actually drift. Run a fortnight of real documents through before anyone changes their process, and read the variance list rather than the match list. The variances tell you where your ordering data is weak, which is usually a more valuable finding than the invoice errors you were looking for.
Clone the app, invite purchasing and finance, and the orders, the bills, and the tolerance rules are yours.
See the reading step in Convert File to Text, the intake pattern in Build a Document Intake App, and the payment side in Automate Invoices and Receipts. Shape the line-item structure with Databases in Projects, browse live builds in the Community Gallery, or explore automations. Pair this with Send Supplier Invoices Straight to an Approval Board upstream and Log Deliveries From the Packing Slip in the Box for the three-way check.
Frequently Asked Questions
Does this do a real three-way match?
It does the two-way match out of the box, ordered against billed. Add the receiving side by feeding in delivery notes from Log Deliveries From the Packing Slip in the Box and the same comparison step can check all three. Build it in that order so you can see each half working.
What if the PO number is missing from the invoice?
The row is held as unmatched with the reason stated rather than being guessed into a match. You can add a fallback in the prompt that tries supplier plus date plus total, but keep it as a suggestion a human confirms.
Can it handle partial deliveries and partial invoices?
Yes. Ask for quantities per line and compare cumulative billed quantity against ordered quantity rather than a single equality check. The row then shows part-billed instead of variance, which is what a purchasing team actually wants to see.
How does it handle different units or descriptions?
The agent reads the description as written and you set the tolerance rules. When a supplier writes a line differently from your PO the row is flagged for review with both descriptions shown, so a person makes the call once and the agent remembers the pairing.
Do scanned invoices slow the matching down?
Reading words off a scan uses AI credits like any AI step, and a typed PDF is read straight through at no extra credit cost. Practically, both land in the queue the same way. See AI Credits and Models.
Can suppliers submit documents themselves?
Yes. Publish the upload form and send them the link, or take documents in through a webhook. Both paths carry a real stored file into the automation, which is what the reading step needs.
What is the size limit on the documents?
Scans and photos should stay under 20 MB, the ceiling for reading words off an image. Typed PDFs and spreadsheets are read as text and are bounded by your plan upload size instead.
Can it match on something other than the PO number?
You can add fallbacks such as supplier plus date plus total, but keep them as suggestions a person confirms. Automatic fuzzy matching on money is how small errors become paid errors, and an unmatched row costs far less to resolve.
