# BR-IC-03: Add the VAT identifiers that an intra-community document allowance requires
A document-level allowance in category `K` needs what a `K` line needs: a seller or tax representative VAT identifier, and a buyer VAT identifier.
- Layer: EN 16931
- Severity: fatal (the document is invalid)
- Topics: VAT, Parties and addresses, Allowances and charges
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-IC-03/
- Explanation last updated: 2026-09-28
## The short answer
`BR-IC-03` fails when a document-level allowance, `cbc:ChargeIndicator` of `false`, has tax category `K` and the document lacks a VAT identifier for the seller side or for the buyer. In the recorded example the full pallet discount of 1.25 is in `K` and the buyer has no `cac:PartyTaxScheme`; adding the buyer VAT identifier `DE123456789` under the `VAT` scheme fixes it.
An intra-community discount normally sits beside `K` lines, so `BR-IC-02` arrives with it, as it does here. One missing identifier gives both findings, and adding it clears both.
## What the rule checks
The trigger is any `cac:AllowanceCharge` with `cbc:ChargeIndicator` of `false` whose `cac:TaxCategory` is `K` under the `VAT` scheme. The finding is raised once, at the document root.
The allowance is enough without any `K` line. When tried, the recorded failing invoice with its line moved to category `Z`, and the breakdowns adjusted to match, reported this rule and not `BR-IC-02`.
The identifiers asked for are those a `K` line needs: on the seller side a `VAT` `cac:PartyTaxScheme/cbc:CompanyID` for the seller or for a tax representative, and on the buyer side a `VAT` `cac:PartyTaxScheme/cbc:CompanyID` for the buyer.
A buyer legal registration identifier is no substitute. The failing invoice keeps `87654321` in the buyer `cac:PartyLegalEntity` and still fails, whereas the reverse-charge allowance rule `BR-AE-03` would accept it.
A buyer number under another scheme does not count either. When tried, `DE123456789` with the tax scheme `TAX` reported this rule and `BR-IC-02`, exactly as its absence did.
| Term | Meaning | UBL element |
|---|---|---|
| BT-95 | Document level allowance VAT category code | `cac:AllowanceCharge[cbc:ChargeIndicator = false]/cac:TaxCategory/cbc:ID` |
| BT-31 | Seller VAT identifier | `cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID` |
| BT-63 | Seller tax representative VAT identifier | `cac:TaxRepresentativeParty/cac:PartyTaxScheme/cbc:CompanyID` |
| BT-48 | Buyer VAT identifier | `cac:AccountingCustomerParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID` |
## How an integration ends up here
Possible causes, from the shape of the rule rather than from measured usage:
- The buyer VAT number is mapped only for reverse-charge documents, and the export fills the parties of an intra-community supply as if it were domestic.
- The customer was set up for EU deliveries by delivery country alone, and its VAT number was never collected.
- The discount takes category `K` from the lines, while the buyer party comes from an order record that has no tax fields.
- The buyer VAT number is held on a contact or delivery record that the invoice export does not read.
## How to fix it
1. Confirm that the discount belongs to the intra-community supply. A discount on `K` goods takes category `K` and a rate of 0.
2. Take the buyer VAT identifier from the customer record, with its country prefix, and write it as `cac:PartyTaxScheme` with `cbc:CompanyID` and `cac:TaxScheme/cbc:ID` of `VAT`, between `cac:PostalAddress` and `cac:PartyLegalEntity` in the buyer party.
3. Check the seller side at the same time: the seller `cac:PartyTaxScheme` must use the `VAT` scheme, or a `cac:TaxRepresentativeParty` must carry a `VAT` identifier. `BR-IC-04` shows the seller side failing.
4. If the buyer has no VAT number, take the category of the lines and the discount back to the tax determination rather than inventing an identifier.
## Before and after
These are fragments, not complete documents. The complete synthetic documents they come from are linked below.
Fragment of the failing invoice: a discount in category K, and a buyer with a legal registration identifier but no VAT identifier
```xml
7300010000001
Example Buyer Ltd
87654321
false
95
Full pallet discount
1.25
K
0
VAT
```
Fragment of the corrected invoice: the buyer VAT identifier DE123456789 under the VAT scheme
```xml
7300010000001
DE123456789
VAT
Example Buyer Ltd
87654321
```
The corrected invoice gives the buyer `DE123456789` in a `VAT` `cac:PartyTaxScheme`; the failing invoice has no buyer VAT identifier, and the discount of 1.25 in `K` is the same in both. Besides `BR-IC-03`, the failing document reports `BR-IC-02`, because its line is also in category `K`.
### What the validator reported
- The failing invoice reports [BR-IC-02](https://ironfang.com/docs/finance/rules/BR-IC-02.md) and **BR-IC-03**. The corrected document passes every layer with no findings.
- [Download the failing XML](https://ironfang.com/finance/rule-examples/BR-IC-03-invalid.xml)
- [Download the corrected XML](https://ironfang.com/finance/rule-examples/intra-community-discount-valid.xml)
Recorded on phive 12.1.0 / phive-rules-peppol 4.5.6 / Saxon-HE 12.10, the engine behind the free validator, using synthetic data. A recorded result is regression evidence for these documents; it is not a certification.
## Where it applies
- Applies to UBL `Invoice` and `CreditNote`. Converted to a credit note, the failing invoice reported `BR-IC-02` and this rule when tried.
- Reported by the EN 16931 layer as one fatal finding at the root, whichever side is missing.
- Charges in `K` have the same requirement under `BR-IC-04`, and lines under `BR-IC-02`. The reverse-charge equivalent for allowances, `BR-AE-03`, also accepts a seller identifier under any scheme and a buyer legal registration identifier.
## Related rules
- [BR-IC-02 makes the same identifier demand for K lines and is reported beside this rule](https://ironfang.com/docs/finance/rules/BR-IC-02.md)
- [BR-IC-04 is the identifier rule for a K document charge, shown with the seller side missing](https://ironfang.com/docs/finance/rules/BR-IC-04.md)
- [BR-AE-03 is the looser reverse-charge version for document allowances](https://ironfang.com/docs/finance/rules/BR-AE-03.md)
- [BR-IC-06 requires the same K discount to carry a rate of 0](https://ironfang.com/docs/finance/rules/BR-IC-06.md)
## Scope and source
Written for Peppol BIS Billing 3.0.21 (May 2026), EN 16931 1.3.16, as applied to UBL 2.1 Invoice and CreditNote documents. Other profiles, syntaxes and releases can define this identifier differently. Guidance version 2026-09-28.1: source checked 2026-09-28, explanation last updated 2026-09-28.
[The official definition of BR-IC-03](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-IC-03/) carries the normative wording and test. This page is our explanation of it, not a copy.
Guidance does not change the engine verdict. Fixing this finding does not mean the document passes every layer, and validation does not certify legal or tax compliance or transmit a document over Peppol.
## Links
- [This rule as a web page](https://ironfang.com/docs/finance/rules/BR-IC-03)
- [Free Peppol invoice validator](https://ironfang.com/tools/peppol-validator)
- [Rule index](https://ironfang.com/docs/finance/rules.md)
- [Ironfang Finance API docs](https://ironfang.com/docs/finance)
- The same rule is available to MCP clients as the tool `finance.rule.get` on https://mcp.ironfang.com/mcp