Verify Norwegian Organisasjonsnummer and MVA Before Paying

A Norwegian supplier invoice with an organisasjonsnummer or an "NO...MVA" VAT number needs four checks before AP approves payment or relies on the input VAT: the nine-digit number must pass Norway's MOD-11 structure test, Brønnøysundregistrene must confirm the entity exists and is current, the VAT Register must confirm MVA registration when VAT is charged, and the registered name must match the supplier on the invoice.

A valid-looking number is not enough. The checksum only proves the number is structurally possible; it does not prove that the supplier exists, has not been deleted, is allowed to charge MVA, or is the same legal entity named in your purchase order and supplier master.

Treat the checks as payment controls, not as a single lookup:

• Structure: normalize the value from the invoice and test the MOD-11 check digit. If it fails, request a corrected invoice before approval.
• Register existence: look up the organisation number in Brønnøysundregistrene. If no entity is returned, hold payment and escalate supplier onboarding.
• MVA status: if the invoice charges Norwegian VAT, confirm that the supplier is registered in the VAT Register. If registration is not confirmed, do not rely on the VAT amount until the supplier resolves it.
• Name match: compare the registered legal name and address with the invoice, contract, purchase order, and supplier master. If the mismatch is more than formatting or a known trading name, hold the change and ask for evidence.

Official register pages explain the number and registration facts. AP still needs a decision sequence that turns invoice fields into actions: approve, hold, correct, escalate, or treat the MVA as unresolved.

The same discipline matters whether the check is manual for one invoice or automated across a supplier list. The invoice supplies the data points: supplier name, organisation number, MVA suffix, invoice date, VAT amount, total, payment reference, and source document. The control only works when those fields are extracted consistently and compared against the right register data before payment is released.

Normalize the number and run the MOD-11 structure check

Start by reducing the invoice value to the nine-digit organisation number. A Norwegian supplier may print it as plain digits, with spaces, or as a VAT number wrapped with "NO" and "MVA". For the structure check, remove spaces, dots, "NO", and "MVA". What remains should be nine digits.

The Brønnøysund Register Centre guidance on Norwegian organisation numbers states that a Norwegian organisation number consists of 9 digits, with the last digit being a modulus 11 check digit; if a business is registered in the VAT Register, its VAT number is the same as its organisation number.

The MOD-11 check uses the first eight digits and the weights 3, 2, 7, 6, 5, 4, 3, and 2. Multiply each digit by its weight, add the products, divide by 11, and subtract the remainder from 11. The result is the check digit. If the division leaves no remainder, the check digit is 0. If the result is 10, the organisation number is invalid.

For the official example 123456785, the first eight digits produce 138; 138 mod 11 leaves 6, and 11 - 6 gives check digit 5. If the calculation returns 10, the organisation number is invalid.

This is the right first filter for validating a Norwegian VAT number on an invoice, but it is only a format test. A checksum-valid organisation number may still be the wrong supplier, a deleted entity, or a real entity that is not registered for MVA. Passing MOD-11 should move the invoice to the register checks, not straight to payment approval.

Confirm the entity exists and is current in Brønnøysundregistrene

Once the number passes MOD-11, check whether it identifies a real entity in Brønnøysundregistrene. For AP, this is not a broad business-information search. It is the control that answers whether the legal supplier named on the invoice exists in Enhetsregisteret and whether the supplier master should trust that identity.

For a one-off check, AP can use Brønnøysund's public search. For a system or spreadsheet-assisted process, the Open Data API supports a single-entity lookup at the "api/enheter" endpoint by organisation number. The relevant finance point is not the code; it is which returned fields should be compared with the invoice and supplier master:

• organisasjonsnummer, to confirm the number returned is the number on the invoice.
• navn, the registered legal name.
• forretningsadresse, the business address.
• organisasjonsform, such as AS, ENK, or NUF.
• næringskode, the industry classification, useful as a reasonableness check.
• slettedato, where a populated deletion date is a strong stop signal.
• Other status signals in the response where the API provides them.

Brønnøysund's API documentation treats a valid request for a non-existent resource as a 404 response. In AP language, that is a payment hold: if the copied organisation number returns no entity, route the case through supplier onboarding and do not "fix" the number by guessing.

Also keep main entities and sub-entities separate. The legal supplier on the invoice should map to the entity you pay and book against, not merely to a workplace, branch, or operational unit with related data.

A Brønnøysund supplier lookup should leave evidence, not just a pass or fail. Save the result or exception note with the invoice approval record when the supplier is new, high value, or has changed legal details.

Check MVA registration when the invoice charges VAT

The "MVA" suffix changes the AP question. A Norwegian organisation number can be real without the supplier being registered in the VAT Register, so the register-existence check and the MVA-registration check are separate controls.

