The .pdf file.
A PDF does not contain a table. It contains characters at coordinates, and the table is something you and the extractor both infer.
What it actually is
PDF is a page description language. It records that a glyph appears at a position in a font at a size. Where you see a column, the file holds a set of numbers that happen to share an x coordinate; where you see a row, a set that happen to share a y coordinate. The grid exists in your head.
This is why extraction quality varies so much between documents that look equally tidy. A generator that emits cells left to right in reading order produces something almost trivially reconstructible. One that emits a whole column at a time, or that draws the rules as separate vector paths, does not.
Then there is the second kind of PDF entirely: a scan. That file has no text at all, only an image of one, and every figure has to be read visually. Selling both as "supported" without distinguishing them is how a product ends up quietly wrong about a number.
At a glance
- What it stores
- Glyphs at coordinates, not cells
- Two kinds
- Native, with a text layer, and scanned, which is an image
- Table structure
- Not stored. Inferred from geometry.
- Read here as
- Extracted for native PDFs, interpreted for scans
- Checked against
- Subtotals printed in the document itself
- Lost on the way in
- Payment references and long identifiers truncated by the layout
- Status
- Ready
- Fidelity
- Data extracted
- Largest file
- 250 MB
Checked for a text layer first. A PDF written by software keeps its table structure; a scan is read as an image and told apart from the first kind.
A scanned PDF is read by eye, so it lands in the interpreted tier and is checked against its own totals.
Upload one
The analysis runs before there is anything to pay for. You see what it found, and the evidence behind it, first.
No account needed to start. You only pay when you like what you see.
What goes wrong, and what is done about it
01
A table split across a page break
The header repeats at the top of each page, the last row of one page and the first of the next are often halves of the same record, and a naive extraction produces one table per page with a header row buried in the middle of the data.
Tables are stitched back into one, repeated headers are removed, and a row broken across the boundary is rejoined rather than left as two half rows.
02
Numbers that reconcile to nothing
A misread minus sign, a thousands separator taken as a decimal point, or a column that lost its rightmost digit to a clipped bounding box all produce a spreadsheet that looks perfectly clean and does not add up.
Where the document prints a subtotal, the extracted rows are summed and compared against it. A column that does not reconcile is flagged on the page it came from rather than shipped looking clean.
03
A scan that looks native
Many scanners run OCR and embed the result as an invisible text layer. The file then reports that it has text, and the text is whatever the OCR thought it saw, with none of the confidence information that would let you distrust it.
The text layer is checked for the signatures of machine reading rather than trusted because it exists. A document identified this way is treated as interpreted and re-derived against its own totals.
If you have the choice, send something else
If the system that produced the PDF can also export CSV, XLSX or OFX, use that. A PDF has already thrown away the fields that were not printed — a bank statement PDF, for example, no longer has the payment reference that invoice matching runs on.
Questions people ask
Will it work on a scanned document?
Yes, and less well, which it tells you. A native PDF extracts close to exactly. A scan is read visually, lands in the interpreted tier, and every figure is re-derived against the totals printed in the same image before it is shown.
What happens to figures it cannot read?
They are listed as unreadable with their page number. Nothing is guessed to fill a gap, because a plausible invented figure is worse than an obvious hole.
Can it do a hundred monthly reports at once?
Zip them and upload the archive. The structure worked out on the first is reused across the rest, so the hundredth costs far less than the first.