Attestwire › Rule reference › BR-AE-02
BR-AE-02 Reverse charge requires both parties to be identified
noun · EN 16931 · fatal · BT-31 / BT-32
a reverse charge with one of the two parties missing.
Your invoice was refused because it applies reverse charge, where the customer accounts for the VAT instead of you, but does not identify both parties for VAT. Reverse charge only works when the invoice shows who is shifting the tax and who is taking it on, so the fix is to add the missing VAT or registration number, usually the customer’s. In the standard the rule is BR-AE-02, and the fields are the seller’s VAT identifiers (BT-31, BT-32, BT-63) and the buyer’s (BT-48, BT-47).
- Business term
BT-31 / BT-32— Seller and buyer VAT identifiers- Severity
fatal- Applies to
All profiles
The fix
Ask the customer for their VAT number and put it in the buyer VAT identifier, buyer.vatId. Make it a hard requirement on any customer you are willing to invoice under reverse charge. Validate it against VIES when you save it, and store both the timestamp and the consultation number VIES gives back, because that number is your evidence.
Re-check it periodically, since registrations get cancelled and it is the status on the date of supply that counts. If a customer has no VAT ID and no legal registration identifier, they are not eligible for reverse charge: charge domestic VAT rather than leaving the field empty.
What the rule requires
If any invoice line is marked reverse charge, code AE in BT-151, the invoice must identify the seller for VAT, through BT-31, BT-32 or BT-63, and identify the buyer, through BT-48 (buyer VAT identifier) or BT-47 (buyer legal registration identifier).
Our input check covers both halves. An AE line with neither buyer.vatId nor buyer.legalRegistrationId is fatal. So is an AE line on an invoice with no seller identifier at all (no seller.vatId, no seller.taxRegistrationId and no taxRepresentative). The seller half is in the EN 16931 schematron, not in a national add-on, so it applies on every profile.
A common misunderstanding: reverse charge is not a discount, and it is not an exemption. The supply is still taxable. What moves is the obligation to account for the VAT, from you to your customer, and that only works if the customer is identifiable as a taxable person. That is what the buyer VAT identifier is for.
An Invoice that contains an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) 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).
Failing and passing
validateInput({
// ...
buyer: {
name: "Client GmbH",
// neither vatId nor legalRegistrationId <- BR-AE-02
address: { city: "Wien", postalCode: "1010", countryCode: "AT" },
},
lines: [{ id: "1", description: "API subscription", quantity: 1,
unitCode: "C62", unitPrice: 490,
vatCategory: "AE", vatRate: 0 }],
});
// -> { valid: false, errors: [ { rule: "BR-AE-02", ... } ] }validateInput({
// ...
buyer: {
name: "Client GmbH",
vatId: "ATU12345678", // verified against VIES, response retained
address: { city: "Wien", postalCode: "1010", countryCode: "AT" },
},
lines: [{ /* ... */ vatCategory: "AE", vatRate: 0 }],
});
// -> { valid: true, errors: [] }Why it exists
Under reverse charge your buyer self-assesses output VAT and usually reclaims the same amount as input VAT, a net-zero entry they still have to file. Their identifier on your invoice is your evidence that shifting the liability was legitimate. If it is missing, or if it was invalid on the date of supply, a tax authority can treat the supply as domestic and taxable, and that assessment lands on you, the supplier, not on your customer.
That is why the library’s fix line tells you to check VIES and keep the response rather than only fill the field in.
What the library returns
The full error returned by @attestwire/en16931. It includes the rule ID,
affected field and suggested correction. Developers can use this object in their application:
{
"rule": "BR-AE-02",
"field": [
"BT-31",
"BT-32"
],
"severity": "fatal",
"message": "A line uses VAT category AE (Reverse charge), so the invoice must carry the seller VAT identifier (BT-31), the seller tax registration identifier (BT-32), or a seller tax representative (BG-11). Under reverse charge you charge no VAT, but the supply is still yours and the authority still has to attribute it to you — the buyer's self-assessed input is matched against a named supplier.",
"fix": "Set seller.vatId (e.g. \"DE123456789\"). If you are not VAT-registered but have a national tax number, set seller.taxRegistrationId instead.",
"example": "\"seller\": { \"vatId\": \"DE123456789\" }",
"docsUrl": "https://attestwire.com/rules/BR-AE-02"
}How our check differs
Both halves fire under this rule id. An AE invoice with no seller identifier (no BT-31, BT-32 or BT-63) fails as BR-AE-02 on every profile, not just on XRechnung.
You may see BR-CO-26 beside it, and BR-DE-16 as well on XRechnung. Those rules break on the same omission, so all of them report it.
The gap that is left is scope. The official rule also covers document level allowances and charges (BG-20/BG-21) marked AE.
This check reads invoice lines only, so an AE charge on an invoice with no AE line does not reach it. That case comes back as BR-AE-03, which reads the document level allowances and charges and asks for the same identifiers. A KoSIT or Peppol report would name BR-AE-02 for it, so if you automate on ids, allow for both.