Test an E-Invoice Before Sending: A Four-Level Test Plan

To test an e-invoice before sending it to a German customer, run one real invoice from your system through four checks: the XML schema, the business rules of EN 16931 and XRechnung, the invoice content required by § 14(4) UStG, and the delivery route to the recipient, for example the test environment of the federal platform OZG-RE.

This plan is written for foreign suppliers of German companies and authorities, for ERP and finance teams rolling out e-invoicing, and for software vendors onboarding customers. You end up with a test plan, suitable test files and a log template you can reuse for every new recipient.

What do you need before you start?

• An invoice from your production system with real master data (legal name, address, VAT ID or German tax number, bank details), marked as a test or addressed to a fictitious buyer.
• The recipient's requirements: format (XRechnung in UBL or CII syntax, or ZUGFeRD/Factur-X), delivery channel (e-mail, portal, Peppol) and, for public-sector buyers, the Leitweg-ID (buyer reference, BT-10).
• A validator with the current rule configuration from KoSIT (Koordinierungsstelle für IT-Standards, the German body that maintains XRechnung). As of October 2026 this is configuration 2026-08-31 for XRechnung 3.0.2; GitHub shows no newer release.
• One valid and one deliberately invalid test file, so you can see whether your check actually catches errors.
• A spreadsheet or document for the test log.

Which four levels does the test plan cover?

A validator covers only the first two levels. The other two are manual, and that is where many first invoices fail.

The list of XRechnung mandatory fields shows which fields matter at level 2. How format errors, business rule errors and content errors differ for tax purposes is explained in our post on e-invoice format errors.

Step by step: how to test an e-invoice

1. Pick a test case. Use your most common invoice type, for example two lines and one VAT rate. Result: a document you will produce every day.
2. Generate the file. Export the invoice from your system as XRechnung or ZUGFeRD. Result: an .xml file, or a PDF with embedded XML.
3. Check the identifier. Open the XML and find the specification identifier (BT-24). For XRechnung 3.0 it is urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0. An outdated identifier means the validator finds no matching validation scenario at all.
4. Validate. Check the file against configuration 2026-08-31. Result: accept or reject, plus a list of rule codes.
5. Fix errors at the source. Correct the master data or the template in your invoicing system, not the single XML file. Generate the invoice again and revalidate.
6. Review the content. Walk through Section 14(4) of the German VAT Act (§ 14 UStG): names and addresses of both parties, tax number or VAT ID, issue date, invoice number, quantity and type of goods or services, supply date, net amount per VAT rate, VAT rate and VAT amount.
7. Run a negative test. Validate a deliberately broken file. If your check reports no errors there, it is not checking what you think it is.
8. Test delivery. Send the file to the recipient's test environment or as an agreed test invoice. Result: a receipt confirmation or an error message from the recipient.
9. Log the result. Record file, rule version and outcome (template below).

Repeat steps 1 to 6 for every special case you actually issue: credit notes, corrected invoices, VAT-exempt supplies, reverse charge, discounts or early-payment terms (Skonto).

Which test files work for positive and negative tests?

Testing with a single valid file does not show whether your check detects errors. Combine both kinds.

According to its changelog, the KoSIT test suite is compatible with XRechnung 3.0. Its test-overview.md lists the business cases as positive test instances, for example "01.01: Standard invoice with 2 lines, 1 tax category, 1 payment means code 58". Pick the cases closest to your own invoices and compare your file field by field.

The broken test file includes a missing buyer reference (BR-DE-15), a credit transfer without an IBAN (BR-DE-23-a: if payment means code 30 or 58 is used, group BG-17 "CREDIT TRANSFER" must be present) and a BT-106 total that does not match the sum of the lines (BR-CO-10). How to fix messages like these is covered in fix XRechnung validation errors.

How do you test delivery to a German recipient portal?

A valid file can still be rejected, for example because the Leitweg-ID does not belong to the buyer or the channel is misconfigured. That is why delivery belongs in the test.

For invoices to the German federal administration, the FAQ on e-rechnung-bund.de (opens in a new tab) sets out these rules:

• The federal invoice platform OZG-RE has its own test environment. Suppliers are advised to register there and test invoice submission.
• Test invoices never go to the production platform, and real invoices never go to the test environment.
• If you use the "Weberfassung" (web form) or "Upload" channels, the platform validates your e-invoice and shows a validation report with formal errors before you submit.
• For other channels, a magnifier icon in the invoice overview leads to the detailed results of the formal check if the platform rejects an invoice.
• For Peppol tests, the FAQ publishes a dedicated Peppol receiver ID and Leitweg-ID for the reference environment. Production invoices should follow only once transmission works there.
• Fictitious IBANs may be used in the test environment.

For state and municipal portals, and for business customers with their own supplier portal, ask for a test environment or agree on a clearly marked test invoice. How the delivery channels work in detail is covered in how to send e-invoices in Germany.

Template: a test log for customer onboarding

A short log answers the later question of which rule version an invoice type was approved against. It also helps when a customer asks what was checked after a first rejection. The data in the example is fictitious.

Store the log with the test file. When the rule configuration changes, for example with XRechnung 4.0, test again and start a new log.

Common testing mistakes

How to test an e-invoice with docutools.pro

1. Open the XRechnung validator and choose "Load sample invoice" to see the flow with a valid file. The sample has its own allowance and does not use up your uploads.
2. Upload your own XML with "Select file". The file is sent to our server and checked the way the KoSIT validator does (configuration 2026-08-31). The free plan includes two uploads per day up to 500 KB; the quota resets at midnight UTC. The validator does not accept ZUGFeRD PDFs, so first extract the XML from the PDF.
3. Read the result: "KoSIT-conformant / Valid XRechnung" or "Not KoSIT-conformant", the "Compliance score" and the list of findings with rule codes. The list of XRechnung error codes gives background on individual codes; the rule text in your result is what counts.
4. For the negative test, download the broken test file and check it the same way. You should see the findings listed in the template description.
5. For level 3, walk through the mandatory details with the "XRechnung/ZUGFeRD XML" mode of the German invoice requirements checker. On XML import it always marks the supply date, exemption note and discounts as missing; tick them by hand once you have checked them.
6. If your system cannot produce e-invoices yet, use the XRechnung generator to create a test invoice without an account, as "XRechnung XML", "ZUGFeRD XML" or "ZUGFeRD PDF". It produces standard invoices (type 380) only, no credit notes or corrections.

The docutools.pro validator does not produce a report file to keep; the result is shown on the page only. For a report to attach to your log, also run the KoSIT validator itself. More articles are collected in our validation and error guides.

What should you check after the test passes?

• Validate the first production invoice to each new recipient again and ask for confirmation of receipt.
• Repeat one test case after every update of your invoicing software.
• Watch the KoSIT rule configuration date: XRechnung 3.0.2 applies today, and the pre-release of XRechnung 4.0 has been published since September 2026.
• Add every rejection from a recipient, with its rule code, to the log so the next test covers exactly that case.

Sources

• FAQ on e-invoicing in the federal administration: OZG-RE test environment and Peppol tests (German) (opens in a new tab)
• KoSIT XRechnung test suite on GitHub, release 2026-08-31 (opens in a new tab)
• KoSIT validator configuration for XRechnung on GitHub (opens in a new tab)
• § 14 UStG, issuing invoices (German VAT Act) (opens in a new tab)

Last reviewed: October 2026

This article is general information, not tax or legal advice.