InvoiceTypeCode: which code to use when?

Overview of InvoiceTypeCodes in e-invoicing: when to use which code and which standards support them.

The InvoiceTypeCode is a three-digit code in the XML element cbc:InvoiceTypeCode that determines which type of invoice you are sending. The correct code ensures the receiver immediately knows whether it is a regular invoice, a credit note, a correction or a self-billing invoice.

The permitted codes come from two subsets of the UNCL1001 code list: the invoice list (UNCL1001-inv) for invoices and the credit note list (UNCL1001-cn) for credit notes. Not every code is available in every standard.

Overview of InvoiceTypeCodes
CodeTypePeppol BIS V3NLCIUSXRechnungDescription380Commercial invoiceYesYesYesStandard sales invoice for B2B and B2G transactions381Credit noteYesYesYesSettlement or refund, references a previous invoice. Uses credit note syntax383Debit noteYesYesNoAdditional amount after the original invoice, e.g. for supplementary services or corrections384Corrective invoiceNoYesYesCorrection of a previous invoice. Can contain both positive and negative amounts386Prepayment invoiceYesYesNoPartial payment prior to full delivery389Self-billingNo (*)YesYesInvoice created by the buyer on behalf of the supplier261Self-billed credit noteNo (*)--Credit note for self-billing, uses credit note syntax

(*) Code 389 is not permitted within standard Peppol BIS Billing V3, but is within Peppol BIS Self-Billing 3.0 (a separate profile with its own CustomizationID and ProfileID). Within NLCIUS, 389 is permitted as a regular InvoiceTypeCode without a separate profile.

Explained per code
380: Commercial invoice

The standard code for regular sales invoices. This is by far the most commonly used InvoiceTypeCode. Virtually every B2B or B2G invoice sent via Peppol uses code 380. The code is available in all common standards: Peppol BIS V3, NLCIUS and XRechnung.

Code 380 is also used in the Netherlands as an alternative to a credit note. With this "negative Invoice", amounts and quantities are entered as negative, so the invoice functions as a credit. This is the convention described in the UBL Chain Test by GBNED Research Bureau. The difference from a real credit note (381): with code 380 amounts are negative, with code 381 they are positive (the CreditNote schema implicitly makes clear it is a correction). See Credit note variants for a detailed comparison.

381: Credit note

A credit note corrects or cancels (part of) a previous invoice. The credit note references the original invoice via a BillingReference. Credit notes use a separate XML syntax (CreditNote instead of Invoice) and a separate DocumentTypeId on the Peppol network.

Code 381 is supported in Peppol BIS V3, NLCIUS and XRechnung.

383: Debit note

A debit note is used when an additional amount needs to be charged after the original invoice, for example for extra services, price corrections or contractual adjustments. Unlike a corrective invoice (384), a debit note contains only positive amounts.

The code is available in Peppol BIS V3 and NLCIUS, but not in XRechnung.

384: Corrective invoice

A corrective invoice replaces or corrects a previous invoice and can contain both positive and negative amounts. NLCIUS prefers corrective invoices over credit notes, because the correction mechanism clearly shows in one document what has changed.

Code 384 is available in NLCIUS and XRechnung, but not in standard Peppol BIS Billing V3.

386: Prepayment invoice

A prepayment invoice is used for partial payments preceding the full delivery of goods or services. The code is available in Peppol BIS V3 and NLCIUS, but not in XRechnung.

389 and 261: Self-billing

Self-billing is the process where the buyer creates the invoice on behalf of the supplier. This occurs with temporary workers, intercompany invoicing and certain procurement contracts. There are two codes for self-billing:

  • 389 (Self-billed invoice): the invoice the buyer creates on behalf of the supplier
  • 261 (Self-billed credit note): the corresponding credit note for a self-billing invoice
Self-billing: two variants compared

Within the Peppol ecosystem, there are two ways to implement self-billing. The choice depends on the profile you use.

AspectPeppol BIS Self-Billing 3.0NLCIUS / SI-UBL 2.0CustomizationIDOwn value (...selfbilling:3.0)Unchanged (NLCIUS standard)ProfileIDOwn value (...selfbilling:01:1.0)UnchangedInvoiceTypeCode389 (invoice) or 261 (credit note)389SMP registrationSupplier must be separately registered for self-billing receiptNo additional registration neededRoutingPSB routes based on separate document typePSB recognises code 389 and routes automatically

With Peppol BIS Self-Billing 3.0, self-billing is a separate profile with its own CustomizationID and ProfileID. The supplier must be specifically registered in the SMP to receive self-billing documents.

With NLCIUS/SI-UBL 2.0, the approach is simpler: you only change the InvoiceTypeCode to 389. The CustomizationID and ProfileID remain unchanged, and the PSB recognises the document type automatically. If the supplier is already registered for regular SI-UBL invoices, no additional SMP registration is needed.

Which code should you choose?

For most situations, code 380 (regular invoice) or 381 (credit note) is sufficient. These are the codes that all standards and receivers support. Only choose a different code if your specific use case requires it:

  • Want to correct an invoice? Use 384 (corrective invoice) if you use NLCIUS or XRechnung, or 381 (credit note) if you work with BIS Billing V3.
  • Invoicing on behalf of the supplier? Use 389 (self-billing) and choose the correct profile based on your standard.
  • Sending a partial invoice prior to delivery? Use 386 (prepayment invoice).

Also view the overview of Party Identifiers and EAS codes