vatverify home
All guides

Norwegian brreg explained: org-number, MVA, and the open registry

How the Brønnøysund Register Centre runs Norway's Entity and VAT registers, what the public REST API returns, and where MVA diverges from the rest of Europe.

Key facts

  • Norway sits outside the EU (it is in the EEA). Its VAT, called MVA (merverdiavgift), is a wholly national registry with no VIES crossover.
  • Every Norwegian business has a 9-digit organisation number (organisasjonsnummer) issued by Brønnøysundregistrene (the Brønnøysund Register Centre, abbreviated "brreg"). The 9th digit is a MOD-11 check digit.
  • MVA registration is a separate flag managed jointly by Skatteetaten (the tax authority) and surfaced on the brreg record as registrertIMvaregisteret.
  • The REST API at data.brreg.no/enhetsregisteret/api/enheter/{orgnr} is public, open data, no auth. brreg enforces a fair-use rate limit, with 429 responses for IPs that sustain heavy traffic.
  • MVA is a display suffix with no digits attached; it is stripped before any lookup.

What the registry is

Brønnøysundregistrene is a shared-services agency run by the Norwegian Ministry of Trade, Industry and Fisheries. It operates around twenty national registers from its base in the town of Brønnøysund, far north of Trondheim. The two registers relevant to VAT validation are:

  • Enhetsregisteret (the Entity Register). Every Norwegian business is listed here with its 9-digit organisation number, legal form, registered address, and a set of flags indicating status in other registers.
  • Merverdiavgiftsregisteret (the VAT Register). A subset of Enhetsregisteret businesses that have crossed the NOK 50,000 annual-turnover threshold (or registered voluntarily). The register itself is operated by Skatteetaten (the Norwegian Tax Administration), but its membership flag is exposed via brreg's Entity Register record as registrertIMvaregisteret.

The legal basis is the Enhetsregisterloven (Entity Register Act) of 1994 and the Merverdiavgiftsloven (VAT Act) of 2009. Public access to the data is a deliberate policy choice: Norway treats the entity register as open public data, published under a permissive reuse licence, and exposes it without authentication.

MVA's standard rate is 25%. Reduced rates apply: 15% on food, 12% on passenger transport and cinema tickets, and 0% on certain cultural categories. These are tax-rules-engine concerns rather than registry concerns, but worth noting because they frequently surface on the same invoices where you are doing the validation.

What the API returns

The lookup is a plain GET on a REST endpoint:

GET https://data.brreg.no/enhetsregisteret/api/enheter/123456789
Accept: application/json

A successful response carries the full entity record. The fields we care about for VAT validation:

{
  "organisasjonsnummer": "123456789",
  "navn": "EXAMPLE AS",
  "organisasjonsform": { "kode": "AS", "beskrivelse": "Aksjeselskap" },
  "registrertIMvaregisteret": true,
  "registreringsdatoEnhetsregisteret": "2018-04-01",
  "forretningsadresse": {
    "land": "Norge",
    "landkode": "NO",
    "postnummer": "0001",
    "poststed": "OSLO",
    "adresse": ["Eksempelgata 1"]
  },
  "slettedato": null
}

Key signals:

  • registrertIMvaregisteret: true if the business is VAT-registered. This is the flag vatverify checks for data.valid.
  • slettedato: a deregistration date. A non-null value means the entity has been deleted from the Entity Register; brreg strips the VAT flag at the same time.
  • organisasjonsform.kode: legal form. AS is limited company, ENK is sole proprietor (enkeltpersonforetak), ASA is public limited, NUF is a Norwegian-registered foreign enterprise.

Unknown numbers return HTTP 404 with a small JSON error body. Malformed requests return HTTP 400. The API also exposes /enhetsregisteret/api/enheter?organisasjonsnummer=... as a search form, but direct path lookup is cheaper and the one we use.

Rate limits and quirks

