How KID, IBAN and BBAN Payment Details Travel in an EHF Invoice

In an EHF invoice the KID goes in cbc:PaymentID, the bank account goes in cac:PayeeFinancialAccount/cbc:ID, and the one thing that separates an IBAN from a BBAN is whether a bank identifier is written beside it. An IBAN may carry a BIC in cac:FinancialInstitutionBranch/cbc:ID; a BBAN must not have that element at all. Everything else about the two is identical.

That is a short answer to a question that costs real money when it is got wrong, because most of these mistakes do not fail validation. A missing account number stops the invoice at the door. A wrong KID does not: it produces a perfectly valid document, a delivered invoice, and a payment that lands in the seller's bank with nothing to match it against. This page sets out where each field belongs, which rules actually test it, and which failures are silent.

Where does the KID number go in an EHF invoice?

Into cbc:PaymentID, directly under cac:PaymentMeans.

KID — kundeidentifikasjon — is a numeric reference a Norwegian seller agrees with their bank so that incoming payments reconcile automatically against open receivables. The buyer's bank carries the value through the payment; the seller's bank reads it on arrival and matches it. It is a banking artefact that happens to be printed on the invoice, which is why it has no dedicated invoice field and does not need one.

In EN 16931 terms the field is BT-83, remittance information. The Norwegian specification's own worked example makes the mapping explicit — it annotates <cbc:PaymentID> as "Remittance information about the payment, for example KID-number". So the KID is not a Norwegian extension bolted onto the format. It is the ordinary European remittance field, used the Norwegian way:

<cac:PaymentMeans>
  <cbc:PaymentMeansCode name="Credit transfer">30</cbc:PaymentMeansCode>
  <cbc:PaymentID>01245785421</cbc:PaymentID>
  <cac:PayeeFinancialAccount>
    <cbc:ID>4970011111222</cbc:ID>
    <cbc:Name>AccountX</cbc:Name>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>

Three values get confused with one another here often enough to be worth separating. The invoice number (BT-1) identifies the document. The buyer reference (BT-10) is whatever string the buyer asked you to quote so their accounts-payable system can route the invoice internally. The KID is neither: it belongs to the banking leg and exists so the money can find the receivable. Putting the invoice number in PaymentID is a common and entirely silent substitution — the invoice is valid, and the seller's bank simply fails to match the payment.

Which do you send, an IBAN or a BBAN?

Whichever the account is, in the same element. The branch element is the difference.

Both a BBAN and an IBAN are written to cac:PaymentMeans/cac:PayeeFinancialAccount/cbc:ID, and the Norwegian guidance is blunt about what goes in it: "The payment account identifier can be a BBAN or IBAN number, not the physical text 'BBAN' or 'IBAN'." The field takes the number.

Two of those rows carry most of the errors. The first is the branch element: the Norwegian specification states that cac:FinancialInstitutionBranch shall not be used when applying a BBAN, and a system that always writes the BIC because it always has one will quietly produce a non-conforming domestic invoice. The second is SEPA. If the payment means code says SEPA — 58 for a credit transfer, 59 for a direct debit — then the account has to be an IBAN, because a BBAN is not allowed in a SEPA payment at all.

A direct debit is the one case where the shape changes rather than just the branch element. The account to be debited moves into cac:PaymentMandate/cac:PayerFinancialAccount, and a mandate reference becomes mandatory — PEPPOL-EN16931-R061 fails any invoice using payment means code 49 or 59 without one.

Which payment means code goes with the account?

One is mandatory, and the Norwegian guidance has a typo in it worth knowing about.

cbc:PaymentMeansCode carries BT-81 and is required on every payment instruction under BR-49. For the cases a Norwegian seller actually meets, the values are 30 for an ordinary credit transfer and 58 for a SEPA credit transfer, with 48, 54 and 55 covering card payments and 49 and 59 covering direct debits.

Section 3.3.1 of the Norwegian guidance names "54 (SEPA credit transfer)" in a prose sentence, while its own SEPA section a few paragraphs later correctly uses 58. In the Peppol payment means code list 54 is a credit card. 58 is the value to send for a SEPA credit transfer; the 54 is a slip in the document rather than a national deviation, and we mention it only because reading that sentence literally produces an invoice that says "paid by card" to every system downstream.

What does validation actually catch here?

Two of the four things that go wrong, and not the two that cost you money.

• BR-49 (fatal) — a payment instruction must specify the payment means type code.
• BR-50 (fatal) — "A Payment account identifier (BT-84) shall be present if Credit transfer (BG-17) information is provided in the Invoice." An empty or absent account number under a credit transfer stops the document.
• BR-61 (fatal) — the same requirement stated again for SEPA credit transfer, local credit transfer and non-SEPA international credit transfer.
• PEPPOL-EN16931-R061 (fatal) — a mandate reference is required for direct debit.

