Germany’s e-invoicing obligations are arriving in stages, which means most software vendors will treat them as a deadline to hit later. Kursretter took the opposite approach. Founder Jörg Braner built compliant e-invoicing into his platform while his customers’ counterparties are still working on paper, using the PDF Generator API E-Invoice API to go from an invoice PDF to a structured, standard-compliant document without building the standard himself.
Who Kursretter is built for
In Germany, companies above a certain size have to make sure their employees are trained in first aid and basic fire safety. Around 1,500 small providers deliver those courses, each running somewhere between 50 and 400 a year. Kursretter is the platform they can run that on: course scheduling, trainer management, participant lists, digital certificates, registration with the insurance funds, and the billing that follows.
Billing is the awkward part, because the money and the booking come from different places. The companies book the course, the insurance fund pays for it, and every course ends in a three-way settlement. On top of that, providers partly invoice the employers directly for travel lump sums when a trainer has to reach a location, and for the delta fee when a course does not fill to its minimum number of participants.
So a single course can produce invoices in two directions, to two very different kinds of recipient. That is the surface e-invoicing had to cover.
The challenge: a PDF stops being an invoice
Two things put e-invoicing on the roadmap at the same time.
The first was internal. Kursretter already holds the participant data for every course, so invoicing sits one short step from information the platform has anyway. Before that link existed, billing meant uploading attachments by hand. Closing the gap between the course happening and the invoice going out was a straightforward efficiency win.
The second was regulatory, and less optional. German e-invoicing is rolling out progressively: the obligation to be able to receive e-invoices landed first, issuing obligations follow, and further requirements kick in in January.
“E-invoicing is becoming step by step mandatory, to be able to receive but also required to be sent. It will come anyhow as a requirement sooner or later, in the next twelve months. For me it’s important to be well prepared.”
The part that catches software vendors out is what an e-invoice legally means. A PDF of an invoice does not qualify. A compliant document carries structured XML built to the EN 16931 semantic model, so the receiving system can read every field without a human or an OCR pass in the middle. Getting that right is not a layout problem, it is a data-modelling problem: which fields are mandatory, what the permitted values are, how the profile constrains you.
For Kursretter’s customers, the consequence is concrete. When the insurance funds and employers move to electronic inboxes, a provider still sending PDF attachments has an invoice that cannot be processed, and a payment that does not arrive on time.
There is an irony in the timing, and Jörg is blunt about it.
“That’s the funny part about these type of insurances in Germany. They are very paper-based still. But I assume that step by step they will also open up.”
Building ahead of a counterparty that is not ready yet is a deliberate bet, not an accident.
The solution: start from a document that already validates
Jörg did not start with the specification. He started from the free ZUGFeRD invoice template in the PDF Generator API template library and worked backwards from something that already produced a valid document.
“I used your template from the Free Templates Library basically as a start.”
From there it was learn as you go: the EN 16931 structure, what belongs in the JSON payload, which values the standard accepts and which it rejects. He used AI assistance to get through the first rounds of trial and error, pasting payloads in and asking what was wrong, and came to PDF Generator API support for the parts the AI could not answer.
“In the beginning it’s a bit painful until you have it, but step by step you understand and learn how these JSONs need to look from an EU standard perspective. What can you do, what can’t you do.”
The point of the API is that this learning curve is the only work. Kursretter did not have to implement the standard, maintain it as profiles change, or build the hybrid PDF and XML packaging. The platform sends its invoice data to the e-invoice endpoint and gets back a document that is valid by construction.
Two routes to an invoice, one document layer
Kursretter now runs two routes to an invoice: a Lexware integration for customers already working that way, and the PDF Generator API E-Invoice API for compliant documents that can go straight to an electronic inbox. Offers, B2B invoices, B2C invoices and reversals for both all come out of the same document layer, so adding a document type is a template job rather than a new integration.
The impact: ready before it is required
The first production customer is live, and the rollout across the base is staged rather than rushed. That staging is the whole point. When German insurers and employers do switch to electronic inboxes, Kursretter customers will not need a project to become compliant. It will already be in the product they are using, and the provider will not have to think about EN 16931 at all.
Cost mattered for getting there early. A bootstrapped platform whose customers have barely started sending e-invoices cannot justify enterprise volume pricing for the capability.
“That was great, that you introduced that low-cost price. Because I’m ramping up. The amount of invoices will increase over time, and the more the customers and the insurers have to take real e-invoices, the more the volume will rise. But for me it’s important to be well prepared, and right now I’m not stressed out.”
The same account scales without a migration when that volume arrives, from a handful of invoices a month into the hundreds of thousands.
Conclusion
Compliance deadlines reward whoever moved first. Kursretter shipped EN 16931 e-invoicing into a bootstrapped platform, as a side project, by starting from a template that already worked and letting the API carry the standard. When German e-invoicing stops being optional, Jörg’s customers will find the feature already waiting for them.
Getting ahead of an e-invoicing mandate?
If EN 16931 is on your roadmap and you would rather not implement the standard yourself, PDF Generator API turns your existing invoice data into a compliant e-invoice through one endpoint. Start from a free ZUGFeRD or Factur-X template, send the data your system already has, and get back a document that validates, at a price that works while your volume is still small.
