DEV Community: Hao Zhang

Six parsing changes that made invoice extraction trustworthy

Hao Zhang — Sun, 01 Nov 2026 02:17:11 +0000

First version worked on my test invoice. Then a real accountant sent twelve.

It got the date on nine of them, the total on six, and the right total on four. The failures were not random — they clustered into six patterns, and fixing those six is what turned a demo into something I would let a bookkeeper use.

This is the second post in a series about DocExtract, where the PDF never leaves the browser. The first post covered the architecture and the walls; this one is about the specific parsing decisions.

1. Detect the text layer instead of assuming it

A PDF is a container. Some hold glyph positions; some hold a scanned JPEG. And the frustrating middle: a scanned page that still carries 20–40 characters of letterhead and a page number.

A naive check (if (textContent.items.length)) sends those to the text-layer parser, which then extracts a date and nothing else.

What worked was a character count per page with a threshold, plus a per-page decision instead of a per-document one:

const chars = items.reduce((n, it) => n + (it.str?.length || 0), 0);
const useTextLayer = chars > 120;

A 10-page PDF where page 1 is a cover letter and pages 2–10 are scans needs the decision per page, not per file.

2. Group rows with a tolerance, not equality

Text items arrive with x/y. A visual row is not a y value — the vendor name and the invoice number on "one line" were often 3 points apart.

const TOL = 6; // points ≈ 2mm at typical invoice scale
const rows = [];
for (const it of items.sort((a, b) => b.y - a.y)) {
  const row = rows.find(r => Math.abs(r.y - it.y) <= TOL);
  if (row) { row.items.push(it); row.y = (row.y + it.y) / 2; }
  else rows.push({ y: it.y, items: [it] });
}

Six points fixed the three-row-instead-of-one problem without merging genuinely distinct table rows. It is the single highest-leverage constant in the whole parser.

3. Treat money as a locale problem

parseFloat fails on half of Europe:

EUR 170,00      €170.00      170,00 €      1 234,56      CHF 1'234.50

The rule that finally worked: the last separator is the decimal one.

