E-Invoicing · on-premise SDK

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.

01 · The 2025 mandate

Germany made structured B2B invoicing mandatory. Most ERPs are not ready.

The German Wachstumschancengesetz introduced a phased transition to mandatory electronic invoicing between businesses. The dates are public and the deadlines are short:

2025-01-01 — every German business must be able to receive a structured electronic invoice (ZUGFeRD or XRechnung) from another German business. Paper and unstructured PDFs may continue to be sent, but the recipient cannot refuse a structured one.

2027-01-01 — businesses with annual turnover above EUR 800 000 must issue structured electronic invoices for all B2B transactions in Germany.

2028-01-01 — mandatory issuance extends to every German business regardless of turnover.

The directive is not unique to Germany. France phases in mandatory B2B e-invoicing via Factur-X / Chorus Pro between 2026 and 2027. Italy has been mandatory since 2019 (SDI). Poland (KSeF), Spain, Belgium and the Netherlands are on parallel tracks. The underlying EU directive 2014/55/EU and the EN 16931 semantic model give all of them a common data shape.

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.

02 · What the SDK does

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.

03 · Standards conformance

One SDK, four output families

StandardWhat it isWhere it matters
ZUGFeRD 2.xHybrid 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-XFrench 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 16931The 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 3PEPPOL'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.

04 · Why on-premise matters

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.

05 · Integration paths

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 bash

Web 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 Java

GUI 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 install

PDF 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 Windows
06 · Where it sits in the Aloaha family

One 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.

07 · Operator questions

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.

08 · Two main customer segments

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
Related: All features · Sovereign SBC · AI receptionist · Credential Provider V2 · OIDC IdP · EU Wallet verifier · Compare · Deutsch