brreg applies a fair-use rate limit rather than a single fixed number, and sustained heavy traffic is what triggers it. Exceeding the ceiling returns HTTP 429 with a short back-off window. In practice, short bursts against a warm dataset are rarely throttled, but long sequential scans are. Plan for modest concurrency and honour any Retry-After header you receive.

Quirks to be aware of:

  • NUF entities. A Norwegian-registered foreign enterprise (NUF) is a branch of a foreign company. It has a Norwegian organisation number and can be VAT-registered even though its headquarters is abroad. Treat NUFs as standard Norwegian taxpayers when registrertIMvaregisteret is true.
  • Struck-off businesses. slettedato populates on the day of deregistration, but the VAT flag can take up to 48 hours to flip to false. Always check slettedato alongside the VAT flag; if either indicates the business is gone, return valid: false.
  • ENK sole proprietors. Many sole proprietors are below the NOK 50,000 threshold and are therefore not VAT-registered. You will see valid entities with registrertIMvaregisteret: false.
  • EORI is not MVA. Norwegian EORI numbers share the same 9-digit org-number core and look like NO123456789. EORI is a customs identifier managed by Tolldirektoratet, not a VAT identifier. Do not confuse the two on cross-border shipping flows.

How vatverify handles it

The brreg pipeline is the simplest of the four registries because there is no auth layer and the response shape is already JSON.

  1. Normalise: strip whitespace, dots, hyphens, and the optional MVA/mva suffix; uppercase the prefix.
  2. Format check: the request must start with the two-letter NO prefix followed by the nine-digit body. Bodies that fail the shape check return invalid_format before any network call.
  3. Cache lookup: freshness is 30 days on valid records and 24 hours on invalids, with a seven-day fallback window past freshness used to smooth upstream outages.
  4. Upstream call: HTTP GET with a 10-second timeout. Parse JSON, map registrertIMvaregisteret to data.valid, map navn to data.company.name, map forretningsadresse to data.company.address.

Norwegian MOD-11 and the rest of the Brønnøysund checksum machinery (weights 3, 2, 7, 6, 5, 4, 3, 2 over the first eight digits) ships in the @vatverify/vat-rates offline library for clients that want to reject typos before calling the API.

On 404 (entity not found), we cache valid: false under the invalid-freshness window. On 5xx or timeout, we apply the degraded-cache posture: serve the last cached record with meta.source_status: "degraded", else return registry_unavailable.

Authenticated consultations do not exist for brreg; the API is fully open, and there is no per-lookup identifier analogous to the VIES requestIdentifier. If you need audit-grade proof for a Norwegian validation, snapshot the response body alongside the verified_at timestamp in your own system, stored in tamper-evident form. Because brreg is open-data, a timestamped record of the public endpoint's response is the established substitute for a consultation number.

Because brreg is a REST API with predictable latency, the degraded-mode path fires less often here than for the SOAP registries. A typical Norwegian validation against a warm cache returns in under 20 ms; a cache miss plus upstream call lands under 400 ms most days. The tax-rules engine downstream of /v1/validate consumes the same normalised response, so Norwegian entries behave identically to their EU counterparts once they have been resolved.

Gotchas worth knowing

  • The MVA suffix is display sugar. It is not a distinct registry. Numbers with and without the suffix are the same record.
  • Norway's threshold is NOK 50,000, not a euro figure. If you cross-check against EU-style thresholds, you will misclassify small Norwegian businesses. Use the NOK figure and the registrertIMvaregisteret flag, not turnover assumptions.
  • slettedato can precede the VAT flag flip. During the 24-48 hour propagation window a business can show slettedato non-null and registrertIMvaregisteret: true. Check both.
  • Open data ≠ opinionated schema. brreg is a statistical register run by a statistics agency; field semantics can drift slightly across API versions. Pin your client to the documented schema and treat unknown fields as additive.

See the API reference

Validate VAT in three lines.

Free up to 500 requests per month. No credit card.

Start free