Credit notes and corrections

Whether a recipient system books a document as an invoice or offsets it as a credit comes down to a single field: the invoice type code (BT-3). It carries a code from UNTDID code list 1001, the UN/EDIFACT directory of document functions, of which EN 16931 permits a subset. A wrong code does not produce a schema error — it produces wrongly booked documents. This guide sorts out 381, 384 and the 380 family, and shows how the preceding invoice reference and the sign logic should look in UBL and CII.

381, 384 or the 380 family?

A credit note (381) is a standalone commercial document that credits an amount to the buyer — after a return, a complaint or a retroactive discount. It carries its own document number and does not invalidate the preceding invoice; it offsets it in full or in part. Do not confuse it with self-billing, where the buyer issues the invoice on the supplier’s behalf: that is code 389.

A corrected invoice (384) replaces an earlier invoice in substance — wrong VAT rate, wrong address, wrong routing reference. Functionally, the 384 takes the place of the preceding invoice, which becomes void.

For staged billing there is the 380 family: 326 (partial invoice), 386 (prepayment invoice), and the final invoice as an ordinary 380 that settles prepayments received via BT-113.

One UBL peculiarity: a 381 is usually transported as its own root element, CreditNote, with cbc:CreditNoteTypeCode, while 380/384/326 live in the Invoice root with cbc:InvoiceTypeCode. CII — the syntax behind ZUGFeRD and Factur-X — only knows CrossIndustryInvoice; the code always sits in ram:ExchangedDocument/ram:TypeCode:

<!-- UBL, Invoice root (380, 384, 326 …) -->
<cbc:InvoiceTypeCode>384</cbc:InvoiceTypeCode>

<!-- UBL, CreditNote root (381) -->
<cbc:CreditNoteTypeCode>381</cbc:CreditNoteTypeCode>

<!-- CII (ZUGFeRD, Factur-X, XRechnung CII) -->
<ram:TypeCode>381</ram:TypeCode>

Referencing the preceding invoice: BG-3

A credit note or correction without a reference is close to useless for the recipient’s accounts payable. EN 16931 provides the group BG-3 for this: the number of the preceding invoice (BT-25) and, optionally, its issue date (BT-26). The group is optional and repeatable in the standard (one credit note covering several invoices), but in practice every 381 and 384 should carry it — many workflow systems match on it automatically.

In UBL:

<cac:BillingReference>
  <cac:InvoiceDocumentReference>
    <cbc:ID>RE-2026-0417</cbc:ID>
    <cbc:IssueDate>2026-05-12</cbc:IssueDate>
  </cac:InvoiceDocumentReference>
</cac:BillingReference>

In CII the reference sits inside ApplicableHeaderTradeSettlement; as usual, the date requires format="102" (YYYYMMDD):

<ram:ApplicableHeaderTradeSettlement>
  <!-- … currency, taxes, totals … -->
  <ram:InvoiceReferencedDocument>
    <ram:IssuerAssignedID>RE-2026-0417</ram:IssuerAssignedID>
    <ram:FormattedIssueDateTime>
      <qdt:DateTimeString format="102">20260512</qdt:DateTimeString>
    </ram:FormattedIssueDateTime>
  </ram:InvoiceReferencedDocument>
</ram:ApplicableHeaderTradeSettlement>

Sign logic: positive 381 or negative 384?

EN 16931 explicitly allows negative values in the totals fields (BT-106 through BT-115) and prescribes no particular pattern. Two conventions have established themselves in practice.

First, the 381 with positive amounts: the document type itself reverses the booking direction, and the amounts merely state the size of the credit. Second, the negative invoice: a 380 or 384 with negative totals, permitted in XRechnung since version 2.0 and common there.

What you should avoid is the combination: a 381 with negative totals gets double-negated or outright rejected by many recipient systems. Pick one pattern — when in doubt, the one the recipient specifies — and carry it through consistently.

Consistently means: the BR-CO arithmetic rules of EN 16931 operate on signed values and apply unchanged. BT-106 must equal the sum of the line amounts, BT-112 must equal BT-109 + BT-110. Negating only the grand total while leaving the lines positive fails validation reliably.

Common validation errors

With credit notes and corrections we mostly see five findings. BH-TYPE-01 warns about exotic type codes from the full UNTDID catalogue (such as 80 or 261) — stick to 380, 381, 384 and 326. BR-CO-10 fires when BT-106 does not equal the sum of the line net amounts (BT-131) — the classic: totals negated, lines not. BR-CO-13 hits corrections that copy allowances or charges (BT-107/108) from the preceding invoice without flipping their sign. BR-CO-14 reports a VAT total that does not match the breakdown (BG-23) — typical when the category amounts were forgotten during the sign flip. And BR-CO-15 catches grand totals computed from absolute values instead of the signed sum BT-109 + BT-110.

Validate before sending

The Billhorse validator checks the type code, the preceding invoice reference and the full BR-CO arithmetic directly in your browser — the file never leaves your machine. The same engine is available as an API with validate and parse endpoints, currently in private beta.

← All guides · Last updated: 2026-07-04