BR-02 An invoice must have an invoice number
Every invoice needs a non-empty identifier in BT-1, unique within your own numbering. Our check fires when invoiceNumber is missing, empty or only whitespace.
- Business term
BT-1— Invoice number- Severity
fatal- Applies to
All profiles
What the rule requires
Your invoice needs an identifier in business term BT-1, unique within your own numbering. Good news on the format: it is a plain string, and EN 16931 imposes no length, pattern or “must be an integer” requirement at all. 2026-000142, INV/2026/08/17 and a1b2c3 all satisfy it.
Our input check fires when invoiceNumber is missing, empty, or only whitespace. What it cannot do is check uniqueness — we only ever see one invoice at a time, so that part is on you.
An Invoice shall have an Invoice number (BT-1).
Why it exists
Think of BT-1 as the handle every downstream system grabs onto: the buyer’s accounts-payable matching, the credit note that references this document six months from now, your audit trail, the tax authority’s reconciliation. EN 16931 itself only asks that it is there — but national VAT law generally wants the number sequential and gap-free within a series. That is why the library’s fix line says “sequential” and tells you to cancel with a credit note rather than reuse a number.
What the library returns
The exact object in result.errors when this rule fires.
Generated by running @attestwire/en16931, not transcribed:
{
"rule": "BR-02",
"field": "BT-1",
"severity": "fatal",
"message": "An invoice must have an invoice number (BT-1). It is the identifier the buyer, your accounts-receivable ledger and the tax authority all use to refer to this one document, so it must be unique within your numbering sequence.",
"fix": "Set invoiceNumber to your next sequential invoice identifier. Do not reuse a number, even for a document you later cancel — issue a credit note instead.",
"example": "\"invoiceNumber\": \"2026-000142\"",
"xpath": "/ubl:Invoice/cbc:ID",
"docsUrl": "https://attestwire.com/rules/BR-02"
}
xpath locates the element in the generated UBL document,
which is where a KoSIT or Peppol validator will report the same problem.
Failing and passing
validateInput({
profile: "en16931",
invoiceNumber: "", // <- BR-02
issueDate: "2026-08-09",
currency: "EUR",
seller: { /* ... */ },
buyer: { /* ... */ },
lines: [ /* ... */ ],
});
// -> { valid: false, errors: [ { rule: "BR-02", ... } ] }validateInput({
profile: "en16931",
invoiceNumber: "2026-000142",
issueDate: "2026-08-09",
currency: "EUR",
seller: { /* ... */ },
buyer: { /* ... */ },
lines: [ /* ... */ ],
});
// -> { valid: true, errors: [] }The fix, in plain English
Pass the invoice identifier your accounting system actually displays, not the database primary key behind it. This is the string your customer will quote back at you on the phone. And if you build the number from a sequence, format it once at the point of issue and store the formatted value — otherwise a reissue of the same document can quietly produce a different BT-1.
How our check differs
Be aware that the uniqueness and “do not reuse” advice in our fix is not part of BR-02. EN 16931 asserts presence only. Sequential, gap-free numbering comes from national VAT law instead (for example §14 UStG in Germany, or art. 242 of the VAT Directive as implemented locally). We put it in the fix because a developer reading the rule alone will build something that fails an audit later — but please do not cite us for it. Cite your own jurisdiction.
See also: BR-01 — renumbering note — older versions of this library emitted BR-01 here.