A KID — short for kundeidentifikasjon, customer identification — is the digit string printed on the giro stub at the bottom of a Norwegian supplier invoice. It is the customer-and-invoice reference Norwegian banks use to auto-allocate the buyer's payment to the right open item on the supplier side. To extract KID number from Norwegian invoice payments cleanly, an AP team needs four fields off the same stub, treated as one bundle rather than four separate field hunts: the KID, the kontonummer (the supplier's 11-digit Norwegian bank account number), the beløp (amount in NOK), and the forfallsdato (due date).
The KID itself is digits only. Length runs from 2 to 25, the rightmost digit is always a check digit, and the field is right-aligned in fixed-width contexts.
Two algorithms produce that check digit: MOD 10 (Luhn) or MOD 11. The choice is not the payer's — the supplier's bank assigns one when the supplier signs the OCR-betaling agreement, and it stays consistent for every invoice that supplier issues. The payer cannot tell which algorithm applies from the KID alone, so a payer-side validator implements both and accepts the KID if either passes. False positives from doing so are rare enough to ignore in practice.
Where the KID sits — anatomy of the giro stub
The giro stub — betalingsblankett on a Norwegian invoice, sometimes giroblankett in older templates — is the boxed-off payment slip at the bottom-right of a typical Norwegian supplier invoice. It carries the four routing fields the bank needs and nothing else of substance; the rest of the invoice is line items, tax breakdowns, and supplier identification.
The fields appear in a stable order, each with its Norwegian label printed in the box:
- Beløp — the amount due, in Norwegian kroner. The label is usually printed with "NOK" or "kr" alongside the figure, and the figure is formatted with a comma as the decimal separator (e.g.,
12 345,00) in standard Norwegian convention. - Til konto — the supplier's 11-digit kontonummer, formatted as
XXXX.XX.XXXXX. This is where the payment is sent. - Forfallsdato — the due date. Norwegian convention is
DD.MM.YYYY, though some suppliers printDD.MM.YYor use slashes. - KID — the digit-only customer-identification reference, length 2 to 25, right-aligned within its field on the printed slip. This is the field that tells the supplier's bank which open invoice the payment settles.
The supplier (kreditor) and buyer (debitor) names appear on the slip too, but they are not part of the bank-routing bundle. The bank routes on KID and kontonummer; the names are for human readability.
Three logo overlays commonly sit on or beside the giro stub: eFaktura, Avtalegiro, and increasingly Vipps. These signal which payment instruments the supplier accepts beyond a one-off bank transfer. They do not change the four extraction fields — the KID and kontonummer underneath are what each instrument routes on. The disambiguation of who initiates the payment under each instrument comes later.
Layout varies more than the labels do. Some suppliers print the giro stub on the bottom of every page; some only on the last page; some place it in a sidebar rather than a footer. The labels and the field order stay consistent across the variations, even when position drifts. Pure pattern-based extraction tuned to a specific position breaks when the layout shifts; AI-based extraction that recognises the labels themselves rides the variation. The same point matters for scan quality: faded scans and lower-resolution PDFs can blur the leading or trailing digits of the KID, which is the failure mode the check-digit validation later in this article exists to catch. Switzerland uses an analogous structured-payment block at the bottom of an invoice — see the Swiss QR-bill structured payment reference for the parallel system AP teams paying Swiss suppliers will encounter alongside the Norwegian KID.
The kontonummer that travels with the KID
A Norwegian bank account number is 11 digits, conventionally formatted with two dots as XXXX.XX.XXXXX. The first 4 digits are the registry number that identifies the issuing bank — DNB, Nordea, SpareBank 1, Sbanken, Handelsbanken, and so on — the next 6 are the account number within that bank, and the final digit is a MOD 11 check digit. The kontonummer travels with the KID through every payment file: the bank uses both together to route the payment to the right supplier and credit the right open invoice on that supplier's books.
The kontonummer's MOD 11 check uses a fixed weight sequence rather than the cycling weights used for the KID MOD 11 walked later in this article. Reading the first 10 digits of the account number from right to left, the weights are 2, 3, 4, 5, 6, 7, 2, 3, 4, 5. Multiply each digit by its weight, sum the products, and take the result mod 11. The 11th digit — the one printed at the end of the account number — equals 11 − remainder, with two special cases: a remainder of 0 yields a check digit of 0, and a remainder of 1 would yield a check digit of 10, which is invalid — the issuing bank would not have generated such an account number.
Validating the kontonummer in the same extraction pass as the KID catches data-entry slips and OCR glitches before the payment file is sent. A transposed digit in the registry portion typically routes the payment to the wrong bank and triggers a return; a transposed digit in the account portion can route to a real but wrong account. The check digit catches single-digit errors and most adjacent-digit transpositions in either portion.
A note on scope: when the AP team is paying a Norwegian supplier from a Norwegian bank account, the kontonummer is what the payment file carries. When the payment is cross-border — a foreign company paying a Norwegian supplier from outside Norway — IBAN replaces the kontonummer in the payment instruction, and the IBAN-and-BIC validation rules apply instead. The 11-digit kontonummer format and the MOD 11 check covered here are Norway-domestic.
MOD 10 (Luhn) walked end-to-end
The MOD 10 algorithm used in Norwegian KIDs is the Luhn algorithm. Length 2 to 25 digits. The rightmost digit is the check digit. Working leftward from the digit immediately left of the check digit, apply alternating weights of 2 and 1 — so the second-rightmost digit gets weight 2, the next leftward gets weight 1, then 2, then 1, and so on across the rest of the KID. Multiply each digit by its weight. If a product is two digits — which only happens when a digit of 5 through 9 receives weight 2 — sum the two digits of that product before adding to the running total. Sum all the resulting values across the non-check digits. The check digit is whatever value makes the grand total — non-check sum plus the check digit — a multiple of 10.
Take the fictitious KID 12345674 (a worked example, not a real supplier KID). Strip the check digit 4 and walk the remaining digits 1234567 from right to left:
| Position from right | Digit | Weight | Product | After digit-sum |
|---|---|---|---|---|
| 2 | 7 | 2 | 14 | 1 + 4 = 5 |
| 3 | 6 | 1 | 6 | 6 |
| 4 | 5 | 2 | 10 | 1 + 0 = 1 |
| 5 | 4 | 1 | 4 | 4 |
| 6 | 3 | 2 | 6 | 6 |
| 7 | 2 | 1 | 2 | 2 |
| 8 | 1 | 2 | 2 | 2 |
Sum of the right-hand column: 5 + 6 + 1 + 4 + 6 + 2 + 2 = 26. The check digit must bring the grand total to the next multiple of 10. 26 plus check digit equals 30, so the check digit is 4 — which matches the printed final digit of 12345674. The KID validates under MOD 10.
A real-world implementation runs this check in a few lines of code: iterate the KID right to left, alternate the weight, apply the digit-sum where the product exceeds 9, sum, and confirm the total mod 10 is zero. MOD 10 catches every single-digit error and most adjacent-digit transpositions — enough error-detection strength for many supplier-bank assignments, though not all transpositions and not the same combinations of multiple errors that MOD 11 catches.
MOD 11 walked end-to-end on a different KID
MOD 11 works differently enough from MOD 10 that a payer-side validator implementing one cannot satisfy itself with a tweak to handle the other. Length 2 to 25 digits, rightmost digit is the check digit. Working leftward from the digit immediately left of the check digit, apply weights cycling 2, 3, 4, 5, 6, 7 — so position 2 (one left of the check digit) gets weight 2, position 3 gets weight 3, position 4 gets weight 4, position 5 gets weight 5, position 6 gets weight 6, position 7 gets weight 7, and then the cycle restarts so position 8 gets weight 2 again, position 9 gets weight 3, and so on for as long as the KID runs. Multiply each digit by its weight. Sum the products whole — there is no digit-sum step in MOD 11.
Take the sum mod 11. The check digit equals 11 − remainder, with two special cases worth being explicit about. If the remainder is 0, the check digit is 0 (not 11). If 11 − remainder works out to 10, the KID is invalid — a check digit cannot be two digits — and the supplier's billing system re-rolls a different KID rather than emit one that ends in 10. In practice this means a small fraction of candidate KIDs are skipped at issue time, which is invisible to the payer because the invoice never carries an invalid KID in the first place.
Take the fictitious KID 1234567892 (a worked example, not a real supplier KID). Strip the check digit 2 and walk the remaining digits 123456789 from right to left:
| Position from right | Digit | Weight | Product |
|---|---|---|---|
| 2 | 9 | 2 | 18 |
| 3 | 8 | 3 | 24 |
| 4 | 7 | 4 | 28 |
| 5 | 6 | 5 | 30 |
| 6 | 5 | 6 | 30 |
| 7 | 4 | 7 | 28 |
| 8 | 3 | 2 | 6 |
| 9 | 2 | 3 | 6 |
| 10 | 1 | 4 | 4 |
Notice the weight cycle restarting at position 8 — the weight returns to 2 after position 7, then climbs through 3, 4, and so on if the KID had more digits. Sum of the product column: 18 + 24 + 28 + 30 + 30 + 28 + 6 + 6 + 4 = 174. Take 174 mod 11: 174 = 15 × 11 + 9, so the remainder is 9. Check digit is 11 − 9 = 2, which matches the printed final digit of 1234567892. The KID validates under MOD 11.
MOD 11 catches the same error classes MOD 10 does plus a wider band of transposition and substitution combinations, which is why it is the more common assignment for Norwegian KIDs and the same algorithm used for the kontonummer check digit. The article does not need to argue MOD 11 is "better" in the abstract — the supplier's bank already chose, and the payer's job is to validate against whichever applies.
Choosing the algorithm — and the OCR-betaling terminology overload
When a Norwegian supplier signs up for OCR-betaling service with their bank, the bank assigns either MOD 10 or MOD 11 to that supplier's KIDs. The choice happens once, at the point the supplier signs the agreement, and it stays consistent across every invoice that supplier issues from then on. The payer cannot infer the algorithm from the KID itself — both algorithms produce digit-only KIDs of valid length, both check digits land in the range 0 to 9, and a KID generated under one will look identical in shape to a KID generated under the other.
The practical rule for a payer-side validator is to implement both algorithms and accept the KID if either passes. A KID with a single transposition or a missing digit will almost always fail both algorithms; the cases where a wrong KID passes one of the two by coincidence are rare enough in practice to ignore, given the cost of falsely rejecting a valid KID. The first invoice from a new supplier reveals which algorithm their bank chose; for any team building per-supplier confidence scoring, that becomes a useful field to cache after the first successful validation.
Two senses of OCR meet at this point in the workflow, and confusing them is a real source of operational mistakes. OCR-betaling is the Norwegian banking term for the bank's automated reconciliation of incoming KID-tagged payments. The supplier's bank reads the KID off the payment instruction, looks up the supplier's open invoices, and credits the correct one without manual matching. It has nothing to do with optical character recognition of scanned text. OCR in the AP-software sense — character recognition of scanned PDFs — is the upstream extraction step that pulls the KID off a paper or PDF invoice in the first place. Both terms appear in the same operational sentence: a Norwegian AP team running scanned supplier invoices through an OCR pipeline to extract the KID for an OCR-betaling-enabled supplier. Be explicit on every subsequent use about which is meant. Sweden has a structurally similar arrangement on the supplier side — see Sweden's Bankgiro and OCR reference number system for the parallel framework AP teams paying Swedish suppliers will hit, with its own analogous reference-on-invoice convention and the same potential for terminology mix-ups.
Bookkeeping and ERP systems serving Norway — Visma, Tripletex, PowerOffice GO, and Microsoft Dynamics 365 Business Central with Continia or IT.integro layered on top — typically validate KIDs against both algorithms automatically as part of their AP processing. Teams building their own validation should match this behaviour rather than picking one algorithm and rejecting the other.
Three routes for getting the KID off the invoice
Three practical routes get the four-field bundle off a Norwegian supplier invoice and into the bank file. Most AP teams use a mix rather than committing to one.
Manual transcription. The AP clerk reads the giro stub on the printed or PDF invoice and types KID, kontonummer, beløp, and forfallsdato into the bank portal or AP system by hand. Fits one-off payments, occasional Norwegian suppliers, or any team with a low single-digit volume of Norwegian invoices per month. The error rate from manual transcription is the dominant failure mode at any meaningful volume — a transposed KID digit, a missed leading zero, a wrong forfallsdato month — and it is exactly what the check-digit validation later in the pipeline catches before the payment file goes to the bank. Below maybe 20 Norwegian invoices a month, the time saved by anything more sophisticated does not repay the setup; above that, the manual route stops scaling.
OCR or AI extraction from the invoice PDF. The extraction tool reads the giro stub on each PDF in a batch and returns the four fields in one pass. Norwegian field labels are stable enough across suppliers that pattern-based extraction tuned to Beløp / Til konto / Forfallsdato / KID works well for clean PDFs from familiar templates. Layout variation, overlay logos on the stub, scan-quality issues, and unfamiliar templates are where AI-based extraction earns its place — it recognises the labels themselves rather than relying on a fixed coordinate map, which means it handles a new supplier's invoice on the first run rather than after a per-template configuration step. This is the volume-fit route for an AP team with more than a handful of Norwegian suppliers per month, and the route where automated invoice data extraction tooling shifts the bottleneck from typing to reviewing the validation flags on the resulting bundle. Our own product is built around exactly this shape of work: a single natural-language prompt names the four fields the bank file needs (KID, Kontonummer, Beløp_NOK, Forfallsdato) plus any validation columns the team wants flagged, batches up to 6,000 invoices process through the same prompt in one run, and the output is a structured XLSX, CSV, or JSON file that drops straight into the bank's payment-batch upload. Norwegian field labels and Latin scripts are handled natively, so the prompt does not need to translate Beløp to "amount" or Forfallsdato to "due date" before extraction.
Structured EHF receive. When the supplier sends an EHF (Elektronisk Handelsformat) invoice through Peppol rather than a PDF, the four-field bundle arrives already structured. The KID specifically appears as the cbc:PaymentID element under cac:PaymentMeans in the EHF / Peppol BIS Billing 3.0 XML; the kontonummer arrives in cac:PayeeFinancialAccount, the beløp in the document totals, and the forfallsdato in cbc:DueDate. No OCR step is required, though AP teams still need a Norway EHF XML-to-Excel field mapping when the structured invoice has to become a reviewable spreadsheet. With Norway's 2027 B2B EHF e-invoicing mandate bringing structured receipt to the default state for many supplier flows, this route will progressively replace PDF extraction for compliant suppliers — but PDFs from non-mandated suppliers, foreign suppliers, and historic backlogs keep the other two routes relevant for years.
The three routes coexist in any real AP function. Structured EHF for the suppliers who send it, OCR or AI extraction for the PDF batches, manual transcription for the rare paper invoice or the one-off vendor payment. The validation logic on the four-field bundle is the same regardless of route — the bank does not care which path produced the KID, only that the KID and kontonummer route the payment correctly when the bank file lands.
Adjacent payment instruments — eFaktura, Avtalegiro, and Vipps Faktura
Three Norwegian payment instruments commonly appear as logo overlays on the giro stub or come up in conversation with suppliers about how invoices will be paid. They are not interchangeable, and understanding which one a supplier expects matters for the AP workflow even though none of them changes the four-field extraction.
eFaktura is a consumer-side electronic invoice. The supplier sends the invoice through the eFaktura network and it lands in the buyer's banking app — DNB, Nordea, SpareBank 1, Sbanken, or the Vipps mobile app — for one-tap acceptance. Underneath, eFaktura carries the KID and kontonummer that the bank uses to route the payment. On the company AP side, eFaktura is mostly a consumer rail; it becomes relevant when a sole trader or small-business owner is paying as an individual through their personal banking, not when a company AP function is processing supplier payments at scale.
Avtalegiro is the direct-debit standing-order arrangement. The buyer pre-authorises the supplier through their bank, and the supplier pulls the payment on the forfallsdato; the routing again uses KID and kontonummer underneath. AvtaleGiro is Norway's direct debit scheme, used for both B2C and B2B recurring payments such as utility bills, subscriptions, rent, and loans. AP teams running Avtalegiro for recurring suppliers still need clean KID extraction at sign-up time and on each invoice for reconciliation — the standing order does not eliminate the supplier's need to issue an invoice, and it does not eliminate the AP team's need to match the pulled payment back to the invoice on their books.
Vipps Faktura is a Vipps-mediated payment rail oriented at individuals and the smallest businesses. It surfaces a Vipps payment request rather than a bank-transfer instruction, and it is at the margin of mainstream B2B AP — useful to recognise when the logo appears, rarely the route a company AP function settles supplier payments through.
The practical takeaway is that the four-field extraction does not change across these instruments. The KID is the common routing identifier; the kontonummer is the destination; the beløp and forfallsdato carry the amount and timing. The instrument choice changes who initiates the payment (buyer push versus supplier pull) and through which channel — bank portal, banking app, Vipps. It does not change what the extraction step has to deliver to the AP team's downstream processing.
When the KID is missing — the sole-trader and micro-business case
Some Norwegian invoices arrive without a KID at all. The smallest suppliers — sole traders, micro-businesses, occasional invoicers — often skip KID setup because they have not signed up for OCR-betaling with their bank and have no need for automated reconciliation at their invoice volume. KID is not a Bokføringsforskriften §5-1-1 mandatory field, so the absence does not make the invoice non-compliant; the kontonummer, the supplier's organisasjonsnummer, the beløp, and the forfallsdato remain on the invoice as usual — see the §5-1-1 checklist of mandatory fields on a Norwegian MVA invoice for the full set the supplier is obliged to print.
The standard workaround is for the buyer to pay against the kontonummer with a free-text reference field — typically the supplier's invoice number — that the supplier reconciles by hand on receipt. The payment still lands in the supplier's account; it just does not auto-allocate to a specific open invoice the way a KID-tagged payment would. The supplier's reconciliation becomes manual matching of bank-statement entries against their open-invoice list. For a supplier issuing a handful of invoices a month, this is workable and common.
On the AP side, handling the case cleanly means extracting kontonummer, beløp, and forfallsdato as usual, leaving the KID field empty (or flagging it explicitly in the extraction schema), and substituting the supplier's invoice number into the bank's free-text reference field when the payment is created. Validation logic should treat KID-absent as a flagged-but-payable case, not as an extraction failure that blocks the row. The flag is useful evidence at downstream review — a missing KID on a small supplier's invoice is expected; a missing KID on a large established supplier's invoice usually means the extraction missed it and the row should be re-checked against the source PDF.
The same picture applies on the EHF side. EHF invoices from sole-trader suppliers may arrive without a cbc:PaymentID element, and the same kontonummer-plus-free-text-reference pattern handles them. Missing structured KID is not malformed EHF; it is a supplier who is invoicing without an OCR-betaling agreement.
The four-field extraction schema that feeds the Norwegian payment file
A workable extraction schema for a Norwegian supplier-invoice batch comes down to the four payment-relevant fields, a handful of identification columns the AP team needs for its own audit trail, and validation flags that let downstream payment-file generation skip-or-flag suspect entries cleanly:
| Column | Source | Purpose |
|---|---|---|
InvoiceNumber | Invoice header | AP identifier |
SupplierName | Invoice header | Human-readable AP identifier |
SupplierOrgnr | Invoice header / footer | 9-digit Norwegian organisasjonsnummer for audit trail |
KID | Giro stub | Routes payment to the correct open invoice on the supplier's books |
Kontonummer | Giro stub | 11-digit destination account |
Beløp_NOK | Giro stub | Amount due in NOK |
Forfallsdato | Giro stub | Due date |
KID_Algorithm_Validated | Computed | true if the KID passes MOD 10 OR MOD 11; false otherwise |
Kontonummer_ChecksumValid | Computed | true if the kontonummer passes its MOD 11 check; false otherwise |
The two validation columns earn their place by changing how downstream payment-file generation behaves on a row-by-row basis. Rows where KID_Algorithm_Validated is false get held for human review before the payment file is sent — the issue is almost always a missing leading digit, a transposed digit, or an OCR misread of an ambiguous character, not a genuinely invalid supplier KID. A quick eyeball against the source PDF resolves most of them. Rows where Kontonummer_ChecksumValid is false get held entirely; an invalid kontonummer either routes the payment to the wrong bank or fails the bank's input check at file submission, and either way the cost of stopping the row is lower than the cost of letting it through.
Once the bundle is clean, the bank-file step is downstream. Norwegian banks accept payment instructions through online-banking payment-batch upload (the modern path used by most AP teams) or through Telepay or Telepay 2 file uploads in legacy flows; either way, the AP team's job is delivering the four validated fields per row, and the bank's software handles the file-format generation. Walking the Telepay format is outside the scope of this article — it is a developer-side topic for teams building bank integrations rather than an AP extraction concern.
The validated bundle becomes part of the broader Norwegian payment record-keeping that audit, compliance, and reconciliation lean on later. The archive of which payments were made to which supplier, against which invoice, on which forfallsdato, with which KID, is what dispute resolution and the Norway SAF-T audit-file requirements and routine bookkeeping reviews all draw on. A clean, validated extraction bundle at the front of the workflow is what makes the rest of that record-keeping straightforward to produce.
One small operational detail worth flagging: every row in the structured output references the source file and the page number the data came from, which is what turns the human-review step on a flagged row into a one-click jump back to the giro stub the KID was extracted from.
Extract invoice data to Excel with natural language prompts
Upload your invoices, describe what you need in plain language, and download clean, structured spreadsheets. No templates, no complex configuration.
Related Articles
Explore adjacent guides and reference articles on this topic.
Sweden Bankgiro & OCR Number Invoice Payment Guide
Guide to Sweden's Bankgiro payment system and OCR reference numbers on invoices. Covers number formats, Mod 10 validation, and SS 61 41 14 layout rules.
Norway A-melding 2026: Foreign Employer Payroll Reporting Guide
Norway A-melding for foreign employers: 5th-of-month Altinn deadline, what each wage line carries, and the 2026 skattetrekkskonto and utbetalingsdato rules.
Norway B2B E-Invoicing Requirements 2027
Norway's 2027 B2B e-invoicing rules explained: who must send EHF, the 2030 receive obligation, exemptions, Peppol setup, and readiness steps.