A catering company buys fifty croissants at a bakery. The buyer pays, then asks one more question: “Please send us an e-invoice.”
For the bakery, the sale is done. The invoice is where the work starts. Which format? Which network? Which customer details? And does the answer change across the border?
Across Europe, the answer depends on the country. Is e-invoicing mandatory in Europe? For sales to public bodies, yes, everywhere in the EU. For business-to-business sales, it depends on the country and often on the size of the company. Some countries already require e-invoices, others introduce the duty in phases, and EU regulation will push the trend further. Europe has no single e-invoicing system: Austria, Germany, France, Italy and Poland each set their own formats, transmission networks, clearance schemes, buyer IDs and dates.
This article follows the sale from the till to the e-invoice. You learn what changes in Europe, what the change means for Developers, Partners, and Merchants and how fiskaltrust keeps the national differences out of your checkout.
For technical requirements, see the:
fiskaltrust e-invoicing technical documentation1. One sale, many sets of rules
Invoices in Europe are moving from paper and human-oriented documents to structured data that business software processes directly. A PDF attached to an email is digital, and still not a structured e-invoice. An e-invoice stores supplier, buyer, line items, VAT numbers and amounts in machine-readable form, ready for automatic processing.
Picture a POS company with merchants in Austria, Germany, France, Italy and Poland. At the counter, every sale looks the same: a seller, a business customer, a transaction. After the sale, the paths split. In Germany, the invoice follows EN 16931, in a format such as XRechnung or ZUGFeRD. In France, invoices travel through approved platforms, the Plateformes Agréées. In Italy, they go through SDI in the FatturaPA format. Poland has KSeF and its own invoice format. Austria sets e-invoicing rules for the public sector.
A German e-invoice does not turn into an Italian FatturaPA invoice because both countries mandate e-invoicing, and the French platform model differs from the Polish clearance system. Peppol makes Europe more interoperable, but national platforms and requirements still apply.
So the real question for a European POS provider is not how to create one e-invoice. It is how to support the same business process in several countries without turning every national system into a separate POS integration.
2. From sale to e-invoice in five steps
Back at the bakery. For merchants already using fiskaltrust, every sale passes through the fiskaltrust.Middleware. The e-invoice starts from this recorded transaction, not from a separate invoicing process afterwards.
From the outside, the steps look simple. Each one needs accuracy: the right buyer, every required field, the right structure, and the right national or European infrastructure. Here the country differences appear.
The bakery owner selects the sale and the customer. fiskaltrust creates the e-invoice from the transaction data already recorded. Behind the scenes, fiskaltrust keeps a legal copy of every e-invoice for the national retention period, and the owner follows the status in the fiskaltrust.Portal until the buyer accepts the invoice. When an invoice needs a correction, the original is cancelled first and a new invoice is issued, so the same revenue never counts twice.
The rules keep moving. Specifications and formats change, national systems develop, and new requirements arrive. Implementing each change separately in every POS product would never end.
3. Three ways to work with the same sale
A bakery with one catering customer has different needs from a software platform processing invoices automatically at scale. The same transaction therefore works at three levels.
| Where | How |
|---|---|
| Back office | Create the e-invoice from an existing transaction in fiskaltrust.Portal. |
| At the counter | Use fiskaltrust.InStoreApp when buyer information needs to be captured during the sale. |
| Inside the POS | Use the fiskaltrust API when the PosCreator wants the complete experience inside its own software. |
These are not three unrelated products. They are three ways of working with the same transaction. A merchant issuing a few business invoices does not need the same setup as an ERP or POS platform processing thousands.
4. Buyer data decides where the invoice lands
One requirement applies to developers, partners and merchants in every market: identifying the buyer correctly. An e-invoice addressed to a company name alone reaches no one. The process needs enough information to route the invoice to the right recipient.
The details differ by country and purpose: a Peppol ID, a registration number or a national routing identifier. The merchant needs the right details about the business customer. The dealer tells the merchant what to collect. The developer makes sure the POS captures the buyer information correctly and reuses the data at the point of sale.
The format gets most of the attention. Yet an invoice reaches the correct company only when the system knows who the company is.
5. What this means for you
For Developers: build the process, not another country integration
For developers, the European dimension is the most important part of the story. E-invoicing in several countries means several sets of requirements, different formats and channels, connections to national systems and ongoing changes in each market.
fiskaltrust moves as much country-specific work as possible behind the integration. For supported markets, the technical model uses your existing fiskaltrust account, Middleware and credentials. In the API workflow, the POS provides the transaction as a B2B invoice case through the existing /sign flow, supplies the buyer information, and uses /issue for issuing, delivery and status handling.
Your work does not disappear. The POS still has to recognise when a customer requires a business invoice, collect the buyer information and offer the user experience when e-invoicing happens inside the POS. What you skip: implementing every country-specific invoice format, every routing infrastructure and every future development alone.
For Partners: start with the workflow, not the technology
When merchants start asking about e-invoicing, the dealer often takes the first call. The topic sounds like a technical support problem. The first questions are operational.
How often does the merchant issue B2B invoices? Does the customer ask for the invoice at the checkout, or does invoicing happen later in the office? Does the merchant’s transaction data already reach fiskaltrust? And in which countries does the business operate?
The answers show the real requirements. For occasional B2B invoices, a back-office workflow is often enough. When invoices always follow the sale, capturing the buyer at the counter makes sense. For high volumes or automation, integration inside the POS fits best.
The dealer helps activate and configure the system, checks whether the merchant’s sales already reach fiskaltrust, and finds the most convenient workflow without carrying responsibility for every invoice format and delivery channel in each country.
For Merchants: the invoice starts from the sale
The technology behind European e-invoicing is complicated. Your daily routine should stay simple.
Without a connected process, the bakery owner opens another program, finds or retypes the sale, enters the customer data, creates the invoice and sends the document through the country-specific channel. With a fiskaltrust-connected POS, the sale already accepted by fiskaltrust becomes the starting point. The owner works with the sale and the customer, not with XML formats, routing protocols or API endpoints.
Some responsibility stays with you. Customer information must be correct, and country-specific onboarding or business requirements might apply. The technical details of formats and transmission stay out of the checkout.
6. E-invoicing mandates in five markets
The five markets below show why European e-invoicing needs both a common integration approach and country-specific implementation and where mandatory B2B e-invoicing already applies. Status as of 23 September 2026. Legal dates in this area have moved before, so check the current e-invoicing requirements for your own country.
| Market | What is different | Key dates |
|---|---|---|
| Austria | E-invoicing is established for federal B2G transactions; B2B e-invoicing remains voluntary. | B2G since 2014 · ViDA cross-border rules from 1 July 2030 |
| Germany | Every business must receive structured B2B invoices; mandatory issuing is phased in. | Receiving since 1 Jan 2025 · issuing 1 Jan 2027 / 1 Jan 2028 |
| France | Approved platforms, the Plateformes Agréées, connect businesses to the national infrastructure. | 1 Sep 2026 (receive; large and mid-sized issue) · 1 Sep 2027 (SMEs issue) |
| Italy | E-invoicing runs through the national SDI clearance system in FatturaPA. | Mandatory since January 2019 |
| Poland | KSeF is the national central e-invoicing and clearance platform. | 1 Feb 2026 (large) · 1 Apr 2026 (all) · penalties from 1 Jan 2027 |
Austria
Austria has required electronic invoices for B2G business since 1 January 2014, and for all suppliers to the federal government since April 2020 — the public procurement side of e-invoicing. Suppliers to the government use either ebInterface, the Austrian XML standard, or Peppol BIS Billing 3.0. Between private companies, e-invoicing is a choice and rests on agreement between the two partners. No B2B mandate exists today, and none is drafted.
For businesses: Austrian companies with customers or suppliers in Germany, France, Italy or Poland already meet e-invoicing rules through those partners. From 1 July 2030, the EU’s ViDA reform requires structured e-invoices for cross-border B2B sales inside the EU, so Peppol capability and clean customer data built today are not wasted work.
Germany
Germany runs a phased mandate for domestic B2B invoices. Every German business has had to receive structured B2B e-invoices since 1 January 2025. Businesses with turnover above 800,000 euros must issue them from 1 January 2027, and all businesses follow on 1 January 2028. The threshold looks at total revenue in the previous year, so revenue above 800,000 euros in 2026 places a business in the 2027 group. Accepted formats follow EN 16931, with XRechnung, ZUGFeRD and Peppol BIS 3.0 as the main options. Germany uses no central government platform for B2B.
For businesses: A paper invoice or a plain PDF does not count as an e-invoice. Receiving is already a duty for every business, whatever your own issuing date.
France
France carries the nearest deadline. From 1 September 2026, all French VAT-registered businesses must receive e-invoices, and large and intermediate-sized enterprises must also issue them. Small and micro-enterprises follow on 1 September 2027. Every invoice travels through a government-certified approved platform, a Plateforme Agréée, and the required formats are UBL 2.1, CII and Factur-X. Invoice templates also need new mandatory fields, including the customer SIREN and the delivery address.
For businesses: The receiving duty covers every size from 2026, with no exemption. Automatic penalties do not apply until 31 December 2026, and this is no postponement: the legal date stays 1 September 2026.
Italy
Italy was the first EU country to make e-invoices mandatory between businesses. Since January 2019, every domestic invoice goes as FatturaPA XML through the SDI platform of the Agenzia delle Entrate, and the mandate covers all VAT-registered entities with no revenue threshold. Coverage widened in July 2022 to flat-rate taxpayers above 25,000 euros a year, and in January 2024 to all of them. The old quarterly Esterometro report for cross-border invoices disappeared in July 2022; those transactions now run through SDI as well.
For businesses: SDI validates each invoice and either delivers it to the buyer’s registered channel or returns a rejection notice. The most frequent rejection comes from a wrong Codice Fiscale or Partita IVA on either side, so customer data quality decides your daily workload.
Poland
Poland now runs one government platform for invoices, KSeF. The seller sends the invoice to KSeF, KSeF checks it and gives it a number, and the buyer collects it from the platform. Invoices between Polish businesses no longer travel by email or post. Businesses with 2024 sales above 200 million PLN have sent every domestic B2B invoice through KSeF since 1 February 2026. All other VAT-registered businesses followed on 1 April 2026, and every VAT-registered business has had to receive invoices through KSeF since 1 February.
The smallest businesses have more time: while invoices issued outside KSeF stay under 10,000 PLN a month including VAT, the old way of invoicing remains allowed until 1 January 2027. KSeF accepts one invoice template, an XML file with fixed field names and a version number. Version FA(3) replaced FA(2) on 1 February 2026, with new VAT rate codes, more payment fields and the option to carry attachments. Any system still producing FA(2) gets rejected.
For businesses: 2026 is a transition year without KSeF penalties; penalties apply from 1 January 2027, so use the time to get the process right. From 1 January 2027, payments have to carry the KSeF number of the invoice, so matching payments to invoices depends on this number. An offline mode covers a lost connection: issue the invoice, then send it to KSeF by the next business day. The buyer collects every invoice from the platform, so the buyer’s tax number has to be correct.
Five countries, five systems. The transaction itself does not change because the sale happens in another European country. The infrastructure behind the invoice changes a great deal.
7. What Europe shares: EN 16931, Peppol and ViDA
With so many national differences, does Europe share anything at all? Yes. EN 16931 provides a common semantic foundation for structured e-invoices, and Peppol provides a network for exchanging structured business documents between organisations. Together they make interoperability across Europe practical — without making national legislation disappear. The European picture is a common foundation with national implementations built around it.
ViDA, the EU reform “VAT in the Digital Age”, adds an EU layer. From 1 July 2030, ViDA requires structured e-invoices with digital reporting for cross-border B2B sales inside the EU, and national e-invoicing systems need to align with the EU model by 1 January 2035. Alignment does not mean identical systems: each member state keeps its own rules.
For software providers, the question is therefore not only whether a POS meets the next national requirement, but whether it handles the next change without rebuilding the whole process.
8. E-invoicing is not e-reporting
The two terms sound alike and cover different processes. Some national reforms contain both; they remain separate products and technical processes.
- E-invoicing
- The creation, transmission and tracking of the structured invoice.
- E-reporting
- The transmission of transaction, invoice or VAT information to the tax authority.
The fiskaltrust e-invoicing add-on covers the creation, transmission and tracking of structured invoices. E-reporting is a separate topic and not part of the add-on.
9. Where to start
| Role | A useful starting point |
|---|---|
| Developer | Review the common technical documentation, confirm your current API setup and then review the implementation requirements for each market you intend to support. |
| Partner | Review your merchant base by country and identify which customers need occasional back-office invoicing, invoicing at the counter or a directly integrated POS workflow. |
| Merchant | Check the current requirements in the country where you operate and speak with your POS provider, dealer or fiskaltrust contact about whether your existing setup is ready. |
10. Europe will not become one country
European e-invoicing is not about Europe switching to one invoice type or one technology. National specifics stay, and companies and software vendors follow the rules of the markets they serve. The goal is to stop every national difference from becoming another independent process inside the POS: the merchant concentrates on the transaction and the customer, the dealer helps merchants adopt e-invoicing without becoming an expert in every format, and the developer builds the business process without maintaining every national infrastructure behind it.
That is the role of fiskaltrust.eInvoice: connecting the transaction at the point of sale with the e-invoicing infrastructure that follows it. The transaction is the common starting point; what happens next depends on the market.
And the bakery? The owner selects the sale, picks the catering company from the saved customers, and goes back to the ovens.
11. Technical documentation for POS creators
Should you have any questions about the content in this article or how e-invoicing applies to your setup, please contact us.

Disclaimer: E-invoicing regulations differ by country and change across Europe as governments publish new laws, deadlines and technical specifications. This article reflects the information available on 23 September 2026. The content serves general information only and does not replace legal or tax advice. Before you make decisions for your business, contact fiskaltrust to verify the requirements for your country.

