E-invoicing standards: formats and networks

E-invoicing standards do not matter because finance teams enjoy XML acronyms. They matter because every mandatory e-invoicing project depends on the same foundation: structured data, valid tax logic, the right exchange network and invoice statuses that your ERP can actually track.

Across Europe, countries are moving from PDF-based invoicing to structured electronic invoices exchanged through platforms, networks or tax authority systems. Belgium requires structured B2B e-invoices from 2026, France starts its phased rollout in September 2026, and Germany is moving progressively from mandatory receipt to mandatory issuance between 2025 and 2028.

For companies using NetSuite, this is not just a format question. It is a finance operations question. Your ERP needs to provide the right data, connect to the right infrastructure, handle country-specific requirements and keep AR and AP teams in control.

If you are still defining your broader roadmap, start with our overview of e-invoicing mandates across Europe. If you are already assessing your NetSuite environment, our NetSuite e-invoicing readiness checklist gives a practical structure for reviewing data, tax codes, workflows and testing scenarios.

‍

What are e-invoicing standards?

E-invoicing standards define how invoice data is structured, validated, exchanged and processed between business systems. They make invoices machine-readable, so platforms, tax authorities, customers and suppliers can validate and process invoice data without relying on manual entry or OCR.

A reliable e-invoicing setup usually combines five layers.

First, there is the semantic standard. This defines the business data an invoice must contain. In Europe, the main reference is EN 16931.

Second, there is the syntax or format. This defines the technical file structure used to represent the invoice. Common examples include UBL, CII, Factur-X and XRechnung.

Third, there is the network or platform. This defines how the invoice is exchanged between parties. Examples include Peppol, accredited platforms and government portals.

Fourth, there are country-specific rules. Each country can define its own rollout timeline, local identifiers, validation rules and reporting requirements.

Fifth, there is the ERP integration layer. This defines how invoice data, statuses and errors are managed in the ERP. For NetSuite users, this includes records, custom fields, workflows, saved searches and dashboards.

The mistake is to treat these layers as separate topics. They work together. A valid e-invoice is not just a file in the right format. It is a structured business transaction that must be generated, routed, validated, accepted, rejected, archived and monitored.

That is why e-invoicing should not be treated as a narrow technical project. As explained in our 6 key takeaways for NetSuite users preparing for e-invoicing mandates, the real challenge often starts with master data, AR/AP flows and status tracking inside NetSuite.

‍

Why e-invoicing standards matter now in Europe

The European e-invoicing landscape is becoming operational. The EU’s e-invoicing framework created a common foundation around EN 16931, the European standard for electronic invoicing. But each country can still define its own rollout calendar, platform model, identifiers and implementation rules.

That creates a challenge for mid-market companies operating across several countries. A business with entities in Belgium, France, Germany and the Netherlands may need to manage Peppol, approved platforms, UBL, Factur-X, XRechnung, tax identifiers, e-reporting and different invoice lifecycle statuses.

For a finance team, that complexity should not become daily manual work. The right architecture should keep users close to NetSuite while the compliance layer handles local formats, networks and platform requirements.

This is where technical standards become operationally important. If your master data is incomplete, tax codes are poorly mapped or invoice statuses do not flow back into NetSuite, compliance becomes a bottleneck instead of an automation opportunity.

For companies using NetSuite across several countries, the goal is not to build a separate process for every mandate. The goal is to build a scalable model. That is the logic behind the Novutech x Invopop NetSuite e-invoicing solution for Europe, which helps finance teams manage AR and AP e-invoicing flows from NetSuite while connecting to the right compliance infrastructure in the background.

‍

EN 16931: the European reference standard

EN 16931 is the European semantic standard for electronic invoicing. It defines the core business terms that an electronic invoice should contain, such as seller, buyer, invoice lines, VAT breakdown, totals, payment terms and references.

EN 16931 is not the same thing as a file format. It is the common business model behind several formats and profiles. Peppol BIS Billing 3.0, for example, is a Core Invoice Usage Specification based on EN 16931.

