XRechnung 2.0.2: CII validation rule changes

For an endpoint identifier (cbc:EndpointID or ram:URIID) that has a schemeID and the invoice declares itself as an XRechnung extension, the schemeID must be exactly one of the codes from the CEF EAS code list accepted by the rule, with no spaces inside the value. The test fails if the schemeID is empty or whitespace-only, contains an internal space, or is not in the allowed code list.

Set the schemeID attribute to a valid CEF EAS code from the rule's list, such as "0088" or "0208". Ensure the value is not empty and does not contain spaces. If the current scheme identifier is not in the list, map it to the appropriate CEF EAS code.

In UBL, the rule applies to cac:InvoiceLine/cac:Item/cac:CommodityClassification/cbc:ItemClassificationCode and cac:CreditNoteLine/cac:Item/cac:CommodityClassification/cbc:ItemClassificationCode, and requires the @listID attribute to exist. The UBL test only checks exists(@listID), so it requires the attribute to be present, even if empty. In CII, the rule applies to //ram:DesignatedProductClassification and passes if ram:ClassCode is absent, or if ram:ClassCode has a @listID with non-whitespace content. If ram:ClassCode is present but its @listID is missing or empty/whitespace, the rule fails.

For UBL, add a listID attribute to the cbc:ItemClassificationCode element and set it to a value identifying the classification scheme; the rule does not define the allowed values, so consult the relevant code list or specification. For CII, if you include ram:ClassCode inside ram:DesignatedProductClassification, set its listID attribute to a non-empty scheme identifier; alternatively, if no classification code is required, the element may be omitted.

The rule requires cbc:TaxCurrencyCode (UBL) or ram:TaxCurrencyCode (CII) to hold an ISO 4217 alpha-3 currency code from the list accepted by BR-CL-05. It passes only when the normalized value is exactly one of the 178 listed codes, for example EUR, USD, or GBP. A document fails if the element is empty, contains only whitespace, has an internal space, or uses a code not on that list.

Put a valid ISO 4217 alpha-3 currency code in the tax currency field, such as EUR, USD, or GBP. Ensure the value has no internal spaces (surrounding whitespace is ignored by the rule) and is not empty or only whitespace. Check that the code is present in the BR-CL-05 list; if the current code is something else, replace it with the correct three-letter ISO 4217 code.

The rule requires the invoice currency code to be a valid ISO 4217 alpha-3 currency code. It checks that the code contains no spaces and appears in the rule's list of accepted currency codes. A document fails if cbc:DocumentCurrencyCode (UBL) or ram:InvoiceCurrencyCode (CII) is empty, contains whitespace, or is not one of the listed codes.

Set the currency code element to a three-letter ISO 4217 code from the list allowed by the rule, for example EUR, USD, or GBP. In UBL use cbc:DocumentCurrencyCode; in CII use ram:InvoiceCurrencyCode. Ensure the value contains no spaces.

The rule requires that the @currencyID attribute on amount elements (UBL) or on ram:TaxTotalAmount (CII) contains an ISO 4217 alpha-3 currency code from the list accepted by the rule, and that the code contains no spaces. Because the severity is fatal, an invoice that does not satisfy this condition is rejected with message [BR-CL-03]-currencyID MUST be coded using ISO code list 4217 alpha-3.

Set the currencyID attribute to a valid three-letter ISO 4217 alpha-3 code that appears in the rule's list, for example EUR or USD. Ensure the value is not empty and contains no spaces. In UBL this applies to amount elements such as cbc:TaxAmount; in CII it applies to ram:TaxTotalAmount[@currencyID]. If the current value is not a valid code, correct it in the source system.

This advisory rule checks the CII element ram:SpecifiedTradePaymentTerms inside ram:ApplicableHeaderTradeSettlement. It requires that there be at most one such element; the test is count(ram:SpecifiedTradePaymentTerms) <= 1. If more than one is present, the validator reports this warning; the document is not rejected for it, but the recommendation is to have only one.

Ensure that /rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement contains no more than one ram:SpecifiedTradePaymentTerms. If the invoice currently contains multiple payment terms, reduce them to a single SpecifiedTradePaymentTerms element, or check which one should be kept if multiple are output by the system.

The rule checks that in /rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement there is at most one ram:AdditionalReferencedDocument element whose ram:TypeCode equals 130. This is a warning, so a document with more than one such element is still valid, but the validator reports it as advisory.

Ensure that under ram:ApplicableHeaderTradeAgreement only one ram:AdditionalReferencedDocument has ram:TypeCode set to 130. Remove any extra ram:AdditionalReferencedDocument elements with that type code, or change their ram:TypeCode if they serve a different purpose.

The rule requires that inside ram:ApplicableHeaderTradeAgreement there is no more than one ram:AdditionalReferencedDocument with ram:TypeCode equal to 50. This is a warning, so a document with multiple such elements is not rejected, but it is recommended to have at most one. The test counts these elements and reports if the count exceeds 1.

Ensure that ram:ApplicableHeaderTradeAgreement contains at most one ram:AdditionalReferencedDocument with ram:TypeCode=50. If multiple are present, remove the duplicates or combine the data so only one such reference remains. In the generating system, make sure it does not emit more than one additional referenced document of this type.

This rule checks that the total number of ram:Description elements inside all ram:SpecifiedTradePaymentTerms under ram:ApplicableHeaderTradeSettlement is at most 1. Since the severity is warning, a document with more than one such description is not rejected, but the validator reports it as advisory. The test counts descriptions across all payment terms, not per term, so multiple payment terms each with a description would trigger the warning.

Reduce the number of ram:Description elements under ram:SpecifiedTradePaymentTerms to zero or one in total. For example, keep only one ram:SpecifiedTradePaymentTerms/ram:Description and remove the others, or consolidate the information into a single description.

The rule requires that ram:BuyerTradeParty contains at most one ram:DefinedTradeContact. The test allows zero or one contact; a document fails only if it has two or more DefinedTradeContact elements under the buyer trade party.

Remove or merge the extra ram:DefinedTradeContact elements under /rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:BuyerTradeParty so that at most one remains.

The rule requires that each line-level settlement (ram:SpecifiedLineTradeSettlement) contains exactly one tax breakdown (ram:ApplicableTradeTax). Since this is a warning, the validator reports the document but does not reject it when the count is not 1 (i.e. zero or more than one).

In the CII invoice, ensure that every ram:SpecifiedLineTradeSettlement has exactly one ram:ApplicableTradeTax child element. If there are multiple ApplicableTradeTax elements, adjust the line so only one tax category is represented; if none is present, add one.

The rule requires that under ram:ApplicableHeaderTradeAgreement, the ram:SellerTradeParty element contains at most one ram:DefinedTradeContact child. A document fails this fatal rule if two or more ram:DefinedTradeContact elements are present. Zero occurrences are allowed.

Check the ram:SellerTradeParty element inside ram:ApplicableHeaderTradeAgreement. Remove any extra ram:DefinedTradeContact elements so that only one remains (or none). If multiple contacts seem necessary, consolidate the details into a single ram:DefinedTradeContact element.