Peppol credit notes: type code 381, amount signs and the P9 process

A credit note in Peppol is document type code 381 (UNTDID 1001), sent as a UBL CreditNote document. Code 381 already tells the receiver "this reduces what the buyer owes". So you do not negate the whole document a second time. The totals on a credit note are stated as positive numbers.

That is the part everyone gets right. Here is the part almost every article gets wrong: individual lines on a credit note can be negative. The official Peppol BIS Billing 3.0 credit note example contains a line with CreditedQuantity of −3 and a LineExtensionAmount of −1500. Negative lines are legal. A globally negated document is what breaks. And exactly one amount may never be negative: the item net price (BT-146), enforced by rule BR-27.

This page covers the three things people actually search for. What code 381 means and how it differs from 380. What Peppol business process P9 is, and why you never put "P9" in the XML. How to reference the original invoice with BillingReference, and whether that reference is mandatory.

Invoice type code 381 vs 380

EN 16931 calls this business term BT-3, the invoice type code. The value comes from the UNTDID 1001 code list. In UBL the element name depends on the document root. An Invoice document uses cbc:InvoiceTypeCode. A CreditNote document uses cbc:CreditNoteTypeCode. Peppol BIS Billing 3.0 restricts BT-3 to a short list, and every allowed code maps to one of the two UBL document types.

If you send code 381, the root element must be CreditNote and the lines must be CreditNoteLine with CreditedQuantity. Putting 381 inside an Invoice document is a schema mismatch, not a business rule violation, so the error you get back is often unhelpful.

Peppol business process P9

Peppol BIS Billing 3.0 lists nine invoicing processes, P1 through P9. P9 is the credit note process. The specification defines it in one line:

"P9: Credit notes or invoices with negative amounts, issued for a variety of reasons including the return of empty packaging."

Read that definition again. P9 explicitly covers both credit notes and invoices with negative amounts. Peppol does not forbid negative amounts. It forbids saying the same thing twice in two conflicting ways.

The sign rule, precisely

The Peppol BIS Billing 3.0 specification states two symmetric rules. For a credit note: "The function of crediting or debiting is controlled merely by the business document type (e.g. 380 or 381) while the representation of the amount, including its sign, is not affected." For a negative invoice: "The function of crediting or debiting is controlled merely by the sign of the amount concerned, while the business document type (e.g. 380) has no relevance on the operation."

In plain language: pick one carrier for the credit signal. Either the document type carries it (381 with amounts stated as you would state them on the original invoice), or the sign carries it (380 with the amounts negated). Never both. A credit note whose totals are all negative means "credit a negative amount", which is a charge. That is the double negation problem, and it is a silent one. Many such documents pass validation and then book the wrong sign in the receiver's ledger.

The sign of an individual line is a different matter. Correction documents routinely credit one line and re-charge another. That is why the BIS credit note example carries a positive line 1 and a negative line 2. The line signs describe the correction. The document type describes the direction.

A correct Peppol credit note in UBL

This is the shape of a valid credit note. Note the profile identifiers, the BillingReference, the positive item net price, and the mixed line signs.

<CreditNote xmlns="urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2"
            xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
            xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">

  <cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0</cbc:CustomizationID>
  <cbc:ProfileID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</cbc:ProfileID>

  <cbc:ID>CN-2026-001</cbc:ID>
  <cbc:IssueDate>2026-03-10</cbc:IssueDate>
  <cbc:CreditNoteTypeCode>381</cbc:CreditNoteTypeCode>
  <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
  <cbc:BuyerReference>PO-99812</cbc:BuyerReference>

  <!-- BG-3: the invoice being credited -->
  <cac:BillingReference>
    <cac:InvoiceDocumentReference>
      <cbc:ID>INV-2026-042</cbc:ID>
      <cbc:IssueDate>2026-02-28</cbc:IssueDate>
    </cac:InvoiceDocumentReference>
  </cac:BillingReference>

  <!-- Line 1: 7 days credited, positive -->
  <cac:CreditNoteLine>
    <cbc:ID>1</cbc:ID>
    <cbc:CreditedQuantity unitCode="DAY">7</cbc:CreditedQuantity>
    <cbc:LineExtensionAmount currencyID="EUR">2800.00</cbc:LineExtensionAmount>
    <cac:Item>
      <cbc:Name>Consulting, senior</cbc:Name>
      <cac:ClassifiedTaxCategory>
        <cbc:ID>S</cbc:ID>
        <cbc:Percent>21.0</cbc:Percent>
        <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
      </cac:ClassifiedTaxCategory>
    </cac:Item>
    <cac:Price>
      <!-- BR-27: never negative -->
      <cbc:PriceAmount currencyID="EUR">400.00</cbc:PriceAmount>
    </cac:Price>
  </cac:CreditNoteLine>

  <!-- Line 2: 3 days re-charged, negative. This is legal. -->
  <cac:CreditNoteLine>
    <cbc:ID>2</cbc:ID>
    <cbc:CreditedQuantity unitCode="DAY">-3</cbc:CreditedQuantity>
    <cbc:LineExtensionAmount currencyID="EUR">-1500.00</cbc:LineExtensionAmount>
    <cac:Item>
      <cbc:Name>Consulting, junior</cbc:Name>
      <cac:ClassifiedTaxCategory>
        <cbc:ID>S</cbc:ID>
        <cbc:Percent>21.0</cbc:Percent>
        <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
      </cac:ClassifiedTaxCategory>
    </cac:Item>
    <cac:Price>
      <cbc:PriceAmount currencyID="EUR">500.00</cbc:PriceAmount>
    </cac:Price>
  </cac:CreditNoteLine>

  <cac:LegalMonetaryTotal>
    <cbc:LineExtensionAmount currencyID="EUR">1300.00</cbc:LineExtensionAmount>
    <cbc:TaxExclusiveAmount currencyID="EUR">1300.00</cbc:TaxExclusiveAmount>
    <cbc:TaxInclusiveAmount currencyID="EUR">1573.00</cbc:TaxInclusiveAmount>
    <cbc:PayableAmount currencyID="EUR">1573.00</cbc:PayableAmount>
  </cac:LegalMonetaryTotal>
