Credit note in UBL: two variants and when to choose which

Two ways to send a credit note in UBL: the CreditNote document and the negative Invoice. When to choose which variant?

Sometimes an invoice needs to be corrected. An amount too high, an incorrect VAT rate, a return: the solution is a credit note. In the UBL standard, there are two ways to send a credit note. They are technically very different, but serve the same purpose. Which variant you choose depends on your software, your receiver and the Peppol profile you use.

Variant 1: the CreditNote document

The first variant is a separate UBL document type: CreditNote. This document uses its own XML schema (CreditNote-2) and has its own element names. Instead of InvoiceLine it is called CreditNoteLine, and instead of InvoicedQuantity there is CreditedQuantity.

<CreditNote xmlns="urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2">
  <cbc:ID>CN-2026-0001</cbc:ID>
  <cbc:IssueDate>2026-03-08</cbc:IssueDate>
  <cbc:CreditNoteTypeCode>381</cbc:CreditNoteTypeCode>
  <cac:BillingReference>
    <cac:InvoiceDocumentReference>
      <cbc:ID>F-2026-00042</cbc:ID>
    </cac:InvoiceDocumentReference>
  </cac:BillingReference>
  <!-- parties, VAT totals, etc. -->
  <cac:CreditNoteLine>
    <cbc:ID>1</cbc:ID>
    <cbc:CreditedQuantity unitCode="EA">5</cbc:CreditedQuantity>
    <cbc:LineExtensionAmount currencyID="EUR">125.00</cbc:LineExtensionAmount>
    <!-- item and price -->
  </cac:CreditNoteLine>
</CreditNote>

All amounts in a CreditNote are positive. The fact that it is a CreditNote document implicitly makes clear that it is a correction. The BillingReference element references the original invoice being credited.

Characteristics of the CreditNote document
  • Own XML root node (CreditNote instead of Invoice)
  • Own element names (CreditNoteLine, CreditedQuantity)
  • All amounts are positive
  • Widely supported by Peppol receivers
  • TypeCode is 381 (credit note related to invoices)
Variant 2: the negative Invoice

The second variant uses the regular Invoice document, but with negative amounts. The InvoiceTypeCode remains 380 (commercial invoice). Technically it is a regular invoice, but because of the negative amounts it functions as a credit note. This is the Dutch convention described in the UBL Chain Test by GBNED Research Bureau.

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">
  <cbc:ID>CN-2026-0001</cbc:ID>
  <cbc:IssueDate>2026-03-08</cbc:IssueDate>
  <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
  <cac:BillingReference>
    <cac:InvoiceDocumentReference>
      <cbc:ID>F-2026-00042</cbc:ID>
    </cac:InvoiceDocumentReference>
  </cac:BillingReference>
  <!-- parties, VAT totals, etc. -->
  <cac:InvoiceLine>
    <cbc:ID>1</cbc:ID>
    <cbc:InvoicedQuantity unitCode="EA">-5</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="EUR">-125.00</cbc:LineExtensionAmount>
    <!-- item and price -->
  </cac:InvoiceLine>
</Invoice>

In this variant, quantities and amounts are negative. The VAT amount and the payable amount are also negative. The structure is otherwise identical to a regular invoice.

Characteristics of the negative Invoice
  • Same XML root node as a regular invoice (Invoice)
  • Same element names (InvoiceLine, InvoicedQuantity)
  • Amounts and quantities are negative
  • InvoiceTypeCode is 380 (regular invoice), the negative sign indicates it is a credit
  • Simpler to implement for sending software (no separate document type needed)
  • Described in the GBNED/UBL Chain Test as the standard Dutch approach
Which variant should you choose?

The choice depends on three factors:

What does your software support? Some accounting software generates a CreditNote document by default, others a negative Invoice. If your software only supports one variant, the choice is made.

What does the receiver expect? Within Peppol, both variants are supported by the BIS Billing 3.0 profile. In practice, however, receiving systems may have a preference. When in doubt, the CreditNote document is the safest choice, as it is the most explicit variant.

Which Peppol profile do you use? The standard BIS Billing 3.0 profile accepts both the CreditNote schema (381) and the Invoice schema with negative amounts (380). Not all profiles support both. Check this if you use an industry-specific profile.

Tip: with eConnect you can submit both variants. The platform automatically recognises whether it is a CreditNote document or a negative Invoice, and processes them the same way. If the receiver expects a specific format, the PSB automatically transforms the document.

Sign conventions compared

The two variants use opposite sign conventions. This overview shows how the same credit (5 units of 25 euros) appears in both variants:

ElementCreditNote (TypeCode 381)Negative Invoice (TypeCode 380)XML schemaCreditNoteInvoicePriceAmount25.00 (positive)25.00 (positive, required per BR-27)CreditedQuantity / InvoicedQuantity5 (positive)-5 (negative)LineExtensionAmount125.00 (positive)-125.00 (negative)AllowanceCharge amountspositivenegativeTaxAmountpositivenegativePayableAmountpositivenegative

The crucial difference lies in interpretation. In a CreditNote, the reverse sign is implicit: all amounts are positive, but the document type makes clear it is a credit. In a negative Invoice, the negative amounts themselves are the indicator.

The PriceAmount (unit price) is positive in both variants. This is established in validation rule BR-27. In the negative Invoice, you make the amount negative via the quantity or via the LineExtensionAmount, not via the unit price.

Dutch convention and Peppol

The UBL Chain Test by GBNED Research Bureau describes exclusively the 380 variant (negative Invoice) for credit notes. Many Dutch accounting packages that are "UBL Ready" certified therefore generate a negative Invoice by default. Peppol BIS 3.0, on the other hand, uses the CreditNote schema (381) with positive amounts by default.

Receiving software must support both variants. The PSB automatically transforms between the two schemas where necessary, so the receiver gets the document in the format their software expects.

What must always be included

Regardless of which variant you choose, a valid credit note always contains:

  • A reference to the original invoice via BillingReference / InvoiceDocumentReference
  • The correct TypeCode: 381 for the CreditNote schema, 380 for the negative Invoice
  • Correct VAT calculation (consistent with the original invoice)
  • The same currency as the original invoice

A credit note without a reference to the original invoice is not accepted by many receiving systems. That reference is also needed for VAT administration: during an audit it must be traceable which invoice was credited.

Partial credit

It is not mandatory to credit an invoice in its entirety. You can also send a partial credit note that corrects only part of the original invoice. If you credit two of the ten invoiced items, for example, the credit note only contains those two lines with the corresponding amounts.

Tip: when sending invoices via the PSB API, you can use the targetDocumentTypeId parameter when downloading a document to specify whether you want to receive a CreditNote or Invoice variant. The PSB can transform between the two variants on the fly.

Validate your credit note