Norwegian customers

For Norwegian Legal Entities, send only the 9-digit organisation number (organisasjonsnummer) under scheme 0192. It is verified against the Brønnøysund Register Centre. Do not send the MVA number (scheme 9909, NO…MVA): it is not a Peppol address, and this endpoint refuses it. Our Peppol provider refuses any Norwegian sender without it, so getpeppr adds it itself when it registers the customer — in sandbox once verification succeeds, in production once the customer has confirmed the authorisation — and only if the register confirms, at that moment, that the company is in the VAT Register (Merverdiavgiftsregisteret).

• Registered for VAT: the MVA number is added and never announced as an address; the customer can send invoices that carry VAT.
• Not registered for VAT: the customer is registered with its organisation number only. It can receive, but getpeppr cannot send its invoices yet: Norwegian invoices that carry VAT need the MVA number, and invoices outside the scope of VAT are not accepted today.
• The register cannot be read (outage) or does not show an active entity: registration stops as registration_failed (provider_error) in sandbox, or provisioning_failed in production, rather than guessing. Retry with the same POST in sandbox. In production an outage is retried automatically for 30 days; if it still fails, call POST /v1/legal-entities/:id/attestation again (no new email, no new confirmation).

The MVA number does not appear in identifiers, which lists only what you declared. An organisation number approved by hand (a sub-unit, for example) gets no automatic MVA number: contact support. The VAT Register is checked when the customer is registered, not afterwards — if the company later leaves it, see when a VAT registration ends.

Can the customer send?

status: "active" means the customer can receive. To know whether it can also send, read vatRegistration, which GET /v1/legal-entities/:id and the list return for Norwegian customers only:

{
  "vatRegistration": {
    "status": "not_registered",
    "checkedAt": "2026-09-29T08:01:00.000Z",
    "source": "brreg",
    "vatNumberAdded": false
  }
}

• vatNumberAdded: true: the MVA number is held; the customer can send.
• status: "not_registered": the company is not in the VAT Register. It can receive; invoices sent in its name are refused with 422 STORECOVE-NO-SENDER-PAIR.
• status: "unknown", or "registered" with vatNumberAdded: false: the number is not held and getpeppr cannot add it on its own. Contact support.

legal_entity.* webhooks do not carry this field: on legal_entity.registered, read the entity once to decide whether to offer sending.

Testing in the sandbox

You do not need a real Norwegian company to test sending. The Brønnøysund Register Centre publishes a test register of fictitious companies. In the sandbox, when the live register does not know an organisation number, getpeppr looks it up in that test register.

1. Pick a fictitious company that is in the VAT Register: this test-register search lists twenty active ones.
2. Create the customer with its organisation number under 0192 and its exact registered name.
3. Once it is registered, vatRegistration reads source: "brreg_test" and vatNumberAdded: true: you can send invoices in its name.

{
  "vatRegistration": {
    "status": "registered",
    "checkedAt": "2026-10-04T18:00:00.000Z",
    "source": "brreg_test",
    "vatNumberAdded": true
  }
}

• What this tests: your whole integration — creating the customer, its verification, the webhooks, the MVA number getpeppr adds, and sending on the Peppol test network.
• What it does not prove: anything about a real company. "brreg_test" means the company is fictitious. In production only the live register answers, so the same number is refused as not found.
• A real company you create in the sandbox is still checked against the live register only, and its organisation number, name and address become visible in the public directory of the Peppol test network. Use one you control.
• The test network is shared. If someone else already registered the same fictitious company, registration fails with registrationDetail.reason: "already_registered": pick another company rather than retrying.

When it does not go through

Branch on the Getpeppr-Result-Code header, which every response carries, or on the body's code where one is given — never on the error text.

• verification_failed: the register did not confirm the identity; verificationDetail.reason says whether the name or the number is at fault. The identifier cannot be changed: archive and create again.
• unsupported_scheme or a sub-unit held for review (pending): there is no API to drive a manual review — contact support.
• The same organisation number under another externalId is refused at once with 409 identifier_already_in_use: one company, one customer.
• registration_failed in sandbox: retry the same POST. provisioning_failed in production: call POST /v1/legal-entities/:id/attestation again — getpeppr retries for up to 30 days (a definitive refusal by the provider ends it earlier), with no new email and no new confirmation.
• Authorisation emails are sent in an available language; Norwegian is not one today.