Clean vehicles (CVD) — what a vehicle invoice has to carry on top

Two codes, on the same invoice line

The vehicle category goes in BT-158 under the CVD scheme and must be one of six: M1, M2, M3, N1, N2 or N3 — M for passengers, N for goods. The drive type goes in BT-161 as the item attribute BG-32 named cva, and has exactly three values: clean, zero-emission or other.

BR-DE-CVD-06-a and BR-DE-CVD-06-b tie the two together: set one and the same line must carry exactly one of the other. A category without a drive type is as unusable as a drive type without a category.

And the invoice has to match the tender

BR-DE-CVD-01 and BR-DE-CVD-02 make the contract reference (BT-12) and the tender or lot reference (BT-17) mandatory — both are optional in an ordinary XRechnung. Without them the reported purchase cannot be tied to a procurement.

These rules only apply when you produce the CVD variant. Its identifier in BT-24 ends in #compliant#urn:xeinkauf.de:kosit:xrechnung:cvd_0.9; an ordinary XRechnung is checked against none of them. Which identifier you send is BR-DE-21.

All CVD rules

Which field the rule guards, and the official rule text beneath it.

• BR-DE-CVD-01

  Contract reference becomes mandatory (BT-12)

  Das Element […] "Contract reference" (BT-12) muss übermittelt werden.

  What the rule requires

  A CVD invoice must carry the contract reference (BT-12), which is optional in an ordinary XRechnung. All that is checked is that the field has content: whitespace alone fails, anything else passes — the rule set never looks at the number itself. The expression does not show that the rule only concerns CVD invoices; that condition lives in the rule’s context, which only takes in documents whose BT-24 carries the CVD identifier.

  Why it fires

  The CVD identifier is set in BT-24, but the mapping is not extended — fields that are optional in an ordinary XRechnung stay empty. Or the contract number is there but ends up in the purchase order reference (BT-13) or only in a note (BT-22). For this rule only BT-12 counts.

  How to fix it

  Send the buyer’s contract number in BT-12: as cac:ContractDocumentReference/cbc:ID in UBL, and in CII as ram:ContractReferencedDocument/ram:IssuerAssignedID inside ram:ApplicableHeaderTradeAgreement. In a UBL invoice the element follows cac:OriginatorDocumentReference (BT-17); in a UBL credit note it comes before it. A placeholder such as "n/a" passes the check but leaves the purchase impossible to attribute to a procurement procedure.

  In the XML

  A UBL fragment. The CII path is named above — same change, different element names.

  <cbc:BuyerReference>04011000-12345-03</cbc:BuyerReference>
  <cac:OrderReference>
    <cbc:ID>RV-2026-0815</cbc:ID>
  </cac:OrderReference>
  <cac:OriginatorDocumentReference>
    <cbc:ID>VG-2026-017-L2</cbc:ID>
  </cac:OriginatorDocumentReference>

  <cbc:BuyerReference>04011000-12345-03</cbc:BuyerReference>
  <cac:OriginatorDocumentReference>
    <cbc:ID>VG-2026-017-L2</cbc:ID>
  </cac:OriginatorDocumentReference>
  <cac:ContractDocumentReference>
    <cbc:ID>RV-2026-0815</cbc:ID>
  </cac:ContractDocumentReference>

  What the validator checks

  UBLcac:ContractDocumentReference/cbc:ID[boolean(normalize-space(.))]

  CIIram:ContractReferencedDocument/ram:IssuerAssignedID[boolean(normalize-space(.))]

