# BR-IC-04: Identify the seller and buyer under the VAT scheme when a document charge is intra-community
A document-level charge in category `K` requires a seller VAT identifier, or a tax representative's, and a buyer VAT identifier, both under the `VAT` scheme.
- 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-04/
- Explanation last updated: 2026-09-28
## The short answer
`BR-IC-04` fails when a document-level charge, `cbc:ChargeIndicator` of `true`, is in category `K` and the document does not identify the seller side and the buyer under the `VAT` scheme. In the recorded example the freight charge of 6.00 is in `K`, and the seller's `GB123456789` sits in a `cac:PartyTaxScheme` whose scheme is `TAX`; changing that scheme to `VAT` fixes it.
A number under `TAX` is a seller tax registration identifier, not a seller VAT identifier. For the seller side, that distinction is what this rule turns on, while some other VAT category rules accept either.
## What the rule checks
The rule fires on any `cac:AllowanceCharge` with `cbc:ChargeIndicator` of `true` whose `cac:TaxCategory` has `cbc:ID` of `K` under the `VAT` scheme, and reports once, at the root.
On the seller side, only a `cbc:CompanyID` in a seller `cac:PartyTaxScheme` with scheme `VAT` counts, or one in `cac:TaxRepresentativeParty` with scheme `VAT`. When tried, removing the seller `cac:PartyTaxScheme` altogether gave the same two findings as the `TAX` scheme did.
A seller with both schemes passes. When tried, adding a `VAT` `cac:PartyTaxScheme` with `GB123456789` next to the `TAX` one made the failing invoice valid.
A tax representative satisfies the seller side on its own. When tried, a German `cac:TaxRepresentativeParty` with `DE987654321` under `VAT`, added to the failing invoice with the seller still under `TAX`, made it valid.
The buyer side has no alternative: it needs a buyer `cac:PartyTaxScheme/cbc:CompanyID` under `VAT`. Removing it from the valid freight invoice reported this rule and `BR-IC-02` when tried.
The charge triggers the rule without any `K` line. When tried with the only line moved to category `Z` and the breakdowns adjusted to match, the freight in `K` reported this rule without `BR-IC-02`.
| Term | Meaning | UBL element |
|---|---|---|
| BT-102 | Document level charge VAT category code | `cac:AllowanceCharge[cbc:ChargeIndicator = true]/cac:TaxCategory/cbc:ID` |
| BT-31 | Seller VAT identifier | `cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID (tax scheme VAT)` |
| BT-32 | Seller tax registration identifier | `cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID (a tax scheme other than VAT)` |
| 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 (tax scheme VAT)` |
## How an integration ends up here
Possible causes, from the shape of the rule rather than from measured usage:
- The seller's VAT number is configured under a generic tax scheme code, `TAX`, which domestic Standard rated invoices accept.
- The seller holds a national tax number as well as a VAT number, and the export writes only the first one it finds.
- The seller uses a fiscal representative in the destination country, and `cac:TaxRepresentativeParty` is sent without its `cac:PartyTaxScheme`.
- Freight is added to the invoice after the party data was built for a domestic document.
## How to fix it
1. Look at every `cac:PartyTaxScheme` under the seller party and read its `cac:TaxScheme/cbc:ID`. The seller VAT number has to be under `VAT`.
2. If the number there is the seller VAT identifier, change the scheme to `VAT`. If it is a national tax number, keep it under `TAX` and add a second `cac:PartyTaxScheme` holding the VAT identifier.
3. If the seller acts through a fiscal representative, send `cac:TaxRepresentativeParty` with name, postal address and a `VAT` `cac:PartyTaxScheme`, after `cac:AccountingCustomerParty`.
4. Check the buyer as well: in the recorded example, `DE123456789` under `VAT` in the buyer party already satisfies the buyer side.
## 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 freight charge in category K, and the seller number under the tax scheme TAX
```xml
7300010000001
GB123456789
TAX
true
FC
Freight to Berlin
6.00
K
0
VAT
```
Fragment of the corrected invoice: the same seller number under the VAT scheme
```xml
7300010000001
GB123456789
VAT
```
Only the seller's tax scheme differs: `TAX` in the failing invoice, `VAT` in the corrected one, with `GB123456789` in both. The failing document reports `BR-IC-02` as well as `BR-IC-04`, since its line is in category `K` and meets the same seller-side test.
### What the validator reported
- The failing invoice reports [BR-IC-02](https://ironfang.com/docs/finance/rules/BR-IC-02.md) and **BR-IC-04**. The corrected document passes every layer with no findings.
- [Download the failing XML](https://ironfang.com/finance/rule-examples/BR-IC-04-invalid.xml)
- [Download the corrected XML](https://ironfang.com/finance/rule-examples/intra-community-freight-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`. As a credit note, the failing invoice gave `BR-IC-02` and this rule when tried.
- Reported by the EN 16931 layer once per document, at the root.
- The reverse-charge rule for charges, `BR-AE-04`, would accept the seller number under `TAX`, and so would the Standard rated seller check `BR-S-02`.
- The rate on the charge is a separate matter for `BR-IC-07`, and the charge amount must be inside the `K` taxable amount under `BR-IC-08`.
## Related rules
- [BR-IC-02 applies the same seller and buyer test to K lines and is reported beside this rule](https://ironfang.com/docs/finance/rules/BR-IC-02.md)
- [BR-IC-03 is the identifier rule for a K document allowance, shown with the buyer side missing](https://ironfang.com/docs/finance/rules/BR-IC-03.md)
- [BR-AE-04 is the reverse-charge version for document charges, which accepts a seller identifier under any scheme](https://ironfang.com/docs/finance/rules/BR-AE-04.md)
- [BR-IC-07 requires the same K charge to carry a rate of 0](https://ironfang.com/docs/finance/rules/BR-IC-07.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-04](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-IC-04/) 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-04)
- [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