
e‑invoicing is becoming a hard mandate, not a "nice‑to‑have", and the technical bar is being set by tax authorities and standard‑setting bodies rather than finance teams or ERPs.
Across the EU, Latin America, and Asia, finance teams are adapting to broad B2B e‑invoicing mandates that apply across all sectors, not just one industry at a time.
If your logistics, SaaS, retail, construction, healthcare or PMS stack cannot produce EN 16931‑compatible, tax‑ready data into recognised networks, you risk failed clearance, late payments and non‑compliance as EU‑style continuous transaction controls (CTC) spread.
At its core, an e‑invoice is structured data that can be issued, transmitted, and received automatically end‑to‑end. Under the European e‑invoicing standard EN 16931 and ViDA, compliant implementations rest on four pillars:
Use a schema aligned with EN 16931 so parties, VAT treatment, totals and line‑level taxes are machine‑readable and interoperable. The VAT in the Digital Age package will make EN 16931‑compliant structured e‑invoices mandatory for intra‑EU digital reporting from 2028 onwards, with Member States preparing mandatory B2B schemes on the same backbone.
Most European public bodies are now required to receive EN 16931‑compliant invoices. The same set of syntax rules, UBL and UN/CEFACT CII, are reused in national frameworks such as XRechnung (Germany), FatturaPA (Italy), and facturae (Spain). OpenPeppol's four‑corner model and AS4 transport have become the de facto "trusted rail" for B2G/B2B interoperability, complemented by country platforms and emerging four‑corner networks such as the US Digital Business Networks Alliance (DBNA).
Invoices rely on mechanisms recognised in EU law, such as eIDAS and the VAT Directive, as qualified electronic signatures, secure channels, or strong business controls.
Invoices must be stored in a tamper‑proof way for the retention period defined in each Member State's transposition of the VAT Directive.
Logistics and freight ran on PDF attachments, manual keying, and disputes over surcharges. Real‑time tax controls are forcing structure into that chaos. In many European markets, freight carriers and forwarders now issue machine‑readable invoices via PEPPOL or local networks, rather than PDFs by email.
Technically, this means mapping complex charge structures, fuel, detention, demurrage, and accessorials into standardised line types and tax categories recognised by EN 16931 and local VAT rules.
Transport Management Systems and warehouse platforms integrate with e‑invoicing gateways to keep shipment events and invoice data in sync. Multiple endpoints must be supported: public customers via national B2G portals, private shippers via PEPPOL, and customs or VAT systems for digital reporting.
A concrete example: Logitude, a global freight‑forwarding SaaS, integrated DDD Invoices’ unified API to meet Belgium’s PEPPOL‑based e‑invoicing mandate in about one month, with only two integration meetings. By sending one standard JSON payload to DDD Invoices, Logitude now has compliant format delivery to the network and evolving CTC/ViDA rules handled externally.
The payoff? fewer disputes and faster receivables, but only if master data is consistent across all systems feeding the invoice.
SaaS billing engines already think in structured data: customer IDs, plans, metered usage, and tax codes. The gap is translating that into invoices that comply with EU VAT rules and emerging real‑time reporting under VAT in the Digital Age (ViDA).
For subscription and usage-based SaaS, the technical priorities are:
In practice, this means mapping subscription lifecycle events (sign‑up, upgrade, downgrade, renewal, cancellation) plus usage records into a single invoice object that can be transformed into local formats and sent through the right channel (PEPPOL, national CTC platforms, or direct B2B delivery) without touching the billing UX. If done well, your invoice API becomes an asset for large customers’ procurement and AP teams, not just a compliance checkbox like it is with Step Adria.
Retail is where e‑invoicing meets real‑time point‑of‑sale: high volume, thin margins and mixed B2C/B2B flows.
In clearance and centralised-exchange regimes such as Italy, retailers must send invoices or fiscal receipts in a structured format to a central platform, which reuses the data for VAT control and, increasingly, for other reporting. Most journeys start at the POS by mapping item, tax and customer data into an EN 16931‑compatible schema that can be reconstructed into full invoices on demand, especially for B2G or large B2B customers. That’s exactly what a boutique retail software vendor in Montenegro did when new fiscalization rules required real‑time tax reporting.
In fiscalization regimes like Montenegro, every POS sale becomes a signed XML record with a unique identifier and QR code that lets tax authorities and even customers verify the receipt in real time, turning the POS into a regulated tax device rather than just a sales screen.
Retail software has to validate those QR‑coded receipts, reconcile them against daily Z‑reports and ensure that what the POS shows matches what was cleared centrally. Retailers then rely on scalable transport options, PEPPOL for public buyers, national platforms where they exist and direct B2B integrations for key accounts, while automating validation and rejection handling so peak-season volumes don’t explode back into manual rework.
Montenegro, instead of maintaining a brittle local solution, embedded DDD Invoices’ standardised API so that every POS sale became a compliant, real-time-reported invoice without changing the front-end workflow.
Public-sector construction is fully inside the EU public procurement and e-invoicing framework, so suppliers must issue EN 16931‑compatible invoices into national B2G platforms. In many EU countries, those B2G platforms are reachable via PEPPOL, so once a construction vendor connects through an access point, they can reuse the same rail for project‑based invoices to multiple public buyers instead of maintaining bespoke integrations per portal.
From a tax and legal perspective, construction e‑invoicing has to capture VAT rules for works of immovable property, including reverse‑charge scenarios and the correct place‑of‑supply flags.
Orders, contracts and acceptance certificates are linked via identifiers recognised by national e‑procurement or B2G portals; get the structure wrong and the invoice is rejected at the gateway before the due date even starts running.
A practical example is the Climatherm–GSoftware partnership in Montenegro, where a construction‑adjacent ERP vendor plugged DDD Invoices into its existing workflows to handle local fiscalization and e‑invoicing rules without rewriting its project billing module. By sending standardised invoice data to DDD Invoices, GSoftware could issue compliant invoices for Climatherm’s climate and thermal projects and reuse PEPPOL and other rails where needed. If you want to see how that
Healthcare adds two constraints on top of “normal” invoicing: strict protection of medical data and a dense layer of VAT exemptions under Article 132 of the VAT Directive. e‑Invoicing has to expose explicit VAT codes and exemption reasons at the line level while keeping protected health information out of the payload.
Hospitals and clinics integrate e‑invoicing with hospital information systems, pharmacy systems and insurers via APIs that reference internal case or episode IDs without leaking diagnostic content.
Because many providers bill public payers, B2G e‑invoicing and compliance with the European standard are particularly critical here, and health‑sector data standards such as HL7 are often used to align clinical identifiers with fiscal records.
A good example is the partnership with Savo Medenica s.p., a specialised accounting software provider serving communal and utility companies in Montenegro, where DDD Invoices was integrated to handle fiscalised invoicing and near real-time reporting without exposing sensitive operational details in the payload. By moving from a bespoke local setup to a standard API, Savo Medenica could keep its healthcare‑adjacent clients’ billing logic and clinical references in their existing systems while letting DDD Invoices apply the correct signatures, QR codes and tax reporting flows in the background
Property and hospitality platforms already manage recurring rent, service charges, utilities and ad-hoc fees; e-invoicing turns that stream into a formally regulated VAT data set. At the e‑invoicing level, most PMS flows boil down to four transaction types: recurring rent, recurring service charges, metered utilities and one‑off charges for ad‑hoc services or damages.
A good illustration of this pattern is Zenoti’s work with DDD Invoices, where Zenoti needed to make membership fees, prepaid packages and one‑off services fiscally compliant across multiple European countries directly from its own platform. By integrating the DDD Invoices API, Zenoti can automatically convert every appointment, membership renewal and retail sale into a locally compliant invoice or fiscal receipt. Applying the right VAT rules, fiscalization steps and B2B/B2G reporting without forcing salons, spas and clinics to change how they manage customers, pricing or bookings inside Zenoti.
By exposing e‑invoicing capabilities via APIs, PMS systems let operators automatically issue compliant invoices to tenants, guests and corporate accounts and route them via national platforms or PEPPOL where required. With robust archiving and retrieval, often built on PDFA‑3 and long‑term storage rules, PMS data becomes a single source of truth for both occupancy/revenue and VAT reporting and audit defence across multiple property cycles.
ViDA will make structured EN 16931‑compliant e‑invoices and near real‑time reporting the default for intra‑EU B2B by 2030, on top of national CTC and clearance regimes. DDD Invoices keeps you ahead of this with one API that converts your existing invoice objects into locally compliant documents for 30+ countries, including platforms like Poland’s KSeF, Hungary’s NAV, Romania’s RO_Cius and Serbia’s SEF.
Behind the scenes, DDD Invoices maps a single JSON schema to EN 16931‑derived XML, validates against local rules, and routes via tax portals, PEPPOL, national networks or corner models, feeding status back into your ERP, SaaS, POS, PMS or marketplace. The same stack ingests PDFs and scans with AI, and archives everything in a tamper‑proof, GDPR‑compliant way.
If you want mandates, interoperability and archiving handled as infrastructure instead of product debt, integrate DDD Invoices once and reuse it as each new country or CTC rule goes live.
Not yet, but under the ViDA, structured EN 16931‑compliant e‑invoices and digital reporting will become mandatory for intra‑EU B2B transactions by 2030, with many Member States rolling out national B2B mandates earlier.
It means the invoice uses the European semantic data model, so core elements (supplier, customer, VAT treatment, totals, and line‑level tax) are represented in a harmonised, machine‑readable way, using approved syntaxes like UBL or UN/CEFACT CII.
They share the same EN 16931 core model, but each country and sector can define usage specifications and extra fields (for example, XRechnung in Germany, FatturaPA in Italy, facturae in Spain, or health-sector and construction-specific extensions).
They implement four‑corner exchange models with agreed standards, so any sender connected via an access point can reach any receiver, while tax authorities trust the transport (AS4, security, governance) for B2G and increasingly B2B transactions.
DDD Invoices exposes one JSON‑based API and hides country‑specific formats, tax rules and network connections, generating local EN 16931‑derived XML and delivering it via tax portals, PEPPOL or national networks while keeping the industry app’s UX untouched.
Written by the Compliance & Growth Team
Reviewed by Denis V. P.