• BR-DE-CVD-02

  Tender or lot reference becomes mandatory (BT-17)

  Das Element […] "Tender or lot reference" (BT-17) muss übermittelt werden.

  What the rule requires

  A CVD invoice must carry the tender or lot reference (BT-17) — the identifier of the procurement procedure or lot the invoice belongs to. Only the presence of content is checked. In UBL only cac:OriginatorDocumentReference/cbc:ID counts; in CII, BT-17 has no element of its own but is a ram:AdditionalReferencedDocument, and the expression wants ram:TypeCode 50 and a ram:IssuerAssignedID in the same element.

  Why it fires

  Systems that produce both syntaxes from one model easily carry the CII construct over into UBL and write the number as a cac:AdditionalDocumentReference with cbc:DocumentTypeCode 50. That does not count — in an invoice a CEN rule even rejects type code 50 in its own right. In a UBL credit note, on the other hand, the form is a natural choice, because the CEN rules allow type code 50 precisely there; yet BR-DE-CVD-02 looks only for cac:OriginatorDocumentReference in credit notes too. In CII the number fails when its document carries type code 916, that of a supporting document (BG-24), or none at all.

  How to fix it

  In UBL, write the number as cac:OriginatorDocumentReference/cbc:ID — in an invoice before cac:ContractDocumentReference, in a credit note only after cac:ContractDocumentReference and cac:AdditionalDocumentReference, because the order differs there. In CII it goes into ram:ApplicableHeaderTradeAgreement as a ram:AdditionalReferencedDocument with ram:IssuerAssignedID and ram:TypeCode 50.

  In the XML

  A UBL fragment. The CII path is named above — same change, different element names.

  <cac:ContractDocumentReference>
    <cbc:ID>RV-2026-0815</cbc:ID>
  </cac:ContractDocumentReference>
  <cac:AdditionalDocumentReference>
    <cbc:ID>VG-2026-017-L2</cbc:ID>
    <cbc:DocumentTypeCode>50</cbc:DocumentTypeCode>
  </cac:AdditionalDocumentReference>

  <cac:OriginatorDocumentReference>
    <cbc:ID>VG-2026-017-L2</cbc:ID>
  </cac:OriginatorDocumentReference>
  <cac:ContractDocumentReference>
    <cbc:ID>RV-2026-0815</cbc:ID>
  </cac:ContractDocumentReference>

  What the validator checks

  UBLcac:OriginatorDocumentReference/cbc:ID[boolean(normalize-space(.))]

  CIIram:AdditionalReferencedDocument[normalize-space(ram:TypeCode) = '50' and normalize-space(ram:IssuerAssignedID)]

• BR-DE-CVD-03

  At least one vehicle line per invoice (BG-25)

  In einer Rechnung muss mindestens eine […] INVOICE LINE (BG-25) enthalten sein, in der der Scheme identifier von […] "Item classification identifier" (BT-158) den Wert 'CVD' und der […] "Item attribute name" (BT-160) den Wert 'cva' enthält.

  What the rule requires

  A CVD invoice must contain at least one invoice line (BG-25) whose item carries both: an item classification identifier (BT-158) under the CVD scheme and an item attribute (BG-32) whose name (BT-160) is cva. Both have to sit on the same item — a category on one line and a drive type on another is not enough. Whether the values themselves are permitted is left to BR-DE-CVD-04 and BR-DE-CVD-05.

  Why it fires

  The vehicle data exists only as free text in the item name or description ("vehicle category M3, battery-electric") rather than in the structured fields. Or it is spelled differently: the comparison is exact, so "cvd", "CVA" or one space too many does not count. If the invoice does not bill a vehicle at all, the CVD identifier in BT-24 may itself be the wrong choice.

  How to fix it

  Add both to the item of the vehicle line. In UBL that is cac:Item/cac:CommodityClassification/cbc:ItemClassificationCode with listID="CVD" and cac:Item/cac:AdditionalItemProperty with cbc:Name cva; the attribute follows cac:ClassifiedTaxCategory. In CII it is ram:SpecifiedTradeProduct/ram:DesignatedProductClassification/ram:ClassCode with listID="CVD" and a ram:ApplicableProductCharacteristic with ram:Description cva; here the attribute comes before the classification.

  In the XML

  A UBL fragment. The CII path is named above — same change, different element names.

  <cac:Item>
    <cbc:Description>Fahrzeugklasse M3, batterieelektrisch</cbc:Description>
    <cbc:Name>Gelenkbus 18 m</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:Item>
    <cbc:Description>Fahrzeugklasse M3, batterieelektrisch</cbc:Description>
    <cbc:Name>Gelenkbus 18 m</cbc:Name>
    <cac:CommodityClassification>
      <cbc:ItemClassificationCode listID="CVD">M3</cbc:ItemClassificationCode>
    </cac:CommodityClassification>
    <cac:ClassifiedTaxCategory>
      <cbc:ID>S</cbc:ID>
      <cbc:Percent>19</cbc:Percent>
      <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
    </cac:ClassifiedTaxCategory>
    <cac:AdditionalItemProperty>
      <cbc:Name>cva</cbc:Name>
      <cbc:Value>zero-emission</cbc:Value>
    </cac:AdditionalItemProperty>
  </cac:Item>

  What the validator checks

  UBL(cac:InvoiceLine/cac:Item | cac:CreditNoteLine/cac:Item)[cac:CommodityClassification/cbc:ItemClassificationCode/@listID = 'CVD' and cac:AdditionalItemProperty/cbc:Name = 'cva']

  CIIram:IncludedSupplyChainTradeLineItem/ram:SpecifiedTradeProduct[ram:DesignatedProductClassification/ram:ClassCode/@listID = 'CVD' and ram:ApplicableProductCharacteristic/ram:Description = 'cva']

