BT-10, Leitweg-ID, and Business Rule Errors: Why Valid XML Still Gets Rejected

German e-invoice validation has two layers, and most senders only test the first. The BStBK FAQ names both: format errors and business rule errors (Geschaeftsregelfehler). A file can be perfectly valid XML against the schema and still fail the second layer, rejected by the recipient's system or flagged as critical by a validator.

Layer 1: Format Errors

A format error means the file violates the permissible syntaxes or their technical specifications. Wrong schema version, invalid characters, malformed XML. The legal consequence is severe: a formally defective e-invoice does not meet Section 14 (1) sentence 6 UStG. It is an other-format invoice, with input VAT deduction only during the transition periods.

Format errors are loud. Validators reject the file outright. Most software catches them.

Layer 2: Business Rule Errors

Business rules check the logical dependencies of the information inside the invoice. The file parses, but the content contradicts itself or omits what the rules require. Typical cases from the BStBK FAQ:

• Missing mandatory content: no entry in the BT-10 Buyer reference field in an XRechnung where the buyer requires one
• Contradictory content: the stated tax amount does not match the calculated tax amount

Validators report these as critical errors. Recipients' systems reject the invoice, or route it to a manual queue where it sits unpaid.

The Fields That Fail Most

BT-10 (Buyer reference)

The Buyer reference is how enterprise and public-sector recipients route your invoice internally. For B2G invoicing to German federal authorities, the Leitweg-ID (a structured routing identifier) is mandatory and goes in this field. Enterprise buyers increasingly demand their own reference: a cost center, a purchase order number, a contract code.

Why it fails: the field is optional in the base standard but mandatory in the buyer's specification. Your software validates against the standard; the buyer validates against their onboarding requirements. Both files are "valid"; one gets paid.

Fix at the source: the Buyer reference belongs in the customer master record, collected at onboarding, not typed per invoice.

Arithmetic fields

EN 16931 defines how line amounts, allowances, charges, and tax amounts must sum. A rounding strategy that differs between your line calculation and your tax calculation produces a mismatch of one cent, and a critical error.

Fix at the source: calculate at line level, sum upward, and use the rounding mode the standard specifies. Never round the tax base and the tax amount in different directions.

Seller and buyer identifiers

A VAT ID in the wrong format, a missing electronic address (BT-34/BT-49) when the transmission channel requires one (Peppol endpoint IDs), or an outdated legal name that no longer matches the registration data.

Fix at the source: master data hygiene. Validation errors here are symptoms of a stale contractor record, not of a bad invoice.

The Validation Workflow

1. Validate in production, with production data. Test invoices built from real customer records, not synthetic samples. The errors live in your master data.
2. Use the KoSIT validator as the reference. It checks syntax, semantics, and conformity with national extensions.
3. Classify every finding. Format error: fix the generator. Business rule error: fix the data or the calculation logic.
4. Fix at the source, never in the file. Hand-edited XML desynchronises from your books and your archive. The GoBD record must match what you sent.
5. Collect buyer specifications at onboarding. BT-10 requirements, Leitweg-ID, endpoint IDs, profile expectations. An invoice rejected for a missing reference is a collections delay, not just a technical defect.

The Recipient Side

The BStBK recommends that recipients validate every incoming e-invoice: syntax, semantics, and conformity with national extensions. Findings trigger contact with the issuer, not silent booking.

For buyers, business rule errors in incoming invoices are an early-warning system:

• A supplier whose invoices keep failing arithmetic checks has a calculation bug that will eventually hit a tax amount
• A missing Buyer reference means your AP team routes by hand; cost and delay
• A business rule error on mandatory VAT information can endanger your input VAT deduction if left uncorrected

Common Misreadings

"The schema validation passed, so the invoice is fine." Schema is layer one. Business rules are layer two. Buyers and auditors operate at both.

"BT-10 is optional." In the base standard, yes. In your customer's specification, usually no. The field that is optional in the standard is mandatory in the relationship.

"One cent of rounding does not matter." To a validator, it is a critical error. To an automated AP system, it is a rejection. Automate the rounding the standard expects.

"We will fix rejected invoices when customers complain." Rejection queues are silent. The invoice sits unpaid; the reminder goes out; the relationship absorbs the friction. Validate before sending.

This material is information of a general nature and does not constitute legal or tax advice. For a specific situation, verify the current rules or consult a qualified adviser.