BR-CL-19

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.01_comprehensive_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: the text content of AllowanceChargeReasonCode was deleted, leaving the element present but empty. The page publishes it because the engine reported BR-CL-19 for the edited document and did not report it for the untouched one.

UBL Invoice — fails

The vendored file around the change, verbatim:

<cac:AllowanceCharge>
  <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
  <cbc:AllowanceChargeReasonCode></cbc:AllowanceChargeReasonCode>
  <cbc:AllowanceChargeReason>Fixed long term</cbc:AllowanceChargeReason>
  <cbc:MultiplierFactorNumeric>10</cbc:MultiplierFactorNumeric>
  <cbc:Amount currencyID="EUR">10</cbc:Amount>
  <cbc:BaseAmount currencyID="EUR">100</cbc:BaseAmount>
  <cac:TaxCategory>
    <cbc:ID>E</cbc:ID>
    <cbc:Percent>0</cbc:Percent>
    <cac:TaxScheme>
      <cbc:ID>VAT</cbc:ID>
    </cac:TaxScheme>
  </cac:TaxCategory>
</cac:AllowanceCharge>

UBL Invoice — passes

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

<cac:AllowanceCharge>
  <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
  <cbc:AllowanceChargeReasonCode>102</cbc:AllowanceChargeReasonCode>
  <cbc:AllowanceChargeReason>Fixed long term</cbc:AllowanceChargeReason>
  <cbc:MultiplierFactorNumeric>10</cbc:MultiplierFactorNumeric>
  <cbc:Amount currencyID="EUR">10</cbc:Amount>
  <cbc:BaseAmount currencyID="EUR">100</cbc:BaseAmount>
  <cac:TaxCategory>
    <cbc:ID>E</cbc:ID>
    <cbc:Percent>0</cbc:Percent>
    <cac:TaxScheme>
      <cbc:ID>VAT</cbc:ID>
    </cac:TaxScheme>
  </cac:TaxCategory>
</cac:AllowanceCharge>

What the engine reports for the edited invoice

{
  "element": "cbc:AllowanceChargeReasonCode",
  "field": "cbc:AllowanceChargeReasonCode",
  "fix_hint": "Encode `cac:AllowanceCharge[cbc:ChargeIndicator = false()]/cbc:AllowanceChargeReasonCode` using a valid value from UNCL 5189 code list.",
  "location": "cac:AllowanceCharge[cbc:ChargeIndicator = false()]/cbc:AllowanceChargeReasonCode",
  "message": "Coded allowance reasons MUST belong to the UNCL 5189 code list; '' is not a listed allowance reason code.",
  "rule": "BR-CL-19",
  "severity": "fatal",
  "terms": [],
  "title": "Coded allowance reasons MUST belong to the UNCL 5189 code list."
}

Rule ids the engine reports for 01.01_comprehensive_test_ubl.xml untouched: none. After the edit, BR-CL-19 is reported that was not before.

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.01_comprehensive_test_ubl.xml from this repository, apply the one edit named above, and run einvoice validate 01.01_comprehensive_test_ubl.xml --profile xrechnung --format json, or paste the file into the browser validator, which runs this same engine locally with no upload.