Guide
E-invoicing build vs buy for SaaS
Your product issues invoices for your customers — and from 2027 those must become compliant e-invoices. Three paths, honestly compared.
Updated on
What are the three options for SaaS teams?
| Criterion | OSS library (build) | E-invoicing API (buy, headless) | Full-service provider (buy, process) |
|---|---|---|---|
| Integration effort | High: serializer, KoSIT operations, error mapping | One POST request from your backend | Migrating the whole invoicing process |
| Control over your user experience | Full | Full — your product stays the interface | Limited: third-party portal and process |
| KoSIT validation | Run and interpret it yourself | Included, on every XRechnung generate | Included |
| Format version bumps (XRechnung 4.0 expected late 2026) | Your roadmap | Maintained server-side | The provider's |
| Running cost | No licence — but engineering time | From €0 (50 docs/month); Solo €19/month, Starter €49/month | Typically setup plus per-user or per-document pricing |
| Lock-in | None | Low: JSON in, XML out, parse back | High: process and data live with the provider |
What does build really cost?
Producing the XML is the smallest part — libraries like horstoeko/zugferd or Mustangproject solve exactly that part for you (dedicated comparison). What stays on your roadmap are the items that rarely make the estimate:
- KoSIT operations: the official validator (Java) has to run, stay pinned, and follow every scenario update — it is the legal reference.
- Error mapping: Schematron findings point at XML XPaths. Your tenants work in your product — someone has to translate
BR-DE-15into "field X in your form is missing". - Version maintenance: XRechnung, ZUGFeRD and Peppol keep evolving (XRechnung 4.0 is expected late 2026); UBL and CII must stay in sync.
- Test corpus: golden files, edge cases (cash discounts, VAT exemptions, credit notes) and CI against the real validator.
When is build the right call?
You want compliance as an in-house competency, you have the engineering capacity, your invoice shapes are stable, and KoSIT already runs in your CI. Then a library is viable — and stays viable as long as someone owns the maintenance.
When is buy the right call?
You are a SaaS issuing invoices for your customers, invoicing compliance is not your product, and your users should understand failures inside your interface. A headless API like normbill keeps your product as the interface: invoice JSON in, compliant XRechnung or ZUGFeRD / Factur-X out, and on failure a 422 report that names the field in your request. Pricing is public: free up to 50 documents/month, then from €19 — no sales call, failed generates never billed. Choose a full-service provider when you want to hand off the invoicing process entirely — accepting the lock-in that comes with it (our honest comparison).
Where next?
OSS vs API · 2027 checklist · Playground · Get a free API key