I built a PDF table checker that verifies arithmetic in any PDF without a template

Thanks Bhavin — yes, the sub-pixel jitter is the quiet tax you only discover by looking at raw coordinates from pdfjs-dist. My first pass without the snap produced column anchors that fractured into three distinct x-positions for what should be a single column, and the totals never matched anything. The 4px threshold came from inspecting a few actual financial PDFs — most generators stay within 2-3px of their intended grid, so 4px catches the drift without merging genuinely separate columns.

Thanks Frank! pdfjs-dist handles the extraction — it returns a stream of text items, each with string value, x/y position, and width, with no table semantics at all. The column anchor detection does the structural work: I collect all x-positions where numeric strings appear, and any x-cluster that shows up in two or more consecutive rows becomes a verifiable column. Everything else — which rows are totals, what to sum — is keyword matching and arithmetic on top of those anchors.

Really like the coordinate-based approach. I've worked with PDF parsing before, and the y-position snapping trick solves a lot of those tiny alignment issues that usually break row detection.

This is brilliant! How do you handle the actual text/number extraction from the PDF without relying on

Good problem to pick. By the time a reconciliation breaks in a spreadsheet you've usually lost the trail back to page 8, so catching it at the source is worth a lot. Template-free is the hard version of it too.

A few things I've run into with tabular financial PDFs that might break it:

Right-aligned columns vs left-edge anchoring. Numeric columns in reports are nearly always right-aligned, so the left x of a column moves depending on how wide the number is. 1,847,332.10 and 12.40 can land as two different anchors even though they're the same column. If you're clustering on transform[4], try clustering numeric items on x + width instead. The right edge is the stable one. This one is mean because uniform test data hides it, and it shows up on exactly the row you care about: a wide grand total sitting under narrow line items.

pdf.js splits numbers across text items. Depending on kerning and glyph runs you can get 1, then 234 then .56 as three separate items on the same row. Worth merging adjacent same-row items when the horizontal gap is under a space width, before anything tries to parse a number out of them.

Accounting number formats. (1,234.56) means negative. Drop that sign and a correct table gets reported as broken, which is about the worst way for a checker to fail. Same deal with trailing minus (1,234.56-), CR/DR suffixes out of SAP exports, a bare dash or n/a or nil standing in for zero, and EU decimal comma (1.234,56).

Nested subtotals. On a P&L or a balance sheet, summing back to the previous total row will under-count. A grand total covers the section subtotals above it, not just the rows since the last one. You've already got what you need to fix this: indent depth on the label column gives you the hierarchy, so you can sum siblings at the same level only.

Ratio columns. A "% margin" or "% of revenue" column has a total that's a weighted average, so checking it additively throws false positives. Rough heuristic: if the stated total is close to 100, or close to the weighted mean of the rows, skip the column.

Tolerance near zero. A purely relative 0.1% tolerance goes to zero when the total does, so a subtotal that legitimately nets to 0.00 will flag on float noise alone. Integer cents plus an absolute floor (a couple of cents per row summed) covers that, and also covers display rounding, where each row is rounded on its own and the stated total isn't.

Bookmarked. I've got a few statements I'll run through it this week, will come back if I find a layout that trips it.

@hannune The Korean currency-symbol-as-separate-span case is a good one because it breaks the naive x-gap merge from the other direction — the symbol is a legitimate separate span you want to keep separate, sitting at exactly the tight gap you're using to merge decimal fragments. So the gap threshold alone can't disambiguate. The thing that saved me elsewhere was to stop treating it as pure geometry and add a tiny grammar: a fragment is only a decimal continuation if it looks like one (leading dot or two digits after you've already seen a group separator), and the currency glyph gets classified out before clustering rather than merged in. Slower, but the false merges go away.

On the page-boundary case bypassing your reassembly pass — that's the real trap, because your merge is row-local and the failure is that the row set itself is wrong. I don't think you fix that inside the number layer at all; the window reset is a structural assumption in the row grouper, and no amount of fragment cleanup downstream will undo it. You have to make the total-row search page-aware: carry the "rows since last total" state across the page break instead of resetting at the edge, and treat repeated column headers as continuation markers rather than fresh sections.

Row-count-based tolerance is a smart calibration and honestly better than a flat 0.1% — but be clear-eyed that it's still bounding the error you expect, not the one that actually happens. The unrounded-source case isn't a function of row count; a two-row column can be off by a full cent if both were rounded the same direction. If the source ever gives you unrounded figures anywhere — a footnote, a machine-readable attachment, anything — reconciling against those instead of guessing a threshold is the only thing I've seen actually close it. Absent that, I don't have a clean answer, and I'd rather flag "can't verify rounding basis" than assert a pass.

The failure mode that'll bite you isn't rotated text or spanning cells — it's that the number you extract and the number a human reads aren't the same value. PDFs routinely display "1,234.50" while the underlying text stream, depending on how the producer laid it out, gives you "1,234" and ".50" as two separate text items at adjacent x-positions, or negatives shown as "(1,234)" or with a trailing minus. Your y-clustering will happily merge or split those, and your sum will be wrong by a decimal shift — the worst kind of wrong, because it's plausible. A subtotal that's off by exactly 100x doesn't look like a parsing bug, it looks like the report is broken, and now you've flagged a false positive on someone's audited financials.

The other one: displayed values are rounded, but the true subtotal is computed on unrounded figures. A column of 33.333, 33.333, 33.334 displays as three 33.33s summing to 99.99, but the stated total is 100.00. Your 0.1% tolerance saves you here for large numbers and burns you for small ones — 0.01 on a 3.00 total is well over 0.1%. Rounding reconciliation is a genuinely hard, domain-specific problem, and "sum the displayed cells" quietly assumes it away.

If you want to know what breaks it, feed it a report where a total row spans a page boundary — the "back to the previous header or total" window resets at the page edge and you'll silently sum half the rows.