BR-AE-04 This invoice contains a document level charge (BG-21) whose VAT category code (BT-102) is AE (Reverse charge) — charges[0] — so the invoice must 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)
This invoice contains a document level charge (BG-21) whose VAT category code (BT-102) is AE (Reverse charge) — charges[0] — so the invoice must 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). Reverse charge moves the VAT liability to the buyer, who self-assesses it. A document level adjustment in category AE changes the base they self-assess on, so both ends of the transfer have to be identifiable: yours for the output side that reports zero, theirs for the input side that reports the tax. This is the only allowance/charge family that constrains the buyer as well as the seller.
This rule is implemented and its error payload below is real, but the long-form write-up — normative text, worked example, divergence note — is not written yet. Everything the library knows about this rule is on this page. Ask and we will prioritise it.
- Business term
BT-31 / BT-48- Severity
fatal
What the library returns
The exact object in result.errors when this rule fires.
Generated by running @attestwire/en16931, not transcribed:
{
"rule": "BR-AE-04",
"field": [
"BT-31",
"BT-48"
],
"severity": "fatal",
"message": "This invoice contains a document level charge (BG-21) whose VAT category code (BT-102) is AE (Reverse charge) — charges[0] — so the invoice must 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). Reverse charge moves the VAT liability to the buyer, who self-assesses it. A document level adjustment in category AE changes the base they self-assess on, so both ends of the transfer have to be identifiable: yours for the output side that reports zero, theirs for the input side that reports the tax. This is the only allowance/charge family that constrains the buyer as well as the seller.",
"fix": "Set buyer.vatId to your client's VAT number (buyer.legalRegistrationId also satisfies the rule) and make sure seller.vatId or seller.taxRegistrationId is set. Validate the buyer's number against VIES on the invoice date and keep the response — if it is invalid at the time of supply the liability stays with you.",
"example": "\"buyer\": { \"vatId\": \"ATU12345678\" }",
"xpath": "/ubl:Invoice/cac:AllowanceCharge[2]/cac:TaxCategory/cbc:ID",
"docsUrl": "https://attestwire.com/rules/BR-AE-04"
}
xpath locates the element in the generated UBL document,
which is where a KoSIT or Peppol validator will report the same problem.
A passing value
"buyer": { "vatId": "ATU12345678" }The fix
Set buyer.vatId to your client's VAT number (buyer.legalRegistrationId also satisfies the rule) and make sure seller.vatId or seller.taxRegistrationId is set. Validate the buyer's number against VIES on the invoice date and keep the response — if it is invalid at the time of supply the liability stays with you.