ZUGFeRD-csharp end of maintenance: your options in .NET

ZUGFeRD-csharp is the open-source .NET library most teams use to create and read ZUGFeRD, Factur-X and XRechnung invoices (about 1.7 million NuGet downloads). Its maintainer has announced that maintenance ends on 30 November 2026. Until then there are only selected bug fixes and security reviews. After that the NuGet packages are marked as legacy and the repository is archived. New features and new standard versions go only into a commercial successor.

Nothing breaks on 1 December: version 18.0.1 keeps working, and its Apache 2.0 licence stays. The risk is the next rule change. The rules for German and French e-invoices are updated several times a year. KoSIT's last XRechnung configuration came out on 31 August 2026, and the French reform's rules are still moving. And from 1 January 2027, German companies with more than €800,000 turnover in the previous year must send e-invoices to German business customers.

We make Valinvo, which is option 4 below. We have tried to describe every option fairly; weigh that accordingly.

Option 1: keep version 18.0.1 and check what it produces

The cheapest option, and a sensible one for now. The code you have keeps working. What you lose is someone who notices when a new rule makes your invoices invalid. So let something notice it for you: run every invoice type you produce through the official rules in your CI, and run it again after each rule release.

• The official checker for XRechnung is the KoSIT validator with its XRechnung configuration. It needs Java.
• Without Java: Valinvo's free validator applies the official rules for ZUGFeRD / Factur-X (PDF/A-3 included), XRechnung and Peppol over HTTP, and the GitHub Action does it in CI. You can try it without an account; see the example below.

Good for: teams whose invoices don't change often and who can react when a check fails. Risk: when a rule does change, someone has to change the code that writes the XML.

Option 2: fork and maintain it yourself

The Apache 2.0 licence allows it, and the code is well known. But you take on what the maintainer just stepped back from: following ZUGFeRD, Factur-X, XRechnung and EN 16931 releases and keeping the output valid. Good for: companies for which e-invoicing is a core part of their own product. Risk: it's an ongoing job, not a one-off.

Option 3: a commercial .NET library

The maintainer offers a commercial successor with a similar API, and other vendors sell .NET libraries for ZUGFeRD and XRechnung too. The offers we found in November 2026 are yearly subscriptions of roughly €550 to €1,100 (net) for a team, depending on the number of developers. Check the renewal terms and whether the library contacts the vendor's servers to verify the licence.

Good for: teams with a lot of code on ZUGFeRD-csharp, or who build their own PDF and embed the XML. A library with a similar API is the shortest migration.

Option 4: create the invoice through an API

Instead of a library in your code, you send one JSON invoice to an HTTP API and get the finished XRechnung (UBL or CII), ZUGFeRD PDF or Peppol file back. Rule updates happen on the service side, not in your release cycle. Valinvo checks every invoice against the official rules before returning it, and tells you the result in the response headers. It works from any language that can send an HTTP request; the quickstart has the JSON model and examples.

The limits, plainly:

• The invoice data goes to a service. Valinvo processes it in memory in the EU and doesn't store it, under a data processing agreement. It's still a third party. Planned: a Valinvo library that runs inside your own application, so invoice data never leaves your systems, billed by usage. If you need it, write to us.
• Today the ZUGFeRD PDF uses Valinvo's layout. If you need the XML embedded into a PDF you render yourself, write to us.
• Valinvo is in beta. You can try it with 2 invoices a day without a key. Paid plans start at €29/month and open after the beta.

Good for: new projects, teams that use more than one language, or teams that want neither a library nor Java in their stack.

Check the invoices you create today

This works with option 1: send the PDF your current code creates (or the XML alone, with Content-Type: application/xml).

curl -X POST https://valinvo.bmk-hub.com/v1/validate \
  -H 'X-Accept-Terms: 1.0' \
  -H 'Content-Type: application/pdf' \
  --data-binary @invoice.pdf

The answer names the rules applied, for example zugferd-2.5.2-en16931+pdf-a-3u, and lists every error with its rule ID and location. Warnings don't make an invoice invalid.

Which option when

Options 1 and 4 combine well: keep what works, check it against the current rules, and move invoice types to the API when they need to change.

By using the validator or the API you accept the Terms of Use.

Quickstart · XRechnung validator · Peppol validator · ZUGFeRD / Factur-X validator · ZUGFeRD-csharp: your options · Error codes