• BR-DE-CVD-04

  Permitted vehicle categories (BT-158)

  Ein […] "Item classification identifier" (BT-158) mit dem Scheme identifier 'CVD' muss einen Wert aus der Liste der zulässigen Fahrzeugkategorien enthalten.

  What the rule requires

  Where an item classification identifier (BT-158) uses the CVD scheme, its value must be one of the six vehicle categories: M1, M2, M3, N1, N2 or N3. The expression strips leading and trailing spaces first, but case matters, and any addition makes the value invalid. Classifications under other schemes are not checked by this rule.

  Why it fires

  The field holds a vehicle description instead of the category ("bus", "car"), the category is written in lower case ("m3"), or it was copied from the vehicle data together with a suffix — "M3 Class I" for a city bus, "M1G" for an off-road vehicle. All of these fail, even though a human can read the category in them.

  How to fix it

  Send the bare code, in capitals and without any addition — in UBL in cac:CommodityClassification/cbc:ItemClassificationCode with listID="CVD", in CII in ram:DesignatedProductClassification/ram:ClassCode with listID="CVD". M stands for vehicles carrying passengers, N for goods vehicles. Details such as the bus class belong in the item name or description, not in the code.

  In the XML

  A UBL fragment. The CII path is named above — same change, different element names.

  <cac:Item>
    <cbc:Name>Gelenkbus 18 m, batterieelektrisch</cbc:Name>
    <cac:CommodityClassification>
      <cbc:ItemClassificationCode listID="CVD">M3 Klasse I</cbc:ItemClassificationCode>
    </cac:CommodityClassification>
    <cac:ClassifiedTaxCategory>
      <cbc:ID>S</cbc:ID>
      <cbc:Percent>19</cbc:Percent>
      <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
    </cac:ClassifiedTaxCategory>
    <cac:AdditionalItemProperty>
      <cbc:Name>cva</cbc:Name>
      <cbc:Value>zero-emission</cbc:Value>
    </cac:AdditionalItemProperty>
  </cac:Item>

  <cac:Item>
    <cbc:Name>Gelenkbus 18 m, batterieelektrisch</cbc:Name>
    <cac:CommodityClassification>
      <cbc:ItemClassificationCode listID="CVD">M3</cbc:ItemClassificationCode>
    </cac:CommodityClassification>
    <cac:ClassifiedTaxCategory>
      <cbc:ID>S</cbc:ID>
      <cbc:Percent>19</cbc:Percent>
      <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
    </cac:ClassifiedTaxCategory>
    <cac:AdditionalItemProperty>
      <cbc:Name>cva</cbc:Name>
      <cbc:Value>zero-emission</cbc:Value>
    </cac:AdditionalItemProperty>
  </cac:Item>

  What the validator checks

  UBLnot(normalize-space(@listID) = 'CVD') or normalize-space(.) = $CVD-VEHICLE-CATEGORY

  Variables in it

  $CVD-VEHICLE-CATEGORY

  ('M1', 'M2', 'M3', 'N1', 'N2', 'N3')

  CIInot(normalize-space(@listID) = 'CVD') or normalize-space(.) = $CVD-VEHICLE-CATEGORY

  Variables in it

  $CVD-VEHICLE-CATEGORY

  ('M1', 'M2', 'M3', 'N1', 'N2', 'N3')

