The invoice that looks right and gets sent back

The email is four lines long and tells you nothing. "Our system cannot process this invoice. Could you reissue it?" You open the PDF you sent. It has your logo, the client's name, the line items, the total, your bank details. It looks like every other invoice you have sent for years. Nothing on it is wrong.

Somewhere in a finance team you have never met, a field was empty, and now you are guessing which one.

So you change something. You add the purchase order number, because that is the only thing you can think of. You send it again. Two days later the same four lines come back. You still do not know what is wrong, and now you have sent the same customer two invoices for one job, which is its own small problem you will deal with later.

Why does a correct-looking invoice get sent back?

Because an invoice is not a record of what happened. It is the document your customer's tax deduction hangs on, and the person rejecting it is protecting their own money, not correcting your paperwork.

The work is already done. That is what makes this particular friction so irritating — nobody is disputing the amount, the quality or the delivery. The thing being blocked is the paperwork about something that already happened, and every day it sits there is a day of your cash sitting in someone else's account with everyone in agreement that it should not be.

If you have billed businesses across a border, you have probably met at least one of these.

• The invoice comes back with no reason. The person who emailed you is relaying a complaint from a system, and they do not know which field it was either.
• It gets paid, and then eight months later someone asks for a corrected invoice. Their auditor disallowed the deduction. Your accounts have moved on, your numbering has moved on, and "just send a new one" is not a five-minute job.
• Your accounting tool has one "Notes" box, and everything a foreign customer needs turns out to belong in that box.
• You number invoices per client, or restart at 1 each January, and someone tells you the numbering is not acceptable. It had never come up before.
• You wrote "Consulting services, October" as the description. That was fine for six years and then it was not.

None of these feel like a document problem. They feel like the invoice being judged by rules you were never shown.

The part that makes it hard to fix is that nothing gets worse gradually. The invoice you have been sending for six years does not slowly stop working. It works, and works, and works, and then you take on one customer in another country — or your existing customer hires a finance team that runs the checks their old bookkeeper did not — and the same document that was fine last month is refused. Nothing changed on your side. What changed is who is reading it, and what they have to prove to someone else.

And because it arrives as a rejection rather than as a rule, it feels arbitrary. It is not. There is a list. It has been the same list for years, it is published, it is about one page long, and almost nobody who sends invoices has ever been shown it.

What is actually being checked?

The customer's right to deduct the VAT they paid you. In the EU that right is conditional: Article 178(a) of the VAT Directive says a business may deduct only if it holds an invoice that satisfies Article 226, and Article 226 is a list of things the invoice must contain.

Two consequences follow, and they explain most of the strange behaviour above.

It is not your money at stake, it is theirs. That is why the rejection comes from their side and why it can arrive months later when someone audits the file. Nobody is inspecting your invoices. They are inspecting the deduction, and your invoice is the evidence.

Nothing in your workflow enforces the list. Invoice tools are mostly built for domestic sales, where far fewer particulars are required. Cross a border, or sell to a business instead of a consumer, and the requirements grow — but the form you fill in does not.

So the list is short, it is public, and almost nobody sending invoices has read it.

What has to be on an invoice?

Article 226 requires these on every invoice, always:

• The date of issue.
• A sequential number, based on one or more series, that uniquely identifies the invoice.
• Your VAT identification number, the one under which you made the supply.
• The customer's VAT identification number, where they are liable for the tax on the supply, or where the supply is an intra-Community supply of goods.
• Full name and address of both you and the customer.
• The quantity and nature of the goods, or the extent and nature of the services.
• The date the supply was made or completed, or the date of a payment on account, where that date differs from the date of issue.
• The taxable amount per rate or exemption, the unit price excluding VAT, and any discounts or rebates not already included in the unit price.
• The VAT rate applied.
• The VAT amount payable, unless a special scheme excludes it.

Then there are the conditional mentions. They are short phrases, and the wording matters more than the formatting:

• Where the customer is liable for the tax, the invoice says "Reverse charge".
• Where the customer issues the invoice on your behalf, it says "Self-billing".
• Where the supply is exempt, the invoice references the provision that exempts it.
• Margin schemes for travel agents and for second-hand goods, works of art and collector's items each have their own required mention, as does a supply made through a tax representative.

Read the article itself before you build against this. It is one page, it is public, and it is the source your customer's auditor will use.

Which fields actually break?

Three, in my experience, and they break for the same reason: they look like presentation and they are not.

Sequential numbering. "Sequential" is not "increasing". A series has to identify invoices uniquely and without gaps you cannot explain. Per-customer counters produce 2026-ACME-004 alongside 2026-BETA-004, which can be fine as separate series but is not fine as one. Restarting at 1 every January is usually acceptable if the year is part of the number and you can say so. What is never fine is deleting an invoice — if you issued number 47 and it was wrong, 47 still exists and you correct it with a credit note. A gap you cannot account for is the thing an auditor notices first.

