All posts

Rechnungskit: German e-invoicing on autopilot for online shops

If you sell into Germany, e-invoicing is coming for you. Rechnungskit turns shop payments into checked ZUGFeRD invoices by itself. We took a look.

Rechnungskit: German e-invoicing on autopilot for online shops

If you run an online shop that sells into Germany, this is either already on your desk or heading there fast: the e-invoice. Since January 2025 companies in Germany have to be able to receive e-invoices, and over the next few years issuing them becomes mandatory step by step. Sounds like paperwork? It is.

Which is why we get a kick out of it when someone in our circle takes on a topic this dry. We had a proper look at Rechnungskit and we will tell you straight what we like about it, how it works and where the project stands right now.

What is Rechnungskit, really?

Let us be honest: invoicing tools are a dime a dozen. Almost all of them work the same way. You get an empty form, you type in line items, you hit "generate PDF" and you hope everything adds up. At three invoices a month that is fine. At a shop with hundreds of orders it is madness.

Because in commerce the invoice does not start at a desk. It starts the moment someone pays you, through Stripe, Mollie or PayPal. Every piece of data is already there: the amount, the order, the customer, the tax rates. So why touch all of it again by hand?

That is exactly where Rechnungskit comes in. The system does not start at an empty form, it starts at your payment.

What makes it different from a PDF generator?

"Not another PDF generator" is written right on their home page, and the line lands. Producing a nice looking PDF invoice is not hard. The real work is everything around it:

  • E-invoices in ZUGFeRD 2.2. Every invoice is a PDF with embedded XML per EN 16931. Humans can read it, machines can process it, and it meets the standard the German rules require.
  • Checks before it goes out. Mandatory fields under section 14 of the German VAT act, tax rates, format rules and gapless numbering all get validated before the invoice reaches your customer. Errors surface before anyone sees them, not at the accountant.
  • A GoBD-compliant archive. Every document lands write-protected in the archive, audit-proof for eight years and exportable whenever you need it.
  • DATEV and OSS exports. Bookings, fees and payouts come out pre-matched as a DATEV export, SKR03 or SKR04, and EU sales go out as a quarterly OSS report.

Short version: this is not about making invoices prettier. It is about never having to touch them again.

How does it run from payment to bookkeeping?

The flow is deliberately plain, four steps, all automatic:

  • Payments first. Every payment comes straight from the payment provider, fees and payouts included. The payment is the source of truth.
  • Match the order data. Payments get linked to the orders from your shop automatically, whether that is Shopify, WooCommerce or your own API. Payment links work too.
  • Apply the rules. VAT per country, reverse charge, cancellations, small amounts. Only once every rule checks out does the invoice get created as ZUGFeRD and move into the audit-proof archive.
  • Export. At the end your accountant gets finished bookings instead of a folder full of PDFs.

You confirm the matching once, and after that every transaction runs the same checked path. Set it up once and the rest takes care of itself.

What does this mean for your accountant?

One line from Rechnungskit stuck with us: "Invoices your accountant never has to touch." Because let us be real, most bookkeeping trouble does not start in the shop, it starts at the handover to the firm. Documents go missing, Stripe and PayPal fees are not assigned to anything, and at quarter end the treasure hunt begins.

So Rechnungskit reconciles the payouts as well. Fees and refunds get assigned to transactions so the numbers actually add up at the end. And through role-based access, accountants and auditors can go straight into the archive without any email ping-pong with ZIP files.

What about privacy and hosting?

Invoice data is some of the most sensitive material a company holds. So we like that nobody cut corners on the foundation here. It is built and hosted in Germany, specifically at Hetzner in Falkenstein, with encrypted backups inside the EU and a GDPR data processing agreement included.

That is not a marketing sticker, it is a deliberate call. If you work in compliance you cannot really preach about privacy while your data sits somewhere you cannot quite point to.

Where is the project right now?

We will stay honest here, the way you know us: Rechnungskit is currently in a closed beta with a waiting list. Not everything is finished, and frankly that is what we like about it. Instead of a loud launch producing a thousand half-working accounts, they are working through every edge case with a manageable group of shops. Tax logic is genuinely complicated, so this is the right way round.

Getting on the list costs nothing, you do not need a credit card, and the team gets in touch personally when your turn comes. That kind of direct, unfussy communication is exactly how we run our own projects. #FirstNameBasis

So who is it for?

Rechnungskit is one of those projects that takes a dry piece of red tape and solves it the way we like: honestly, thoughtfully and without empty promises. No blank form, but automation starting at the payment. No PDF cosmetics, but real standards-compliant e-invoices, checked, archived and ready for DATEV and OSS.

If you run an online shop selling into Germany and you would rather not make e-invoicing your new hobby, take a look and put your name down: rechnungskit.de

And if you have questions, just get in touch. Together we make the difference.