For NetSuite users, EN 16931 matters because it defines what your ERP data needs to support. Your customer records, subsidiary data, VAT numbers, tax codes, invoice lines, payment information and references must be structured enough to populate the required business terms.

If that data is missing or stored inconsistently across custom fields, the technical connector cannot solve the problem alone. This is why Novutech recommends starting with a readiness assessment before implementation. Our NetSuite e-invoicing readiness checklist covers the main areas to review before go-live, including entity scope, master data, tax mapping, AR/AP flows, testing and governance.

‍

Key e-invoicing formats explained

Different countries and networks rely on different formats. The goal is not for finance teams to manually choose between them invoice by invoice. The goal is to build an architecture where NetSuite provides clean structured data, and the integration layer converts it into the required local output.

‍

UBL

UBL, or Universal Business Language, is one of the most widely used XML formats for electronic business documents. It is commonly used in Peppol-based invoice exchange and supports structured invoices, credit notes and other business documents.

UBL is important because it provides a detailed machine-readable structure for invoice data. It can carry invoice headers, line details, tax amounts, payment information, supplier and buyer details, and references.

For NetSuite, the practical question is whether invoice data can be mapped cleanly into the required UBL fields. That includes standard transaction fields, custom fields, subsidiary information, customer records and tax logic.

If your company operates in Peppol countries, UBL readiness should be part of your NetSuite preparation. This is especially important for companies with Belgian entities, where B2B structured e-invoicing is becoming mandatory from 2026. For more context, read our article on NetSuite e-invoicing readiness, which explains why master data and tax mapping are usually the first areas to review.

‍

Peppol BIS Billing 3.0

Peppol BIS Billing 3.0 is a key profile used for invoice exchange through the Peppol network. It is based on EN 16931 and provides rules for how invoices and credit notes should be structured and validated in Peppol flows.

Peppol matters because it is becoming a major interoperability layer in Europe. In practical terms, it helps companies exchange structured invoice data through a network model instead of building one-to-one technical connections with every customer or supplier.

For multi-country companies, Peppol can reduce point-to-point complexity. But Peppol readiness still requires the right routing identifiers, participant configuration, tax data and validation rules.

For NetSuite users, this means Peppol should not be treated as a separate portal project. The required identifiers, statuses and validation feedback should be connected to the ERP wherever possible, so finance users can monitor activity directly from NetSuite.

‍

UN/CEFACT CII

CII, or Cross Industry Invoice, is another structured XML invoice syntax aligned with EN 16931. It is often discussed alongside UBL because both can be used to represent structured invoice data.

CII is particularly relevant in contexts where hybrid or country-specific invoice standards rely on it. For companies operating across Europe, the key point is not whether CII is better than UBL. The key point is whether your e-invoicing architecture can generate the syntax required by each country, without rebuilding the ERP logic each time.

This is where a scalable integration layer becomes important. NetSuite should provide the right business data, while the compliance layer should manage the required country output.

‍

Factur-X

Factur-X is a hybrid invoice format that combines a human-readable PDF with embedded structured XML data. It is especially relevant in France and Germany, where hybrid formats are common in e-invoicing discussions.

The important distinction is that the PDF is not the compliance object on its own. The structured data is what allows systems to validate and process the invoice.

For finance teams, this can be useful because users can still view a familiar PDF representation, while systems process the structured invoice data in the background.

This matters in France, where the e-invoicing reform changes how companies issue, receive and report invoice data. If France is in scope for your NetSuite environment, you can also read our complete guide to mandatory electronic invoicing in France.

‍

XRechnung

XRechnung is a German e-invoicing format aligned with EN 16931. Germany requires companies to be able to receive EN 16931-compliant e-invoices from 1 January 2025, with mandatory issuance being phased in later.

For NetSuite users with German entities, XRechnung readiness means more than generating a file. It means ensuring customer and vendor data, VAT treatment, invoice references, payment details and validation logic are reliable before invoices are exchanged.

If Germany is part of your rollout, include it in your country and entity scope early. Do not wait until the issuance deadline to review German-specific fields, tax logic and invoice workflows.

‍

GOBL

