Instantly open, validate, and repair XRechnung and ZUGFeRD files. Smart Repair engine with full audit trail. No registration required.
Built specifically for German accounting workflows. From parsing to archiving.
Don't just see errors — fix them. Our inline editor detects missing VAT IDs, arithmetic inconsistencies, and mandatory fields, then generates a corrected XML with a GoBD-ready audit trail.
Full audit trail for every validation and repair, fulfilling German tax office requirements.
Your sensitive financial documents never leave your session. Files processed entirely in-memory.
Drop a ZIP file of multiple XMLs and process them all at once. Perfect for month-end accounting.
PROExport invoice data as semicolon-separated CSV, ready for direct import into DATEV accounting software.
PROStart free. Upgrade when you need unlimited processing and archiving.
For quick invoice checks
For accountants & businesses
€47.88 billed yearly — or €4.99 monthly.
XRechnung is the German standard for electronic invoices (e-invoices) in the B2G (Business-to-Government) sector, based on the European standard EN 16931. Since 27 November 2020, suppliers invoicing federal government agencies must submit invoices exclusively in the XRechnung format. From 2025, this obligation is being progressively extended to cover B2B (Business-to-Business) transactions.
An XRechnung is a pure XML file — not human-readable without specialized tools. Our XRechnung Viewer translates these machine-readable data into a clear, structured display: you instantly see the seller, buyer, line items, tax amounts, and all mandatory fields. Errors are highlighted in color, and the Smart Repair engine automatically suggests corrections.
Whether you are an accountant, tax advisor, ERP developer, or public procurement officer: this tool lets you inspect XRechnung files online — no installation, no validation software of your own. Your file is sent over an encrypted connection, processed in memory only, and not stored.
The tool supports XRechnung UBL 2.x/3.0, XRechnung CII, and ZUGFeRD 2.x files. Here is how to use it:
Your file is sent over an encrypted connection to our server, processed in memory only for validation, and not stored.
Your XML file is sent over an encrypted connection to our validation API, parsed in memory, and validated against the EN 16931 schema (German subset) — without permanent storage. The browser then displays the result in a structured view.
The Smart Repair engine fixes the most common content errors: missing or incorrectly formatted seller and buyer VAT IDs, invalid invoice numbers or dates, miscalculated net, VAT and gross amounts (with a rounding tolerance up to 0.01 €), and mismatched VAT categories. Every change is logged with a timestamp, user ID and change description; Pro users can save this log to the GoBD Vault. The engine does not auto-correct the Leitweg-ID (BT-10) — that field must be filled in manually.
ZUGFeRD PDFs cannot be uploaded to the viewer directly: first extract the embedded XML with our ZUGFeRD/Factur-X extractor (runs entirely in your browser), then upload the resulting XML file here for validation. Current ZUGFeRD versions are supported (profiles BASIC, EN 16931/COMFORT, EXTENDED) as well as Factur-X.
Check incoming supplier invoices for completeness and correctness before posting. Detect missing VAT IDs or invalid tax amounts before the tax office queries them.
Test XRechnung files generated by your ERP system against official Schematron rules. See the exact error code and the affected XML element at a glance.
Validate incoming XRechnungen from suppliers for formal correctness and route them back for correction if needed. Leitweg-ID validation at the click of a button.
Pre-validate your own invoices before submitting them to the government portal (e.g. OZG-RE) and ensure no mandatory fields are missing.
The following XML structure shows the minimum fields required for a compliant XRechnung 3.0 in UBL format. Mandatory fields per EN 16931 and the German extensions are highlighted.
<?xml version="1.0" encoding="UTF-8"?>
<ubl:Invoice xmlns:ubl="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2">
<!-- Group 1: Invoice Header -->
<cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0</cbc:CustomizationID>
<cbc:ProfileID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</cbc:ProfileID>
<cbc:ID>RE-2024-0042</cbc:ID> <!-- BT-1: Invoice Number -->
<cbc:IssueDate>2024-03-15</cbc:IssueDate><!-- BT-2: Invoice Date -->
<cbc:DueDate>2024-03-29</cbc:DueDate> <!-- BT-9: Due Date -->
<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode><!-- BT-3: Invoice Type -->
<cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode><!-- BT-5 -->
<cbc:BuyerReference>991-123456-24</cbc:BuyerReference><!-- BT-10: Leitweg-ID (DE mandatory) -->
<!-- Group 2: Seller -->
<cac:AccountingSupplierParty>
<cac:Party>
<cac:PartyName><cbc:Name>Sample GmbH</cbc:Name></cac:PartyName>
<cac:PostalAddress>
<cbc:StreetName>Sample Street 1</cbc:StreetName>
<cbc:CityName>Berlin</cbc:CityName>
<cbc:PostalZone>10115</cbc:PostalZone>
<cac:Country><cbc:IdentificationCode>DE</cbc:IdentificationCode></cac:Country>
</cac:PostalAddress>
<cac:PartyTaxScheme>
<cbc:CompanyID>DE123456789</cbc:CompanyID><!-- BT-31: Seller VAT ID -->
<cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
</cac:PartyTaxScheme>
</cac:Party>
</cac:AccountingSupplierParty>
<!-- Group 3: Buyer -->
<cac:AccountingCustomerParty>
<cac:Party>
<cac:PartyName><cbc:Name>Federal Ministry Example</cbc:Name></cac:PartyName>
</cac:Party>
</cac:AccountingCustomerParty>
<!-- Payment Information -->
<cac:PaymentMeans>
<cbc:PaymentMeansCode>58</cbc:PaymentMeansCode>
<cac:PayeeFinancialAccount>
<cbc:ID>DE89370400440532013000</cbc:ID><!-- BT-84: IBAN -->
</cac:PayeeFinancialAccount>
</cac:PaymentMeans>
<!-- Tax Total -->
<cac:TaxTotal>
<cbc:TaxAmount currencyID="EUR">190.00</cbc:TaxAmount>
</cac:TaxTotal>
<!-- Document Totals -->
<cac:LegalMonetaryTotal>
<cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount>
<cbc:TaxExclusiveAmount currencyID="EUR">1000.00</cbc:TaxExclusiveAmount>
<cbc:TaxInclusiveAmount currencyID="EUR">1190.00</cbc:TaxInclusiveAmount>
<cbc:PayableAmount currencyID="EUR">1190.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>
<!-- Invoice Line -->
<cac:InvoiceLine>
<cbc:ID>1</cbc:ID>
<cbc:InvoicedQuantity unitCode="HUR">10</cbc:InvoicedQuantity>
<cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount>
<cac:Item>
<cbc:Name>Consulting Service</cbc:Name>
<cac:ClassifiedTaxCategory>
<cbc:ID>S</cbc:ID>
<cbc:Percent>19</cbc:Percent>
<cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
</cac:ClassifiedTaxCategory>
</cac:Item>
<cac:Price><cbc:PriceAmount currencyID="EUR">100.00</cbc:PriceAmount></cac:Price>
</cac:InvoiceLine>
</ubl:Invoice>This example satisfies all mandatory fields per XRechnung 3.0 (CustomizationID for KoSIT compliance, Leitweg-ID in BT-10, VAT ID in BT-31). Upload it in the viewer to see the validation result.
The Leitweg-ID is a unique identifier that routes the invoice to the correct recipient (typically a government agency) in the German e-invoice system. It is transmitted in XML element BT-10 (cbc:BuyerReference). While the EU standard EN 16931 treats this field as optional, German extension rule BR-DE-15 makes it mandatory — but only as a presence check: KoSIT does not validate whether the Leitweg-ID itself is correctly formatted or has a valid check digit. A missing Leitweg-ID will result in rejection by the government portal (OZG-RE); check the format and check digit separately with our Leitweg-ID validator. The format is: {prefix}-{number}-{check digit}, e.g. 991-12345-73.
XRechnung supports two XML syntaxes: UBL (Universal Business Language, ISO/IEC 19845) and CII (UN/CEFACT Cross Industry Invoice, D16B). Both syntaxes are semantically equivalent and fully EN-16931-compliant — they differ only in XML structure and namespaces. UBL uses the namespace urn:oasis:names:specification:ubl:schema:xsd:Invoice-2, CII uses urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100. Most German government portals accept both syntaxes. ZUGFeRD 2.x uses CII exclusively.
KoSIT (Koordinierungsstelle für IT-Standards) is the official body responsible for XRechnung standardization and validation in Germany. KoSIT publishes Schematron rules and XSD schemas against which XRechnung files are checked. Our viewer implements the same validation rules and displays error codes in KoSIT format (e.g. BR-DE-15, BR-CO-15). For official KoSIT validation before submitting to a government portal, we also recommend the official KoSIT Validator.
The German Wachstumschancengesetz (March 2024) mandates the gradual introduction of e-invoicing in the German B2B sector: From 1 January 2025, all companies must be technically able to receive structured e-invoices. From 1 January 2027, companies with annual turnover above €800,000 must issue e-invoices. From 1 January 2028, the issuance obligation applies to all VAT-registered companies regardless of turnover. Transitional solutions (PDF by email) remain permissible in certain constellations until these dates.
XRechnung is a pure XML format (UBL or CII) with no visual component. ZUGFeRD is a hybrid format: it combines a human-readable PDF/A-3 document with an embedded XML file (always CII syntax). Both formats are EN-16931-compliant. XRechnung is required for B2G invoices to federal agencies. ZUGFeRD is commonly accepted in the B2B sector and for state government agencies. Our viewer supports both formats.
Your file is sent over an encrypted connection to our server and processed in memory only for validation and repair — it is not stored permanently; we only keep a counter for your daily usage quota. GoBD compliance refers to the audit trail of the Smart Repair function: every automatic change is logged with a timestamp, user ID, and change description. This log is only saved if you are a Pro user and actively use the GoBD Vault feature.
The central German receiving channel for e-invoices to public administration is OZG-RE (Onlinezugangsgesetz-Rechnungseingang). Since 19 September 2025, the formerly separate federal platform ZRE has been merged into OZG-RE, so federal, state and municipal agencies are now all reachable through the same portal. PEPPOL (Pan-European Public Procurement Online) also transmits XRechnung as PEPPOL BIS Billing 3.0. Many federal states additionally run their own portals (e.g. eRechnung Bayern, eRechnungsportal Baden-Württemberg). Our viewer checks whether your file meets the minimum requirements for all these portals.
BR-DE-15 is a German extension business rule stating: 'An invoice shall have a Buyer reference' (BT-10, cbc:BuyerReference) — the field that carries the Leitweg-ID on invoices to public-sector recipients. The rule only checks that the BuyerReference element is present and not empty — it does not validate whether the Leitweg-ID itself is correctly formatted or has a valid check digit; KoSIT doesn't check that. Solution: ask the recipient (agency, client) for the correct Leitweg-ID and enter it in the corresponding field. Check the format and check digit separately with our Leitweg-ID validator — the Smart Repair engine does not auto-correct this field.
Yes. Since XRechnung is based on the European standard EN 16931, EN-16931-compliant invoices from other EU countries (e.g. Peppol BIS Billing from Austria, the Netherlands, or Scandinavia) are generally compatible and will be validated. Country-specific extension rules (e.g. Austrian ÖNORM A 6369) are shown as informational notices, but do not cause errors in the German context.