How do I check if a Norwegian company is deleted from the register?

What does it mean that a company is deleted?

Deletion is the register recording that the entity has ceased to exist. The record itself is not erased: the organisation number, the registered name and the history remain queryable in Enhetsregisteret, which is precisely what makes a programmatic check possible years after the fact. What disappears is the going concern behind the number. There is no board acting for it, no one holding signing authority on its behalf, and no lawful way for anyone to be trading under it.

In the status model this guide builds on, deleted is terminal and wins over everything else. The derivation checks the slettedato first, so a company that went through bankruptcy and was then struck off reports deleted, not bankrupt. That ordering is deliberate: bankrupt describes an entity still inside proceedings, while deleted describes one the proceedings are finished with. Whatever else the record says, the slettedato is the last word.

For any decision that involves money, this makes deleted the easiest verdict to act on. An active company is a judgement call and a bankrupt one is a claims process, but a deleted one leaves no counterparty to deal with at all.

Which states lead to deletion?

Two roads, and both are visible in the register while they are being travelled. The first is under avvikling, voluntary liquidation: the owners have decided to wind the company up, and it still exists while it settles its obligations. The status derivation reports this as liquidating, a state of its own rather than a footnote on active.

The second is tvangsavvikling or tvangsoppløsning, forced liquidation: the winding up is imposed rather than chosen by the owners. The register carries it as its own flag, and the derivation reports forced_liquidation. The distinction matters for how you read a counterparty: a company winding itself down is executing a plan, while one being wound down by force has already stopped meeting somebody's requirements.

Because both states precede the slettedato, deletion is a monitored slide rather than a surprise. The raw flags under_avvikling and under_tvangsavvikling are tri-state: a real boolean passes through, and an absent value surfaces as null, meaning unknown, never silently as false. A pipeline that respects that honesty knows the difference between a clean bill and a missing one.

Why is paying a deleted company a fraud signal?

Because nobody can lawfully be trading under a deleted organisation number, an invoice carrying one has no innocent steady state. Either the supplier's identity in your master data has gone stale, or someone is using the remains of a real registration as cover. A deleted company is attractive cover exactly because it is real: the number validates, the name has history, and a lookup that only asks whether the record exists comes back reassuring.

This is the supplier-fraud angle, and it is why the deletion check belongs in the payment path rather than only in onboarding. The supplier check guide walks the full pre-payment checklist; the deletion test is its sharpest single item because the verdict is binary. Even in the innocent case, a restructured supplier billing under its old identity, the money must still be redirected to an entity the register says exists, so the payment pauses either way.

How do I check it programmatically?

One call. GET /api/v1/company/{org}/verify reduces the registry signals to a single verification_status of pass, warn, fail or unknown, and keeps the individual signals visible beside it. A deleted company is no longer active, so the verdict is fail, with is_active false pointing at why. The business status guide covers the full verdict model.

The road states arrive through the same call: liquidation in either form also means the company is not active, and the raw distress flags on the company context tell you which road it is on. Bankruptcy, the other distress state worth its own reading, is owned by the bankruptcy check guide. And when the data cannot support an answer, the verdict says unknown rather than guessing: give unknown its own branch in your code, because folding it into pass converts missing evidence into a payment.

Make the first call

The sandbox request returns the full verify shape on synthetic data with no key. The TypeScript sample runs the live check and branches on the verdict, with unknown routed to a manual check instead of being treated as a pass.

# Zero-auth sandbox: the full verify verdict for a synthetic company.
curl -s https://www.apier.no/api/v1/sandbox/public/company/999999999/verify

// One verification call answers the deletion question directly.
const res = await fetch(
  "https://www.apier.no/api/v1/company/999999999/verify",
  { headers: { Authorization: `Bearer ${process.env.APIER_API_KEY}` } },
);

if (!res.ok) {
  const { error_code, explanation } = await res.json();
  throw new Error(`${error_code}: ${explanation.summary}`);
}

const { data } = await res.json();
// A deleted company is no longer active, so the verdict is fail.
// Route unknown to its own branch: missing evidence is not a pass.
switch (data.verification_status) {
  case "pass":
    console.log("registered and active");
    break;
  case "unknown":
    console.log("could not determine, check manually before paying");
    break;
  default:
    console.log("do not pay:", data.verification_status,
      "active:", data.signals.is_active);
}

Frequently asked questions

Can a deleted company be restored?

Treat deleted as final in any automated flow. The register keeps the historical record, but whether an entity can come back on the register depends on why it was struck off, and that is a question for Brønnøysundregistrene rather than for an integration to guess at. Design the pipeline so a deleted counterparty routes to a human instead of to a retry. If a supplier claims to have been restored, run the verification call again and believe the register, not the claim.

Does the organisation number get reused for a new company?

The register's design keeps the number tied to the historical entity: the record, its name and its history stay queryable after deletion, which is exactly what makes a programmatic check meaningful years later. So do not treat a deleted number as a vacant slot that some new business now legitimately occupies. If an invoice carries a number whose record says deleted, the mismatch itself is the signal, and the resolution is to identify a live entity, never to assume the number moved on.

What is the difference between slettet and konkurs?

Konkurs is a distress state: the company still exists as a legal entity while insolvency proceedings run, and there is an estate and a claims process to deal with. Slettet is terminal: the entity is gone from the living register, and only the history remains. The status derivation reflects that ordering by checking the slettedato before the bankruptcy flag, so a company that is both reports deleted. Practically, a bankrupt counterparty is a claims process; a deleted one is nobody.

Why did I still get an invoice from a deleted company?

Two explanations, one innocent and one not. The innocent one is stale master data: the supplier restructured or wound down, and someone's billing system kept issuing under the old identity. The other is fraud: a deleted registration has a real name and a real history, which makes it attractive cover for invoices nobody is entitled to send. Either way the payment stops until a live entity is identified: re-verify the number and contact the supplier through a channel you already trust.

What does under avvikling mean for an open order?

The company still exists and is winding itself down by its own decision, settling obligations as it goes. An existing order can complete, but treat the state as a caution flag for anything new: do not extend fresh credit or prepay against future delivery without checking where the liquidation stands. The state is visible in the register before any slettedato lands, so a check that runs at invoice time rather than only at onboarding sees the slide coming.