The document was a Swiss construction tender. Yours is more likely a month-end pack, a supplier price list, or the same report rebuilt four ways for four people. The document changes. The job does not.
LV2XL is the system I built for that document. It is live, it takes payments, and it started as one client’s problem. This page is that build in detail, and then the part of it that has nothing to do with construction.
Nobody does this for fun. The spreadsheet is where the work happens. The PDF is only how the work arrives.
Every line has to exist as a row: position, description, quantity, unit. The PDF will not hand you that. So a person reads the page and types, and then does it again for the next document.
The document mixes billable lines with structural and specification lines that look nearly identical on the page. Pull the wrong ones in and the total is wrong in a way that looks fine.
It returns something clean looking and confidently wrong. A clean looking sheet with wrong numbers in it is worse than no sheet, because now nobody checks it.
The second number is the product. The first one is the job, and what it is made of is what decides whether any job is worth a system at all.
By hand
20:00:00
By machine
00:00:40
The whole bar is 20:00:00
The mark at its left end is 00:00:40
Every line the system returns carries five values: page, position, text, quantity, unit. On a priced document, two more. A person doing this by hand makes that many transcriptions per line, decides first whether the line is billable at all, and holds the document’s structure in their head throughout.
Then the total gets checked. When the sheet does not match the printed total, the work is not noticing the difference. The work is finding the line.
Manual data entry runs a documented error rate of 1 to 4 percent per field. Against five fields times a few hundred lines, the useful question stops being whether there are wrong cells in the sheet. And then the next document arrives.
Twenty hours: the estimating team’s own figure for this document. Forty seconds: the system’s current run time on lv2xl.ch, after an upgrade. Error rate: Conexiom data-entry benchmarks. Sources in the claim ledger, and I will send them if you ask.
The rest of the page is. But a job like this only becomes automatable if somebody learns the document properly first, so here is the document, in its own language, once.
An NPK-Bau Leistungsverzeichnis is the standardised description of works a Swiss construction project goes out to tender with, built on norm SN 506 511. A hundred pages or more, and it is the document a contractor prices, wins on, and is measured against afterwards.
It is standardised, which is the only reason it can be automated at all. It is also standardised in a way that defeats copy and paste.
You cannot check any of that, and you should not have to.
What is worth taking from it is the shape. The difficulty was never the PDF. It was that being wrong stays invisible until somebody else finds it.
Four tests, run before anything is quoted, on your process exactly as much as on this one. They are also why plenty of work that looks automatable is not.
It repeats, on a trigger you can name.
Every project that goes out to tender. Same document, next job.
The work arrives in the same shape every time, even when that shape is messy.
Standardised on a published norm. Messy, but messy the same way every time.
Somebody can say what a correct result is.
The priced document prints its own total. The extraction sums to it, or it does not.
A mistake is expensive, and it surfaces long after somebody made it.
A wrong quantity travels into a bid and gets found by somebody else, later.
Each one is a decision about what to do when the document is ambiguous. That is the entire product.
A pattern scan counts the positions without a single AI call, so the size of the job is known before anything is committed to it. The server enforces that count rather than trusting the browser.
Nothing runs on a document you have not agreed to process.
The PDF is split into blocks that deliberately overlap, so a position broken across a page boundary is still seen whole by at least one of them.
Duplicates created by the overlap are merged. Units written as a reference are resolved by reading back through the text above them. Swiss number formats are normalised. Anything that still cannot be resolved is flagged for a human rather than filled in with a plausible value.
This is the step a generic extractor does not have.
Page, position, text, quantity, unit. On a priced document, unit price and amount as well, so the sheet carries a total that can be checked against the total printed in the document, which the system was never given.
The output can be checked without trusting me, the model, or the vendor.
One repeating document, a person retyping it, and a definition of correct that nobody checks until later. Here is where it usually lives.
6+ days to close the month, for half of finance teams
The same reports out of the ledger, into the same workbook, refreshed, then into the same slide template so the same variances can be reported out. Every month, on a fixed deadline, with one person carrying it.
One set of numbers, reformatted for each person who wants it their way, then reconciled so the versions still agree. The reconciliation becomes its own recurring deliverable, on top of the report it was meant to check.
7 hrs a week in PowerPoint, 37 percent of it formatting
Building the charts, hunting for the current template, converting last quarter’s deck into this quarter’s design. The work is real, and almost none of it is the thinking.
A price list, a carrier rate sheet, a statement, a schedule. It arrives as a PDF, gets retyped line by line, and when a new version is issued it gets retyped from the top. The tender job with different vocabulary, in your office.
Sources: Ledge month-end close benchmarks 2025, via CFO.com, 100 respondents · the empower PowerPoint study, May 2020, 1,102 respondents in Germany and the US. Both are published by vendors who sell into the problem they measured. In the claim ledger, and I will send them if you ask.
What the call is for
Bring one process that annoys you and we will run the four tests against it out loud. By the end you will know whether it is worth automating and whether I am the right person to build it.
What is in the fifteen minutes
No deck, and no proposal inside the call.