DEV Community: Barry Mooring

My CSV parser put £917,785 of VAT on a £2,442 invoice

Barry Mooring — Thu, 24 Sep 2026 19:41:44 +0000

The invoice came to £2,442. The VAT line said £917,785.

Nothing had crashed and nothing had logged an error. Every step of the code had done exactly what it was designed to do. The template wanted a VAT rate, the spreadsheet had no column called that, and my column matcher chose the best candidate it could find: a column of unit prices. It multiplied, and produced a neat, well-formatted PDF that would have been sent to somebody's customer.

That's the kind of bug this post is about. Parsing a spreadsheet is the easy part. The hard part is that when it goes wrong, the parser doesn't fail. It succeeds, and a wrong number ends up in a document that looks fine.

What I'm building

BroadPaper Cloud turns a spreadsheet into branded PDFs: a monthly client report, an invoice, or forty statements at once. The user uploads a file, picks a design and downloads the result. Nobody checks row 37 of the output, so row 37 has to be right.

Here's what went wrong on the way, and the rules that came out of it.

1. A close second is still a question, however high it scores

The VAT bug came from fuzzy matching. Each spreadsheet column gets a score against each field in the template, and if the best score is high enough, the matcher goes ahead without asking.

The problem was that several money columns scored almost the same. When three candidates are within a hair of each other, picking one without asking for confirmation is a guess.

The fix: confidence depends on how far the winner is ahead, not just on its score. If the best match leads the runner-up by less than 0.15, the user is asked, however well the best one scored.

The second fix was that no choice is ever locked in. Every match keeps its runners-up, so a wrong choice can be changed later. A choice saved last month that doesn't fit this month's file carries a warning.

I then over cooked it, and the screen started asking about everything, even for a spreadsheet whose headings matched the template's field names exactly. That's a failure too. People who are asked ten questions stop reading them, which is worse than never being asked. The question has to be saved for a genuine tie.

2. `INV-10241` is not −10241

My first number parser removed everything that wasn't part of a number, so it could handle £1,234.56 and 1,234 USD. It also turned INV-10241 into -10241.

The whole column was then typed as negative integers and printed, right-aligned, under the heading "Invoice number".

The rule now is that a currency symbol or a currency code is decoration. Any other letter means the value isn't a number.

Digits alone aren't proof either:

// `0044` is a code, and a number would lose the zeros in the document.
// `07700 900123` parses once the space goes, and prints as 7700900123.
const leadingZeros = strings.some((s) => /^0\d[\d ]*$/.test(s));

Headings help, with care. "VAT" on its own is money. "VAT number" is a registration number that has to print exactly as it was written.

3. The date that changed month halfway down a column

Invoice date
03/04/2026
15/04/2026
28/04/2026

If you parse each cell on its own with a flexible date parser, the first row can come out as 4 March and the others as April. Every value parses and the result looks plausible, but one date is a month out.

So a column's type is decided once, by a vote across every value in it. It's only a date column if one date format explains at least 95% of the values. Then every row is read the same way. The 15/04 in row two proves the whole column is day-first. If no value goes above 12, the column really is ambiguous, and the user is asked.

Once the question is settled, the dates are converted to ISO format (2026-04-03) on the way in. Nothing later in the pipeline gets a chance to decide differently.

4. `12,5` became 125

The next version of the parser removed commas so that 1,234 would parse. But in much of Europe, 12,5 means twelve and a half. It became 125: ten times too large, in a money column, with nothing on screen to show it.

A comma now counts as a thousands separator only between groups of three digits:

"1,234"      // 1234
"£1,234.56"  // 1234.56
"12,5"       // not a number
"1.234,56"   // not a number

The last two could be handled with a locale setting. I decided not to guess. A column that can't be read with confidence comes in as text, and a comment in the parser explains why:

// Text is the only type that cannot make a document wrong.

A column wrongly typed as a number prints a wrong figure. A column left as text prints exactly what the person typed. The worst that can happen is that the user has to tell you it's money.

The pattern

Every one of these bugs had the same cause: a guess at the data type or format, which nothing downstream could see. The fixes all follow from that:

Decide each column's type once, across every value, never cell by cell.
When the evidence is weak, fall back to the type that can't print a wrong figure, which is text.
When two answers are close, ask the user, and ask only then.
Keep every automatic decision reversible.

One architecture decision made all this easier: files are parsed in the user's browser, in a Web Worker, and the server only ever receives typed JSON. The server has no workbook parser, so there's no zip bomb or XML exploit to worry about. It still checks every value against its column's type, because a client that can send JSON can send anything.

When you don't need any of this

If your data comes from your own database, it already has types, so use them. This is for data a person typed into a spreadsheet, which is still where most small businesses keep their numbers.

Try it

The free document pages let you fill in and download a single invoice, receipt or delivery note without an account:
broadpaper.com/templates.
BroadPaper Cloud does the same for a whole spreadsheet:
broadpaper.com.

What's the worst thing a spreadsheet has done to your code? I'm fairly sure I haven't found them all ..... yet

The page break you see is a guess: what I learned building an embeddable report designer

Barry Mooring — Tue, 22 Sep 2026 13:41:47 +0000

Sooner or later, every serious business application needs to produce documents for its customers: statements, client reviews, factsheets, invoices, certificates. Then someone asks whether customers can design their own. That's usually when a team starts building a report designer, under deadline pressure and without really meaning to.

