Pull the numbers out of a PDF instead of retyping them. Upload a digital or scanned PDF and AI reads the tables, the header fields, and the line items, then exports Excel, CSV, or JSON. No Python script, no template to configure, and no copy and paste that arrives in Excel as one long column. Drop a file below and see what comes back.
Upload your receipts and invoices
Drop files here or click to upload
Up to 50 files
Uploading...
A PDF is a description of where ink goes on a page, not a table of data. That single fact explains why copy and paste destroys your columns, why Power Query returns nothing from a scan, and why the Python script that worked last quarter broke when a vendor changed their invoice template.
Selecting a table in a PDF viewer and pasting into Excel usually produces one column of run-together values, because the file never stored a table. It stored characters at coordinates that happen to look like rows.
Excel's Get Data From PDF connector reads the text layer of a PDF. A scan or a photo has no text layer, only pixels, so the import returns nothing until something runs OCR first.
pdfplumber, Camelot, and tabula-py read text-layer PDFs well and break on merged cells, multi-page tables, rotated pages, and any layout they were not tuned for. Maintaining that script is a permanent job.
Even a perfect table export leaves a human deciding which cell is the invoice date and which number is the sales tax. Twenty vendor layouts produce twenty differently shaped spreadsheets.
ReceiptOCR handles the whole path in one step: it recognizes text on scanned pages, reconstructs table structure, and labels the values that matter, so you get consistent columns no matter which vendor sent the document.
Text-layer PDFs, scanned pages, and photographs of paper all go through the same pipeline. You never have to work out which kind of PDF you are holding before you start.
Row and column structure is reconstructed rather than inferred from spacing, so line items land in the cells you expect, including on multi-page documents.
Vendor, date, document number, subtotal, sales tax, and total return as labeled values. The same columns from every layout, ready to import instead of ready to reformat.
Upload a month of documents and get one stacked sheet. Each file is read independently, so accuracy does not degrade as the batch grows.
Every extracted value is visible and editable before the file leaves. A confidently wrong total costs more to unwind than a blank one costs to fill.
When the output feeds an application rather than a spreadsheet, post the PDF to an API endpoint and get structured JSON back.
From a folder of PDFs to a spreadsheet you can import, without a parser or a template.
One document or a whole folder. Digital exports, scans from a copier, and phone photographs of paper are all accepted, and mixing them in one batch is fine.
Tip: If you are testing, include a scanned page. That is where most extraction tools quietly fail, and it is the fastest way to tell a real one apart.
Review the header values and the line items on screen. Correct anything the engine flagged or got wrong, which on faded or handwritten paper is where a human still earns their keep.
Download Excel, CSV, or JSON, or call the same extraction over a REST API and skip the download entirely.
Built for US teams whose data arrives as PDFs and has to end up in a spreadsheet, a ledger, or a database.
Vendor bills, receipts, and statements arrive as PDFs and leave as journal entries. The work in between is keying, and it is the work worth deleting.
The report you need lives inside a PDF table somebody else generated. You need it in Excel this afternoon, with the columns intact.
You have written the pdfplumber script. It works until the layout changes. An extraction API returns the same JSON shape regardless of who designed the page.
Hundreds of scanned pages, no text layer, and a deadline. OCR alone gives you words; extraction gives you rows you can sort and total.
Last updated July 2026.
PDF data extraction is the process of turning the contents of a PDF into structured data you can sort, total, and import. It has two halves that most tools only do one of: reading the characters, which is OCR, and deciding what those characters mean, which is field extraction. A digital PDF already contains text and needs only the second half. A scanned PDF is an image and needs both.
Pick the method by asking one question first: does the PDF have a text layer? Open it and try to select a word with your cursor. If the text highlights, it is a digital PDF and text-based tools will work. If your cursor draws a box over an image, it is a scan and nothing will read it until OCR runs. Here is what each route actually returns.
| Method | Works on scans? | What you actually get |
|---|---|---|
| Copy and paste | No | Text, usually in one column, structure lost |
| Excel, Get Data From PDF | No | Detected tables from the text layer, needs cleanup |
| Acrobat, Export To Excel | Yes, runs OCR first | A workbook that mirrors the page layout |
| Python, pdfplumber or Camelot | No, add OCR yourself | Rows and cells, plus a script to maintain |
| OCR engine alone | Yes | Characters and coordinates, no meaning |
| AI document extraction | Yes | Named fields and reconstructed tables |
For a digital PDF, Excel can do it natively. Open a blank workbook and choose Data, then Get Data, then From File, then From PDF, and point it at the file. Power Query lists the tables it detected and you load the ones you want. It works, and it is free with Excel, and it fails in two predictable ways: it finds no tables in a scanned PDF because there is no text layer to read, and it splits or merges columns whenever the source table uses merged cells or wraps a row across pages.
For a scanned PDF, something has to recognize the characters first. Adobe Acrobat does this automatically when you export a scan to Excel, and it produces a workbook that reproduces the page layout, one worksheet per table or per page depending on the setting you choose. That output is usable when the source really is a clean grid. It is much less useful when the thing you want is four values scattered across an invoice, because Acrobat gives you the whole page as cells and leaves the interpretation to you. If your PDFs are vendor bills, the invoice PDF to Excel converter skips that step and returns the fields directly.
Yes, but only with OCR in the pipeline. A scanned PDF contains an image of a page, so there is no text to select, search, or import. Optical character recognition converts those pixels into characters, and only then can a tool find the tables and fields. Any method that skips OCR, including Excel's Power Query connector and most Python table libraries, returns an empty result on a scan and gives no useful error explaining why.
Scan quality decides the outcome more than the software does. Adobe documents 300 dpi as the resolution that produces the best text for conversion, notes that accuracy is slightly lower at 150 dpi, and will not apply OCR at all below 72 dpi. The same holds for phone photographs: shoot the page flat and head on, fill the frame, and avoid shadows across the numbers. A better photograph beats a better OCR engine more often than anyone selling OCR engines would like to admit.
Table extraction is harder than it looks because PDFs do not store tables. They store characters at coordinates, and every extraction tool reconstructs the grid by guessing from whitespace and ruling lines. That guess is right most of the time on a simple table and wrong in specific, predictable places.
Merged cells break the column count. A table that continues onto a second page usually returns as two unrelated tables, with the header attached to the first one only. Rotated or skewed scans shift every column boundary. Numbers with a currency symbol and a thousands separator sometimes arrive as text rather than as values, which is why the SUM at the bottom of your new spreadsheet reads zero. Fix that by checking the numeric separators on import rather than by retyping the column.
This is the question that separates the tools. Extracting a table means capturing everything on the page. Extracting specific data means asking for the invoice number, the due date, and the total, and getting those three values regardless of where the designer put them. Coordinate-based and template-based tools handle this by having you draw a box over each field once, which works beautifully until a vendor moves their logo and every box is wrong.
Model-based extraction reads the document the way a person does and returns the same named fields from any layout. That is the difference between a parser you maintain and a service you use, and it is why AI invoice data extraction holds up across hundreds of vendors while a template library needs a maintainer.
Yes, and for a stable, text-layer PDF it is a reasonable choice. pdfplumber gives you characters, words, and detected tables with good control over the extraction settings. Camelot and tabula-py target ruled tables specifically and do well when the source has visible gridlines. PyMuPDF is fast and reads text and metadata. All three read the text layer only, so a scan requires you to add an OCR step, typically Tesseract, and to handle the deskewing and thresholding that makes Tesseract work on real paper.
The cost of the Python route is not writing it. It is owning it. Vendors redesign invoices, scanners change defaults, a supplier switches to a two-page bill, and the script that ran cleanly for six months starts silently dropping the tax line. If the pipeline is core to your product, own the code. If it is plumbing between a document and your ledger, an extraction API returns the same JSON shape whatever the layout does, and somebody else maintains the parser.
There is no single answer, because three genuinely different jobs share this search. Match the tool to the job:
If the documents are receipts, receipt to Excel converter is the direct path, and a whole month goes through the bulk receipt scanner in one upload. For vendor bills, invoice OCR software returns the header and the line items together. If you are evaluating the broader category of platforms that classify and extract across many document types, the intelligent document processing overview covers what those systems include and which parts most buyers never switch on.
Accuracy depends far more on the input than on the vendor. On a clean, digitally generated PDF, character recognition is effectively a solved problem and the errors that remain are structural: a merged cell, a wrapped row, a footnote read as a line item. On a scan or a photograph, accuracy tracks the scan. Sharp 300 dpi output from a flatbed reads close to a digital file. A creased thermal receipt shot at an angle in a parking lot does not, and no percentage on a marketing page changes that.
The measurement that matters is not the vendor's headline number, it is how many of your documents came back needing a human. Run a hundred of your real files, count the rows you had to correct, and decide from that. We wrote about why published accuracy claims collapse under inspection in how accurate is receipt OCR, and the practical takeaway is to always review before export, which is why every extraction here is editable before the file leaves.
First check whether the PDF has a text layer by trying to select a word. If text highlights, tools such as Excel's Get Data From PDF connector or a Python library can read it. If your cursor draws a box over an image, the page is a scan and OCR has to run before anything can extract from it. AI document extraction handles both cases in one step and returns named fields rather than raw cells.
In Excel, choose Data, then Get Data, then From File, then From PDF, and load the tables Power Query detects. That reads the text layer only, so a scanned PDF returns nothing. For scans, either run OCR first or use an extraction tool that recognizes the characters and reconstructs the table in the same pass, then exports Excel or CSV.
Yes, but only with OCR in the pipeline, because a scanned PDF contains an image rather than text. Scan quality drives the result: Adobe documents 300 dpi as producing the best text for conversion, slightly lower accuracy at 150 dpi, and no OCR at all below 72 dpi. Photograph pages flat and head on for the same reason.
Because a PDF never stored a table. It stored characters at coordinates that happen to look like rows and columns on screen. Copying selects the characters in reading order and drops the layout, so everything lands in one column. Any reliable extraction has to reconstruct the grid from position data rather than copy the text.
Yes. pdfplumber, Camelot, tabula-py, and PyMuPDF all read text-layer PDFs, and Camelot and tabula-py target ruled tables specifically. None of them read scans without an added OCR step such as Tesseract. The real cost of the Python route is maintenance, because vendor layout changes silently break table detection.
OCR converts an image of text into machine-readable characters. It reads. Data extraction decides what those characters mean, labeling one value as the invoice date and another as the sales tax, and rebuilds the table structure. OCR is a step inside extraction, not a substitute for it, which is why an OCR tool alone leaves you with text rather than rows.
For making a document readable, a PDF suite with OCR such as Acrobat Pro or ABBYY FineReader. For pulling one table out of a digital PDF once, Excel's Power Query connector. For the same fields from documents that keep arriving, AI extraction, because it returns consistent columns from any vendor layout without a template per sender.
Yes. Post the PDF to a REST endpoint and receive structured JSON with header fields and line items, so the extraction runs inside your own application rather than in a browser tab. That is the right shape when documents arrive continuously, when the output feeds a database or an ERP, or when the volume makes a manual upload step absurd.
Vendor bills straight into spreadsheet rows.
Named fields from any invoice layout, no templates.
Turn a pile of receipts into a clean spreadsheet.
The same extracted fields as structured JSON.
Why FineReader converts pages but not fields.
What the IDP category includes, and which parts you need.
