BR-DE-10

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 CityName was deleted, leaving the element present but empty. The page publishes it because the engine reported BR-DE-10 for the edited document and did not report it for the untouched one.

UBL Invoice — fails

The vendored file around the change, verbatim:

<cac:Delivery>
  <cbc:ActualDeliveryDate>2018-04-13</cbc:ActualDeliveryDate>
  <cac:DeliveryLocation>
    <cbc:ID>68</cbc:ID>
    <cac:Address>
      <cbc:StreetName>[Deliver to street]</cbc:StreetName>
      <cbc:AdditionalStreetName>4. OG</cbc:AdditionalStreetName>
      <cbc:CityName></cbc:CityName>
      <cbc:PostalZone>98765</cbc:PostalZone>
      <cbc:CountrySubentity>Bayern</cbc:CountrySubentity>
      <cac:AddressLine>
        <cbc:Line>More Details</cbc:Line>
      </cac:AddressLine>
      <cac:Country>
        <cbc:IdentificationCode>DE</cbc:IdentificationCode>
      </cac:Country>
    </cac:Address>
  </cac:DeliveryLocation>
  <cac:DeliveryParty>
    <cac:PartyName>
      <cbc:Name>[Deliver to party name]</cbc:Name>
    </cac:PartyName>
  </cac:DeliveryParty>
</cac:Delivery>

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:Delivery>
  <cbc:ActualDeliveryDate>2018-04-13</cbc:ActualDeliveryDate>
  <cac:DeliveryLocation>
    <cbc:ID>68</cbc:ID>
    <cac:Address>
      <cbc:StreetName>[Deliver to street]</cbc:StreetName>
      <cbc:AdditionalStreetName>4. OG</cbc:AdditionalStreetName>
      <cbc:CityName>[Deliver to city]</cbc:CityName>
      <cbc:PostalZone>98765</cbc:PostalZone>
      <cbc:CountrySubentity>Bayern</cbc:CountrySubentity>
      <cac:AddressLine>
        <cbc:Line>More Details</cbc:Line>
      </cac:AddressLine>
      <cac:Country>
        <cbc:IdentificationCode>DE</cbc:IdentificationCode>
      </cac:Country>
    </cac:Address>
  </cac:DeliveryLocation>
  <cac:DeliveryParty>
    <cac:PartyName>
      <cbc:Name>[Deliver to party name]</cbc:Name>
    </cac:PartyName>
  </cac:DeliveryParty>
</cac:Delivery>

What the engine reports for the edited invoice

{
  "element": "cac:Delivery/cac:DeliveryLocation/cac:Address/cbc:CityName",
  "field": "cac:Delivery/cac:DeliveryLocation/cac:Address/cbc:CityName",
  "fix_hint": "Add the required element at `/ubl:Invoice/cac:Delivery/cac:DeliveryLocation/cac:Address`: Deliver to city (BT-77) must be transmitted when DELIVER TO ADDRESS (BG-15) is present.",
  "location": "/ubl:Invoice/cac:Delivery/cac:DeliveryLocation/cac:Address",
  "message": "The element 'Deliver to city' (BT-77) must be transmitted when DELIVER TO ADDRESS (BG-15) is present.",
  "rule": "BR-DE-10",
  "severity": "fatal",
  "terms": [
    "BG-15",
    "BT-77"
  ],
  "title": "Deliver to city (BT-77) must be transmitted when DELIVER TO ADDRESS (BG-15) is present."
}

Rule ids the engine reports for 01.01_comprehensive_test_ubl.xml untouched: none. After the edit, BR-DE-10 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.