function parseMoney(token, fallbackCurrency) {
  const m = token.match(/(?:(EUR|USD|GBP|CHF|€|\$|£)\s*)?(\d[\d.,\s]*\d|\d)\s*(?:(EUR|USD|GBP|CHF|€|\$|£))?/i);
  if (!m) return null;
  const currency = m[1] || m[3] || fallbackCurrency;
  let raw = m[2].replace(/[\s']/g, '');
  const lastComma = raw.lastIndexOf(','), lastDot = raw.lastIndexOf('.');
  raw = (lastComma > lastDot)
    ? raw.replace(/\./g, '').replace(',', '.')
    : raw.replace(/,/g, '');
  const value = parseFloat(raw);
  return Number.isFinite(value) ? { value, currency } : null;
}

Note [\s'] — the Swiss apostrophe and the French thin space are both thousands separators, and both silently break every regex that only allows , and ..

4. Stop looking for "the number after the label"

The obvious strategy — find the word "Total", take the next number — fails constantly, because the number after "Total" is sometimes the VAT rate, sometimes the quantity column from the row above, sometimes a PO number.

What worked was: for each label, look at the same row, pick the right-most money-looking token on that row, and validate it:

const rowOf = (labelItem) => rows.find(r => r.items.includes(labelItem));
const candidates = rowOf(label).items
  .filter(it => it !== label)
  .map(it => parseMoney(it.str, defaultCurrency))
  .filter(Boolean);
const total = candidates.at(-1)?.value ?? null;

Right-most rather than left-most because in nearly every invoice layout the amount sits to the right of its label. If the row has no money token, return null — do not fall through to the next row. Falling through was how "PO-4471" became the invoice total on one file.

5. A rate is not an amount

This one cost me the most trust, because the wrong answer looks completely plausible:

VAT 20%          170,00

A regex for "VAT" grabs 20. The spreadsheet says VAT = 20, the accountant reconciles against 170, and now nothing else in the file is trustworthy either.

The fix is two lines — reject any token immediately followed by %, and reject bare integers in a VAT context unless they carry a decimal part:

const isRate = (tok) => /^\s*%/.test(tok.after) || tok.text.includes('%');
const looksLikeAmount = (tok) => /\d[.,]\d{2}\b/.test(tok.text);

Same trap with German MwSt. 19 %, and with 0.20 written as 0,20.

6. Prefer a blank cell to a confident wrong number

The last change was cultural rather than technical: every extracted field carries its source.

In the text-layer path, values are marked exact. In the OCR path, they are marked as OCR. Line items are only attempted when the text layer exists — reconstructing qty × unit price from a scanned table is where accuracy collapses, and a half-wrong line-item table is worse than an empty one, because someone will import it.

Concretely:

label not found → null, not a guess
label found but no money token on its row → null
OCR confidence below threshold on the amount → keep the number, flag the row

The output looks less impressive. It is also the reason a bookkeeper can trust the numbers that are there.

What still fails

Being specific about this is the point of the series:

Handwriting. Printed text only. A handwritten receipt returns noise.
Merged-cell headers. A two-level header (Description | Qty | Price above Item | Unit | Total) makes row grouping merge things a human would not.
Multi-page tables. A line-item table continuing on page 2 loses its header and the parser treats those rows as a fresh area.
Currency inference. If the invoice never states a currency and the locale is ambiguous, I return the amount without one rather than guessing.

The uncomfortable lesson

Every "improvement" I made past a certain point made the demo look better and the product worse: more fields extracted, more of them wrong. The six changes above are mostly about refusing to answer.

If you are building anything that turns documents into numbers: the field you leave blank is a feature.

DocExtract runs this parser entirely in the browser — sample invoices are on the site if you want to compare the digital path against the scanned one on your own machine. Free tier is 20 documents a month, no sign-up; paid packs are one-time, not a subscription.

Invoices to CSV, entirely in the browser: the five walls I hit

Hao Zhang — Sat, 31 Oct 2026 08:59:05 +0000

Some documents you are not allowed to upload.

If you are a bookkeeper, an accountant, or anyone handling another person's invoices, "just send it to a converter in the cloud" is not an option. The client did not consent to their purchase history sitting in someone's S3 bucket.

So I built it the other way around: the PDF never leaves the machine. No upload endpoint, no server-side OCR, no per-document API cost. Everything runs in the tab.

This is a write-up of what that constraint actually costs you, because most "OCR in the browser" posts stop at Tesseract.recognize() and never mention the five walls that come after it.

The architecture in one paragraph

pdf.js opens the file and hands back both the rendered page and, if it exists, the text layer with per-item coordinates. If the text layer has enough characters, I parse those items directly — no OCR, no guessing, ~200ms for a normal invoice. If it doesn't (a scan, a photo, a fax), I render the page to a canvas and run tesseract.js over it in a worker. Export is xlsx for spreadsheets or a plain CSV blob.

Two paths, one output shape. The rest of this post is about why the second path is 20x slower and why the first one lies to you.

Wall 1: "PDF" does not mean "text"

The first assumption I got wrong: every PDF has text.

It does not. A PDF is a container. Some contain glyph positions, some contain a single JPEG of a piece of paper, and some contain glyph positions that are correct but useless because the file was produced by an OCR pass in 2009 that mangled them.

You cannot trust the file. You have to measure it:

const page = await pdfDoc.getPage(1);
const content = await page.getTextContent();
const chars = content.items.reduce((n, it) => n + (it.str?.length || 0), 0);

// A real text-layer invoice runs to hundreds of characters per page.
// A scanned page often still has 10-40 characters: a header, a page number.
const useTextLayer = chars > 120;

That threshold matters more than it looks. Scanned invoices frequently carry a few characters — the letterhead, a footer — which is enough to make a naive check say "text layer exists" and then produce an invoice with a date and nothing else.

Wall 2: coordinates are not a table

The text layer gives you spans with x, y, width. It does not give you rows, columns, or cells. A table is something a human perceives, not something the format encodes.

The naive approach is to group spans that share a y. That works until the first invoice where the vendor name and the invoice number sit 3 points apart vertically:

ACME SUPPLIES LTD          y = 712.4
INV-2026-0417              y = 709.1     <- 3pt lower, same visual line
2026-10-14                 y = 712.6

Sort by exact y and you get three rows instead of one. Group with a tolerance instead:

const rowTolerance = 6; // points

function groupRows(items) {
  const rows = [];
  for (const it of items.sort((a, b) => b.y - a.y)) {   // PDF y grows upward
    const row = rows.find(r => Math.abs(r.y - it.y) <= rowTolerance);
    if (row) {
      row.items.push(it);
      row.y = (row.y * (row.items.length - 1) + it.y) / row.items.length;
    } else {
      rows.push({ y: it.y, items: [it] });
    }
  }
  return rows.map(r => r.items.sort((a, b) => a.x - b.x));
}

Six points is roughly 2mm at typical invoice scale. Big enough to merge the three spans above, small enough not to merge two genuine table rows.

Wall 3: money is not a number

Then you try to pull the total out of the text and discover that "the number after the word Total" is a lie in most of Europe.

Total          EUR 170,00
Total          €170.00
Total          170,00 €
Summe          170,00 EUR

parseFloat handles none of these. What worked was a tokenizer that accepts a currency symbol or code on either side of the amount, normalises the separators, and is explicit about what it rejects:

const MONEY = /(?:(EUR|USD|GBP|CHF|€|\$|£)\s*)?(-?\d{1,3}(?:[.,\s]\d{3})*(?:[.,]\d{2})?)\s*(?:(EUR|USD|GBP|CHF|€|\$|£))?/i;

function parseMoney(token, defaultCurrency) {
  const m = token.match(MONEY);
  if (!m) return null;
  const currency = m[1] || m[3] || defaultCurrency;
  let raw = m[2].replace(/\s/g, '');

  // "1.234,56" (EU) vs "1,234.56" (US) — the last separator is the decimal one
  const lastComma = raw.lastIndexOf(',');
  const lastDot = raw.lastIndexOf('.');
  if (lastComma > lastDot) {
    raw = raw.replace(/\./g, '').replace(',', '.');
  } else {
    raw = raw.replace(/,/g, '');
  }
  return { value: parseFloat(raw), currency };
}

Note the whitespace class in the amount: 1 234,56 (thin space as thousands separator) is common in French and German invoices and silently breaks every regex that only allows , and ..

Wall 4: the VAT rate looks exactly like the VAT amount

You ask for "VAT" and the invoice gives you this:

VAT 20%          170,00

A regex looking for the number after "VAT" returns 20 — the rate, not the amount. That is the kind of bug that produces a spreadsheet that is plausible, wrong, and only caught months later during a reconciliation.

The fix is a one-line rule that took me an embarrassing amount of time to write:

// A number immediately followed by % is a rate. Never treat it as money.
const isRate = tok => /^\s*%/.test(tok.after) || tok.text.includes('%');

Same trap with 19, 7, 0.20 and MwSt. 19 % in German files.

Wall 5: memory, workers, and the tab that dies

Digital PDFs are cheap. A 20-page scan is not.

Each page at 300 DPI is a ~2500x3500 canvas — about 35 MB as RGBA. Ten of those cached at once will kill a mobile tab. Three things fixed it:

tesseract.js in a worker, never on the main thread, so the UI does not freeze
render one page at a time and canvas.width = 0 immediately after getImageData, instead of keeping pages around
cap the working resolution (230–300 DPI is the sweet spot; 600 DPI doubles runtime for no accuracy gain on printed invoices)

Real numbers from my own runs:

Document	Path	Time
Digital invoice, 1 page	text layer	under 1s
Scanned invoice, 1 page	OCR, 300 DPI	3–5s
Scanned statement, 20 pages	OCR, one page at a time	60–90s, ~250 MB peak

What it does not do

Worth stating plainly, because a tool that oversells itself is worse than one with a narrow claim:

Handwriting fails. Printed text only. A handwritten receipt returns noise, and you should not trust it.
Line items need a text layer. OCR gives you totals reliably; reconstructing qty × unit price from a scanned table is where accuracy falls off a cliff. I extract line items from digital PDFs and tell you when I cannot.
Merged-cell tables need manual fixing. If the invoice has a two-level header, the row grouping will merge things a human would not.
OCR is not deterministic across languages. English plus one other language works; genuine mixed-script documents do not.

That is the honest boundary. Inside it, the result is exact — it is not interpreted by a model, it is parsed.

What I would do differently

Measure the text layer before promising anything. Most "it worked in testing" failures were scanned files that quietly had 30 characters.
Treat money as a locale problem from day one, not as a parseFloat problem. The European formats are not edge cases, they are half the market.
Say no out loud. Every feature I added past the honest boundary made the product look better and work worse.

If you want to poke at it, it is at receipt2csv.com — there are sample invoices on the page (a digital one and a scanned one) so you can compare the two paths without uploading anything, which is rather the point.

Free tier is 20 documents a month, no sign-up. The paid packs are one-time, not a subscription — because charging a bookkeeper monthly for a tool they use in January and then again in April never sat right with me.

Happy to answer anything about the parsing internals, the coordinate maths, or the parts I gave up on.