• BR-DE-CVD-05

  Permitted drive types (BT-161)

  Wenn innerhalb von […] ITEM ATTRIBUTES (BG-32) der […] "Item attribute name" (BT-160) den Wert 'cva' hat, muss der […] "Item attribute value" (BT-161) einen der zulässigen Werte enthalten.

  What the rule requires

  The item attribute (BG-32) named cva carries the drive type, and its value (BT-161) must be exactly one of three codes: clean, zero-emission or other. The expression ignores leading and trailing spaces but not case. The restriction to attributes named cva lives in the rule’s context, not in the expression — an attribute named "CVA" is passed over, and on a line with a vehicle category BR-DE-CVD-06-a then reports the missing cva.

  Why it fires

  The codes get translated into German ("emissionsfrei", "sauber"), capitalised ("Zero-Emission") or replaced by a description of the drive ("Elektro", "Diesel"). Behind that is a field filled from the source system’s vehicle description rather than from a fixed mapping.

  How to fix it

  Map the drive type to one of the three codes explicitly and write it in lower case: in UBL in cbc:Value of the cac:AdditionalItemProperty whose cbc:Name is cva, in CII in ram:Value of the ram:ApplicableProductCharacteristic whose ram:Description is cva. Which code applies is a classification of the vehicle under the Clean Vehicles Directive — the validator only checks the spelling.

  In the XML

  A UBL fragment. The CII path is named above — same change, different element names.

  <cac:Item>
    <cbc:Name>Gelenkbus 18 m, batterieelektrisch</cbc:Name>
    <cac:CommodityClassification>
      <cbc:ItemClassificationCode listID="CVD">M3</cbc:ItemClassificationCode>
    </cac:CommodityClassification>
    <cac:ClassifiedTaxCategory>
      <cbc:ID>S</cbc:ID>
      <cbc:Percent>19</cbc:Percent>
      <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
    </cac:ClassifiedTaxCategory>
    <cac:AdditionalItemProperty>
      <cbc:Name>cva</cbc:Name>
      <cbc:Value>emissionsfrei</cbc:Value>
    </cac:AdditionalItemProperty>
  </cac:Item>

  <cac:Item>
    <cbc:Name>Gelenkbus 18 m, batterieelektrisch</cbc:Name>
    <cac:CommodityClassification>
      <cbc:ItemClassificationCode listID="CVD">M3</cbc:ItemClassificationCode>
    </cac:CommodityClassification>
    <cac:ClassifiedTaxCategory>
      <cbc:ID>S</cbc:ID>
      <cbc:Percent>19</cbc:Percent>
      <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
    </cac:ClassifiedTaxCategory>
    <cac:AdditionalItemProperty>
      <cbc:Name>cva</cbc:Name>
      <cbc:Value>zero-emission</cbc:Value>
    </cac:AdditionalItemProperty>
  </cac:Item>

  What the validator checks

  UBLnormalize-space(cbc:Value) = $CVA-CODES

  Variables in it

  $CVA-CODES

  ('clean', 'zero-emission', 'other')

  CIInormalize-space(ram:Value) = $CVA-CODES

  Variables in it

  $CVA-CODES

  ('clean', 'zero-emission', 'other')

• BR-DE-CVD-06-a

  A category requires a drive type (BT-158 → BT-160)

  Wenn der Scheme identifier von […] "Item classification identifier" (BT-158) mit dem Wert 'CVD' angegeben ist, muss in derselben Rechnungszeile genau ein […] "Item attribute name" (BT-160) mit dem Wert 'cva' vorhanden sein.

  What the rule requires

  Where an item carries a vehicle category — an item classification identifier (BT-158) under the CVD scheme — the same item must have exactly one attribute whose name (BT-160) is cva: not none, and not two. Only the exact name counts; "Antriebsart" or "CVA" does not. The reverse direction is BR-DE-CVD-06-b.

  Why it fires

  The drive type sits under a descriptive name such as "Antriebsart", or is missing because the source system does not hold it. Two cva attributes appear when one line combines several vehicles with different drives, or when the mapping writes the attributes twice.

  How to fix it

  Write exactly one cac:AdditionalItemProperty with cbc:Name cva per vehicle line in UBL, or one ram:ApplicableProductCharacteristic with ram:Description cva in CII, each with the drive type as its value. Vehicles with different drives belong on separate invoice lines.

  In the XML

  A UBL fragment. The CII path is named above — same change, different element names.

  <cac:Item>
    <cbc:Name>Gelenkbus 18 m, batterieelektrisch</cbc:Name>
    <cac:CommodityClassification>
      <cbc:ItemClassificationCode listID="CVD">M3</cbc:ItemClassificationCode>
    </cac:CommodityClassification>
    <cac:ClassifiedTaxCategory>
      <cbc:ID>S</cbc:ID>
      <cbc:Percent>19</cbc:Percent>
      <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
    </cac:ClassifiedTaxCategory>
    <cac:AdditionalItemProperty>
      <cbc:Name>Antriebsart</cbc:Name>
      <cbc:Value>zero-emission</cbc:Value>
    </cac:AdditionalItemProperty>
  </cac:Item>

  <cac:Item>
    <cbc:Name>Gelenkbus 18 m, batterieelektrisch</cbc:Name>
    <cac:CommodityClassification>
      <cbc:ItemClassificationCode listID="CVD">M3</cbc:ItemClassificationCode>
    </cac:CommodityClassification>
    <cac:ClassifiedTaxCategory>
      <cbc:ID>S</cbc:ID>
      <cbc:Percent>19</cbc:Percent>
      <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
    </cac:ClassifiedTaxCategory>
    <cac:AdditionalItemProperty>
      <cbc:Name>cva</cbc:Name>
      <cbc:Value>zero-emission</cbc:Value>
    </cac:AdditionalItemProperty>
  </cac:Item>

  What the validator checks

  UBLnot(cac:CommodityClassification/cbc:ItemClassificationCode[@listID = 'CVD']) or count(cac:AdditionalItemProperty[cbc:Name = 'cva']) = 1

  CIInot(ram:DesignatedProductClassification/ram:ClassCode/@listID = 'CVD') or count(ram:ApplicableProductCharacteristic[ram:Description = 'cva']) = 1

