InvoiceSpec

Developer-first German e-invoicing API to generate and validate XRechnung, ZUGFeRD, and EN 16931 compliant invoices without maintaining compliance logic yourself.

Comment

Inspiration

German e-invoicing looks simple from the outside, but integrating it into a real application quickly becomes a compliance and maintenance problem.

Developers need to understand standards such as EN 16931, XRechnung and ZUGFeRD, deal with XML formats like UBL and CII, validate against changing business rules, and keep up with specification updates.

InvoiceSpec was built to move that complexity out of application code.

The goal is simple: give developers one API for German e-invoicing so they can focus on their product instead of becoming e-invoicing compliance experts.

What it does

InvoiceSpec is developer-first e-invoicing infrastructure focused on Germany.

It currently provides APIs for:

  • Generating XRechnung invoices
  • Validating XRechnung invoices
  • Generating ZUGFeRD invoices
  • Validating ZUGFeRD invoices
  • Generating EN 16931 compliant invoices
  • Validating EN 16931 invoices

Developers send structured invoice data to the API and InvoiceSpec handles the underlying invoice format, validation rules and compliance workflow.

The API is authenticated using API keys and usage is credit based.

How we built it

The backend is built with Java and Spring Boot.

The invoice engine uses a canonical invoice model that is mapped into the required e-invoice syntax.

For XML generation, the system supports the relevant UBL and CII structures. Validation is handled through a validation pipeline that includes schema and business-rule validation, including KoSIT-based validation for XRechnung.

ZUGFeRD support combines structured invoice data with the required embedded XML workflow.

The product frontend and developer portal are built using Next.js and TypeScript.

Supabase is used for account and application data, while Stripe handles subscription and payment flows.

The architecture is designed so invoice standards and versions can evolve independently from the public API.

Challenges we ran into

The main challenge was not XML generation itself.

The difficult part is dealing with the relationship between:

  • EN 16931
  • XRechnung
  • ZUGFeRD
  • UBL
  • CII
  • business rules
  • validation scenarios
  • specification versions

Different standards build on top of each other, and a syntactically valid XML document is not necessarily a compliant electronic invoice.

Another challenge was designing an API that stays simple for developers while keeping the compliance engine version-aware internally.

We also had to make validation results useful to developers instead of simply exposing raw validator output.

Accomplishments that we're proud of

We built a reusable invoice engine instead of hard-coding individual document templates.

The same architecture supports multiple German e-invoicing formats while keeping the external API straightforward.

We also separated specification configuration and validation packages from the core application logic, making it easier to support future specification updates.

What we learned

E-invoicing is much more of an infrastructure problem than a document-generation problem.

The hard part is maintaining standards, rules and version compatibility over time.

That led to the core positioning of InvoiceSpec:

German e-invoicing infrastructure for developers.

What's next for InvoiceSpec

The immediate focus is completing the developer experience and launching in Germany.

Planned improvements include:

  • Better human-readable validation errors
  • Free public XRechnung and ZUGFeRD validation tools
  • More SDKs and integration examples
  • Human-readable XRechnung rendering
  • Improved documentation
  • Additional German e-invoicing workflows

The longer-term goal is to make e-invoicing compliance an API problem that application developers no longer need to maintain themselves.

Built With

Share this project:

Updates