Reference
Markdown exportPayment means type codes
UNCL 4461 codes for the payment means (BT-81), with the payment details each code needs on an EN 16931 invoice.
How these codes are used on invoices
UNCL 4461 defines the payment means codes that structured invoices use instead of free text. Receiving systems, ERPs and validators expect exact codes such as 58 (SEPA credit transfer), 30 (Credit transfer), 59 (SEPA direct debit). Codes that appear on European e-invoices; UNCL 4461 contains many more payment instruments.
UNCL 4461
Codes that appear on European e-invoices; UNCL 4461 contains many more payment instruments.
How to use this code list in production
Keep one mapping for payment means 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.
Payment means type codes
| Code | Meaning | Notes |
|---|---|---|
| 1 | Instrument not defined | Only when the payment instrument is genuinely unknown. Receivers cannot automate payment from it, so prefer a specific code. |
| 10 | In cash | Cash payment; no bank account details are needed. |
| 20 | Cheque | Payment by cheque; rare in B2B e-invoicing outside France. |
| 30 | Credit transfer | Credit transfer that is not specifically SEPA, for example an international transfer. The payment account (BT-84) is required (BR-61). |
| 42 | Payment to bank account | Generic payment into a bank account. BR-61 checks the account only for 30 and 58, so state the IBAN in BT-84 yourself. |
| 48 | Bank card | Card payment. Never send the full card number: at most the first 6 and last 4 digits go in BT-87 (BR-51). |
| 49 | Direct debit | Direct debit outside SEPA. Give the mandate reference (BT-89) and the debited account (BT-91) in the direct debit group BG-19. |
| 54 | Credit card | Credit card payment; the card number rule BR-51 applies as for code 48. |
| 55 | Debit card | Debit card payment; the card number rule BR-51 applies as for code 48. |
| 57 | Standing agreement | The parties agreed the payment means earlier and do not repeat it on the invoice. Only use it where that agreement exists. |
| 58 | SEPA credit transfer | The usual code for euro bank transfers. The IBAN in BT-84 is required (BR-61); the BIC (BT-86) is optional within SEPA. |
| 59 | SEPA direct debit | SEPA direct debit. Give the mandate reference (BT-89), the creditor identifier (BT-90) and the debited IBAN (BT-91). |
| 68 | Online payment service | Payment through an online payment provider. Name the service and any payment link in the payment means text (BT-82). |
| 69 | Transfer advice | Advice that a transfer was or will be made; rare on invoices. For ordinary bank transfers use 30 or 58. |
| 70 | Bill drawn by the creditor on the debtor | Bill of exchange that the seller draws on the buyer. Agree the details outside the invoice and describe them in BT-82. |
| 97 | Clearing between partners | The amount is offset against counterclaims instead of being paid, for example against a credit note. Explain the offset in BT-82. |
| ZZZ | Mutually defined | A payment means that no other code covers, agreed between the parties. Describe it in BT-82; receivers cannot process it automatically. |
Next step
Create an XRechnung from your PDF and confirm the codes
The converter determines codes from this list for BT-81 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-CL-16, BR-49.
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 UNCL 4461 and keep the spelling and casing expected by the standard.
- Check that the payment means 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 payment means codes for an invoice or an ERP export.
What are payment means codes used for on an invoice?
UNCL 4461 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 payment means codes are used most often?
Common examples on this page include 58 (SEPA credit transfer), 30 (Credit transfer), 59 (SEPA direct debit). The right choice depends on your transaction, tax treatment, recipient requirements, and the invoice profile you are sending.
Where do payment means 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 payment means codes?
Use only values allowed by the relevant implementation guide, keep the code exactly as defined in UNCL 4461, 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 UNCL 4461 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.