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.
So if your .NET app writes invoices with ZUGFeRD-csharp, here are the four ways forward I see, with what each costs you.
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, you can send the file to a hosted validator over HTTP (example at the end).
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 I 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. 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, ZUGFeRD PDF or Peppol file back. Rule updates happen on the service side, not in your release cycle.
The trade-off: the invoice data goes to a third party, so you need a data processing agreement, and you depend on the service being up.
Good for: new projects, teams that use more than one language, or teams that want neither a library nor Java in their stack.
Which option when
| Your situation | Option |
|---|---|
| Invoices work today, little change planned | 1: keep 18.0.1, check it in CI |
| E-invoicing is part of your own product | 2: fork, or 3 |
| A lot of code on the library | 3: a commercial library |
| New project, or no library or Java wanted | 4: an API |
Options 1 and 4 combine well: keep what works, check it against the current rules, and move invoice types to an API when they need to change.
Checking what you produce today
I build Valinvo, which does option 4 and has a free validator for option 1. To check a 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. No account needed, and the file isn't stored. There's also a GitHub Action for CI.
A longer version with the API's limits is on our site (also in German).
Disclosure: I build Valinvo, so I'm not neutral on option 4; I tried to describe every option fairly. Facts as of 3 November 2026, from the library's README and announcement and the vendors' public price lists. I wrote this with the help of an AI assistant.
Top comments (0)