Skip to content
user@convertitive:~$convertitive

Invoice to Excel Converter

Line items and header fields, typed and ready for a formula — not a wall of merged text.

An invoice PDF mixes two different shapes of data: a repeating line-item table (description, quantity, unit price, tax rate, line total) and a set of one-off header fields (vendor name, invoice number, invoice date, due date, subtotal, tax total, grand total) that appear once per document. A layout-based extractor treats the whole page as one grid and either mashes the header fields into the table or drops them entirely. Extract's pipeline is told explicitly what each piece is — it pulls line items into rows and header fields into a single top-level summary — and cross-checks that each line's total is consistent with quantity × unit price, adjusted for whether tax is applied per line or once at the invoice level, so a column that's actually a discount or a shipping fee doesn't get misread as another line item.

./extract

Structured invoice exports

Upload an invoice and see line items and header fields split correctly before you pay for anything.

How to use

  1. Upload the invoice PDF

    Drop the invoice in. The first page extracts free so you can confirm the line-item columns and header fields look right before signing in.

  2. Check the header fields

    Vendor name, invoice number, invoice date, due date, subtotal, tax total, and grand total are pulled out as a single summary row separate from the line items, so they don't pollute the line-item table.

  3. Review the line-item table

    Each row is description, quantity, unit_price, tax_rate, and line_total. Rows where the line total doesn't reconcile with quantity × unit price are flagged for a quick check.

  4. Fix anything flagged

    Correct any flagged cell inline — a common case is per-line tax vs. invoice-level tax, which the extractor notes rather than silently assuming.

  5. Process every page and export

    Sign in (free — two full exports included) for multi-page invoices, then download a typed .xlsx or .csv where SUM() and unit-price formulas work immediately.

Frequently asked questions

Does it separate line items from header fields like vendor and totals?
Yes. Line items (description, quantity, unit_price, tax_rate, line_total) go into the table rows, while vendor_name, invoice_number, invoice_date, due_date, subtotal, tax_total, and grand_total are extracted as document-level fields, either in a dedicated summary row or the first row — they aren't mixed into the line-item table.
How does it handle tax — per line item or once at the invoice level?
Both, depending on how the invoice is laid out. If tax is applied per line, line_total should equal quantity × unit_price × (1 + tax_rate); if the invoice instead applies tax once at the bottom, the extractor notes that so you don't get a mismatched per-line reconciliation for a totals structure the invoice never used.
What if a vendor's invoice format changes month to month?
Extraction is semantic per document — each invoice is read on its own, by column meaning rather than a fixed template, so a vendor switching their layout (adding a PO number column, moving totals) doesn't require you to configure anything new.
Can it handle multi-page invoices with line items spanning pages?
Yes — each page is processed and the line items accumulate into one table; repeated header rows that appear at the top of continuation pages are recognized as headers, not duplicated as data rows.
Is invoice data private and deleted after processing?
Files are processed on encrypted infrastructure in the EU and deleted automatically one hour after export. The first-page preview is free and doesn't require an account — see the privacy policy for full retention details.
Does it work on scanned or photographed invoices?
Yes. Scanned pages route through OCR and are marked accordingly; any character the model can't confidently read is flagged rather than guessed, which the line-item total check will often catch anyway if a quantity or price digit is misread.

About

Why invoices need two extraction shapes, not one

Most PDF-to-table tools assume a single flat grid, which works for a plain data table but breaks on an invoice, where a repeating line-item block sits above or below one-off header fields that only ever appear once. Extract's prompt explicitly separates the two: line items become table rows keyed by description/quantity/unit_price/tax_rate/line_total, while vendor, invoice number, dates, and totals are pulled as document-level fields. The line-item check — line_total against quantity × unit_price, adjusted for where tax is applied — is the same arithmetic an accounts-payable clerk runs manually, done automatically so a transposed digit surfaces as a flagged row rather than an invoice paid for the wrong amount.

A real scenario: an AP clerk clearing a vendor invoice backlog

An accounts-payable clerk at a small company receives invoices from a few dozen vendors, each with its own PDF layout — different column orders, some with per-line tax, some with a single tax line at the bottom, a couple that only exist as scanned copies faxed in from an older vendor. Manually re-keying line items into the accounting system is the single slowest part of the AP cycle and the easiest place for a fat-fingered unit price to slip through. Uploading each invoice gets a typed line-item table plus a separated header summary, with mismatched line totals flagged before the data ever reaches the ledger — turning an hour of manual entry per vendor batch into a few minutes of review.

Sources & references

Authoritative references behind the math, constants, and tables on this page. Verified by Buğra Sözeri on the dates shown and re-checked at every deploy.