# How non-EU suppliers can create compliant invoices for EU customers

- Date: 2026-04-20
- Modified: 2026-08-29
- Reviewed: July 9, 2026
- Reading time: 3 min read

A practical guide for suppliers outside the EU: understand EN 16931, recipient-specific formats, routing, and the review steps needed before sending

> Reviewed against EUR-Lex Directive 2014/55/EU, EU VAT in the Digital Age.

This guide is for companies outside the EU that invoice European customers and need to move from generic PDFs to structured electronic invoice data.

The practical question is not “how do I make one EU invoice?” but “which data model, syntax, channel, and identifiers does this customer or route require?” The answer can differ by country, customer type, and submission route.

## What “EU compliant” actually means

- The invoice data follows the EN 16931 core semantic model or a national CIUS (Core Invoice Usage Specification) based on it.
- The data is bound to a syntax the recipient or network accepts. The European standard identifies UBL 2.1 and UN/CEFACT Cross Industry Invoice (CII) as compliant syntaxes; national implementations and profiles can add further rules.
- Required identifiers, VAT codes, payment references, and routing details are present and pass the relevant validation rules before submission. Validation does not replace checking the applicable VAT and commercial requirements.
## Questions to answer before you convert anything

- Which country is the recipient in, and is the invoice B2B, B2G, or platform-routed?
- Does the recipient expect a network such as PEPPOL, a portal upload, or direct exchange?
- Is a pure XML invoice required, or does the recipient accept a hybrid PDF with embedded XML, such as a permitted ZUGFeRD/Factur-X profile?
- Which buyer identifiers, VAT references, and business terms are mandatory for this customer?
## Where non-EU suppliers usually fail

- Sending a visually correct PDF without structured, machine-readable invoice data when the recipient requires an eInvoice.
- Reusing one invoice template across all countries without country-specific identifiers or routing logic.
- Assuming cross-border VAT treatment and exemption reasons are obvious, or that a validator decides the underlying tax treatment for you.
- Skipping validation because the invoice “looks right” to the human reviewer.
## A practical rollout path

Start by grouping your EU customers by country, customer type, and delivery channel. Then define the target syntax, applicable national rules, and required identifiers for each group before you automate anything.

If your source system still creates PDFs, use conversion as a bridge. Review the extracted data, validate the generated XML against the recipient’s rules, and keep an exception process for invoices that need human correction.

## FAQ

### Do non-EU suppliers always need the same invoice format for every EU customer?

No. The required syntax and profile depend on the recipient country, customer type, delivery channel, and sometimes the network or platform used for submission.

### Is EN 16931 alone sufficient?

Not always. EN 16931 provides the shared core semantic model and business rules, but a national CIUS, network, or recipient can add stricter rules, identifiers, or routing requirements. VAT and other legal obligations still need separate review.

### Can PDF conversion still be useful for non-EU suppliers?

Yes. It can be a practical bridge when the ERP still outputs PDFs, provided the extracted data is reviewed, the chosen profile is accepted by the recipient, and the generated XML is validated before delivery.

## Official references

- [EUR-Lex Directive 2014/55/EU](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32014L0055)
- [EU VAT in the Digital Age](https://taxation-customs.ec.europa.eu/taxation/vat/vat-digital-age_en)