EU VAT mistakes in SaaS billing: eight failures and their fixes

VAT errors in billing rarely surface where they start. A missing validation status on a customer shows up only when the EC Sales List doesn't match the invoices. An overwritten address shows up only when a credit note lands in the wrong country. This article collects eight failures that keep recurring in SaaS billing with EU customers. For each one you get the symptom, the cause, the fix and a query that catches it before the next filing.

The examples assume a seller established in Germany, so German rules appear where they matter. The order in which tax decisions should be made in the system is covered in the article on EU tax logic for SaaS. This one is about what breaks when that order is missing.

Customer classification: errors before the first invoice

1. An entered VAT ID switches on reverse charge directly

Symptom: invoices without VAT to customers whose number was never confirmed, or to numbers with a typo. The EC Sales List contains numbers that the validation service rejects.

Cause: the VAT ID field at checkout doubles as the switch for the tax treatment. Whatever is typed in counts as verified.

Fix: a number gets a status (pending, valid, invalid, unavailable), and only valid with a stored validation record leads to reverse charge. Everything else follows an explicit rule. How the check should run is covered in the article on automating VIES checks. Invoices already issued are corrected through a credit note and a new invoice, once finance has assessed the case.

Query: reverse charge invoice lines whose customer has no validation record dated before the invoice.

2. Reverse charge without the required wording

Symptom: the invoice shows no VAT but doesn't say why. Or it carries the note and still shows VAT, because the template and the calculation read from different sources.

Cause: the note is part of the PDF template and depends on a different field from the tax calculation.

Fix: for a cross-border B2B supply under reverse charge, the invoice has to state that the customer is liable for the VAT (the EU VAT Directive sets the invoice requirements; in Germany § 14a UStG requires the wording "Steuerschuldnerschaft des Leistungsempfängers"). Note, VAT amount and ledger account all have to come from the same stored tax result on the invoice line.

Query: invoices with zero VAT and no note, and the reverse.

Place of supply: errors with consumers

3. The country comes from a single field

Symptom: a consumer in Austria is charged German VAT because their credit card was issued in Germany. Or a consumer in Germany is charged Austrian VAT because they logged in from a Vienna network.

Cause: the code takes the first country field available, usually the payment provider's.

Fix: Implementing Regulation (EU) 282/2011 sets out presumptions for where the customer is located. Store each piece of available evidence separately, plus which one decided. If they conflict, open a review case.

Query: customers whose billing country, card country and IP country disagree, with no documented decision.

4. The address gets overwritten

Symptom: a credit note for a spring supply carries the country the customer moved to in autumn. The correction lands in a country where no sale ever took place.

Cause: the customer record only knows the current state, and documents read it at runtime.

Fix: tax-relevant customer data is versioned with a start date. Every invoice line stores the tax result that applied when it was finalised, and credit notes inherit it from the original line. How this works for quarters already in an OSS return is shown in the article on OSS quarter-close controls.

Query: credit notes with no link to an original line.

Amounts: rounding and gross prices

5. Every component rounds differently

An example: an invoice has three items at EUR 0.99 net each, VAT at 19%. Round per line and you get 3 × EUR 0.19 = EUR 0.57 VAT. Round on the total and you get 2.97 × 0.19 = 0.5643, so EUR 0.56. If checkout rounds per line, the invoice rounds on the total and the ledger export does something else again, you get cent differences that add up across thousands of invoices to a figure nobody can explain.

Fix: one rounding rule, calculated in one place, and only read by PDF, e-invoice and ledger export. Structured e-invoices check totals and VAT amounts strictly; how to test that before sending is covered in the article on validating XRechnung and EN 16931.

Query: invoices whose stored VAT total differs from a recalculation under the agreed rule.

6. Gross prices without deciding who absorbs the rate difference

Symptom: net revenue per subscription varies by country, and nobody decided that it should.

Cause: consumers see one gross price everywhere, say EUR 11.90. At 19% that's EUR 10.00 net; in a country with 25% it's only EUR 9.52. That's allowed, but it has to be intended, and the pricing logic has to back the net amount out of the gross price instead of adding VAT on top of a net price.

Fix: store on each price whether it's net or gross, and carry that flag from quote to invoice.

Documents and filings: errors after sending

7. Invoices are edited after they've been sent

Symptom: the PDF the customer has differs from the document in the system, or the amount you reported no longer matches any current invoice.

Cause: support or finance fixes a mistake directly in the sent invoice.

Fix: a sent invoice stays as it is. In Germany invoices must be retained for eight years (§ 14b UStG). Corrections go through a cancellation or credit note and, if needed, a new invoice, each pointing to the original. A failed direct debit or a chargeback is a payment event and doesn't cancel an invoice. How a final payment default is treated for VAT is a separate decision for finance.

Query: invoices with a modification time after their sent time.

8. EC Sales List and reverse charge invoices don't agree

Symptom: the total in the EC Sales List differs from the total of reverse charge invoices.

Cause: the EC Sales List is built from accounting, but the reverse charge flag only exists in billing, or credit notes are missing from one of the two sources.

Fix: both figures come from the same invoice lines. Per customer VAT ID and reporting period, the sum of reverse charge lines, credit notes included, has to match the line you report.

The checklist before every filing

Start with failures 1 and 4. They produce the most expensive corrections because they affect many invoices at once. Kontier stores the tax result on every invoice line, with the validation record and a link to the original line, in its European billing infrastructure, so these queries run directly on the document data.