BR-04 Invoice type code missing

The invoice needs a type code, such as 380 for an invoice or 381 for a credit note.

What the rule says

An Invoice shall have an Invoice type code (BT-3).

The rule's official wording (CEN / KoSIT). The German XRechnung rules are published in German.

Why it happens

The document has no type code (BT-3), the number that says whether it's an invoice, a credit note or similar.

How to fix it

Use 380 for a normal invoice, 381 for a credit note, 384 for a corrected invoice or 326 for a partial invoice.

Applies to

Every EN 16931 e-invoice: XRechnung, ZUGFeRD / Factur-X, Peppol and others.

Check your invoice again Create an invoice that passes

More about BR-04

The type code tells the receiver what kind of document this is, and that changes how it's booked. A credit note (381) reduces what the buyer owes; a corrected invoice (384) replaces an earlier one; a partial invoice (326) is one of several for the same order. The codes come from the UNTDID 1001 code list.

XRechnung and ZUGFeRD allow only some codes. The ones you'll normally need are 380 (commercial invoice), 381 (credit note), 384 (corrected invoice), 389 (self-billed invoice, where the buyer issues the invoice), 326 (partial invoice) and 875/876/877 for partial, partial-final and final construction invoices.

The fields involved

BT-3 Invoice type code: CII rsm:ExchangedDocument/ram:TypeCode; UBL cbc:InvoiceTypeCode

Typical situations

The XML was built by hand and the TypeCode element was left out.
The software writes the document type as a word, such as "Invoice", instead of a code.
A credit note template doesn't set any type code.

Example

A normal invoice in CII:

<rsm:ExchangedDocument>
  <ram:ID>RE-2026-0142</ram:ID>
  <ram:TypeCode>380</ram:TypeCode>
  ...
</rsm:ExchangedDocument>