fatalEN 16931EN 16931 business ruleCIIUBLBG-20BT-31BT-32BT-47BT-48BT-63BT-95
An Invoice that contains a Document level allowance (BG-20) where the Document level allowance VAT category code (BT-95) is "Reverse charge" shall contain the Seller VAT Identifier (BT-31), the Seller tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48) and/or the Buyer legal registration identifier (BT-47).
A document level allowance uses VAT category Reverse charge (AE), but the invoice does not identify both parties: it needs a seller identifier AND a buyer identifier, and at least one of the two is missing.
Add BOTH sides, not just one — this rule fails until both are present, which is why adding only the seller identifier leaves the same error in place. You need the Seller VAT identifier (BT-31) — or, if the seller is not VAT-registered in the usual way, the Seller tax registration identifier (BT-32) or the Seller tax representative VAT identifier (BT-63); and the Buyer VAT identifier (BT-48), or failing that the Buyer legal registration identifier (BT-47). Reverse charge means the BUYER accounts for the VAT instead of you, so the invoice has to identify who will do that — an invoice with no buyer VAT number is not a reverse-charge invoice, it is an invoice with missing VAT. In practice the seller identifier is already in your system and the buyer's is the one you have to collect and store; it is worth checking it against VIES before you send, because a wrong or lapsed number makes the reverse charge invalid and the VAT becomes yours to pay. If this is not really a reverse-charge supply, the other fix is to change the allowance's VAT category code instead.
CII — context $VATAE_Allowance
(//ram:SellerTradeParty/ram:SpecifiedTaxRegistration/ram:ID[@schemeID = ('VA', 'FC')] or //ram:SellerTaxRepresentativeTradeParty/ram:SpecifiedTaxRegistration/ram:ID[@schemeID = 'VA']) and (//ram:BuyerTradeParty/ram:SpecifiedTaxRegistration/ram:ID[@schemeID = 'VA'] or //ram:BuyerTradeParty/ram:SpecifiedLegalOrganization/ram:ID)UBL — context /ubl:Invoice | /cn:CreditNote
(exists(//cac:AllowanceCharge[cbc:ChargeIndicator=false()]/cac:TaxCategory[normalize-space(cbc:ID) = 'AE'][cac:TaxScheme/normalize-space(upper-case(cbc:ID))='VAT']) and (exists(//cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID) or exists(//cac:TaxRepresentativeParty/cac:PartyTaxScheme[cac:TaxScheme/(normalize-space(upper-case(cbc:ID)) = 'VAT')]/cbc:CompanyID)) and (exists(//cac:AccountingCustomerParty/cac:Party/cac:PartyTaxScheme[cac:TaxScheme/(normalize-space(upper-case(cbc:ID)) = 'VAT')]/cbc:CompanyID) or exists(//cac:AccountingCustomerParty/cac:Party/cac:PartyLegalEntity/cbc:CompanyID))) or not(exists(//cac:AllowanceCharge[cbc:ChargeIndicator=false()]/cac:TaxCategory[normalize-space(cbc:ID) = 'AE'][cac:TaxScheme/normalize-space(upper-case(cbc:ID))='VAT']))
Nothing is stored, and the whole invoice is checked, not just this rule. A PDF only works if it is Factur-X / ZUGFeRD — a PDF with the invoice XML inside it.