# BR-IC-01: Send exactly one intra-community VAT breakdown
A document with any intra-community content (category `K`) must have one VAT breakdown in category `K`: not none, and not two.
- Layer: EN 16931
- Severity: fatal (the document is invalid)
- Topics: VAT
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-IC-01/
- Explanation last updated: 2026-09-28
## The short answer
`BR-IC-01` fails when category `K` appears anywhere in the document, on a line, a document-level allowance or charge, or a VAT breakdown, and the root `cac:TaxTotal` does not hold exactly one `cac:TaxSubtotal` whose tax category is `K`. The recorded example writes the intra-community breakdown twice; delete the copy.
When there is no `K` breakdown at all, add one: the taxable amount of the `K` content, a tax amount of 0.00, a rate of 0 and the reason `VATEX-EU-IC`.
## What the rule checks
The rule runs once, at the document root. It looks for `K` under the `VAT` scheme in any `cac:ClassifiedTaxCategory` or `cac:TaxCategory`, then counts the `K` tax categories in the root VAT breakdown, and passes only when that count is 1.
Two identical `K` breakdowns fail even though each one matches the line. This rule was the only finding for the recorded example, because `BR-IC-08` compares each breakdown with the whole `K` sum and both held the full 25.00.
A split fails more loudly. When tried on an invoice with a freight charge in `K`, one `K` breakdown of 25.00 for the line and another of 6.00 for the freight reported this rule and `BR-IC-08` on each breakdown.
An allowance or charge brings the rule into play on its own. When tried, a Standard rated invoice with a freight charge coded `K` and no `K` breakdown reported this rule, and `BR-IC-04` as well, since that buyer had no VAT identifier.
A `K` breakdown with no `K` content behind it passes, because the breakdown is itself the `K` occurrence and the count is 1. When tried with the only line recoded `Z`, the leftover breakdown was reported by `BR-IC-08` and the line by `BR-Z-01`, not by this rule.
Recoding the breakdown to another category silences the delivery checks too, because `BR-IC-11` and `BR-IC-12` look for a `K` breakdown. When tried with the breakdown recoded `Z` over the `K` line, the document reported this rule and `BR-Z-08` only.
| Term | Meaning | UBL element |
|---|---|---|
| BT-118 | VAT category code | `cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory/cbc:ID` |
| BT-151 | Invoiced item VAT category code | `cac:InvoiceLine/cac:Item/cac:ClassifiedTaxCategory/cbc:ID (cac:CreditNoteLine/cac:Item/cac:ClassifiedTaxCategory/cbc:ID in a credit note)` |
| BT-95 | Document level allowance VAT category code | `cac:AllowanceCharge[cbc:ChargeIndicator = false]/cac:TaxCategory/cbc:ID` |
| BT-102 | Document level charge VAT category code | `cac:AllowanceCharge[cbc:ChargeIndicator = true]/cac:TaxCategory/cbc:ID` |
## How an integration ends up here
Possible causes, from the shape of the rule rather than from measured usage:
- The breakdown is built once from the lines and appended again after a recalculation, without the first one being removed.
- Breakdowns are grouped by tax code rather than by category, and two tax codes, one for goods and one for freight, both map to `K`.
- The line category is switched to `K` for EU customers while the breakdown is still generated from the domestic tax code, so the document has `K` lines under an `S` or `Z` breakdown.
- A document-level charge is coded `K` on an otherwise domestic invoice, so `K` appears without any breakdown for it.
## How to fix it
1. Count the `cac:TaxSubtotal` elements whose `cac:TaxCategory/cbc:ID` is `K`, and list where else `K` appears: line items and root-level allowances and charges.
2. If there are two or more, merge them into one. Its taxable amount is the `K` line net amounts plus `K` charges minus `K` allowances, its tax amount is 0.00, and it keeps the reason code `VATEX-EU-IC` and text.
3. If there is none, decide first whether the `K` content is right. For a genuine intra-community supply, add the `K` breakdown, and check the delivery date or invoicing period and the deliver-to country that `BR-IC-11` and `BR-IC-12` then require; for a line or charge coded `K` by mistake, give it the category and rate of the rest of the document instead.
4. Group breakdowns by VAT category and rate, never by tax code, source module or line, so the duplicate cannot come back.
## Before and after
These are fragments, not complete documents. The complete synthetic documents they come from are linked below.
Fragment of the failing invoice: two VAT breakdowns in category K, each for the full 25.00
```xml
0.00
25.00
0.00
K
25.00
0.00
K
```
Fragment of the corrected invoice: one K breakdown
```xml
0.00
25.00
0.00
K
0
VATEX-EU-IC
Intra-community supply
VAT
```
The failing invoice has two `cac:TaxSubtotal` elements for category `K`, each with a taxable amount of 25.00; the corrected invoice has one. The failing document reports only `BR-IC-01`, and its VAT total of 0.00 and other amounts are unchanged.
### What the validator reported
- The failing invoice reports **BR-IC-01**. The corrected document passes every layer with no findings.
- [Download the failing XML](https://ironfang.com/finance/rule-examples/BR-IC-01-invalid.xml)
- [Download the corrected XML](https://ironfang.com/finance/rule-examples/intra-community-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`. The failing invoice converted to a credit note reported the same single finding when tried.
- Reported by the EN 16931 layer once per document, at the root, however many `K` breakdowns there are.
- Reverse charge has the same one-breakdown requirement under `BR-AE-01`.
- Once the single `K` breakdown is in place, its amounts are checked by `BR-IC-08` and `BR-IC-09`, and its presence brings in `BR-IC-10`, `BR-IC-11` and `BR-IC-12`.
## Related rules
- [BR-IC-08 checks the taxable amount of the single K breakdown against the K lines, charges and allowances](https://ironfang.com/docs/finance/rules/BR-IC-08.md)
- [BR-AE-01 is the same count for the reverse-charge breakdown](https://ironfang.com/docs/finance/rules/BR-AE-01.md)
- [BR-IC-09 requires the tax amount of the K breakdown to be zero](https://ironfang.com/docs/finance/rules/BR-IC-09.md)
- [BR-IC-11 asks for a delivery date or invoicing period once a K breakdown is present](https://ironfang.com/docs/finance/rules/BR-IC-11.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-01](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-IC-01/) 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-01)
- [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