BR-02An Invoice shall have an Invoice number (BT-1).
Official rule text
The invoice must carry an invoice number (BT-1) — the identifier the recipient books it under, pays against and refers back to. A reminder, a credit note and a remittance advice all point at it later.
- Severity
- Error
- Applies to
- CII, UBL
- Rule set
- v2026-08-31
- Checked on
Written and checked against the official KoSIT rule set by Dmytro Yalanskyi, NormAPI.
Why does BR-02 happen?
In practice almost always a mapping error: the field is named differently internally and never populated on export, or the number is assigned only after the document is generated.
What the validator checks
The expression the official KoSIT rule set evaluates — not paraphrased, but read from the Schematron file it ships. UBL and CII address different document trees, so the same rule reads differently in each.
- UBL
normalize-space(cbc:ID) != ''- CII
normalize-space(rsm:ExchangedDocument/ram:ID) != ''
Source: rule set v2026-08-31
How do you fix BR-02?
Populate BT-1 with your invoice number before generating the document — cbc:ID at document level in UBL, ram:ID inside ExchangedDocument in CII. Watch the data type while you do: BT-1 is text, not a number. Route it through a numeric field on the way and leading zeros disappear — “RE-0042” becomes 42, and the invoice goes out carrying a number that does not exist in your books. No rule catches that; the reconciliation does.
In the XML
A UBL fragment. The CII path is named above — same change, different element names.
<cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0</cbc:CustomizationID>
<cbc:IssueDate>2026-08-26</cbc:IssueDate><cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0</cbc:CustomizationID>
<cbc:ID>RE-2026-0042</cbc:ID>
<cbc:IssueDate>2026-08-26</cbc:IssueDate>Related rules
NormAPI provides technical validation, not tax or legal advice.