GOBL is a JSON-based universal invoice format used as a common structured layer before conversion into country-specific formats. In the Novutech x Invopop approach, NetSuite data can be transformed into a GOBL payload, then converted into local formats such as Peppol, Factur-X, XRechnung or other country-specific outputs.

This approach is useful for multi-country NetSuite environments because it avoids building separate ERP logic for every local mandate. NetSuite remains the operational source of finance data, while the compliance layer manages conversion, validation, routing and local requirements.

This is one of the reasons Novutech partnered with Invopop. The Novutech x Invopop solution is designed to help NetSuite users manage e-invoicing compliance across multiple countries while keeping daily AR and AP work close to the ERP.

‍

UBL vs Factur-X vs XRechnung vs GOBL

The easiest way to compare e-invoicing formats is to look at the role each one plays in the architecture.

EN 16931 is the European semantic standard. It defines the invoice data your ERP must be able to provide.

UBL is an XML syntax widely used in Peppol and many European e-invoicing flows. For NetSuite, it requires clean field mapping from transactions, customers, subsidiaries and tax codes.

Peppol BIS Billing 3.0 is the invoice profile used for Peppol network exchange. It requires validation, routing identifiers and access to the right network infrastructure.

CII is another XML syntax aligned with EN 16931. It is used in several European e-invoicing contexts and may be required depending on the country or platform model.

Factur-X is a hybrid invoice format combining a readable PDF with embedded structured XML data. It is especially relevant in France and Germany, where users may still need a readable invoice view while systems process structured data.

XRechnung is a German e-invoicing format aligned with EN 16931. It requires German-specific validation, invoice fields and tax logic.

GOBL is a universal structured invoice layer used in the Novutech x Invopop approach. It helps avoid building a separate NetSuite integration for every country by transforming NetSuite data into a common format before conversion into local standards.

The right question is not “Which format should we choose?” The better question is: Which countries, entities, transaction types and networks are in scope — and how can we support them without turning NetSuite into a patchwork of country-specific customizations?

For companies with several European subsidiaries, that question should be answered before implementation starts. Our e-invoicing mandates webinar recap for NetSuite users explains why multi-country compliance needs a scalable approach from the beginning.

‍

Peppol and e-invoicing networks

A format defines the invoice data. A network defines how that invoice moves.

Peppol is an interoperability network that allows businesses and public authorities to exchange structured electronic documents through certified access points. Peppol BIS Billing 3.0 defines how invoices and credit notes are structured for that exchange.

In practical terms, Peppol helps avoid a separate technical connection with every customer or supplier. Instead, parties exchange documents through the network using participant identifiers and standardized rules.

For NetSuite users, Peppol readiness usually requires Peppol participant identifiers for customers and suppliers, routing information stored in the right records, invoice data mapped to the required structure, validation before transmission, status feedback inside NetSuite and error handling for rejected or invalid invoices.

Peppol does not remove the need for clean ERP data. It makes clean data more important.

That is why data cleanup should start before configuration. A missing VAT number, incorrect address or invalid routing identifier can block invoice transmission. In our NetSuite e-invoicing readiness checklist, master data review is one of the core preparation steps before go-live.

‍

Platforms, CTC and country-specific models

Not every country follows the same model. Some countries rely heavily on Peppol. Others require invoices to pass through approved platforms, government systems or clearance-style controls.

France is a good example. From 1 September 2026, companies need to move into the new framework for electronic invoicing and e-reporting, including the use of approved platforms. The reform is not only about issuing invoices. It also covers receiving invoices, reporting transaction data and, in some cases, payment-related data.

This changes the invoice lifecycle. Instead of “created, sent, paid,” invoices may move through statuses such as generated, transmitted, received, accepted, rejected, disputed or corrected.

For finance teams, the operational challenge is visibility. If those statuses live only in an external platform, users lose control. If they flow back into NetSuite, finance can monitor exceptions, correct errors and keep the process manageable.

If you need a deeper view of the French rollout, read our article on mandatory electronic invoicing in France. If you want to understand the operational impact in NetSuite, our webinar recap on electronic invoicing 2026 and NetSuite explains the key changes for finance teams.

‍

What e-invoicing standards mean for NetSuite

