Lido extracts complete invoice tables, including line items, tax breakdowns, and custom fields, without templates or pre-configuration. Upload any invoice and Lido outputs structured rows and columns in Excel, Google Sheets, or CSV regardless of the document layout.
Most invoice extraction tools handle header fields like vendor name, invoice date, and total amount. The real challenge starts when you need line-item descriptions, per-item quantities, conditional tax breakdowns, or custom fields that do not exist in the tool's default schema.
Line items live inside tables that span pages, nest sub-items, merge cells, and follow formatting rules that vary by vendor. This guide covers how to extract that deeper data and which tools handle it. For teams that need business logic built into the extraction pipeline, Lido handles it without templates or custom code.
Most extraction tools can pull line-item descriptions and quantities from clean, digital invoices with simple table structures. The problem is that real invoices rarely look like that. Tables span multiple pages, rows nest under category headers, and cells merge across columns.
A gas distribution company processing over 20,000 invoices a month ran into exactly this. Their rent invoices contained nested tables where each category line needed to be split into individual product lines with calculated pricing. Their previous extraction tool could not parse them at all. Lido resolved the nested rent table extraction during a single demo session.
A construction company extracting bill of materials from multi-page engineering drawings needed the same item consolidated when it appeared across different pages, with quantities summed. A single fitting might show up on page 3, page 7, and page 14. Each instance needed to be identified, matched, and combined into one row with the total count.
This is the line-item extraction problem most tools do not advertise: it is not about whether they can read a table. It is about whether they can read your tables.
Most invoice extraction platforms ship with a fixed schema: invoice number, date, vendor name, total, and maybe a basic line-item table. Custom fields, if supported at all, are typically limited to 5 or 10 predefined slots. For more details, see our guide on invoice parsing.
Real invoice processing requires fields that no default schema anticipates. An IT services company in Australia needed to extract multiple serial numbers per line item from their supplier invoices, with each serial number generating its own output row. That is not a standard field or even a standard structure.
A fashion company processing 1,000 sales orders a month needed computed fields that do not exist on the source document at all. Their POs from retailers arrive with a total quantity but no size breakdown. The team has to look up a separate reference table to split that into S, M, L, and XL quantities based on percentage ratios. Lido's computed columns and reference table integration handle this automatically during extraction rather than in a spreadsheet afterward.
Not all extraction is created equal. Understanding where your documents fall on the difficulty spectrum explains why your current tool might handle some invoices perfectly and others not at all.
Header fields. Invoice number, date, vendor name, total amount. These sit in consistent locations and use predictable labels. Nearly every OCR tool handles these reliably.
Simple line items. Description, quantity, unit price, line total. When the table is clean and single-page, most modern tools get this right.
Complex tables. Nested structures, multi-page tables, merged cells, category headers mixed with data rows. This is where most tools start failing.
Business logic. Tax calculations applied conditionally, size breakdowns computed from reference tables, unit conversions. Almost no extraction tool handles this natively.
Cross-document logic. Matching extracted data against reference files, deduplicating items across pages, PO matching. This requires an entirely different approach than document-level extraction.
Most tools market themselves based on how well they handle the first two levels. But most AP teams live in levels three through five. Lido handles those levels using computed columns, conditional extraction, and reference table integration.
Tax extraction sounds simple until you see how taxes actually work on real invoices. Many invoices apply different tax rates to different line items, include multiple tax jurisdictions, or calculate taxes based on item-level flags that are not obvious to a machine reading the document.
A restaurant group processing around 4,000 pages per week across 13 companies encountered this with their local vendor invoices. Their suppliers mark individual items with a "T" to indicate they are taxable. The sales tax percentage applies only to those flagged items.
Lido handles the conditional tax logic by reading the flags and applying the tax calculation selectively during extraction. Most extraction tools flatten multiple taxes into a single field, but Lido preserves per-line tax breakdowns including state, county, and regulatory surcharges.
Multi-tax invoices add another layer. When an invoice includes state tax, county tax, and a regulatory surcharge each applied to different subsets of line items, the extraction tool needs to parse which tax applies to which line and output the breakdown correctly. That level of granularity matters for AP audits.
When you process invoices from vendors across states, countries, or different accounting systems, formats diverge. Dates arrive as MM/DD/YYYY, DD/MM/YYYY, YYYY-MM-DD, or written out. Number formats use periods or commas as decimal separators. Unit measurements toggle between imperial and metric.
A construction company extracting materials from engineering drawings dealt with this at the measurement level. Quantities arrived in feet, inches, or a combined format like "10 foot 2 inches." Their downstream system needed everything in inches. The extraction tool had to read the measurement, recognize the mixed format, parse each component, and output a single value in the target unit.
This kind of format normalization happens silently in manual data entry. A human reads "10 foot 2 inches" and types "122" without thinking about it. But when you automate extraction, every format inconsistency becomes a potential data error unless the tool can interpret and normalize on the fly.
Credit notes, debit adjustments, and return annotations add complexity that goes beyond standard line-item extraction. These documents modify previous transactions, which means the extraction tool needs to capture not just what is on the page but the relationship to prior invoices.
Restaurant managers regularly annotate invoices by hand, crossing out items, writing "return" next to lines, and changing quantities. These handwritten modifications need to be captured as adjustments, not ignored as noise. For most extraction tools, a crossed-out line is either invisible or an error. For the accounting team, it is critical data.
Handling credit notes also means understanding negative amounts, return quantities, and reference invoice numbers that tie back to the original transaction. If your extraction tool treats every document as a standalone invoice, it will mishandle anything that references or modifies a prior one.
Solving the line-item extraction problem at the levels where most tools fail requires a fundamentally different approach from traditional OCR or template-based extraction.
First, the tool needs to understand document structure, not just text. Reading characters on a page is not the same as understanding that rows 3 through 7 are nested under a category header on row 2, or that a table continues on the next page with the same columns but no repeated header.
Second, it needs to support business logic as part of the extraction pipeline. Tax calculations, unit conversions, computed fields, and conditional rules should not be a post-processing step in Excel.
Third, it needs to handle cross-document relationships. When a 900-unit PO needs to be split by size using a reference table, or when duplicate items across 14 pages need to be consolidated with summed quantities, the tool needs access to more context than a single page provides.
If you are evaluating extraction tools for line-item level data, test with your hardest documents, not your cleanest ones.
Nested tables. Find an invoice with sub-items grouped under categories, or a multi-page table where data continues across page breaks. Check whether the hierarchy is preserved or flattened.
Conditional tax logic. Use an invoice where tax applies to some items but not others. Check whether the tool calculates per-line tax correctly or just pulls the total tax amount from the bottom of the page.
Custom fields. Try to extract a field that does not exist in the tool's default schema. If you are limited to a handful of predefined slots, you will hit a wall as soon as your requirements go beyond the basics.
Computed values. Test whether the tool can generate values that are not on the document, like calculated columns, lookups from reference tables, and unit conversions. If all it can do is read what is printed, you will still need manual post-processing.
Multi-page consolidation. Upload a document where the same item appears on multiple pages. Check whether the tool can identify duplicates and sum quantities, or whether it just gives you redundant rows.
Lido uses a custom blend of AI vision models, OCR, and LLMs to extract structured data from any document without templates or model training. You describe what you need in plain language, and the system interprets the document structure, applies business logic, and outputs clean, structured data.
When your extraction needs go beyond headers and into the line-item details that drive your accounting, the tool matters more than the marketing claims. Try Lido free with 50 pages to test on your own invoices.
%20(1).svg)
.png){kind=small}
