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

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

1. Which country is the recipient in, and is the invoice B2B, B2G, or platform-routed?
2. Does the recipient expect a network such as PEPPOL, a portal upload, or direct exchange?
3. 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?
4. 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.