For NetSuite users, e-invoicing compliance starts inside the ERP.

A compliant setup needs clean data, reliable mapping and finance workflows that reflect the new invoice lifecycle. The connector matters, but the connector can only work with the data NetSuite provides.

Master data becomes critical

Customer and vendor records need to contain the right legal names, VAT numbers, addresses, country codes, local identifiers and routing information.

This is often where projects slow down. Missing VAT numbers, inconsistent addresses or invalid identifiers can block invoice transmission, even if the technical connection is working.

NetSuite users should review master data before implementation starts. The earlier finance teams identify missing fields, inconsistent records or country-specific identifiers, the easier the rollout becomes.

‍

Tax mapping needs to be structured

A correct invoice total is not enough. E-invoicing platforms need to understand the VAT treatment behind the invoice.

That means NetSuite tax codes must map correctly to the structured invoice data: standard VAT, reduced VAT, exemptions, reverse charge, intra-community transactions and local tax requirements.

If the tax explanation is unclear or inconsistent, the invoice may fail validation even if the amount is mathematically correct.

This is why e-invoicing is a finance process topic, not only an integration topic. The tax logic in NetSuite needs to be understandable by the receiving platform, the customer and, where applicable, the tax authority.

‍

AR and AP flows both matter

Many teams start with outgoing invoices because issuance deadlines create pressure. But e-invoicing also affects supplier invoices.

Incoming e-invoices need to be received, validated, matched, approved and posted. For companies using purchase orders, goods receipts or approval workflows in NetSuite, AP readiness should be part of the project from the start.

In our e-invoicing mandates webinar recap, we explain why AP is part of the project too. E-invoicing is not only about sending compliant customer invoices. It also changes how finance teams receive, process and monitor supplier invoices.

‍

Status tracking becomes part of finance operations

E-invoicing creates a more detailed invoice lifecycle. Finance teams need to know whether an invoice has been generated, sent, accepted, rejected or blocked by an error.

This requires dedicated records, saved searches, dashboards or status fields in NetSuite. Without this layer, teams end up checking external portals manually or managing exceptions in spreadsheets.

The goal should be simple: finance users should not need to leave NetSuite for routine monitoring. They should be able to see what happened, what failed and what needs action directly from the ERP.

‍

Custom fields and templates need review

Many NetSuite environments are customized. Required data may sit in custom transaction fields, customer fields, subsidiary fields or connected systems.

Before go-live, teams should confirm where each required value is stored, whether it is mandatory, how it is validated and how it maps into the structured invoice payload.

This is one of the reasons e-invoicing projects should include a review of the real NetSuite configuration. Standard documentation is not enough if your company uses custom fields, specific approval rules, connected billing tools or entity-specific invoice templates.

‍

A scalable architecture for multi-country e-invoicing

The wrong approach is to build one isolated integration per country. That may work for the first mandate, but it becomes difficult to maintain as new countries, subsidiaries and transaction types come into scope.

A scalable architecture separates responsibilities clearly.

NetSuite should remain the operational ERP. It should manage invoice creation, customer and vendor data, tax logic, approval workflows, accounting and finance visibility.

The e-invoicing layer should manage structured conversion, format requirements, platform connectivity, regulatory updates, transmission and status feedback.

This is the logic behind the Novutech x Invopop solution for NetSuite e-invoicing. Novutech manages the NetSuite connector and ERP-side workflows, while Invopop manages the compliance layer, including GOBL, country formats, networks and platform requirements.

For finance teams, the goal is simple: stay in NetSuite as much as possible, while complying with local e-invoicing obligations in the background.

This approach is especially relevant for companies with multi-country operations. Instead of rebuilding the logic country by country, finance teams can rely on a common NetSuite-side architecture and let the compliance layer handle local output requirements.

‍

How to choose the right e-invoicing setup

The right setup depends on your country scope, entity structure, transaction flows and ERP maturity.

Start with these questions.

Which countries and legal entities are in scope?
Mandates vary by jurisdiction and entity type. A Belgian subsidiary, a French entity and a German entity may each require different formats, identifiers or platform connections.