• BR-DE-CVD-06-b

  A drive type requires a category (BT-160 → BT-158)

  Wenn […] "Item attribute name" (BT-160) mit dem Wert 'cva' angegeben ist, muss in derselben Rechnungszeile genau ein […] "Item classification identifier" (BT-158) mit dem Scheme identifier 'CVD' vorhanden sein.

  What the rule requires

  Where an item carries an attribute whose name (BT-160) is cva, the same item must have exactly one item classification identifier (BT-158) under the CVD scheme: not none, and not two. Only listID="CVD" spelled exactly that way counts; the same category under another scheme does not. The reverse direction is BR-DE-CVD-06-a.

  Why it fires

  The category sits under another scheme, ZZZ for instance — a natural result if the line was first tested as an ordinary XRechnung, where BR-CL-13 rejects the CVD scheme because it is not in UNTDID 7143. Two categories appear when one line combines, say, a car (M1) and a van (N1).

  How to fix it

  Set the category exactly once per line with listID="CVD" — on cac:CommodityClassification/cbc:ItemClassificationCode in UBL, on ram:DesignatedProductClassification/ram:ClassCode in CII. Vehicles of different categories belong on separate invoice lines. Further classifications may stand alongside, as long as their scheme comes from UNTDID 7143 — which is what BR-TMP-CVD-01 checks.

  In the XML

  A UBL fragment. The CII path is named above — same change, different element names.

  <cac:Item>
    <cbc:Name>Gelenkbus 18 m, batterieelektrisch</cbc:Name>
    <cac:CommodityClassification>
      <cbc:ItemClassificationCode listID="ZZZ">M3</cbc:ItemClassificationCode>
    </cac:CommodityClassification>
    <cac:ClassifiedTaxCategory>
      <cbc:ID>S</cbc:ID>
      <cbc:Percent>19</cbc:Percent>
      <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
    </cac:ClassifiedTaxCategory>
    <cac:AdditionalItemProperty>
      <cbc:Name>cva</cbc:Name>
      <cbc:Value>zero-emission</cbc:Value>
    </cac:AdditionalItemProperty>
  </cac:Item>

  <cac:Item>
    <cbc:Name>Gelenkbus 18 m, batterieelektrisch</cbc:Name>
    <cac:CommodityClassification>
      <cbc:ItemClassificationCode listID="CVD">M3</cbc:ItemClassificationCode>
    </cac:CommodityClassification>
    <cac:ClassifiedTaxCategory>
      <cbc:ID>S</cbc:ID>
      <cbc:Percent>19</cbc:Percent>
      <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
    </cac:ClassifiedTaxCategory>
    <cac:AdditionalItemProperty>
      <cbc:Name>cva</cbc:Name>
      <cbc:Value>zero-emission</cbc:Value>
    </cac:AdditionalItemProperty>
  </cac:Item>

  What the validator checks

  UBLnot(cac:AdditionalItemProperty[cbc:Name = 'cva']) or count(cac:CommodityClassification/cbc:ItemClassificationCode[@listID = 'CVD']) = 1

  CIInot(ram:ApplicableProductCharacteristic/ram:Description = 'cva') or count(ram:DesignatedProductClassification/ram:ClassCode[@listID = 'CVD']) = 1

