In short
- Payment information lives in
BG-16Payment instructions, which contains one mandatory code and three optional sub-groups: credit transfer, card, direct debit. - The code in
BT-81comes from the UNTDID 4461 list and decides which other fields must be present. - Four rules do most of the rejecting: BR-49, BR-50, BR-51 and BR-61.
BT-83Remittance information is where cash application succeeds or fails.
Payment information is not something the VAT Directive requires on an invoice. Article 226 lists the mandatory content, and a bank account is not on it. Yet it is the part of the document the buyer's treasury looks at first, and in a structured invoice it is the part most likely to be populated badly, because the source system usually held it as a line of free text at the bottom of a PDF template. This reference sets out how the European semantic model structures it, which codes are used, and which rules reject a document when it is wrong.
The structure
BG-16 is a group, not a field. It holds one required code, two optional free-text elements, and up to three sub-groups, each of which applies to one family of payment method. The numbering follows the usual convention described in how to read a BT number.
| Term | Name | What it carries | Note |
|---|---|---|---|
BT-81 | Payment means type code | How payment is expected, as a code | Required whenever BG-16 is present |
BT-82 | Payment means text | The same, in words | Optional, for humans |
BT-83 | Remittance information | The reference the payer should quote | The key to automatic matching |
BG-17 | Credit transfer | Account details for a transfer | May repeat, one per account |
BT-84 | Payment account identifier | IBAN, or a proprietary account number | Required inside BG-17 |
BT-85 | Payment account name | The account holder's name | Optional |
BT-86 | Payment service provider identifier | BIC or equivalent | Optional |
BG-18 | Payment card information | Details of a card already used | Never a full card number |
BT-87 | Payment card primary account number | Truncated card number | Limited by BR-51 |
BT-88 | Payment card holder name | Name on the card | Optional |
BG-19 | Direct debit | What the seller will collect, and under which mandate | For collection rather than payment |
BT-89 | Mandate reference identifier | The debtor's mandate reference | Must match what the bank holds |
BT-90 | Bank assigned creditor identifier | The seller's creditor identifier | For SEPA direct debit |
BT-91 | Debited account identifier | The buyer's account to be debited | Optional |
Around the group sit three terms at document level that treasury also reads: BT-9 Payment due date, BT-20 Payment terms, and BT-115 Amount due for payment, which is the total with VAT less anything already paid (BT-113) and adjusted by any rounding (BT-114).
The code in BT-81
The payment means code is drawn from UNTDID 4461, a UN/CEFACT list with far more values than anybody uses. A European invoice in practice uses a small subset.
| Code | Meaning | What it implies for the rest of BG-16 |
|---|---|---|
58 | SEPA credit transfer | Account identifier required (BR-61) |
30 | Credit transfer | Generic credit transfer, not scheme-specific |
42 | Payment to bank account | Also seen; close in meaning to 30 |
59 | SEPA direct debit | Direct debit group expected; mandate reference |
49 | Direct debit | Non-SEPA collection |
48 | Bank card | Card group; truncated number only |
57 | Standing agreement | Settlement under an existing arrangement |
10 | In cash | Rare in business-to-business, but valid |
1 | Instrument not defined | Permitted, and useless to the payer |
ZZZ | Mutually defined | Only meaningful where both parties have agreed what it means |
A national profile may restrict the list further, and some do. That is the normal behaviour of a core invoice usage specification, and it is why the code that works for one receiver can fail for another.
The rules that reject
Four business rules in the standard do most of the work, and they are worth knowing by number because that is how a rejection message will cite them.
- BR-49. If
BG-16is present,BT-81must be present. An empty payment block with just an account number is invalid. - BR-50. If credit transfer information is given, the account identifier
BT-84must be present. - BR-61. If the code means SEPA credit transfer, local credit transfer or non-SEPA international credit transfer, the account identifier must be present — so a code of
58without an IBAN fails even when the credit transfer group was omitted altogether. - BR-51. A full card number must never appear. The rule refers to the card industry's limit of the first six and last four digits.
There is one more that lives outside the group. Where the amount due for payment is positive, the invoice must carry either a payment due date or payment terms. A system that computes the due date only at posting time, after the invoice has been sent, will fail it.
BT-83 Remittance information is the reference the seller wants quoted back on the bank statement. Populate it with something the receivables system can match on — the invoice number, or a structured creditor reference — and cash application becomes a lookup. Leave it empty, and the saving from structured invoicing on the receiving side is spent again by the seller's cash team.
Where it goes wrong in practice
Three failures recur, and none of them is a format problem.
The bank details came from the template, not the master. The account on a PDF invoice was often typed into the layout years ago. When invoicing becomes structured, the value has to come from a governed record — which is a master data task, and it is the moment to discover that three legal entities have been printing the same account.
Changed bank details arrive by invoice. A structured invoice makes it easier, not harder, to change the account a buyer pays into: the new value simply appears in BT-84. Accounts payable should never update a supplier's bank details from an invoice, however well-formed. The change has to come through a verified supplier-maintenance process, and the invoice should be matched against what the master already holds. This is one of the controls to re-establish when accounts payable is redesigned.
Direct debit without a mandate reference. A SEPA direct debit collection needs the mandate reference and the creditor identifier to agree with what the debtor's bank holds. Putting code 59 on the invoice without BT-89 tells the buyer a collection is coming and gives them no way to check it against the mandate they signed.
A short checklist
- The code in BT-81 is chosen per payment method, not hard-coded for every invoice
- Every account identifier in BT-84 comes from governed master data, not from a layout
- BT-83 carries a reference the receivables system actually matches on
- A due date or payment terms is present whenever the amount due is positive
- Card numbers are truncated at source, before any file is written
- Direct debit invoices carry the mandate reference and creditor identifier
