IBAN & BIC in E-Invoices — A Complete Guide

Why Payment Information Matters in E-Invoices

An e-invoice is not just a request for payment — it is a machine-readable instruction that can trigger automatic payment processing. When a buyer's accounts payable system receives a compliant e-invoice, it can extract the payment details, match them against the purchase order, and schedule payment without any manual intervention. For this automation to work, the payment information must be complete, correctly formatted, and in the right XML fields.

Missing or incorrect payment details are one of the top reasons e-invoices are queried or delayed. If the IBAN is invalid, the buyer's system flags the invoice for manual review. If the BIC is missing in a context where it is required, the invoice may fail validation entirely. In countries with strict e-invoicing mandates like Italy and Germany, payment information completeness is part of the compliance requirements.

The European standard EN 16931 specifies that when the payment means is a credit transfer (the most common method for B2B invoices), the seller must provide the payment account identifier — which in practice means the IBAN. This is not optional; it is a structural requirement of a compliant e-invoice.

IBAN Format Explained

The International Bank Account Number is a standardised format defined by ISO 13616. Every IBAN follows the same structure:

• Country code: Two letters identifying the country (DE for Germany, FR for France, etc.)
• Check digits: Two numbers calculated using a modulo-97 algorithm — these catch typos and transposition errors
• BBAN (Basic Bank Account Number): The country-specific portion containing the bank code and account number

For example, a German IBAN like DE89370400440532013000 breaks down as: DE (country) + 89 (check digits) + 37040044 (bank code) + 0532013000 (account number).

The total length varies by country because each nation has different bank code and account number structures. Here are the IBAN lengths for major EU countries:

Important: In e-invoice XML, the IBAN is always stored as a continuous string without spaces — e.g., DE89370400440532013000, not DE89 3704 0044 0532 0130 00. Spaces are only used in printed or displayed formats for human readability.

BIC/SWIFT Code Format

The Bank Identifier Code (BIC), also known as a SWIFT code, identifies the specific bank that holds the account. A BIC is either 8 or 11 characters long:

• Characters 1-4: Bank code (e.g., COBADEFF — Commerzbank)
• Characters 5-6: Country code (e.g., DE for Germany)
• Characters 7-8: Location code (identifies the city or region)
• Characters 9-11 (optional): Branch code — if omitted, it defaults to the head office (often shown as XXX)

For example, COBADEFFXXX is Commerzbank's head office in Frankfurt. An 8-character BIC like COBADEFF is equivalent to the 11-character version with XXX appended.

Within the EU's Single Euro Payments Area (SEPA), BIC is becoming less essential for domestic transfers because banks can derive the BIC from the IBAN. However, for e-invoicing purposes, including the BIC is still recommended as it ensures unambiguous bank identification and is required by some validation rules.

Where They Appear in UBL XML

In Peppol BIS 3.0 and other UBL-based e-invoice formats, payment information is structured within the PaymentMeans element. The key elements are:

• PaymentMeansCode: Identifies the payment method — code 30 for credit transfer (bank transfer), 58 for SEPA credit transfer, 49 for direct debit
• PayeeFinancialAccount/ID: This is where the IBAN goes
• PayeeFinancialAccount/Name: The account holder name (optional but recommended)
• PayeeFinancialAccount/FinancialInstitutionBranch/ID: This is where the BIC goes

The EN 16931 standard requires that when the payment means code indicates a credit transfer, the PayeeFinancialAccount/ID (IBAN) must be present. The BIC is conditionally required — it must be provided when the IBAN alone is insufficient to identify the bank, which in practice means for non-SEPA transfers or when the receiving country requires it.

A single invoice can contain multiple PaymentMeans elements if you accept payment through different methods or to different bank accounts. Each one must be complete and correctly formatted.

EN 16931 Requirements for Payment Information

The European e-invoicing standard EN 16931 defines specific business rules for payment information:

• BT-81 (Payment means type code): Mandatory. Must use a code from the UNTDID 4461 code list. The most common are 30 (credit transfer), 58 (SEPA credit transfer), and 49 (direct debit).
• BT-84 (Payment account identifier): Required for credit transfers. Must be a valid IBAN for SEPA payments. This is the primary field where your bank account number goes.
• BT-85 (Payment account name): Optional. The name of the account holder. Recommended for clarity, especially when the account holder differs from the seller name.
• BT-86 (Payment service provider identifier): The BIC/SWIFT code. Required when the bank cannot be derived from the IBAN alone, or when mandated by country-specific rules.

Country-specific rules may add further requirements. For example, XRechnung (Germany) requires payment means information and strongly recommends including both IBAN and BIC. Italy's SDI has its own payment information requirements within the FatturaPA format.

Common Rejection Reasons

Payment-related validation failures are among the most frequent causes of e-invoice rejection. Watch out for these:

• Missing IBAN: If PaymentMeansCode is 30 or 58 (credit transfer) but no PayeeFinancialAccount/ID is provided, the invoice fails EN 16931 validation. Every credit transfer invoice must include the IBAN.
• Invalid IBAN format: The IBAN must pass the modulo-97 check digit validation. A single wrong digit makes it invalid. Common mistakes include transposed numbers and incorrect length for the country.
• Invalid BIC: BIC codes must be exactly 8 or 11 characters. Common errors include using outdated BIC codes (banks merge and change codes), adding spaces, or confusing BIC with other bank identifiers.
• IBAN/BIC mismatch: If both are provided, the BIC should correspond to the bank identified in the IBAN. While not all validators check this, some do, and a mismatch can delay payment even if the invoice is technically accepted.
• Spaces or special characters: The IBAN and BIC must be stored as continuous strings in the XML. Spaces, hyphens, or dots will cause validation failures.
• Wrong PaymentMeansCode: Using code 30 (generic credit transfer) when 58 (SEPA credit transfer) is expected, or vice versa. Some Peppol access points are strict about this distinction.

How InvoicePeppol Extracts Payment Information

When you upload a PDF invoice to InvoicePeppol, our AI extraction engine identifies and processes payment details automatically:

• IBAN detection: The AI recognises IBAN patterns in the PDF text, validates the check digits, and verifies the length matches the country code
• BIC extraction: BIC/SWIFT codes are identified alongside IBAN information, whether they appear in headers, footers, or payment detail sections
• Format normalisation: Spaces, hyphens, and other formatting characters are automatically stripped so the XML contains clean, continuous strings
• Review step: Before generating the final XML, you can verify all extracted payment details and correct any errors
• Correct XML placement: IBAN and BIC are automatically placed in the correct UBL elements with the appropriate PaymentMeansCode

If your PDF invoice does not contain payment information (some invoices reference a standing payment arrangement), you can add IBAN and BIC manually during the review step before generating the XML.

Frequently Asked Questions