NetSuite E-Invoicing Compliance: Which Mandates Affect You and What to Do Now

If you run NetSuite across European entities, e-invoicing has stopped being something the tax team monitors from a distance. Germany, Belgium, France and Poland each now have a live or fast-approaching legal requirement that changes what counts as a valid invoice, and an invoice is generated, formatted and archived by your ERP. That makes this a NetSuite project with a real deadline, not a policy update to read about later.

None of these mandates hit every business on the same date, and none of them require the same response. Some are already receiving-only obligations you may already be behind on. Others do not start issuing requirements until 2027 or 2028. This guide sets out exactly what applies where, what NetSuite handles on its own, and where you genuinely need more.

What E-Invoicing Actually Changes for a NetSuite Business

An e-invoicing mandate is not a request to send invoices electronically instead of by post. Most businesses already do that. The legal change is narrower and more specific: once a mandate applies to you, only a structured, machine-readable format counts as a valid tax invoice. A PDF, a scanned image or an emailed printout no longer qualifies, even though it looks identical to a human reader.

That single distinction affects four things your NetSuite instance controls directly: the format an invoice is generated in, how it is transmitted to the counterparty, how it is archived, and how tax data is captured on each line rather than just printed as a total. None of those are tax-team decisions. They are ERP configuration decisions, which is why this now sits with whoever owns NetSuite.

At a Glance: When Each Mandate Applies

These are the four countries with the clearest, most current requirements and the strongest relevance to NetSuite OneWorld estates. Dates below are the confirmed positions as officially published; where a date is still described as tentative by the source itself, that is noted.

Beyond these four, the EU’s VAT in the Digital Age reform sets a separate, later horizon: cross-border digital reporting becomes mandatory from 1 July 2030, and countries that already ran their own domestic real-time reporting before 2024 have until 1 January 2035 to align that system with the EU standard. That is a planning horizon, not an immediate deadline, and it does not change any of the country dates above.

Country-by-Country Requirements

Germany

Germany’s mandate sits under the Wachstumschancengesetz (Growth Opportunities Act), which amended Section 14 of the German VAT Act. The Federal Ministry of Finance’s own guidance defines a valid e-invoice as one in a structured electronic format that enables electronic processing, explicitly stating that a plain PDF no longer meets that definition.

Receiving capability has been required since 1 January 2025. Through 2026, any business may still choose to send a conventional invoice.

From 1 January 2027, businesses with prior-year turnover above €800,000 must issue structured e-invoices for domestic B2B transactions; smaller businesses and EDI users not yet compliant with the EN 16931 standard get until the end of 2027. From 1 January 2028, the obligation applies to all domestic businesses regardless of size.

Accepted formats are XRechnung and ZUGFeRD version 2.0.1 or later (excluding its most basic profiles), both built on the EN 16931 European standard. Peppol is mandatory for German business-to-government invoicing but remains optional for B2B; email or another electronic channel is acceptable provided the invoice format itself is compliant.

Archiving is where estates most often get caught out. Retention was reduced from ten years to eight from 1 January 2025, and the invoice must be kept in its original structured format, not a PDF rendered from it. A ZUGFeRD file has to be archived with its embedded XML intact.

Belgium

Belgium’s mandate, confirmed by the European Commission’s own eInvoicing country page, took effect on 1 January 2026 under a federal law amending the VAT Code. Unlike Germany, Belgium did not phase this by company size: all Belgian VAT-registered businesses are in scope for domestic B2B transactions from day one, with intra-community and a small number of exempt transaction types excluded.

Belgium took a different technical approach to Germany as well. Peppol is not optional here. The Peppol BIS Billing 3.0 format, transmitted over the Peppol network, is the default and expected route; an alternative format is only usable by mutual agreement between both parties and must still be convertible to EN 16931.

France

France’s requirements come from Article 91 of the 2024 Finance Law. The European Commission’s 2026 country factsheet for France, updated July 2026, confirms the phased dates: all businesses must be able to receive e-invoices from 1 September 2026, large and medium-sized companies must issue from that same date, and SMEs and micro-businesses follow from 1 September 2027.

France pairs e-invoicing with a separate e-reporting obligation covering B2C and cross-border transaction data, on the same phased dates. Invoices must pass through a government-accredited platform (a Plateforme de Dématérialisation Partenaire, formerly referred to as a PDP), since the originally planned free public platform was discontinued in October 2024. Nearly 100 platforms are currently accredited, so this is a genuine selection decision, not a formality.

Poland

Poland’s Krajowy System e-Faktur (KSeF) is a centralised, government-run platform rather than a distributed network like Peppol, confirmed via the European Commission’s eInvoicing page for Poland. Every invoice is submitted to KSeF, validated, timestamped and only then considered issued, which makes this closer to a real-time clearance model than the other three countries here.

Large taxpayers with turnover above 200 million PLN (roughly €46 million) are in scope from 1 February 2026, with the rest of the B2B market following from 1 April 2026. Micro-enterprises trading below a small monthly threshold reportedly have until 1 January 2027, based on published guidance from Poland’s Ministry of Finance; verify your own entity’s exact position against KSeF’s official portal before treating that date as fixed, since Poland’s timeline has already shifted once.

