Upload PDF, scanned or photographed invoices and download an Excel or CSV file with the header fields and every line item already in columns, one row per invoice or one row per line. A spreadsheet remains the most common destination for invoice data, and for good reason: it is where analysis actually happens, and nobody needs training to use it. Getting there is less trivial than it sounds, because a spreadsheet forces a decision that a PDF never had to make, what one row represents. This page covers that choice, the formats worth using, and the specific ways Excel quietly corrupts invoice data on the way in.
Reads digital PDFs, scans and phone photos. Exports to Excel, CSV and JSON.
Compare the extracted fields and line items against your own document.
Upload your invoices
Drop files here or click to upload
Up to 50 files
Uploading...
This is the decision that determines everything else about your sheet, and it is worth making deliberately rather than accepting whatever a tool produces by default.
One row per invoice is a summary layout: each row holds the supplier, invoice number, dates, subtotal, tax and total, and the line items are not represented at all. It is compact, it is easy to sort and filter, and it is exactly what you want for reconciliation, aging analysis or checking which bills arrived in a period.
One row per line item is a detail layout: each row is a single line from an invoice, with the header fields repeated across every row belonging to the same document. A three-line invoice becomes three rows carrying the same supplier and invoice number. It is longer and looks redundant, but it is the only layout that lets you analyze what was actually bought, code spend by category, or pivot by item across suppliers.
The repeated header fields are not waste. They are what makes a pivot table work. If the supplier name only appears on the first row of each invoice, every subsequent row belongs to a blank supplier as far as Excel is concerned, and every summary you build from it is wrong.
CSV is plain text and universally readable, which makes it the right choice when something other than a person is going to consume the file. An import routine, a script, another system. Its weakness is that it carries no type information at all: every value is a string, and the receiving application decides what it means. That decision is where most invoice data gets mangled.
XLSX carries types. A date stays a date, a number stays a number, and a text column stays text even when its contents look numeric. For a file that a person will open and work in, it is the safer format, and it is what you want when the sheet contains invoice numbers with leading zeros or account references that Excel would otherwise reinterpret.
The rule of thumb: XLSX when a human opens it, CSV when a machine reads it, and check the encoding either way. A CSV written without UTF-8 turns every accented supplier name into noise, which is a tedious thing to discover after the file has been distributed.
Excel applies type inference to anything that looks convertible, and invoice data is full of values that look convertible and are not. These failures are well known, they are entirely predictable, and they still catch people every month.
Most of the problems above are avoidable at the point the file is written rather than repaired afterwards. Exporting to XLSX with explicit cell types is the single most effective step: invoice numbers and reference codes written as text keep their leading zeros and their length, dates written as real date values are unambiguous regardless of locale, and amounts written as numbers with the currency in its own column will sum without editing.
A pivot-ready sheet has a few more properties worth asking for. One header row and no merged cells; no blank rows separating invoices; a consistent column order; header fields repeated on every line-item row; and empty values left genuinely empty rather than filled with "N/A", which turns a numeric column into a text one.
If a CSV is unavoidable, the practical defence is to import it through Excel's data import rather than opening it directly, and to set the problem columns to text during the import. Opening a CSV by double-clicking gives Excel free rein over every column, and it will use it.
Upload the PDF, let the fields and line items be extracted, then export as XLSX or CSV. The step that matters is choosing the layout beforehand: one row per invoice for summary work, or one row per line item with header fields repeated for anything you intend to pivot or analyze.
XLSX when a person will open the file, because it preserves types and stops Excel reinterpreting invoice numbers and dates. CSV when another system will read it, since it is universally parseable. But confirm the encoding is UTF-8 or accented supplier names will be corrupted.
Excel treats a value that looks numeric as a number, and numbers have no leading zeros. Exporting to XLSX with the column explicitly typed as text prevents it. If you must use CSV, import it through the data import dialog and set that column to text rather than double-clicking the file open.
Yes. Line-item export produces one row per line with the invoice header fields repeated on each row, which is the layout pivot tables require. Header-only export is available separately when you want a compact summary of which invoices arrived.
Yes. A batch of invoices exports to a single sheet with each document identified by its supplier and invoice number, which is the usual way to produce a month of payables for reconciliation or analysis in one file.
A complete guide to invoice data extraction: which fields are captured, how header data differs from line items, what structured output looks like, and how extracted values are validated.
Bulk invoice processing for high volumes: uploading hundreds of documents at once, queue behavior, parallelism, partial failure handling, splitting multi-invoice PDFs and surviving month-end spikes.
Convert Sysco invoices to Excel line by line: item code, pack size, quantity, unit price and extended price from Sysco, US Foods and GFS PDFs, ready for food cost.
Invoice OCR software that reads scanned, photographed and native PDF bills. How invoice OCR differs from generic text recognition, why templates break, and what per-field confidence means.
A practical comparison of every way to get data out of invoices: manual entry, Excel and Power Query, Python libraries such as pdfplumber and Tesseract, template tools and AI extraction. With honest notes on when each is the right choice.
An invoice OCR and data extraction API for developers: asynchronous job model, webhook and polling, JSON response shape, idempotency, error handling, rate limits and a sandbox environment.
Upload a few of your least tidy supplier invoices and compare the extracted fields against the documents. That tells you more than any feature list.
