Stripe Invoicing in Germany: creating invoices, pricing and e-invoicing
Stripe Invoicing is the invoicing module in Stripe: you create an invoice in the Dashboard or through the API, Stripe sends it as a PDF with a payment page and collects the money. It costs 0.4% per paid invoice (Starter) or 0.5% (Plus), plus the fee of the payment method. According to its own documentation, Stripe Invoicing does not produce an e-invoice under EN 16931. For B2B invoices in Germany, e-invoices become mandatory in stages from 2027.
What Stripe Invoicing is
Stripe Invoicing is the invoicing module in your Stripe account. You create an invoice in the Dashboard or through the API, and Stripe numbers it, creates a PDF and a payment page, and collects the money by card, direct debit or bank transfer. Payment reminders, automatic reconciliation and a customer portal are included.
It is meant for one-off invoices: consulting, a project, an annual license, a large customer order. For recurring billing, Stripe uses the same invoicing logic under the name Stripe Billing. How to turn subscriptions into proper German invoices is covered under Stripe Billing. This guide stays with the single invoice you trigger yourself.
Stripe is clear about one thing: you know your customers and your business better than Stripe does, so it is up to you to make sure the invoice contains every required detail and complies with the laws of your country. That is what Stripe's guide to customizing invoices says. The sections below explain what that means in Germany.
What Stripe Invoicing costs
Stripe charges for Invoicing as a percentage of each paid invoice. According to the pricing page, there are no base or setup fees (as of October 1, 2026):
| Plan | Fee per paid invoice | Included |
|---|---|---|
| Starter | 0.4% | Invoices via Dashboard and API, payment page, customer portal, automatic collection and reconciliation |
| Plus | 0.5% | Same as Starter, plus quotes |
| Custom | On request | For high volumes |
The Invoicing fee comes on top of the payment method fee. If your customer pays with a standard card from the EEA, Stripe's price list shows 1.5% plus 0.25 euros, and 0.35 euros for a SEPA direct debit. For a SEPA bank transfer, Stripe lists 0.5% per payment, capped at 5 euros (local payment methods).
A worked example: an invoice for 2,000 euros paid by bank transfer costs 8 euros in Invoicing fees on the Starter plan and 5 euros for the transfer. Custom terms agreed with Stripe take precedence.
Creating and sending an invoice in Stripe
In the Dashboard it works the way Stripe describes in its Dashboard guide:
- Under Invoices, click "Create invoice". Stripe saves every state as a draft.
- Select a customer or create a new one. Stripe only requires a name. For a German invoice, enter the full address, and for business customers also the VAT ID (USt-IdNr.).
- Add line items: a one-time item or a saved product, each with quantity and price.
- In each line item's "Item options", set the tax rate and the "Delivery date". The delivery date is your date of supply (Leistungsdatum).
- Under the item options, choose the currency and the tax display, that is, whether prices include tax or not.
- Choose how the invoice is delivered (see the table below) and schedule a send date if needed.
- Click "Review invoice" and send it. This finalizes the invoice in Stripe: the number is fixed and the content can no longer be changed.
Stripe offers four ways to get the invoice to the customer:
| Option in Stripe | What happens |
|---|---|
| Automatically charge a saved payment method | Stripe immediately collects the amount from the saved card or direct debit mandate |
| Send the invoice or payment page link manually | You get a link and send it yourself |
| Send the invoice with a link | Stripe emails the PDF and the payment page to your customer |
| Send the invoice without a link | Stripe emails the PDF only |
For mistakes on invoices that have already gone out, Stripe's approach is to duplicate the invoice, correct it, send it again and void the faulty one. For your bookkeeping you need a proper invoice correction that refers to the original invoice.
Settings for German invoices
Some things you set once in Stripe instead of repeating them on every invoice. Most of them are under Settings, Billing, Invoices:
- Account-level numbering. Stripe has two schemes: sequential per customer or sequential across the whole account. According to Stripe, account level is the default for accounts in the EU. Leave it that way and set your own prefix of up to 12 capital letters or digits.
- Tax IDs. Under "Tax information for invoices" you store your VAT ID or tax number (Steuernummer) so it appears on every PDF. Once saved, a tax ID cannot be edited, only deleted and created again.
- Footer. Room for details such as the commercial register entry, managing directors or the note on the small-business exemption (Kleinunternehmerregelung). After finalization, the footer is fixed.
- Page size and language. Outside Japan, Stripe prints in Letter format by default. You switch to A4 in the advanced options. The language follows the preferred language you store for the customer.
- Payment terms. You set the default due period and the allowed payment methods under the default payment terms.
Up to four custom fields in the invoice header can hold an order number, project number or Leitweg-ID (the routing ID German public-sector buyers require). That helps, but it does not replace the structured field an XRechnung needs for the Leitweg-ID.
Checking the mandatory details under § 14 UStG
§ 14(4) UStG lists the details without which an invoice in Germany is incomplete. Stripe Invoicing can cover most of them, but only if you maintain them:
The gap that shows up most often in practice is the date of supply. Without a delivery date in the item options, the PDF shows only the issue date. Under § 31(4) UStDV, stating the calendar month of the supply is enough, but even that has to be on the invoice.
Invoices up to 250 euros gross fall under the simplified rules for small-amount invoices (Kleinbetragsrechnung, § 33 UStDV). Sales to other EU countries add special rules: supplies of goods to businesses are VAT-exempt as intra-Community supplies (§ 6a UStG), services to businesses fall under the reverse charge procedure (§ 14a(1) UStG), and sales to consumers are reported through the OSS procedure (One-Stop-Shop, § 18j UStG). Stripe does not make these decisions for you; they depend on the tax rates you set up.
What Stripe Invoicing does not cover, or only partly
Beyond the mandatory details on the invoice itself, every outgoing invoice comes with further duties: retention under GoBD (the German rules for proper electronic bookkeeping), evidence for VAT-exempt EU sales, the bookkeeping, and for accrual-based accounts, deferral of revenue. The second quick check shows which of these Stripe covers, based on what Stripe itself documents.
No e-invoice
Stripe says it plainly in its documentation on e-invoicing: Stripe Invoicing creates invoice records and provides the data through the API and webhooks, but does not generate or transmit legally compliant e-invoice files. For that part, Stripe points to apps from the Stripe App Marketplace, with Billit as its preferred partner, or to your own integration via webhooks.
For B2B invoices this soon becomes decisive. Under § 27(38) UStG, businesses may still send invoices to other businesses as PDFs until the end of 2026 if the recipient agrees. From January 1, 2027, that only applies if prior-year revenue was no more than 800,000 euros, and from 2028 it applies to no one. A PDF from Stripe then no longer meets the obligation toward business customers. The tax authorities treat it as an improper invoice that has to be corrected by an e-invoice so your customer can deduct input VAT (section 15.2a(7) UStAE as amended by the BMF circular of 15.10.2025, German). What exactly counts as an e-invoice is explained in ZUGFeRD and XRechnung. You may keep sending PDFs to consumers, because the e-invoicing mandate only applies between businesses in Germany (§ 14(2) sentence 2 no. 1 UStG).
What Stripe locks under GoBD and what it does not
GoBD requires invoices to be retained unaltered, complete and readable at any time, and to be machine-analyzable. That is set out in the BMF circular of November 28, 2019 and in § 147(2) AO (German Fiscal Code). Under § 147(3) AO, you keep invoices and other accounting vouchers for eight years. For an e-invoice, keeping the structured XML part is enough; the PDF part only has to be kept if it contains additional tax-relevant information. The GoBD amendment of July 14, 2025 clarifies this in margin no. 119. On top of that you need procedure documentation (Verfahrensdokumentation) that describes how your documents are created and filed.
Stripe covers part of this. According to Stripe, most details of an invoice can no longer be changed after finalization. Deleting is not possible, only voiding, and a voided invoice can still be found under its number. Memo and metadata stay editable. You export the invoice list as CSV and download each invoice as a PDF (Stripe: manage invoices).
We found no commitment in Stripe's documentation on how long Stripe retains invoices (as of October 1, 2026). There is no XML original, because Stripe does not produce an e-invoice. And according to Stripe, the payment page of a Stripe invoice expires 30 days after the due date, after 120 days at the latest. Stripe's own guide to GoBD recommends dedicated software for archiving and does not claim that Stripe Invoicing meets GoBD. For your procedure documentation, Stripe provides no description of its processes.
VAT ID checked only via VIES
If you store an EU VAT ID on a customer, Stripe checks it automatically in the EU's VIES system, according to its documentation on tax IDs. You see the result in the Dashboard, along with the name and address registered there. Stripe itself notes that VIES only checks whether the number is valid. Whether name and address match is for you to verify. The check runs when the ID is added and is not repeated later. And if you use Stripe Tax: Stripe Tax already applies reverse charge when the number has the correct format, regardless of the check result.
In Germany, the Federal Central Tax Office (Bundeszentralamt für Steuern, BZSt) offers the qualified confirmation request under § 18e UStG. Besides the number, it checks whether the company name with legal form, town, postcode and street match the registered data (BZSt FAQ). If you query through the interface, the record you receive serves as evidence, according to the BZSt. That record belongs in your files, especially for VAT-exempt intra-Community supplies, for which your customer must use a valid VAT ID (§ 6a(1) sentence 1 no. 4 UStG), and for reverse charge to EU business customers. Stripe does not offer this kind of request.
Only payment data for DATEV, no documents
Stripe does not offer an export in DATEV format. Stripe pays out in lump sums net of fees, and those have to be booked through a clearing account (Geldtransitkonto). For this, DATEV offers its payment service provider data service for Stripe, which according to DATEV starts at 10 euros a month. It imports Stripe's payment data and turns it into booking suggestions. The invoice for each payment still has to be created elsewhere. The full path to the booking batch is described in the guide exporting Stripe to DATEV.
Deferred income only via Revenue Recognition
If you collect a year in advance and keep accrual-based books, the part not yet delivered belongs in deferred income (passiver Rechnungsabgrenzungsposten) under § 250(2) HGB (German Commercial Code). Stripe has a separate product for this: Stripe Revenue Recognition spreads revenue over the service period and records deferred amounts as "Deferred revenue", under IFRS 15 and ASC 606. According to the pricing page, it costs from 20 euros a month extra. You download the reports as CSV, optionally with the account numbers of your chart of accounts (Stripe: mapping the chart of accounts). Stripe mentions neither a DATEV booking batch nor deferral under HGB there. When deferred revenue (pRAP) is needed at all is explained in deferred income and deferring revenue for SaaS and online courses.
Payment terms and bank transfer
Many B2B invoices from Stripe are paid by bank transfer rather than by card. For this, Stripe gives each customer their own virtual IBAN and matches incoming transfers to the open invoice. That works reliably when the payment reference contains exactly the Stripe invoice number and nothing else.
So that the e-invoice reaches the customer before they pay, Rechnungskit creates it in this case as soon as the invoice is finalized in Stripe, with the virtual IBAN and the Stripe number as the payment reference. The process, the setup and the results of our tests in Stripe test mode are in the guide Stripe invoice with payment terms.
Turning the Stripe invoice into an e-invoice
You can keep using Stripe Invoicing as before. Rechnungskit reads every Stripe invoice from its data, not from the PDF, and issues the e-invoice from it under your own number range:
- In StripeYou create the invoice, your customer paysWith payment terms by bank transfer, the document is created at finalization
- RechnungskitZUGFeRD invoice with its own number, validated against EN 16931E-invoice
- AfterwardsGoBD archive with SHA-256 checksum and DATEV exportRefunds and credit notes in Stripe become cancellation invoices
Here is how to set it up:
- Connect Stripe to Rechnungskit. For Stripe invoices, the key also needs read access to invoices, customers and tax rates.
- In the mapping of the Stripe connection, choose "Stripe subscriptions (Billing)" as the sales source. The name is a little misleading: it covers all Stripe invoices, including one-off ones.
- Turn off invoice emails to customers in Stripe. Otherwise your customer also gets Stripe's PDF with a different number. The Stripe Billing page shows where the switch is, with a screenshot.
- If you send invoices with payment terms by bank transfer, turn on the card "Stripe invoices with payment terms" in the document rules (Belegregeln).
From each Stripe invoice, Rechnungskit takes the line items, the tax rates and, where available, the service period. Rechnungskit checks the VAT against your tax matrix per country and product category, and sends the invoice in your name. If your customer has a Leitweg-ID, an XRechnung goes out automatically. If the address is missing in Stripe, a small-amount invoice is created for up to 250 euros gross with Germany as the place of supply; otherwise you request the address from the customer via a link.
Refunds and credit notes in Stripe become cancellation invoices (Storno) automatically, pro rata for partial amounts. The original invoice stays unchanged in the archive. For your tax advisor (Steuerkanzlei), the DATEV export is ready with revenue, Stripe fees and payouts.
And the points from the second quick check:
- GoBD archive. Rechnungskit keeps the XML record of every invoice for eight years in immutable storage, with a SHA-256 checksum that is verified on every retrieval. The PDF is regenerated from the XML when needed. Our public procedure documentation describes how this works.
- VAT ID check at the BZSt. Rechnungskit reads the VAT ID from the Stripe customer's tax IDs. If the customer is based in another EU country, Rechnungskit runs a qualified check at the BZSt, for which your own VAT ID must be on file. The invoice is only VAT-exempt if the request confirms everything. Otherwise it is issued with VAT, or you get a task to clarify it. Every BZSt response is archived.
- DATEV. The booking batch contains revenue, Stripe fees and payouts through the clearing account. Every revenue booking carries a document link, and the invoices come along as a document transfer package. Your tax advisor imports both as files. The settings are under DATEV export for your tax advisor.
- pRAP. If you keep accrual-based books, the DATEV export books the future part of the service period to the pRAP account (SKR03 0990, SKR04 3900) and releases it month by month. Rechnungskit takes the period from the Stripe invoice or from the billing period you set on the product.
For context and comparison: what Stripe does as an invoicing route overall is covered under Stripe invoices. Whether to add a partner app or Rechnungskit to Stripe is shown in the comparison of Stripe and Rechnungskit. Rechnungskit charges no markup on payment volume; it counts documents (see pricing).
FAQ
- [1] Stripe Docs - Create invoices in the Dashboard (German version)
- [2] Stripe Docs - Customize invoices (numbering, tax IDs, footer; German version)
- [3] Stripe Docs - Electronic invoicing (e-invoicing)
- [4] Stripe Docs - Hosted invoice page (expiry of invoice links)
- [5] Stripe Invoicing pricing Germany (German)
- [6] Stripe pricing for local payment methods (SEPA bank transfer, German)
- [7] Stripe Guide - Invoicing best practices for Germany
- [8] § 14 UStG, issuing invoices (German)
- [9] § 27(38) UStG, e-invoice transition rules (German)
- [10] German Federal Ministry of Finance - FAQ on mandatory e-invoicing (German)
- [11] Stripe Docs - How invoicing works (finalization, voiding)
- [12] Stripe Docs - Manage invoices (CSV export, PDF download)
- [13] Stripe Docs - Customer tax IDs (VIES check)
- [14] Stripe guide - GoBD in Germany
- [15] Stripe Revenue Recognition (German)
- [16] Stripe Revenue Recognition pricing Germany (German)
- [17] Stripe Docs - Revenue Recognition, mapping the chart of accounts
- [18] DATEV Marketplace - payment service provider data service for Stripe (German)
- [19] § 6a UStG, intra-Community supplies (German)
- [20] § 14a UStG, additional invoicing duties in special cases (German)
- [21] § 31 UStDV, details on the invoice (German)
- [22] § 18j UStG, special scheme for intra-EU distance sales (OSS) (German)
- [23] § 33 UStDV, small-amount invoices (German)
- [24] BMF circular of 15.10.2025 on e-invoicing (incl. section 15.2a(7) UStAE, German)
- [25] § 18e UStG, confirmation procedure (German)
- [26] BZSt - questions and answers on the VAT ID (qualified confirmation, German)
- [27] BZSt - confirming foreign VAT IDs (German)
- [28] § 147 AO, rules on retaining records (German)
- [29] GoBD - BMF circular (version of 28.11.2019, German)
- [30] GoBD - BMF circular, second amendment (14.07.2025, German)
- [31] § 250(2) HGB, deferred income (German)
Rechnungskit is not a tax advisory or law firm. This article explains general principles and does not replace advice from a tax advisor (Steuerberater, § 5 StBerG) or a lawyer (§ 3 RDG). Rechnungskit is built for businesses based in Germany and prepares documents, tax rates and bookings automatically. How your specific case is treated remains your decision, ideally together with your tax advisor or a lawyer.
Every invoice automatically as a valid e-invoice.
Connect your payment provider and we take care of format, validation and archive. Start for free in test mode.
Try it now