Now the other side. There is no rule that tests the KID, because PaymentID is free text to a Schematron validator and there is no way for it to know what the seller's bank expects. There is also no rule that rejects a BBAN written with a BIC, even though the Norwegian guidance says not to do it: that instruction lives in prose rather than in the rule pack, so the invoice passes.

The practical consequence is that the payment block is the part of a Norwegian invoice you cannot sign off with a validator. A green validation report tells you the invoice will be delivered. It says nothing about whether the money will reconcile. The test that matters is a single real payment, end to end, checked in the seller's bank statement — once per bank account, not once per invoice.

How do these fields reach the invoice if you are not writing UBL?

Through three named values, so your ERP posts data rather than markup.

On GoRoute the KID is payment.payment_id, and the account is bank_account.iban, which accepts either form — a BIC is written out only where an IBAN is supplied, which keeps the BBAN rule from being something you have to remember. Both were added to the API on 16 September 2026, alongside the per-line CO₂ emission attributes the same Norwegian guidance defines. The field reference and the validation responses are in the developer documentation, and the Peppol API integration guide is the shortest route from your own invoice records to a validated EHF document — nobody should be authoring cac:PaymentMeans by hand.

What is still unsettled

We have carried no Norwegian production traffic. Norwegian delivery went live for us on 16 September 2026 and has had no live volume since. Everything on this page comes from the published rule packs, the Norwegian specification, and our own invoices validated against the official EHF validator. We would rather say that than imply experience we do not have.

We do not verify the KID check digit. The value is passed through to PaymentID exactly as given. Norwegian KID series are issued with either a Mod10 or a Mod11 check digit depending on the arrangement between the seller and the seller's bank, so a sender that does not know which scheme applies cannot check one.

The Peppol Payment domain is a different thing, and we do not support it. A payment instruction inside an invoice — which is everything on this page — is part of EHF Billing. The Payment domain is ISO 20022 banking messages carried over Peppol, and DFØ lists additional testing for it as still to be announced. We also do not support the pre-award G2 documents, which are public tendering rather than invoicing.

The 2027 B2B mandate does not appear to touch any of these fields. In March 2026 the Norwegian government moved mandatory B2B e-invoicing to 1 January 2027 and put the bill before the Storting. Nothing published so far changes the payment structures, so we read them as unchanged — that is inference, marked as inference, and not a confirmation.

What this page does not cover

VAT treatment. Which category code carries each Norwegian rate, and why all four positive rates use S, are in which VAT category code carries each Norwegian rate in an EHF invoice.

Registration and addressing. Who publishes a Norwegian participant, why a private company files nothing with ELMA, and which number on a Norwegian letterhead is the Peppol address are in how a Norwegian business becomes reachable for EHF invoices.

The documents beyond the invoice. EHF Reminder, Forward Billing and Payment Request each carry their own payment semantics and their own SMP opt-in, and they are covered in the three Norwegian billing documents Peppol does not have. The Payment Request in particular is often mistaken for the Payment domain described above; it is not.

Mandate scope and the country rules as a whole. Those belong to our Norway page.

What to do next

Send one real invoice to one real account and watch the bank statement. Not a validator run — an actual payment. It is the only test that exercises the KID, and it is a half-hour job per bank account rather than a project.

Then write down, for each Norwegian account you invoice from, whether it is being sent as an IBAN or a BBAN and whether a BIC is attached. That single table removes the most common defect on this page before anyone meets it.

If you are building the integration, start with the Peppol API integration guide, where the payment fields, the lookup and the delivery endpoints are set out; the full field reference is in the developer documentation, and recorded walkthroughs of the ERP connectors are on tutorials. The country rules we apply for Norway — EHF, scheme 0192, the Enhetsregisteret check and the VAT categories — are on our Norway page. If you would rather have somebody sit with your payment configuration and map it with you, book a session.

Next read: which VAT category code carries each Norwegian rate in an EHF invoice, which is the other half of getting a Norwegian invoice accepted and paid.

Sources: EHF Billing 3.0, version 3.0.3, published by DFØ (the Norwegian Agency for Public and Financial Management), read 5 October 2026 — section 3.3 for payment information, section 3.3.1 for the IBAN and BBAN examples, the annotation of cbc:PaymentID as "Remittance information about the payment, for example KID-number", the statement that cac:FinancialInstitutionBranch shall not be used with a BBAN, the statement that the identifier is the number and not the text, and the SEPA restriction; Peppol BIS Billing 3.0 section 11.7.1 and the rule list for the texts of BR-49, BR-50, BR-61 and PEPPOL-EN16931-R061, and for the payment means code values, read 5 October 2026; the Norway PA Specific Requirements (OpenPeppol, approved 17 September 2025), section 6, for DFØ's local specifications as the governing layer. GoRoute's own release record is the source for the payment.payment_id and bank_account.iban fields added on 16 September 2026, for Norwegian production delivery going live the same day with no production traffic since, and for the KID check digit being passed through rather than verified. The 1 January 2027 B2B date is the Norwegian government's March 2026 announcement, with the legislative proposal before the Storting. Last reviewed 2026-10-05.