What 87 Real Invoices Actually Contain: A Field-by-Field Study
Published 22 September 2026. Where other products are mentioned we describe the kind of product and its pricing model, not figures, which change.
Most advice about invoice spreadsheets assumes every invoice carries the same fields. It does not. We took 87 publicly published invoices, transcribed all 91 invoices and 221 line items inside them field by field against the original page, and counted what is actually printed. The short version: build a column for every field you expect and roughly half of them will be empty.
The headline numbers
Across 87 documents (135 pages) containing 91 invoices and 221 line items, this is how often each invoice-level field was actually printed on the page:
| Field | Printed | Share of 91 invoices |
|---|---|---|
| Total | 90 | 99% |
| Currency | 90 | 99% |
| Supplier | 89 | 98% |
| Invoice number | 88 | 97% |
| Subtotal | 84 | 92% |
| Invoice date | 82 | 90% |
| Tax / VAT amount | 78 | 86% |
| Tax / VAT rate | 49 | 54% |
| Due date | 36 | 40% |
Three findings that will break a naive spreadsheet
1. Due dates mostly do not exist. Only 36 of 91 invoices printed one. A payment-tracking sheet keyed on due date will be 60% empty, and the usual workaround — assume 30 days — is an invention, not data.
2. A VAT amount is far more common than a VAT rate. 78 invoices printed the tax amount but only 49 printed the rate. If you need the rate, derive it from tax ÷ subtotal and expect rounding noise, rather than expecting a column to read.
3. One in ten invoices has no unambiguous date. Five printed no invoice date at all, and on four more the date was genuinely ambiguous — several dates on the page with nothing marking which was the invoice date. Sorting a spend report by date silently misplaces those rows.
The line-item trap nobody warns you about
Line items are less consistent than invoice headers, and one difference matters more than the rest — whether a row total already includes tax:
| Line-item field | Printed | Share of 221 rows |
|---|---|---|
| Description | 221 | 100% |
| Row total | 212 | 96% |
| Quantity | 156 | 71% |
| Unit price | 151 | 68% |
| Row tax rate | 60 | 27% |
| Row tax amount | 48 | 22% |
Of the 221 rows, 173 had totals excluding tax, 26 had totals including tax, and on 22 it could not be determined from the page. So roughly one row in eight is VAT-inclusive while most are not. Sum a mixed column expecting net figures and the total is overstated — and nothing in the spreadsheet tells you it happened. This is why a line-item table needs a basis column, not just an amount.
Documents are not invoices
Four of the 87 documents contained more than one invoice, so a one-file-one-row import would have lost data. Twenty-two were multi-page. And two were not invoices at all — a gas-usage spreadsheet and a blank bilingual template — despite sitting in folders of invoices. Any bulk process needs to handle "this file is not an invoice" as a normal outcome rather than an error.
How we did it, and what this does not prove
The documents are invoices published openly: open-source document-processing test sets and invoices disclosed in UK public-sector freedom-of-information responses. Each was transcribed field by field from the rendered original and then reviewed in a second field-by-field pass, recording for every field whether it was printed, absent or ambiguous. Line-item rows were annotated the same way, including whether the row total was inclusive or exclusive of tax.
The limits are real and worth stating. Ninety-one invoices is a small sample. It is not a random sample of UK invoices — it is skewed towards public-sector suppliers and towards documents that sample sets chose to include. Transcription and review were done by AI agents against the original page rather than by independent human coders, so the field counts should be read as careful transcription, not audited ground truth. The counts above are recomputed from the annotation files by an automated test, so they cannot drift out of date with the data behind them.
What to do with this
- Treat due date and VAT rate as optional columns, not required ones.
- Store a tax basis alongside every line-item total, or you will sum inclusive and exclusive rows together.
- Let a row exist with a missing date rather than guessing one, and flag it for review.
- Expect a small share of files to contain several invoices, or none.
How many invoices print a due date?
In this sample, 36 of 91 — about 40%. Most invoices state payment terms in words, or nothing at all, rather than printing a dated field.
Do invoices always show the VAT rate?
No. 86% printed a tax amount but only 54% printed the rate. Where you need the rate and it is absent, derive it from the tax amount and subtotal and allow for rounding.
Are invoice line-item totals inclusive or exclusive of VAT?
Both, in the same corpus: 173 of 221 rows were exclusive, 26 inclusive, and 22 could not be determined from the page. That is why a line-item export should record the basis rather than assume one.
Can I see the underlying data?
The documents are all publicly published, and each annotation records the source and the location on the page that each value came from. The figures in this article are recomputed from those annotation files by an automated test.
7 days · 200 documents · No card needed
The full 14-tool comparison table · More guides · What Invoices to Spreadsheets is · Invoice to Excel