Reference
Markdown exportInvoice type codes (common in XRechnung)
UNTDID 1001 codes for the invoice type (BT-3), with the XRechnung restrictions and the references each type needs.
How these codes are used on invoices
UNTDID 1001 defines the invoice type codes that structured invoices use instead of free text. Receiving systems, ERPs and validators expect exact codes such as 380 (Commercial invoice), 381 (Credit note), 384 (Corrected invoice). XRechnung expects 326, 380, 381, 384, 389, 875, 876 and 877 (BR-DE-17). The other codes are valid EN 16931 codes but trigger a warning in XRechnung.
UNTDID 1001
XRechnung expects 326, 380, 381, 384, 389, 875, 876 and 877 (BR-DE-17). The other codes are valid EN 16931 codes but trigger a warning in XRechnung.
How to use this code list in production
Keep one mapping for invoice type codes across ERP source data, generated XML and validation checks. Lock the allowed values before go-live, map legacy values before export, and make sure finance teams know which business cases require manual review.
Invoice type codes (common in XRechnung)
| Code | Meaning | Notes |
|---|---|---|
| 326 | Partial invoice | Invoice for part of an order or service. Accepted in XRechnung. |
| 380 | Commercial invoice | The standard invoice and the right code for almost all B2B and B2G invoices. |
| 381 | Credit note | Credits all or part of an earlier invoice; reference it in BG-3. In UBL send a CreditNote document, not an Invoice with code 381. |
| 383 | Debit note | Charges an additional amount on an earlier transaction. Valid in EN 16931, but not on the XRechnung list (BR-DE-17 warning). |
| 384 | Corrected invoice | Replaces an earlier invoice with corrected data. Reference the original invoice number and date in BG-3 (BT-25, BT-26). |
| 386 | Prepayment invoice | Requests an advance payment that the final invoice deducts as paid amount (BT-113). Not on the XRechnung list (BR-DE-17 warning). |
| 387 | Hire invoice | Invoice for hire or rental. Most receivers handle rent as 380; on the XRechnung channel 387 triggers a BR-DE-17 warning. |
| 389 | Self-billed invoice | The buyer issues the invoice for the seller under a prior agreement. Accepted in XRechnung. |
| 390 | Delcredere invoice | Issued through a del credere agent who guarantees the buyer’s payment. Not on the XRechnung list. |
| 393 | Factored invoice | The receivable is assigned to a factor. Name the factor as payee (BG-10) and give its account. Not on the XRechnung list. |
| 875 | Partial construction invoice | Interim invoice for progress on a construction project (in Germany an Abschlagsrechnung). Accepted in XRechnung. |
| 876 | Partial final construction invoice | Closes a completed part of a construction project and settles its interim invoices. Accepted in XRechnung. |
| 877 | Final construction invoice | Final invoice for a construction project that settles all interim and partial final invoices. Accepted in XRechnung. |
Next step
Create an XRechnung from your PDF and confirm the codes
The converter determines codes from this list for BT-3 from the details on the invoice. You see each value before download and can correct it. Already have an XML file? The free validator reports codes outside the list, for example under BR-DE-17, BR-DE-26.
Download requires an account. Subscriptions from €10/month with annual billing (excl. taxes), or €5 per conversion (excl. taxes) without a subscription.
Practical tips before you send an e-invoice
- Use the exact code from UNTDID 1001 and keep the spelling and casing expected by the standard.
- Check that the invoice type codes you use match the business case and the related fields on the invoice.
- Validate the final XRechnung, ZUGFeRD/Factur-X, UBL, or CII file before sending it to the recipient.
Common code-list mistakes
- Letting free-text values pass through the ERP export instead of mapping them to the official code list.
- Using a technically valid code without checking whether the recipient profile or country rule actually allows it.
- Fixing the XML output only, while leaving the upstream ERP source value inconsistent for the next invoice.
Frequently asked questions
Common questions when teams choose invoice type codes for an invoice or an ERP export.
What are invoice type codes used for on an invoice?
UNTDID 1001 is the standardized list behind these codes. A code tells the receiving system exactly which value you mean, so the invoice can be processed automatically in XRechnung, ZUGFeRD/Factur-X, UBL, CII and Peppol workflows.
Which invoice type codes are used most often?
Common examples on this page include 380 (Commercial invoice), 381 (Credit note), 384 (Corrected invoice). The right choice depends on your transaction, tax treatment, recipient requirements, and the invoice profile you are sending.
Where do invoice type codes go in a structured e-invoice?
Enter the code in the structured invoice field that matches its meaning, for example the currency field, VAT category field, payment means field, unit field, or invoice type field. The exact XML path depends on whether you send XRechnung, ZUGFeRD/Factur-X, UBL, or CII.
How do I avoid validation errors with invoice type codes?
Use only values allowed by the relevant implementation guide, keep the code exactly as defined in UNTDID 1001, and provide all related data required by that choice. Many validation errors happen when a code is correct in isolation but inconsistent with the rest of the invoice.
Can I use codes outside this page?
Often yes, but recipients and national profiles frequently accept only a practical subset of the full UNTDID 1001 list. This page focuses on common invoice values, so confirm buyer-specific or country-specific rules before sending production documents.
Download
Use this code list in your systems or validation rules.