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.
(*) 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.
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.
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.
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.
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.
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.
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:
Within the Peppol ecosystem, there are two ways to implement self-billing. The choice depends on the profile you use.
...selfbilling:3.0)...selfbilling:01:1.0)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.
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:
Also view the overview of Party Identifiers and EAS codes