</CreditNote>

The document totals are positive. They say "credit €1,573.00". The document type says "this is a credit". Nothing is stated twice.

Referencing the original invoice with BillingReference

This is the single most searched detail about Peppol credit notes, and the spec answer is short. The preceding invoice reference is business group BG-3. In UBL it is cac:BillingReference containing a cac:InvoiceDocumentReference. The invoice number goes in cbc:ID (BT-25). The issue date goes in cbc:IssueDate (BT-26).

<!-- Credit one invoice -->
<cac:BillingReference>
  <cac:InvoiceDocumentReference>
    <cbc:ID>INV-2026-042</cbc:ID>
    <cbc:IssueDate>2026-02-28</cbc:IssueDate>
  </cac:InvoiceDocumentReference>
</cac:BillingReference>

<!-- Credit a second invoice: repeat the whole group -->
<cac:BillingReference>
  <cac:InvoiceDocumentReference>
    <cbc:ID>INV-2026-043</cbc:ID>
  </cac:InvoiceDocumentReference>
</cac:BillingReference>

The alternative: a negative invoice (380)

P9 permits the other route. Send a normal Invoice with type code 380 and negate the amounts. Here the sign carries the whole meaning.

<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>

<cac:BillingReference>
  <cac:InvoiceDocumentReference>
    <cbc:ID>INV-2026-042</cbc:ID>
  </cac:InvoiceDocumentReference>
</cac:BillingReference>

<cac:InvoiceLine>
  <cbc:ID>1</cbc:ID>
  <cbc:InvoicedQuantity unitCode="DAY">-7</cbc:InvoicedQuantity>
  <cbc:LineExtensionAmount currencyID="EUR">-2800.00</cbc:LineExtensionAmount>
  <cac:Price>
    <!-- still positive: BR-27 -->
    <cbc:PriceAmount currencyID="EUR">400.00</cbc:PriceAmount>
  </cac:Price>
</cac:InvoiceLine>

<cac:LegalMonetaryTotal>
  <cbc:LineExtensionAmount currencyID="EUR">-2800.00</cbc:LineExtensionAmount>
  <cbc:TaxExclusiveAmount currencyID="EUR">-2800.00</cbc:TaxExclusiveAmount>
  <cbc:TaxInclusiveAmount currencyID="EUR">-3388.00</cbc:TaxInclusiveAmount>
  <cbc:PayableAmount currencyID="EUR">-3388.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>

Notice that the unit price stays positive in both routes. The quantity goes negative instead. That is the one detail most home-grown UBL generators get wrong, and it is the direct cause of the most common rejection.

For Belgian B2B under the 2026 e-invoicing mandate, the credit note (381) is the route to use. VAT reporting and most accounting packages expect a separate credit document rather than an invoice with a negative total. Negative invoices are mainly a legacy escape hatch for systems that cannot emit aCreditNote root element at all.

Validation rules that actually fire

These are the rules you will see in a real rejection message, with their exact spec wording. Two of them are hard sign rules. The rest are arithmetic rules that break when software flips only some of the amounts.

Quick reference

Sending a credit note through the API

If you do not want to hand-build UBL, post flat JSON. Set document_type to CREDIT_NOTE and point referenced_invoice_id at the original invoice. Keep unit_price and quantity positive for a straight credit. The API emits the CreditNote root, sets CreditNoteTypeCode to 381, builds the BillingReference, and runs the Peppol BIS 3.0 schematron before delivery.

POST https://api.e-invoice.be/api/documents/
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json

{
  "document_type": "CREDIT_NOTE",
  "invoice_id": "CN-2026-001",
  "invoice_date": "2026-03-10",
  "referenced_invoice_id": "INV-2026-042",
  "vendor_name": "Your Company BV",
  "vendor_tax_id": "BE0123456789",
  "vendor_address": "Kerkstraat 1, 1000 Brussels, BE",
  "customer_name": "Client NV",
  "customer_tax_id": "BE0987654321",
  "customer_peppol_id": "0208:0987654321",
  "currency": "EUR",
  "items": [
    {
      "description": "Consulting, senior",
      "quantity": 7,
      "unit_price": 400.00,
      "tax_rate": 21.00
    }
  ]
}

To check what your own system produces before you send it, drop the XML into the Peppol invoice viewer. It renders the parsed document type, the amounts and the preceding invoice reference, so a wrong sign or a missing BillingReference is visible in seconds.

If your software emits the wrong signs

Frequently asked questions