How non-EU suppliers can create compliant invoices for EU customers
Official references
Use these sources to verify dates, formats, and official rule changes.
Related Technical Wiki
Explore deep-dive developer documentation and regulatory guidelines matching this article.
A practical guide to EU e-invoicing: EN 16931, UBL/CII, PEPPOL, validation, identifiers, and how to prepare your invoicing process.
What ViDA changes at EU level, what remains national, and how to prepare for cross-border digital reporting from July 2030.
DIN EN 16931-1 semantic model: mandatory and optional data, national CIUS like XRechnung, how EN 16931 maps to UBL and CII, and what validators check before you send.
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
Interactive family tree
One model, two syntaxes, many rule sets
EN 16931 defines what invoice data means. UBL and CII write it down. CIUS and profiles add rules on top. Tap a box for details.
EN 16931
Part 1 · semantic model
- What it is
- The European e-invoicing standard from CEN. Part 1 defines what invoice data means: business terms such as BT-1 (invoice number) and BT-2 (issue date), grouped into business groups (BG), plus the business rules they must meet.
- Who uses it
- Every format in this tree. Public buyers covered by Directive 2014/55/EU must receive and process invoices that follow it, and national B2B mandates build on it.
- Syntax
- None of its own. Part 3 binds the model to two XML syntaxes: UBL 2.1 and UN/CEFACT CII D16B.
- 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.
Frequently asked questions
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.
Ready to convert your invoices?
Convert PDF invoices to XRechnung, ZUGFeRD, and other formats. Subscriptions from €10/month with annual billing (excl. taxes), with a 3-day trial on your first subscription. Or without a subscription: €5 per conversion (excl. taxes).