ZUGFeRD, XRechnung, Factur-X, UBL — on your own servers, in your own code
Aloaha Limited's e-invoicing SDK creates and reads ZUGFeRD, XRechnung and Factur-X invoices in CII syntax from VB6, VBA, VB.NET, C# and Web Services. It also reads UBL / PEPPOL invoices and converts them to ZUGFeRD — the same library doubles as a UBL-to-CII bridge. Invoice data never leaves your process. Ready for the German 2025 B2B e-invoicing mandate.
The mandate has already started. The rest of the EU is on the same runway.
The German Wachstumschancengesetz introduced the phased transition to mandatory B2B electronic invoicing. Germany is not alone: France, Italy, Poland, Spain, Belgium and the Netherlands are on parallel tracks, and the EU-wide VAT in the Digital Age (ViDA, Council Directive 2025/516) will unify cross-border invoicing between 2030 and 2035. The dates below are current as of August 2026 — verify with the primary sources on zugferdpro.com and your Member-State tax authority before making dated procurement commitments.
| Date | Jurisdiction | Obligation |
|---|---|---|
| 2019-01-01 | Italy | All B2B invoices must transit the Sistema di Interscambio (SDI) in FatturaPA XML. Historical baseline; SDI has processed >6 billion invoices to date. |
| 2020-04-18 | EU-27 (B2G) | Directive 2014/55/EU mandatory for all public-sector (B2G) invoicing; every contracting authority in the EU must accept EN 16931-conformant invoices. |
| 2025-01-01 | Germany | All German businesses must be able to RECEIVE structured electronic invoices (ZUGFeRD / XRechnung) from other German businesses. Paper and unstructured PDF may still be SENT, but the recipient cannot refuse a structured one. Small-amount invoices ≤ EUR 250 and tickets exempt. |
| 2026-01-01 | Germany | Paper invoices in domestic B2B are no longer legally compliant. Unstructured PDF-only invoices are also no longer legally compliant unless they carry the embedded ZUGFeRD / Factur-X XML payload. |
| 2026-09-01 | France | Mandatory RECEIVE for all businesses via Chorus Pro / Partner Dematerialization Platforms. Mandatory ISSUE for large enterprises (> EUR 50m turnover or > 5000 employees) and mid-caps (EUR 1.5m to 50m). Factur-X (CII) or UBL 2.1 acceptable. |
| 2026 | Belgium | Mandatory B2B PEPPOL BIS Billing 3 (UBL) between all VAT-registered Belgian businesses. Bilateral peer-to-peer OK, but PEPPOL is the fallback network. |
| 2027-01-01 | Germany | Businesses with annual turnover > EUR 800,000 must ISSUE structured electronic invoices for all domestic B2B. Below-threshold businesses may still send PDFs for one more year. |
| 2027 | Poland | Mandatory KSeF (Krajowy System e-Faktur) B2B; second attempt after the 2024 postponement. FA(2)/FA(3) XML through the national platform. |
| 2027 | Spain | Mandatory B2B e-invoicing under Ley Crea y Crece, phased by turnover (large first, SMEs second). FacturaE + a routing platform obligation. |
| 2027-09-01 | France | Mandatory ISSUE extends to small and micro enterprises. Full B2B coverage complete. |
| 2028-01-01 | Germany | Mandatory ISSUE extends to every German business regardless of turnover. Paper and unstructured PDF no longer permitted for domestic B2B. Only Factur-X / ZUGFeRD (hybrid) or plain XRechnung XML remain. |
| 2030 | EU (cross-border) | ViDA phase 1 — mandatory cross-border B2B e-invoicing between EU businesses under Council Directive 2025/516 (VAT in the Digital Age). Reporting to national tax administrations within a few days of dispatch; national systems must be compatible with the ViDA schema. |
| 2035 | EU-27 | ViDA phase 2 — harmonised Digital Reporting Requirements (DRR) across all Member States retire national divergences. The EN 16931 semantic model becomes the definitive cross-border reference. |
A surprisingly large share of ERP, accounting and billing software still emits flat PDFs that are not machine-readable. Bolting on a structured-invoice generator before each market's go-live date is now the most common e-invoicing project across the EU — and the primary reason the Aloaha ZUGFeRDPro SDK shipped its OEM licence programme.
Operations covering the entire invoice lifecycle (CII-native, UBL-aware)
Create
Build a ZUGFeRD or XRechnung XML payload from your existing invoice data. Fill all EN 16931 mandatory and optional fields: parties, line items, tax breakdown, payment terms, allowances and charges, references, attachments.
Embed
Take an existing PDF/A or PDF/A-3 invoice and attach the structured XML to it. Visual layout is preserved bit-for-bit; the machine-readable payload lives alongside as an embedded file per the PDF/A-3 specification.
Convert
Direct XML to PDF/A-3 conversion: hand the SDK a ZUGFeRD or XRechnung XML and a Word template, get back a single PDF/A-3 file that is both human-readable and machine-extractable. CSV import for spreadsheet workflows.
Extract
Pull the embedded XML out of any received ZUGFeRD or Factur-X PDF. Read structured fields without OCR: amounts, tax codes, due dates, Leitweg-ID, payment references.
Read
Parse a ZUGFeRD, XRechnung or Factur-X invoice (CII syntax) into typed objects your accounting code can iterate over. The same loader also accepts UBL 2.1 / PEPPOL BIS Billing 3 documents into the same internal model — meaning the SDK doubles as a UBL-to-CII converter: read PEPPOL on the way in, emit ZUGFeRD on the way out.
Sign
XAdES on the XML payload, PAdES on the wrapping PDF, RFC 3161 timestamps via the sister Aloaha timestamping service. Detached or enveloped signatures.
Convert UBL → CII
Receive a PEPPOL or UBL XInvoice from an EU partner, load it into the SDK, write it back out as ZUGFeRD or XRechnung — same call shape, same in-memory model. Useful for German recipients whose ERP expects CII but whose EU suppliers send UBL.
One SDK, four output families
| Standard | What it is | Where it matters |
|---|---|---|
| ZUGFeRD 2.x | Hybrid PDF/A-3 + UN/CEFACT CII XML. Profile family: MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED, XRECHNUNG. | SDK reads + writes. German B2B and B2G; the default output of the SDK. |
| XRechnung (CII) | German federal B2G profile in UN/CEFACT CII syntax. Leitweg-ID routing identifier mandatory. | SDK reads + writes. Mandatory for invoicing federal and most state authorities in Germany. |
| Factur-X | French national profile, technically a ZUGFeRD 2.x family member with French semantics. Hybrid PDF/A-3 + CII XML. | SDK reads + writes. French B2B between 2026 and 2027; Chorus Pro for B2G. |
| UBL 2.1 / XRechnung (UBL) | OASIS XML grammar used by PEPPOL BIS Billing 3 and the UBL variant of XRechnung. | SDK reads only. Loaded into the same internal invoice model, then re-emitted as CII (ZUGFeRD / XRechnung). The SDK acts as a UBL-to-CII converter for inbound PEPPOL invoices. |
| EN 16931 | The European semantic data model that all four above conform to. Defines what a compliant invoice contains, not how it is serialised. | The legal anchor. EU directive 2014/55/EU mandates EN 16931 conformance for B2G invoicing across all member states. |
| PEPPOL BIS Billing 3 | PEPPOL's UBL business interoperability specification for invoices. | SDK reads only. Inbound PEPPOL documents become CII on the way through. The PEPPOL transport itself (Access Point with AS4) is a separate piece of infrastructure. |
The SDK is CII-native: its output is always ZUGFeRD / XRechnung / Factur-X (UN/CEFACT Cross Industry Invoice). UBL inbound documents pass through the same internal model on the way in and re-emerge as CII on the way out. Build the invoice once; the choice of CII profile is a single parameter.
Invoice data is some of the most sensitive financial data you hold
An invoice carries the legal name of every customer, the line items they bought, the unit prices, payment terms, tax IDs, bank details, payment references, and occasionally diagnoses, case numbers or other domain-specific identifiers in the free-text notes. For most European businesses this data sits at the intersection of GDPR, the German GoBD, sector-specific obligations (healthcare, legal, public procurement) and the company's own commercial confidentiality.
A cloud-hosted invoicing SaaS is a single concentrated copy of all of that data held by a third party. The Aloaha SDK is the opposite: it runs as a library inside your own process, on your own server, behind your own firewall. The only data crossing a network boundary is whatever your application would have sent anyway. There is no telemetry, no callback, no licence ping after install.
Data residency
Invoice content stays on the host that runs your accounting or ERP application. No transit to a vendor cloud. No conditional access to vendor IP ranges. No vendor outage stops your invoicing.
Compliance posture
One library inside your application is a smaller GDPR / NIS2 / GoBD attack surface than a SaaS dependency. Easier sub-processor diligence; the “sub-processor” is your own server.
Operational independence
The SDK has no licence server callback and no usage telemetry. An air-gapped network behind a national firewall can run it the same as a public-internet one.
Drop into anything from a VBA macro to a Web Services backend
COM (VB6, VBA, Classic ASP)
Register the COM library, instantiate the ZUGFeRD object, fill the structure, call SaveXML or MergeXMLIntoPDF. Works from any COM-aware host including Office macros. Early-binding and late-binding both supported.
VB6 VBA VB5 Classic ASP.NET (C#, VB.NET, PowerShell)
Reference the assembly, instantiate the invoice, configure fields, render output. Works from any CLR language including F#, IronPython, PowerShell scripts. Both early-binding (type-safe) and late-binding (reflection) entry points published.
C# VB.NET .NET Framework .NET 6+Command line
CLI tools wrap the same operations for shell pipelines and scheduled jobs. Useful for batch import from CSV, batch conversion of legacy PDFs, and CI/CD validation of fixture data.
PowerShell cmd.exe bashWeb Services
HTTP entry points (xmluploader, pdfuploader, zugferd, MergeXMLIntoPDF, CreateDOCXFromXML, ExportZUGFeRDXML2Disk) expose the SDK to any language without COM or CLR reach: PHP, Python, Node, Java, Go, Rust.
PHP Python Node JavaGUI tool
Standalone portable Windows GUI that builds, embeds, extracts and reads invoices without writing code. Useful for accounting staff who handle exception cases, audit checks, and one-off invoices outside the ERP.
Portable Windows no installPDF viewer
Free Aloaha ZUGFeRD PDF Viewer reads embedded XML out of any ZUGFeRD / Factur-X PDF and displays the structured fields next to the visual rendering. Useful for recipients verifying inbound invoices.
free download WindowsOne vendor for sovereign identity, communications, signing and invoicing
Aloaha Limited builds the rest of the stack on this page: the CodeB Credential Provider V2 for hardened Windows logon, the CodeB OIDC + Passkeys identity provider, the live EU Digital Identity Wallet verifier, the Voice AI receptionist, the sovereign SBC, the free CodeB Signature Server for HBA / qualified electronic signatures, and the RFC 3161 timestamping service at timenotary.com. The e-invoicing SDK lives next to all of them in the same engineering organisation.
Customers running CodeB usually take the SDK route for invoicing because procurement, support contracts, audit, and the “is the vendor still around in five years?” question all resolve to the same answer. There is no integration story between the comms stack and the SDK; they are simply the same vendor. But that is often enough to short-circuit a multi-quarter RFP.
FAQ
How is this licensed?
Per-developer for evaluation, perpetual licence for production, OEM licensing for ISVs embedding the SDK into their product. The pricing page on zugferdpro.com lists current rates; an evaluation licence is issued by email.
Does it validate against KoSIT / Mustang?
Output satisfies the EN 16931 semantic model and the German Leitweg-ID and BG/BT requirements. Third-party validators occasionally disagree on rule interpretation; the Aloaha team publishes positions when this matters. See the zugferdpro.com blog for the latest.
Can I keep my existing PDF generator?
Yes. The most common deployment shape is your existing application producing the visual PDF as before, and the SDK adding the structured XML attachment in a second step. Layout untouched, machine-readability added.
What about Word templates?
The SDK includes a DOCX to PDF/A converter and a direct “XML + Word template → ZUGFeRD PDF” pipeline. Useful when the invoice layout lives in marketing-controlled Word documents rather than in code.
How are XAdES signatures verified?
Standard XAdES, verifiable by any conforming verifier including the EU eIDAS-compatible toolchain. PAdES signatures on the wrapping PDF are verifiable by Adobe Reader and any PAdES-aware verifier.
Does it support UBL / PEPPOL?
Inbound, yes: the SDK reads UBL 2.1 / PEPPOL BIS Billing 3 invoices into its internal model. Outbound, the SDK always emits CII (ZUGFeRD / XRechnung / Factur-X). For a German company receiving PEPPOL from an EU partner and needing ZUGFeRD for its ERP, the SDK is the bridge. The PEPPOL Access Point (AS4 transport) itself is a separate piece of infrastructure.
Who actually buys this SDK
In practice the SDK is bought by two distinct groups. Both win the same thing: ZUGFeRD compliance bolted onto an existing application without rewriting it.
A · Retrofit a historically-grown invoicing workflow
A business already runs an invoicing or order-to-cash workflow that predates the German 2025 mandate. It might be an MS Access database built ten years ago, a Microsoft Dynamics / Navision install with custom forms, classic VB5 or VB6 desktop tools, a Delphi application, an Office VBA macro, or a modern .NET service. Whatever the host language, the COM + .NET + CLI surface lets the SDK be called from inside that existing application. The typical pattern: the application keeps generating invoices as it always has, and the SDK adds the structured ZUGFeRD XML payload to the produced PDF in a second step. Visual layout is preserved bit-for-bit. No rewrite.
B · Software vendor / ISV adding ZUGFeRD to its own product
An ISV publishes its own commercial invoicing, billing, accounting or ERP product, and now needs to ship ZUGFeRD / XRechnung output to its customer base. Instead of building a CII serialiser in house, the ISV embeds the Aloaha SDK and redistributes it under an OEM licence. The ISV ships ZUGFeRD output to its customers under its own brand, with one consolidated licence covering both the host product and the embedded SDK. OEM terms cover redistribution rights, branding, support escalation and update entitlements.
Both segments contact zugferdpro.com pricing or email info@aloaha.com for an evaluation licence. OEM terms are tiered by deployment volume.
Get the SDK
Download the trial, see the pricing, or read the VB.NET / VB6 sample code on the product home. Same vendor that builds the comms stack on this site.
zugferdpro.com ↗ Downloads ↗ Pricing ↗Frequently asked questions
What is ZUGFeRD?
ZUGFeRD (Zentraler User Guide des Forums elektronische Rechnung Deutschland) is a hybrid electronic invoice format that embeds a structured XML payload inside a human-readable PDF/A-3 document. The PDF can be opened by any reader; the embedded XML allows ERP and accounting systems to extract line items, tax codes, payment terms and totals without OCR. ZUGFeRD 2.x converged with the French Factur-X profile and conforms to the European EN 16931 semantic data model.
What is the difference between ZUGFeRD, XRechnung, Factur-X and UBL?
All four describe the same business object (an electronic invoice conformant with EN 16931) in different syntaxes and presentations. ZUGFeRD, Factur-X and XRechnung-CII use the UN/CEFACT Cross Industry Invoice (CII) XML grammar. UBL (Universal Business Language) is a different OASIS XML grammar, used by PEPPOL across European procurement networks and by the UBL variant of XRechnung. The Aloaha SDK is CII-native: it creates and reads ZUGFeRD, Factur-X and XRechnung-CII. It also reads UBL / PEPPOL invoices into the same internal model and emits them as CII -- so the SDK doubles as a UBL-to-CII converter, but its outbound syntax is always CII, never UBL.
Is German B2B e-invoicing really mandatory from 2025?
Yes. The Wachstumschancengesetz (Growth Opportunities Act) introduced a mandatory transition for B2B invoicing in Germany. From 2025-01-01 every German company must be able to RECEIVE structured electronic invoices (ZUGFeRD / XRechnung) from other German businesses. Mandatory ISSUANCE follows in stages: 2027 for businesses with annual turnover above EUR 800,000, 2028 for all others. Paper and PDF-only invoices stop being legally compliant for B2B at those points.
Where does the invoice data actually live with the Aloaha SDK?
Inside your own process. The SDK is a COM or .NET library you link into your application. There is no cloud round-trip, no SaaS dependency, no third party seeing customer names, line items, tax IDs or payment data. This is the typical reason European businesses pick an on-premise SDK over a cloud invoicing service: invoice content is some of the most sensitive financial data they hold, and GDPR + GoBD reduce the freedom to push it through US-hosted SaaS.
Which programming languages and runtimes are supported?
The SDK ships a COM interface (callable from VB6, VBA, Office macros, classic ASP, any COM-aware host) and a .NET assembly (early-binding or late-binding from C#, VB.NET, PowerShell, F# and any other CLR language). A command-line tool is included for shell pipelines. A Web Services wrapper exposes ExportZUGFeRDXML2Disk, MergeXMLIntoPDF and CreateDOCXFromXML over HTTP for languages without COM / .NET reach.
Can the SDK take a Word template and turn it into a ZUGFeRD-compliant PDF?
Yes. The SDK includes a DOCX to PDF/A converter (ConvertDOCX2PDF) and the MergeXMLIntoPDF entry point that embeds the structured XML into the converted PDF, producing a single PDF/A-3 document that is both human-readable and machine-extractable. The full pipeline (CSV data plus Word layout to ZUGFeRD PDF) is documented with VB.NET and VB6 sample code.
Does the SDK validate against KoSIT / Mustang / EN 16931 schematron rules?
It produces invoices that satisfy the EN 16931 semantic model and the German Leitweg-ID requirement. The toolkit ships its own schema and rule-set; conformance against external validators (KoSIT, Mustang Project) is documented per release. Differences between validators are common in the e-invoicing space and the Aloaha team publishes positions when third-party validators disagree on rule interpretation.
Can existing PDFs be turned into ZUGFeRD invoices without re-generating them?
Yes. The SDK can take any PDF/A or PDF/A-3 document and embed an existing or newly built ZUGFeRD XML payload into it. The visual layout is preserved bit-for-bit; the structured payload is added as an attachment per the PDF/A-3 specification. This is the common upgrade path for accounting software that already produces invoices as PDF.
Does the SDK sign invoices?
Yes. XML payloads can be signed with XAdES (XML Advanced Electronic Signatures) and the wrapping PDF can be signed with PAdES (PDF Advanced Electronic Signatures), including timestamps via RFC 3161. Aloaha Limited also publishes a free CodeB Signature Server for organisations that want a separate signing workbench (signature operations on a dedicated host, kept out of the invoicing application's address space).
How does this fit with the rest of CodeB?
Same parent (Aloaha Limited). CodeB customers already using the signature server for HBA-class qualified signatures, the Credential Provider V2 for hardened Windows logon and the OIDC + EU Wallet identity stack typically have the e-invoicing requirement adjacent in their roadmap. The two stacks share authentication primitives and ship from the same vendor, which simplifies procurement and audit.
What is PEPPOL and is it supported?
PEPPOL (Pan-European Public Procurement OnLine) is a network for exchanging structured business documents across European public administrations and private buyers. The Aloaha SDK READS PEPPOL BIS Billing 3 invoices (the UBL profile used over the PEPPOL transport) and converts them into the same internal model used for ZUGFeRD. Outbound the SDK emits CII (ZUGFeRD / XRechnung / Factur-X), not UBL. Net effect: the SDK is a useful UBL-to-CII bridge for German recipients of PEPPOL invoices from EU partners. The PEPPOL transport itself (Access Point with AS4) is a separate piece of infrastructure.
Where do I get the SDK and what does it cost?
The product home is zugferdpro.com. The Downloads page lists the SDK, the standalone GUI tool and the ZUGFeRD PDF Viewer. The Pricing page lists evaluation, perpetual developer and OEM licence options. Evaluation licences are issued by emailing info@aloaha.com.
Can the SDK integrate with a legacy invoicing application written in MS Access, Navision, VB5, VB6 or Delphi?
Yes. This is one of the two main customer segments. The SDK ships a COM interface registered as an ActiveX server, callable from any host that can use COM: MS Access via Tools / References, Microsoft Dynamics / Navision through automation servers, classic VB5 / VB6 with early or late binding, Delphi via OleVariant or imported type libraries, Office VBA macros, classic ASP. The typical retrofit pattern is to keep the existing application generating invoices as it always has, and call the SDK in a second step to add the structured ZUGFeRD XML payload to the produced PDF, or to emit the XML alongside it. Visual layout is preserved bit-for-bit. No rewrite of the host application required.
Can a software vendor embed and redistribute the SDK as part of its own product?
Yes. This is the second main customer segment. The OEM licence permits an ISV to bundle the SDK with its own commercial invoicing, billing, accounting or ERP product and redistribute it to that ISV's end customers under one consolidated licence. OEM terms cover redistribution rights, branding, support escalation paths and update entitlements. Contact info@aloaha.com for OEM licence terms and pricing tiered by deployment volume.
Does the SDK also work from a command line / batch pipeline?
Yes. The SDK ships CLI tools that wrap the same operations as the COM and .NET interfaces. Useful for scheduled jobs that batch-import CSV invoice data, batch-convert legacy PDFs, validate fixture data in CI/CD, or post-process invoices produced by an upstream application that does not itself know about ZUGFeRD.