After twenty years of building business software, I decided to build the one I kept wishing existed, and to do it properly. It's called BroadPaper. It's an embeddable report designer for React and Angular apps. You declare the data, your users design the document, and you get a print-ready PDF out the other side.

This article isn't really a product pitch. It's about the problems that turned out to be much harder than they looked, because if you've ever shipped document generation, you've probably met some of them.

What you see is not what prints
Here's the problem at the centre of all of this. Browsers paginate for print in their own way, largely invisibly. PDF libraries paginate in another way. So the page break your user sees in a designer preview is really a guess about where the break will fall in the final file.

Most of the time the guess is close enough. Then a client's portfolio has three more holdings than the sample data, a table spills onto a new page, its header doesn't repeat, and a document goes out looking broken. "It looked fine in the preview" is one of the most expensive sentences in document generation.

So the first decision was the biggest one: neither the browser nor the PDF engine gets to decide where a page breaks. BroadPaper does.

It works like this. Each section of a document is measured once, as one continuous galley: an infinitely tall strip, the way typesetters used to work. A pure function, the paginator, then cuts that galley into clip windows and assigns them to pages. It handles keep-together rules, orphans and widows, repeated table headers, and running headers with page numbers. Both the on-screen canvas and the PDF engine are handed pages that have already been decided. Neither of them does any pagination of its own.

If the preview and the PDF measure with the same engine and the same embedded font files, a break on screen is a break in the file. There's a test that lays out the same document in real Chromium and in the engine, and fails if any section drifts by more than 12 pixels.

Bugs that don't crash are the dangerous ones
The engine I build on, Forme, is an open-source (MIT) PDF renderer written in Rust and compiled to WebAssembly. It's excellent, but like any renderer it has its own ideas. One of them was that anything taller than a page gets clipped, silently.

A clip path was hiding a hundred-row table's missing rows. Worse, every neighbouring page's text was still in each page's content stream, so text extraction (and anything downstream of it, like screen readers or search indexing) read the whole table on every page. The PDF looked fine but wasn't.

The fix was to crop each section to exactly the window its page shows. A table that has been cut now reports how many rows it dropped above the window, so everything below it can shift up.

The same thing happened at scale. The measuring surface is 200,000 points tall, and a table passes that at around ten thousand rows. Past that, the output was a one-page PDF with no warning at all. Tables over 1,000 rows are now measured in batches and joined back together. That's exact rather than approximate, because a row's height never depends on its neighbours.

The lesson I keep relearning: in document generation, a crash is the good outcome. The bad outcome is a plausible-looking document that's wrong.

Blocks, not a canvas
A lot of report designers give users a free-form canvas: drag anything anywhere, pixel by pixel. It demos beautifully. In production, headings end up three pixels off the grid, tables overlap footers, and every new data shape breaks the layout.

BroadPaper uses a structured document model instead: page, section, row, column, block. Users still drag and drop, bind fields, set conditions and choose a brand. But because the structure is a tree rather than a sheet of coordinates, the output is predictable. A table always knows which column it's in, and a user can't break the grid even when they try.

That structure is also what makes custom blocks first-class. You give a block a declarative inspector and a pure render function, and it drags, binds, themes and prints exactly like the built-in ones.

No eval, ever
Documents need calculations, like sum(lines.amount) * (1 + taxRate). The shortcut is to hand that string to JavaScript's eval and hope. In a product where end users author templates, that's a security incident waiting to happen.

So expressions go through a hand-written tokeniser, a Pratt parser and a tree-walking interpreter, and they're type-checked against the host application's schemas. The designer can autocomplete fields, and it catches a typo before it ever reaches a document. Business users never see the syntax at all: they build calculations by picking steps.

The template is the contract
When a user saves a design, you get back plain JSON that you store wherever you like. Nothing in it depends on a browser. That turned out to be the most useful property in the whole system.

The report a user designs on Monday can run as a nightly batch on Tuesday and sit behind an API endpoint on Wednesday: same template, same paginator, same engine, and the page breaks don't move. It renders in the browser tab, in Node, or behind a small HTTP render service. There's also a .NET client for .NET 8 and 10, so a C# back end can produce the same PDFs without a JavaScript runtime or a native PDF library on the box.

There's no headless Chrome anywhere. The engine is about 7 MB of WebAssembly, loaded only by pages that actually render a PDF, so there's no browser to install, patch and keep alive on every server.

The SDK also makes no network calls of its own. Your schemas go in, JSON comes out, and your customers' data never leaves your application.

When you shouldn't use it
If your developers write every document in code, react-pdf is great and free. If you already have HTML that prints acceptably, Puppeteer may be all you need. BroadPaper is for the situation where your users need to design documents, and those documents have to come out right every time. I've written some comparisons, including when BroadPaper is the wrong choice, at broadpaper.com/developers/compare.

Try it
The demo runs entirely in your browser, with no account and nothing uploaded. It includes a finished report, a blank page, three brands, a custom block, and a PDF rendered in your own tab.

There's also a public sample application on GitHub, with React and Angular front ends and a .NET back end. It installs the published packages the way you would, rather than from inside a monorepo, which is the part that proves the integration really is as small as I claim: github.com/codingbadger/broadpaper-sample-application

BroadPaper is early, and I'd really value hearing from developers who've been through this. Where would the designer's model break down for the documents your app needs to produce?

Demo and docs: broadpaper.com/developers