BR-DE-25-a

The same invoice, failing and fixed

No vendored test suite ships a labelled example for this rule, so this pair was found rather than written. The engine was run over the vendored instance corpus/xrechnung-testsuite/src/test/technical-cases/cius/01.06_minimal_test_ubl.xml under --profile xrechnung, then re-run over the same file with one mechanical edit applied to one element, over and over, until the edit below changed the verdict: 1 was added to the value of PaymentMeansCode (58 became 59). The page publishes it because the engine reported BR-DE-25-a for the edited document and did not report it for the untouched one.

UBL Invoice — fails

The vendored file around the change, verbatim:

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>59</cbc:PaymentMeansCode>
  <cac:PayeeFinancialAccount>
    <cbc:ID>DE79000000001234567890</cbc:ID>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>

UBL Invoice — passes

The same lines as 01.06_minimal_test_ubl.xml actually ships them — this block is the fix for the block above:

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>58</cbc:PaymentMeansCode>
  <cac:PayeeFinancialAccount>
    <cbc:ID>DE79000000001234567890</cbc:ID>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>

What the engine reports for the edited invoice

{
  "element": "cac:PaymentMeans/cac:PaymentMandate",
  "field": "cac:PaymentMeans/cac:PaymentMandate",
  "fix_hint": "Correct `/ubl:Invoice/cac:PaymentMeans[normalize-space(cbc:PaymentMeansCode) = '59']` so that code 59 (direct debit) requires DIRECT DEBIT (BG-19).",
  "insertion_point_line": 55,
  "location": "/ubl:Invoice/cac:PaymentMeans[normalize-space(cbc:PaymentMeansCode) = '59']",
  "message": "'Payment means type code' (BT-81) is the direct-debit code (59), so DIRECT DEBIT (BG-19) must be transmitted.",
  "rule": "BR-DE-25-a",
  "severity": "fatal",
  "terms": [
    "BG-19",
    "BT-81"
  ],
  "title": "Code 59 (direct debit) requires DIRECT DEBIT (BG-19)."
}

Rule ids the engine reports for 01.06_minimal_test_ubl.xml untouched: BR-DE-TMP-32. After the edit, BR-DE-20 BR-DE-25-a BR-DE-25-b are reported that were not before — one mechanical edit can break more than one rule at a time, and BR-DE-20 BR-DE-25-b are the neighbours this one takes with it.

Two honest limits. This is an edit that provokes the rule, not the only one, and it is not a claim about how real exporters break it. And it is the reverse of the fix a reader needs: the passing block is the vendored file's own content, which is what a conformant invoice looks like here.

Reproduce it yourself: take corpus/xrechnung-testsuite/src/test/technical-cases/cius/01.06_minimal_test_ubl.xml from this repository, apply the one edit named above, and run einvoice validate 01.06_minimal_test_ubl.xml --profile xrechnung --format json, or paste the file into the browser validator, which runs this same engine locally with no upload.