Taxable amount per rate. Not the total. If an invoice carries two VAT rates — a standard-rated service and a reduced-rated item — you need the taxable base for each rate, separately, plus the VAT for each. One "Subtotal / VAT / Total" block is only correct when everything on the invoice is at one rate. Many invoices are, right up to the day one of them is not.

Date of supply. Distinct from the date of issue, and required whenever they differ. This is the field that hides best, because for a lot of businesses the two dates are the same for years. Then you invoice in early January for work finished in December, and the period the deduction belongs to is no longer obvious.

Descriptions deserve a mention too. "Services rendered" or "Consulting" does not state the nature of the service. It is not a rule about being verbose — it is that someone must be able to tell from the invoice what was supplied.

How do you fix this yourself?

Stop treating the required fields as things to remember, and make them things the document has.

Write the list down as a structure, not a checklist. A checklist is consulted when you remember to consult it. Put the ten always-required particulars into whatever produces your invoices as named, addressable places — form fields, template slots, columns in a table. A missing field should look missing.

Derive the totals from the line items. Do not store a subtotal, a VAT amount and a total as three numbers someone types. Compute them from the lines at the moment the document is produced. This is the single change that fixes the per-rate problem, because once the lines carry their own rates, grouping by rate is arithmetic instead of discipline. Concretely: group the lines by VAT rate, sum the net per group, apply each rate to its own group, and print one row per rate. In most template and reporting tools this is a group-by and a sum, and it is an afternoon of work.

Make numbering a counter, not a formatting choice. One counter per series, incremented at issue, never reused, never reset except on a boundary you can describe in a sentence. Store the number when the invoice is issued rather than deriving it at render time, so the same invoice keeps its number forever.

Keep two dates. Issue date and supply date, as separate values, even while they are identical. Adding the second field later means backfilling it on documents you have already sent.

Then test it against the awkward cases, not the ordinary one. An invoice with two VAT rates. A reverse-charge invoice to a business in another member state, where your customer's VAT number must be present and the words "Reverse charge" must appear. A credit note that corrects an earlier invoice. If those three come out right, the ordinary invoice was never going to be the problem.

Honest cost: a day or two, plus the reading. The rules do not change often, which makes this a fixed cost rather than a recurring one. The recurring cost is the version where you do not do it — a rejection every few months, each one taking a week of back-and-forth with someone who cannot tell you what was wrong.

What does this look like when the document is built from data?

If your invoice comes out of a template that is filled from structured data, the required particulars stop being things you fill in and become part of the layout. The line items are an array. The subtotal, the tax and the total are expressions over that array. The numbering, the two dates and both VAT numbers are named fields that are either bound or visibly empty.

There is a VAT-ready invoice template that is laid out this way — both tax identification numbers, line items with per-line rates, and totals summed from the lines rather than typed. The step-by-step version builds the same thing from an empty page and shows the expression that does the summing, which is the part worth copying even if you build it somewhere else entirely.

The point is not the tool. It is that a required field with a name in a template is a field somebody will notice is blank, and a total computed from the lines is a total that cannot disagree with them.

What a template does not do for you. It will not check whether a VAT number is real — that is a lookup against the VIES service, and it belongs in your billing system rather than in the document. It will not know your country's additional requirements: France, for example, layers CIUS-FR on top of the European standard and wants late-payment penalties, the recovery fee and discount terms that Article 226 does not mention. And a rendered PDF is not a structured e-invoice — the mandates now arriving across Europe want XML alongside the page, which is a different problem from getting the page right.

The last one deserves saying plainly, because the two are easy to conflate: an invoice that satisfies Article 226 can still be rejected by a French or Belgian platform for having no structured payload, and a perfectly valid structured payload does not help if the visible invoice is missing the customer's VAT number. They are two requirements, and both of them are still true.

What this does not solve

• Article 226 is the floor, not the ceiling. Member states add their own required mentions. Check your own country and your customer's.
• Getting the fields right does not make the invoice enforceable. Payment terms, late-payment interest and retention of title are contract questions, and several of them are also required mentions in specific countries.
• Nothing here applies unchanged to consumers. B2C invoicing has lighter requirements and different rules about when an invoice is required at all.
• Rules move. The ViDA package adds new data points to Article 226 later this decade. Anything you build should treat the field list as configuration rather than as something welded into a layout.

The customer who sent your invoice back was not being difficult. They were looking at a document that could not do the one job they needed it to do, and they had no more idea than you did which line was missing. Making the fields structural is how you stop having that conversation.

Article references were checked in September 2026 against the consolidated text of Directive 2006/112/EC. Verify against the article itself before you build.