On Norwegian supplier invoices, the same nine-digit organisation number is used as the VAT number when the business is registered for MVA. That is why invoices often show the value as "NO" plus the organisation number plus "MVA". The suffix is a supplier statement, not independent evidence. If the invoice includes Norwegian VAT, AP should confirm that status before relying on the VAT amount.

In Brønnøysund's Open Data API, the relevant field is registrertIMvaregisteret. Read it as "registered in the VAT Register." If the entity exists but this field does not confirm registration, the invoice should not move through normal VAT treatment without clarification. Skatteetaten VAT Register guidance says that when an enterprise is no longer registered, it must not issue invoices with VAT, which is the practical reason AP should hold the MVA element until the status is resolved.

This is also where invoice-date context matters. A status checked today may not answer every historical case by itself. If the invoice relates to a supply period around a registration or deregistration date, AP should ask whether the supplier was registered for the period covered by the invoice, not only whether the current lookup is positive.

If the supplier is MVA-registered and the invoice details line up, continue with the normal approval route. If MVA is charged but registration is not confirmed, hold the VAT treatment and ask for a corrected invoice or evidence before claiming input VAT. For the separate question of what a Norwegian VAT invoice must contain, use the Norwegian MVA invoice mandatory fields guide rather than turning this check into a full invoice-format review.

Treat name, address, and trading-name mismatches as hold-and-clarify events

The name check is where many false positives and real risks look similar. Brønnøysund returns the registered legal name. The invoice may show a brand, department, shortened trading name, old name, or personal-name sole proprietorship. AP should not reject every difference automatically, but it should not update the supplier master on trust either.

Use the mismatch severity to decide the next action:

• Low-risk formatting difference: punctuation, spacing, legal suffix placement, or capitalization differs, but the legal name, address, organisation form, and purchase order all point to the same supplier.
• Plausible trading-name difference: the invoice uses a known foretaksnavn, brand, or department name. Ask for support if the supplier is new or the amount is material.
• Recent legal-name or address change: hold supplier-master changes until procurement, the contract owner, or the supplier provides evidence.
• High-risk mismatch: the registered entity, bank details, invoice narrative, and supplier history do not line up. Hold payment and route the case through the fraud or supplier-onboarding process.

This check is not the same as bank-detail verification. A correct organisation number does not validate a new bank account, and a familiar bank account does not validate a changed legal supplier. Keep those controls separate so one apparent pass does not mask another exception.

Foreign-supplier invoices need their own judgment. A foreign supplier with no Norwegian footprint may not have a Norwegian organisation number at all; the Norwegian buyer may instead need to self-assess VAT under Norway reverse-charge VAT rules for foreign supplier invoices. A NUF, by contrast, is a Norway-registered foreign enterprise and should have an organisation number. VOEC is a separate scheme for certain foreign sellers in consumer e-commerce and should not be treated as a normal B2B supplier organisation number.

Build the checks into supplier onboarding and periodic refreshes

The four checks should not wait for an audit sample. Run them when a supplier is created, when the first invoice arrives, when bank details change, when an invoice is unusually high value, and on a monthly or quarterly supplier-master refresh.

For a periodic refresh, export organisation number, registered name, address, VAT status, last invoice date, and owner. Compare the list against Brønnøysund data and flag exceptions: deletion dates, changed legal names, changed addresses, and MVA status changes. The finance team needs a clean exception list, not a manual review of every supplier.

The quality of the check depends on the invoice data going into it. AP needs supplier legal name, organisation number, MVA suffix, invoice date, VAT amount, total, payment reference, and source reference in a consistent structure; extracting KID payment references from Norwegian invoices is a separate control, but it belongs in the same payment dataset. Invoice Data Extraction fits at that field-capture stage: users can upload mixed invoice batches, prompt for the supplier fields, then download Excel, CSV, or JSON for register checks through invoice data extraction for supplier-verification workflows.

What AP should do when a check fails

Use the failed check to assign the hold reason: failed MOD-11 means request a corrected invoice; no Brønnøysund entity, deletion date, or other stop signal means hold payment and route the case through supplier onboarding; unconfirmed MVA registration means hold VAT treatment until corrected; legal-name, foreign-supplier, or bank-detail mismatches need separate evidence before supplier-master changes.

The same pattern appears in other jurisdictions: AP teams need country-specific authenticity checks before they rely on invoice data, such as AP-side verification of Indian GST e-invoice IRNs for Indian GST invoices. For Norway, the core decision record is the four-part supplier check: MOD-11 structure, Brønnøysund entity status, MVA registration where tax is charged, and legal-name match.