An Invoice Is a Legal Document, Not a Receipt for a Calculation

There is a habit of mind that comes from evaluating accounting software, and it is hard to see from the inside: you judge an invoice by its total. Does the tax calculate correctly, does the subtotal add up, does the document reconcile. All reasonable questions, and all of them are questions about arithmetic. They are the wrong questions in the Netherlands, and the reason is not that Dutch arithmetic is unusual. It is that on the invoice a Dutch business most often issues, there is no arithmetic to get wrong.

A supply of goods or services to a VAT-registered business in another member state carries no VAT. The seller charges nothing; the buyer accounts for the tax in their own country. The line is nil, the tax box is nil, and the total equals the subtotal. Any system on earth can produce that document. What almost no system is asked about during a demo is the thing that makes it a lawful document rather than merely a correct one.

Why this lands harder here than almost anywhere

Every country in the European Union has these rules and most of them get a version of this problem. The reason the Netherlands is where it bites is commercial rather than legal: this is a small, open, re-exporting economy, and a mid-sized Dutch company's customer list is disproportionately in other member states. The cross-border invoice is not the awkward edge case here. It is most of the ledger.

That changes what kind of defect this is. A gap that affects two invoices a year is a nuisance you work around. A gap that affects the majority of your outgoing documents is a property of your system, and it is worth finding out about before you buy rather than in month three of an implementation.

What the document has to say, in plain terms

Strip away the legal drafting and a cross-border invoice is being asked to answer three questions that a total cannot answer.

• Who exactly is the buyer? Not a trading name — a VAT identification number, which is the only identifier that ties the document to a registered business in a specific member state. Their address as well, which is an ordinary invoice particular that the cross-border case makes load-bearing.
• Why is there no tax on this? Stated in words on the document. "btw verlegd", or "VAT reverse-charged" — a sentence saying the obligation has moved to the recipient, so that a reader can tell this apart from a sale that was simply exempt.
• Who are you? Your own VAT identification number, so the same tie exists on the other side of the transaction.

None of the three is a calculation. All three are particulars printed on a page, and every one of them is a thing a system either puts there or does not. There is no partial credit and no clever workaround — either the buyer's number is on the invoice or it is not.

What our own product does, stated exactly

We will use ourselves as the worked example, because it is the only schema we can actually open up for you and because a post on this subject that only criticised other vendors would be worth nothing. The table below is a fact about our invoice template on 5 August 2026, and every row of it is checkable in ten minutes: raise an invoice, download the PDF, look for the field.

Read the middle column before the right one, because it is the surprising half. This is not a case of missing data. Somebody filled in the customer form. The VAT number is in the database, the address is in the database, and both of them are displayed on the customer's own page inside the product. What does not happen is the journey from the record to the document. In our repository, the customer's tax settings are read by exactly two screens — the form that writes them and the page that shows them back — and the invoice template is not one of them.

A settings screen with a VAT number field on it proves the field exists. It does not prove the number reaches the document, and those are entirely different claims that look identical in a demo.

The one row you can act on today

The fourth row is the exception and it deserves its own paragraph, because it is genuinely good news and it would be dishonest to bury it among the absences. Our invoice has a free-text notes box, and it renders on the generated PDF. So "btw verlegd" can go on our document today. A person types it, on each invoice, and it prints.

That is a real capability and it is not a feature, and both halves of that sentence matter. It works. It is also manual, repeated, and unchecked: nothing derives it from the line, nothing notices when it was forgotten, and nothing stops it appearing on an invoice where it does not belong. Describing it as reverse-charge support would be a lie. Describing it as nothing would also be a lie, and it is the more common kind of lie in this direction — the vendor who has decided the honest answer is the bleak one.

Why nobody notices during an evaluation

This class of defect has a particular signature, and understanding it is worth more than the specific facts above, because it generalises to every vendor you will look at.

That last line is the whole mechanism. A software evaluation is conducted in screens — the invoice entry form, the customer record, the tax settings. Every field you are worried about is visible in one of them, so the system appears to hold everything you need. The document is generated at the end, usually once, usually as an afterthought, and usually nobody reads it line by line against a legal requirement. Ask for the PDF, not the settings page. It is the cheapest test on this list and the only one that would have found any of this.

The knock-on nobody mentions: the second return

Alongside the periodic VAT return sits a separate listing of intra-Community supplies — in Dutch, the opgaaf ICP — which reports what you supplied to which VAT-registered customer in which period, keyed to their identification numbers. It is a different filing with a different rhythm from the VAT return itself.

Notice what it is assembled from. It is a per-customer, per-period total tied to VAT identification numbers on transactions. A system that never put those numbers on the transactions cannot produce it, no matter how good its reporting is, because the key the listing is grouped by was never stored against anything. This is why the two "cosmetic" rows at the top of our table are not cosmetic and why they come first in our own ordering: they look like formatting and they are actually the foundation the reporting sits on.

Four questions worth asking any vendor

What we would build, and where we stop on purpose

The build has an order and the first step is much smaller than the rest. Put both VAT identification numbers and the buyer's address on the printed document — the data is already stored, so this is a template and a query rather than a schema change. Then a reverse-charge treatment that survives being saved, with the legend printed from it instead of typed. Then validation of a counterparty number against the EU register at the point of entry. Then, and only then, a return and a listing assembled from the result. What we will not do is tell you whether a particular supply is reverse-charged. That is a determination about your business that your adviser makes and signs, and a software vendor with a view on it is inviting reliance it cannot carry.