Two letters that decide whether your e-invoice gets paid

Accounting E-Invoice EN16931 XRechnung ZUGFeRD

Robert Reiz | 09. November 2026 | 09:15 UTC

ZEIT.IO completes VAT IDs with the correct country prefix across forms, API and imports, and rejects mismatches. Your own EU VAT ID is also checked against the EU's VIES service, so e-invoices no longer bounce over a missing prefix.

Lena is a freelance developer in Mannheim. Her newest customer, Huber Digital in Vienna, sends over its details by email, and the VAT ID in the signature reads U12345678. She copies it into the customer record exactly as it stands and creates her first invoice: 4,800 euros, 30 days payment term.

Two days later the invoice is back. Huber Digital's accounting system has rejected the e-invoice as invalid. The amount, the hours and the bank details are all correct. What's missing is AT, the two letters at the front of the VAT ID.

Lena corrects the customer, cancels the invoice and issues a new one. The 30 days start again.

Auto Prefix for VAT numbers

That no longer happens. ZEIT.IO now adds the correct country prefix to EU, UK and Swiss VAT IDs as soon as you enter them, and tells you that it did.

Why VAT IDs deserve a proper check

A VAT ID looks like a formality, but real money depends on it:

E-invoices are checked by machine. The European e-invoicing standard EN 16931, and with it ZUGFeRD and XRechnung, requires VAT IDs to start with a country prefix. Without it, the whole document fails validation, however correct everything else is.
Cross-border invoices depend on it. If you invoice a business in another EU country without VAT, a valid VAT ID is usually a condition for doing so. If the number turns out to be wrong, the tax office may ask you for the VAT you didn't charge.
Your customer needs a correct invoice too. An invoice with a wrong VAT ID can cost them their input tax deduction, so they will send it back.

The EU offers a free tool for exactly this: VIES, the VAT Information Exchange System. The European Commission's search engine queries the national VAT databases live and answers one question: is this number valid for trade across EU borders or not?

The rule, word for word

The prefix requirement is business rule BR-CO-09 of EN 16931:

"The Seller VAT identifier (BT-31), the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48) shall have a prefix in accordance with ISO code ISO 3166-1 alpha-2 by which the country of issue may be identified. Nevertheless, Greece may use the prefix ‘EL’."

In plain terms: in three fields, the VAT ID must start with the two-letter ISO code of the issuing country. Only Greece may use EL instead.

Field	Meaning	Example
BT-31	The seller's VAT ID, so your own	`DE123456789`
BT-48	The buyer's VAT ID, so your customer's	`ATU12345678`
BT-63	The VAT ID of the seller's tax representative, if there is one	`FR12345678901`

The rule applies to both formats common in Germany: ZUGFeRD includes it in the validation rules of every profile from MINIMUM to EXTENDED, and XRechnung, the German implementation, is built directly on EN 16931. In Lena's case, BT-48 contained U12345678. That is exactly the rule her invoice failed.

What changes now

The prefix adds itself

Enter a VAT ID without a prefix and ZEIT.IO completes it to match the selected country. Spaces and lower-case letters are tidied up along the way:

123456789 for Germany becomes DE123456789
U12345678 for Austria becomes ATU12345678
de 123456789 becomes DE123456789

So that nothing changes behind your back, you see the result straight away: "The VAT ID number was corrected to ATU12345678. Please check the value."

Special cases are handled

Not every country uses its ISO code. Greek VAT IDs start with EL, so GR123456789 becomes EL123456789. This also fixes an error that made it impossible to save any Greek VAT ID at all. Swiss numbers get CHE, and for the United Kingdom both GB and XI (Northern Ireland) are accepted.

Wrong country, clear message

If the number starts with another country's prefix, say FR… on a German company, ZEIT.IO doesn't guess. The entry is rejected with: "The VAT ID number does not match the selected country. Please check the VAT ID number and the country."

Your own VAT ID is checked against VIES

For the VAT ID of your own organisation or freelance business in an EU country, ZEIT.IO goes one step further and asks VIES whether the number exists. That check now also runs when you book a subscription and on the contract form, where previously only the length was looked at. We've also closed a gap where a number unknown to VIES could get through the very first time it was checked.

If VIES doesn't know the number, you'll see: "The VAT ID number does not exist. Please check the VAT ID number."

Every way in

The prefix is added wherever a VAT ID enters ZEIT.IO:

signup, legal form and organisation settings,
customers, suppliers and team members,
the REST API, which returns the corrected value,
DATEV and CSV imports.

Your existing data gets corrected too

Numbers that are already saved are being corrected as well: master data and invoices and credit notes that haven't been finalised yet. Each correction appears in the audit log with the old and new value. Finalised documents stay exactly as they were issued.

What ZEIT.IO doesn't check

Your customers' and suppliers' VAT IDs get the prefix, but no VIES check. If you're invoicing a new customer abroad without VAT, check their number yourself in VIES and keep a record of the result. The EU recommends this in case of a tax audit.
The VIES check covers EU countries only. Swiss and UK numbers get their prefix, but aren't looked up.
Other countries stay untouched. VAT IDs from outside the EU, the UK and Switzerland are saved as entered.
If VIES is unavailable, the number is accepted. The service depends on the national databases and is sometimes down. You won't be stuck because of that.
VIES can also say no to a correct number, for example if it hasn't been activated for intra-EU transactions yet. In that case, your tax office can help.
A result is remembered. ZEIT.IO doesn't keep monitoring a number once it has been checked.
During imports a wrong prefix doesn't stop the run. That value stays as it was, so one bad row can't block the other records.

Why this matters

A rejected invoice doesn't just cost you the few minutes it takes to fix. It costs you the payment term that starts over, an awkward message to a new customer, and sometimes a credit note and a new invoice number. And the cause is two letters that nobody noticed were missing.

Now the mistake gets caught where it's cheapest to fix: at the moment of entry, whether you're typing it in, importing it or sending it through the API. You see what was changed, and your invoices go out with VAT IDs that pass.

Lena's next invoice gets paid in 30 days. Not 32.