Built by Avyth · self-initiated, not client work
Split one merged invoice PDF into separate named files
Accounting systems and scanners hand you one PDF containing dozens of invoices. Filing them means finding where each invoice starts, splitting there, and naming the result by invoice number — a job that is mechanical, slow, and easy to get subtly wrong.
The real interface, with fictional demo data.
The approach
The whole thing runs in the browser. The file is read on the visitor's own machine and never uploaded, which removes the awkward conversation about where a company's invoices are being sent. It reads each page's text, finds invoice-number boundaries, proposes a split, and shows it for review before anything is written.
Decisions
And what each one cost.
Show the proposed split before producing anything
The obvious design is: choose file, get ZIP. The problem is that a wrong boundary is invisible until you open the files. So the tool always shows the page ranges and filenames it intends to use, and you confirm. It is one extra click and it is the difference between a tool you can trust and one you have to check afterwards.
Refuse to guess when the text isn't there
A scanned page has no text layer. Rather than silently folding it into the previous invoice — which produces a confident, wrong answer — the tool names the page and warns that boundaries can't be verified there. Above a threshold it blocks the split entirely.
Position-aware text extraction
Joining PDF text runs naively truncates numbers that span two runs: 'Invoice No. 102' + '31' becomes '102', and the file gets the wrong name. Boundaries are computed from run positions, gaps and line breaks instead.
What it can't do
Splitting on invoice numbers needs a text-based PDF. A scan has no text to read, and no amount of interface design fixes that — so the tool says so rather than pretending. Batches with a fixed number of pages per invoice can use a page-count mode that works on scans.
How it was checked
Tested against generated fixtures covering the cases that matter: a clean multi-invoice file, a file whose middle page has no text layer, a 600-page file that must be refused at the cap, a 400-page dense file, and a non-PDF. The no-text case is the important one — it is the failure that would otherwise look like success.
Live flow last exercised .
Something like this, for your work?
If you have a job that looks like this one — mechanical, repetitive, and currently done by a person — describe it and I'll tell you whether it's worth building.