Anatomy of an electronic invoice

This is the only technical station on the path, and it is deliberately written for the non-technical reader: the finance director signing off the project needs to know what they are buying, and the worst misunderstandings in this whole file happen here.

First correction: the file is not a picture

An electronic invoice is not a PDF.

That looks obvious and catches a great many people, because what reaches the customer may well be a PDF. But what reaches the authority is a structured file a machine reads: every value in a named field in a defined position.

The practical consequence changes the project: a missing field means the whole document is rejected because of it, and there is no “we put it in the notes”. The flexibility an accountant is used to on a paper invoice does not exist.

The elements, and what each one does

Element	What it is	What it prevents
Party details	Name, tax registration number and address for each side	An invoice to a party that does not exist
Sequence and date	Consecutive numbering with no gaps	Deleting an invoice that was issued
Line detail	Item, quantity, unit, price and tax per line	Aggregation that hides the taxable base
Unique identifier	A number that does not repeat for this document	Issuing two versions with different content
Digital stamp	A signature proving the issuer and exposing any change	Editing an invoice after issuance
The chain	The previous document’s fingerprint inside the current one	Removing a document from the middle of the archive
QR code	Condensed data the buyer can read	An invoice that cannot be traced to a real issuer

The two rows before the last are the whole idea.

The stamp makes the invoice provable: any change after stamping shows. The chain makes the archive itself auditable: every document carries its predecessor’s fingerprint, so removing one from the middle breaks the chain and shows immediately.

Understand those two and you understand why an electronic invoice cannot be “edited”. Correction is a new document — a credit or debit note — which is a change in how the accounts department works, rather than a configuration setting.

Three parties produce the document, not one

Who	What they produce
Your system	The fields, the values and the sequence — where every data error lives
The signing layer	The stamp, the hash, the chain and the QR code
The authority or provider	Approval or rejection, and an acceptance reference

That split is the entire diagnostic instrument. When a document is rejected, the first question is: which layer? An error in the first is fixed in master data, in the second in certificates and settings, and in the third it may not be your error at all.

Anybody who cannot tell the three apart sends every rejection to the vendor asking “why?”.

The QR code — the most misunderstood element

The code is neither decoration nor a link to a website. It is data printed on the paper itself: issuer name and tax number, date, total, tax, and on cleared invoices the trace of the stamp.

Its value is that it moves part of enforcement onto the buyer. Anybody with a phone can read the code and compare it against what is printed. An invoice whose code disagrees with its print is exposed in two seconds.

And the common, costly practical error around it is simple: a code printed at a size or contrast that cannot be scanned. The document is accepted electronically and rejected at a field inspection. Test the code with a real phone on a genuinely printed page, not on a screen.

One field stops everything — a worked case

Take a realistic case: a company invoices a new customer, and the invoice is rejected.

Layer	What the report says	What actually happened
The provider	“Validation failed”	Nothing — it relayed the message
The authority	Buyer tax number field invalid	Technical validation refused the value
Your system	The customer was created yesterday with no number	Here is the error
The process	A rep created the customer to raise an order quickly	And here is its cause

The last row is what stops the repeat. Correcting the invoice fixes one case; making the tax number mandatory on customer creation fixes the next hundred.

The rule that follows: every recurring rejection is translated into a setting that prevents incomplete data being entered in the first place, not into an instruction to a member of staff. An instruction is forgotten in a fortnight; a mandatory field is not.

The one exception is the customer who genuinely has no tax number — a final consumer or an exempt body. That case gets a rule of its own, rather than being left as a gap everybody passes through.

What you actually do in this station

• Ask your system vendor for a sample of an actually issued document, open it and read it field by field.
• Compare the required fields against what your system populates today, and write the gap list. That list is your project.
• Print an invoice and scan its code with your phone, comparing what appears against what is printed.
• Write the correction procedure: how a wrongly issued invoice is corrected, and who approves the note.
• Find out where the signing certificates live and who owns their renewal, because their expiry stops all issuance in a single day.

The three commonest mistakes

One: treating the document as a picture. Effort goes into how the print looks while the rejection comes from an invisible field.

Two: trying to edit an issued invoice. The stamp prevents it structurally, and correction is a new document.

Three: neglecting certificate renewal. It is the commonest sudden stoppage in these systems, and its cause is a date nobody wrote in a calendar.

The acceptance test for this station

1. Explain why an electronic invoice is not a PDF.
2. State what the stamp prevents and what the chain prevents, one sentence each.
3. Name the three layers and which errors live in each.
4. Explain what the QR code carries and why it is tested in print.
5. Show the correction procedure for a wrongly issued invoice and who approves it.

What comes next

You know what has to come out. The next station is the real reason projects slip, and the most important one here: your data before your system.