Every AP team knows the drill. An invoice arrives, and someone has to open the corresponding purchase order, then check: Does the vendor name match? Does the PO number match? Do the line items, quantities, and amounts line up? Multiply that by hundreds of invoices per week from dozens of vendors—each sending a different format—and you have a process that eats hours before anyone can even start approving payments.
Template-based tools promise to automate this, but they don't solve the actual problem. You still need to build and maintain a template for every vendor format. When vendor #47 changes their invoice layout, the template breaks. When a new vendor comes on, someone has to configure extraction rules from scratch. The bottleneck isn't the matching logic—it's getting clean data out of documents in the first place.
Three-way matching—comparing the invoice against the PO and the receiving report—is straightforward in theory. The fields are predictable: vendor name, PO number, line items, quantities, unit prices, totals. The comparison logic is mechanical. If the invoice says 500 units at $12.00 and the PO says 500 units at $12.00, it's a match. Flag anything that doesn't line up.
The reason this stays manual isn't the matching step. It's the extraction step. Every vendor sends invoices in a different format—different layouts, different field labels, different table structures. Template-based extraction tools require you to map each vendor's format individually. With 50 vendors, that's 50 templates to build and maintain. With 200 vendors, it's unmanageable. The result: AP staff spend hours on data entry just to get invoice data into a format where matching can happen.
No templates to build per vendor. No retraining when a vendor changes their layout. No manual data entry before matching can begin.
ACS Industries runs this play at scale. They process 400 purchase orders per week across every format—PDFs, scans, images, plain-text emails. Zero templates built. They avoided hiring an additional FTE for data entry and saved 30 hours per week that was previously spent on manual AP automation tasks.
The matching step goes from hours of manual cross-referencing to minutes of reviewing flagged exceptions. Instead of checking every invoice line-by-line against its PO, the AP team focuses only on the 5–10% of documents where something doesn't line up—a price variance, a quantity mismatch, a missing PO number. Everything else flows through automatically.
That's the difference between a process that depends on data entry headcount and one that scales with document volume. More invoices don't mean more hours—they mean more rows in a spreadsheet that Lido already populated.
The same extraction-then-match workflow applies to a challenge that's even more common in international trade: matching packing lists to commercial invoices. In customs brokerage and freight forwarding, these two document types frequently arrive as a single combined PDF—sometimes running to 2,000 pages per shipment. Each packing list line item needs to be matched to its corresponding invoice line item before a customs entry can be filed.
The matching identifier is typically a batch number, reference number, or product code that appears on both the packing list and the invoice. The extracted data from each document type goes into separate sheets, and computed columns use lookups to match records and cross-check values: Does the net weight on the packing list match the invoice? Does the quantity align? Is the country of origin consistent between documents?
One customs brokerage processing 3,000+ entries per month uses Lido for exactly this workflow. Their suppliers' combined packing list and invoice PDFs contain roughly 50 fields per entry. Before automation, a single 80-page packet took several hours of manual data entry and cross-referencing. With Lido extracting both document types and matching on batch numbers, the same process takes minutes. As their operations lead described it: "It's not difficult or complicated. It's just tedious. This takes away the tedious."
Lido's AI columns add another layer: automatic data normalization during matching. Country of origin might appear as "Germany" on one document and "DE" on another. Net weight might be missing from certain line items on the packing list. AI columns can convert country names to standardized codes, flag missing values as NA, and surface discrepancies between the two documents—all without manual rules or lookup tables.
Yes. Lido extracts PO numbers and vendor names from any document format—PDFs, scans, images, emails—without requiring vendor-specific templates. Once the data is extracted into structured columns, matching happens on shared fields like PO number and vendor name regardless of how the original documents were laid out.
Discrepancies get flagged automatically. Price variances, quantity mismatches, missing PO numbers, and unmatched invoices all surface as exceptions. Your AP team reviews only the flagged items instead of checking every invoice manually. You set the tolerance thresholds—for example, allowing a 2% price variance before flagging—so the system matches your existing approval rules.
Lido handles mixed printed and handwritten documents. Block handwriting—the kind typically found on warehouse receiving slips and manually completed PO forms—extracts reliably. Cursive or heavily stylized handwriting may require review, but the system flags low-confidence extractions rather than guessing silently. For trade documents like packing lists and invoices, the vast majority are typed or printed, so handwriting is rarely a concern. When handwritten annotations do appear—such as notes on a packing slip or a customs stamp—Lido extracts the printed data accurately and flags any handwritten additions for review.
No limit. Lido reads documents contextually using invoice OCR powered by AI, not rigid templates. Every vendor format works on the first document without any setup or configuration. When a vendor changes their invoice layout, extraction continues working because the system understands document structure rather than matching against a fixed template.
%20(1).svg)