The required format is a FA-series XML schema, and no financial penalties apply for the whole of 2026, giving a genuine grace period to work through technical issues.

What NetSuite Handles Natively, and Where It Does Not

Oracle publishes a dedicated European Union Electronic Invoicing SuiteApp, and its actual coverage is more specific than “NetSuite supports e-invoicing in Europe” suggests. It matters which direction each country’s support covers.

The gap that matters most is Germany. Oracle’s own documentation describes the German capability as receiving and processing inbound vendor bill transactions in XRechnung format, with no equivalent listed for outbound issuing. For a business facing Germany’s 2027 or 2028 issuing deadline, that means the native SuiteApp alone does not close the requirement; something else has to generate and transmit the outbound structured invoice.

The SuiteApp itself also has real prerequisites worth knowing before you scope anything: it requires a OneWorld account, the Custom Transactions feature enabled, and four other SuiteApps installed first (Advanced Localization Features, EMEA Localization, Localization Assistant and NetSuite Electronic Business). A standard, non-OneWorld NetSuite account cannot install it at all.

Where External Platforms or Integrations Enter

Once native coverage stops short, three routes exist, and which one fits depends on your footprint rather than a general rule.

Native NetSuite plus configuration works where your countries and direction of flow are already covered by the SuiteApp, and your volumes and format needs are straightforward. Confirm this against your actual NetSuite edition and installed localizations rather than assuming coverage, given how country- and direction-specific it is.

A certified third-party platform fills a specific gap, such as German outbound issuing, without replacing your whole invoicing stack. This is usually the fastest route to close one country’s gap.

An integration or mapping layer makes sense once you are managing several countries with different formats, networks and deadlines. If you already run an iPaaS such as Celigo for NetSuite integrations, routing e-invoicing through that same layer keeps country logic centralised instead of duplicated per subsidiary. Our NetSuite integration architecture guide covers how to evaluate that kind of layered decision generally.

Single-Country Versus Multi-Country Architecture

Do not default to “we need middleware” or “native is enough” without checking the actual variables. The real decision inputs are: how many of these countries you operate in, whether native coverage already reaches the direction you need, whether you already run an integration platform for other NetSuite work, your invoice volume, and how much internal capacity you have to maintain country-specific mapping logic as rules change.

One country with native coverage in the direction you need is often a configuration project. Multiple countries, or a country like Germany where native coverage does not reach the obligation you are actually facing, usually justifies a platform or integration layer, because the alternative is maintaining several independently changing rulebooks by hand.

Readiness and Data-Quality Risks

Two other risks are easy to miss. Tax determination logic has to produce correct, machine-readable data per line, not just a correct total on a rendered document. And archiving needs a storage decision made before go-live, not after: many NetSuite estates render and store a PDF at the point of transaction, and if that PDF replaces the original structured file, the compliant record has effectively been destroyed.

A Phased Preparation Plan

1. Map your footprint. List every entity, its country, and which mandate and date actually applies to it. Confirm receiving, issuing and reporting separately, since they are not the same obligation.
2. Audit master data. VAT numbers, legal addresses and network identifiers, validated against source, not assumed correct because they have always been there.
3. Confirm native coverage per country and direction. Check your specific NetSuite edition and installed localizations against what Oracle’s SuiteApp actually supports for each country you operate in, not what it supports in general.
4. Choose the architecture. Native, a certified platform for a specific gap, or an integration layer, based on the variables above rather than a fixed rule.
5. Fix the archiving approach explicitly. Decide how original structured files are retained before your first live invoice, not after.
6. Test with real trading partners. Sandbox testing alone will not surface every formatting and transmission issue a live counterparty will. Test inbound receiving as seriously as outbound issuing, since receiving is already a live obligation in more countries than issuing.
7. Build in buffer before your deadline. Starting the plan in the quarter before a deadline is the most common failure pattern seen across these rollouts generally, not specific to any one country.

Practical Owner Checklist

• List every NetSuite entity and the country mandate that actually applies to it, with its exact date.
• Separate the receiving obligation from the issuing obligation for each country; they are rarely the same date.
• Audit VAT numbers, legal addresses and network identifiers across customer and vendor master data.
• Confirm which countries and directions your current NetSuite edition and localizations genuinely cover.
• Decide the archiving approach for original structured files before go-live.
• Identify whether an existing iPaaS or integration layer should be extended to cover e-invoicing.
• Confirm your organisation’s exact obligations with a qualified local tax or legal adviser before relying on any date in this guide.

Sources and Related ERP Peers Resources

Country and EU-level facts in this article are drawn directly from the German Federal Ministry of Finance, the European Commission’s eInvoicing Country Sheets, and Oracle’s NetSuite documentation, cited beside the claims they support above.

For the broader platform this sits on, our guide to NetSuite OneWorld covers multi-subsidiary and multi-country structure generally. If EDI is part of your estate, our NetSuite EDI integration guide covers how those setups are usually structured, and teams already running an iPaaS should see our Celigo NetSuite integration page for what extending that layer looks like in practice.