Scope and checks

This page sets out what BelegDock can do, what it checks and where it stops. An e-invoice that looks technically valid but is wrong for tax purposes harms you more than one that is never sent. That is why BelegDock stops everything it cannot represent reliably, and tells you why.

Formats and versions

We adopt new versions of the validator and the validation rules deliberately: only after running all test documents, with the version recorded in the archived validation report.

What a passed validation means

The KoSIT validator checks the XML against the schema and the business rules of the EN 16931 standard and of XRechnung. BelegDock sends only documents whose validation report says "accepted", and stores the report together with the document. BelegDock also checks that the report belongs to exactly this XML.

A passed validation is not a certification and not tax advice. It does not confirm that the tax rate, the service or the customer details are correct in substance. That remains your responsibility.

Supported cases

Stripe invoices

• German sellers with a VAT ID or tax number, business customers in Germany
• Invoices in euros with 1 to 1,000 line items, finalized and not voided
• VAT at 19% and 7%, also mixed, net or gross, from Stripe Tax or manual tax rates
• Tax-exempt line items, if you state the category and the exemption reason explicitly as metadata
• Discounts on line items and at invoice level, prorated subscription charges, shipping costs
• Partly or fully paid invoices
• Stripe credit notes as corrective invoices that reference the original invoice
• Reverse charge for services to businesses in the other 26 EU countries, when Stripe Tax determines it and has confirmed the VAT ID through VIES

API invoices

• Paid orders, seller and buyer in Germany, euros, 19% and 7%
• Business customers and consumers, invoices and corrective invoices

Cases BelegDock stops

These documents are neither created nor sent. You see them in the dashboard with the reason.

• Currencies other than the euro, and buyers outside the EU
• Deliveries of goods to other EU countries (intra-community supplies): Stripe knows neither the delivery date nor the proof of delivery
• Reverse charge with an unconfirmed, missing or more than one VAT ID, for German customers (domestic reverse charge under § 13b UStG) or mixed with taxed line items
• Zero tax without an explicit exemption reason; BelegDock never treats 0% as a tax exemption
• Several taxes on one line item, unknown tax rates, rounding differences of more than one cent per line item
• Customer credit balances, overpayments, invoice revisions, invoices that already have credit notes
• Small businesses under § 19 UStG (Kleinunternehmer), the margin scheme, OSS, down-payment invoices
• Invoices to public authorities with a Leitweg-ID through their portals
• Missing mandatory details, such as the buyer reference or the address

What you are responsible for

• Correct company and tax details in Stripe and in BelegDock
• Your customers' buyer reference
• Retaining your invoices according to the GoBD, even if BelegDock keeps them for you
• The EC Sales List (Zusammenfassende Meldung) for reverse charge

Peppol and XRechnung 4.0

XRechnung 3.0 is valid until at least July 31, 2027. KoSIT published XRechnung 4.0 as a preliminary version on September 15, 2026, explicitly not for production use; it expects the final version with official validation rules in spring 2027. We will support 4.0 once these validation rules exist, and keep 3.0 running until the end of the transition period.

For German B2B invoices, the law prescribes the format, not the transmission channel; sending by email is enough. We are preparing Peppol delivery through a certified access point partner, for recipients who require it. We will announce both when they are available, not before.