• BR-TMP-CVD-01

  Scheme of the item classification identifier (BT-158)

  Das Bildungsschema für […] "Item classification identifier" (BT-158) ist aus der Codeliste UNTDID 7143 zu wählen.

  What the rule requires

  In a CVD invoice every item classification identifier (BT-158) on the invoice lines must carry a scheme from the UNTDID 7143 code list — or CVD, which the list does not contain. A missing or empty listID gets through the expression, though: the variable puts CVD with its surrounding spaces in front of the list, and the double space at the join matches an empty value. A missing attribute is rejected by BR-65, an empty listID="" only in CII — in UBL, BR-65 merely checks that the attribute exists.

  Why it fires

  The scheme is an in-house abbreviation or a variant spelling — "cvd" in lower case, say, or the name of a register instead of its code. Every classification on the lines is checked, not only the vehicle category. In an ordinary XRechnung BR-CL-13 reports this; in the CVD variant the KoSIT validator configuration downgrades BR-CL-13 to a notice, because that rule does not know CVD, and BR-TMP-CVD-01 takes over the check as an error.

  How to fix it

  Use either CVD — for the vehicle category only — or a code from UNTDID 7143 as listID, spelled exactly as listed: on cac:CommodityClassification/cbc:ItemClassificationCode in UBL, on ram:DesignatedProductClassification/ram:ClassCode in CII. Make sure yourself that the attribute is never empty, because in UBL the rule set does not catch that case. BR-CL-13 still appearing for the code CVD in a valid CVD invoice is not a fault in the document.

  In the XML

  A UBL fragment. The CII path is named above — same change, different element names.

  <cac:Item>
    <cbc:Name>Gelenkbus 18 m, batterieelektrisch</cbc:Name>
    <cac:CommodityClassification>
      <cbc:ItemClassificationCode listID="cvd">M3</cbc:ItemClassificationCode>
    </cac:CommodityClassification>
    <cac:ClassifiedTaxCategory>
      <cbc:ID>S</cbc:ID>
      <cbc:Percent>19</cbc:Percent>
      <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
    </cac:ClassifiedTaxCategory>
    <cac:AdditionalItemProperty>
      <cbc:Name>cva</cbc:Name>
      <cbc:Value>zero-emission</cbc:Value>
    </cac:AdditionalItemProperty>
  </cac:Item>

  <cac:Item>
    <cbc:Name>Gelenkbus 18 m, batterieelektrisch</cbc:Name>
    <cac:CommodityClassification>
      <cbc:ItemClassificationCode listID="CVD">M3</cbc:ItemClassificationCode>
    </cac:CommodityClassification>
    <cac:ClassifiedTaxCategory>
      <cbc:ID>S</cbc:ID>
      <cbc:Percent>19</cbc:Percent>
      <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
    </cac:ClassifiedTaxCategory>
    <cac:AdditionalItemProperty>
      <cbc:Name>cva</cbc:Name>
      <cbc:Value>zero-emission</cbc:Value>
    </cac:AdditionalItemProperty>
  </cac:Item>

  What the validator checks

  UBL((not(contains(normalize-space(@listID), ' ')) and contains($UNTDID-7143-CVD-CODES, concat(' ', normalize-space(@listID), ' '))))

  Variables in it

  $UNTDID-7143-CVD-CODES

  concat($CVD-CODE, $UNTDID-7143-CODES)

  $CVD-CODE

  ' CVD '

  $UNTDID-7143-CODES

  'AA AB AC AD AE AF AG AH AI AJ …'185 values

  CII((not(contains(normalize-space(@listID), ' ')) and contains($UNTDID-7143-CVD-CODES, concat(' ', normalize-space(@listID), ' '))))

  Variables in it

  $UNTDID-7143-CVD-CODES

  concat($CVD-CODE, $UNTDID-7143-CODES)

  $CVD-CODE

  ' CVD '

  $UNTDID-7143-CODES

  'AA AB AC AD AE AF AG AH AI AJ …'185 values