Which invoice flows are in scope?
Accounts receivable, accounts payable, credit notes, intercompany transactions, domestic B2B, B2C and exports may follow different rules.

Which formats are required?
Depending on the country and transaction type, you may need to support UBL, Factur-X, XRechnung or other structured formats.

Which networks or platforms are required?
Some countries rely on Peppol. Others require accredited platforms, tax portals or clearance-style systems.

Is master data complete?
Missing VAT numbers, local identifiers, addresses or routing data can block invoice transmission.

Are tax codes mapped correctly?
E-invoicing validation depends on structured VAT logic, not only on the final invoice amount.

Can statuses return to NetSuite?
Finance teams need to know whether invoices have been sent, accepted, rejected or blocked by an error.

Has testing covered real scenarios?
Do not test only one clean invoice. Include credit notes, VAT exemptions, reverse charge, multi-line invoices, rejected invoices, supplier invoices, purchase order matching and country-specific routing.

If you are not sure where to start, use the NetSuite e-invoicing readiness checklist as a first internal assessment. It helps structure the work around entity scope, data cleanup, tax mapping, AR/AP flows, sandbox testing and governance.

‍

E-invoicing implementation checklist for NetSuite

Before implementing e-invoicing in NetSuite, finance and operations teams should confirm that the following areas are ready.

Start with legal entity and country scope. List every subsidiary, country, transaction type and mandate deadline. This gives the project a clear boundary and avoids late-stage surprises.

Then review AR and AP transaction types. Customer invoices, credit notes, supplier invoices, purchase orders, intercompany flows and e-reporting transactions may each require different logic.

Next, audit customer and vendor master data. VAT numbers, local identifiers, registered addresses, country codes, email addresses and routing information need to be complete and consistent.

Review tax code mapping and exemption logic. A structured e-invoice must explain the tax treatment, not only show the final amount.

Check invoice templates and required fields. Some data needed for compliance may not appear on the current invoice template or may be stored in custom fields.

Review custom fields used for compliance data. If required values sit outside standard NetSuite fields, the connector and templates must be adapted.

Define the integration architecture. Decide how NetSuite connects to the e-invoicing layer, how statuses return to NetSuite and how exceptions are handled.

Create saved searches and exception dashboards. Finance teams need visibility on invoices that are generated, sent, accepted, rejected or waiting for action.

Test real scenarios in sandbox. Do not rely on one standard invoice. Include the scenarios your business actually uses.

Train users and define support ownership. Finance teams need to understand what changes in their daily work, while admins need clear ownership for errors, updates and monitoring.

This is not just a compliance exercise. Done properly, e-invoicing can improve data quality, reduce manual invoice handling and give finance teams better visibility across countries.

‍

Why Novutech for NetSuite e-invoicing

Novutech helps European growth companies prepare NetSuite for e-invoicing as part of a broader finance transformation roadmap.

With 250+ customers across Europe, 65+ experts, 100+ certifications and more than 90% client retention post go-live, Novutech combines ERP knowledge with finance process expertise. That matters because e-invoicing projects sit at the intersection of compliance, data, tax, integration, user adoption and long-term ERP scalability.

Novutech can help assess your NetSuite readiness, clean and structure data, define country scope, configure AR and AP flows, connect NetSuite to the right e-invoicing infrastructure, test real scenarios and support your team after go-live.

If you want to understand how this works in practice, read more about our NetSuite e-invoicing solution for Europe or explore our broader NetSuite services.

‍

Final takeaway: standards are only useful if your ERP is ready

E-invoicing standards are the technical foundation. But they are not the whole project.

EN 16931, UBL, Peppol, Factur-X, XRechnung and GOBL only create value if the ERP behind them is ready. For NetSuite users, that means clean master data, reliable tax mapping, structured invoice workflows, status visibility and an architecture that can scale across countries.

The companies that handle e-invoicing best will not be the ones that memorize every format. They will be the ones that build a finance setup where compliance is embedded into daily operations.

‍

Ready to prepare NetSuite for e-invoicing?

If you want to understand which e-invoicing standards, formats and networks apply to your countries and entities, Novutech can help you assess your NetSuite setup and define a practical roadmap.