How do I check a Norwegian supplier before paying an invoice?

How does invoice fraud against Norwegian companies work?

The common shapes are identity tricks, not technical exploits. An invoice claims to come from a company that does not exist, or borrows the identity of one that does. A name is chosen to look almost identical to a supplier you already pay, with a different organisation number underneath. Or the entity is real but should never be paid: a company that went bankrupt or was deleted from the register months ago keeps a letterhead alive and keeps invoicing.

What these shapes share is that the registry can see them. A number that resolves nowhere, a status that says konkurs, a look-alike name attached to the wrong organisation number: each is a plain fact in Enhetsregisteret, readable before any payment is queued. The check costs one lookup and catches the fraud class that depends on you not looking.

Be honest about the limit. The other classic move is an altered account number on an otherwise genuine invoice, and no registry lookup can see the payment line of a document. Entity checks and account-side controls are separate layers, and this guide covers only the first. Nothing here is a guarantee of prevention; it is the layer that removes the cheap attacks.

What should I check before paying?

Four checks, in the order they eliminate risk. Existence first, because everything else is meaningless if the number resolves nowhere. Status second, because registered is not the same as active: a company under bankruptcy proceedings or liquidation is still in the register, and a deletion date wins over everything else in the status derivation.

Then the two context checks. If the invoice charges MVA, the supplier should appear in the VAT register, since registration is mandatory from NOK 50,000 in taxable turnover over a rolling twelve months; charged MVA from an unregistered company is a red flag worth a pause. And signing authority tells you whether the person behind the deal plausibly represents the company at all, with the honest caveat that the open data sometimes cannot see the arrangement: the answer is then unknown, never a claimed absence.

How do I run the whole check in one call?

One GET to the verify endpoint returns a single verification_status of pass, warn, fail or unknown, plus the per-check signals behind it: whether the company is active, the all-clear flags for bankruptcy and dissolution, VAT registration, and whether signing authority is visible. The response carries source metadata and a data freshness timestamp, so you can show where every fact came from and how old it is.

The verdict semantics are deliberately conservative. Fail means the company is not actively registered. Unknown means a consulted source could not see enough to decide, most often because the open role data does not show the signing arrangement, and it is a stop, not a soft pass: route the invoice to a human and check manually. Never auto-approve an unknown, because the whole point of the verdict is that silence from the register is not evidence of anything.

How do I wire this into an accounts payable flow?

Check twice at minimum: once when the supplier is onboarded, and again immediately before the first payment. The two moments can be weeks apart, and registry data moves in between; a company can enter bankruptcy proceedings after the contract is signed and before the first invoice is due. The onboarding check validates the relationship, the pre-payment check validates the money movement, and neither substitutes for the other.

For an ongoing supplier base, polling every company before every run is wasteful. The better shape is to follow registry changes as a feed and re-verify only suppliers that actually changed, holding their invoices until a fresh verdict lands. Store the verdict and its timestamp next to the supplier record, so every release decision is traceable to a named check at a named time.

Make the first call

The sandbox call returns the same verdict shape with no key, on simulated data, so you can build the hold-or-pay branch first. The TypeScript sample runs the live check with an API key and acts on the verdict field the way a payment run should: pass releases, everything else holds.

# Zero-auth sandbox: the same verify verdict, on simulated data.
curl -s https://www.apier.no/api/v1/sandbox/public/company/999999999/verify

// Live verify: one GET, one verdict, before the payment run.
const res = await fetch(
  "https://www.apier.no/api/v1/company/999999999/verify",
  {
    headers: {
      Authorization: `Bearer ${process.env.APIER_API_KEY}`,
    },
  },
);

if (!res.ok) {
  // Every non-2xx answers the same structured envelope.
  const { error_code, explanation } = await res.json();
  throw new Error(`${error_code}: ${explanation.summary}`);
}

const { data } = await res.json();
// Act on the verdict field, never on one signal in isolation:
// pass -> release the payment as planned,
// warn or fail -> hold the invoice for human review,
// unknown -> stop and check manually. Never auto-approve unknown.
switch (data.verification_status) {
  case "pass":
    console.log("clear to pay:", data.summary);
    break;
  default:
    console.log("hold:", data.verification_status, data.signals);
}

Frequently asked questions

What is the fastest single check before paying an invoice?

Resolve the organisation number and read the status. One lookup answers whether the company exists at all and whether it is active rather than bankrupt, under liquidation or deleted, which screens out the crudest entity-level frauds: invented identities and invoices sent in the name of dead companies. Validate the digits first, since a number that fails its MOD-11 control digit is a typo, not a company. If you have room for exactly one API call, make it the verify call, which folds this and the other checks into a single verdict.

Does an active status guarantee the invoice is genuine?

No. Registry checks catch entity-level fraud: identities that do not resolve, companies that are bankrupt or deleted, and MVA charged by a company outside the VAT register. They cannot see the payment line on the invoice itself. A genuine-looking invoice from a real, active supplier can still carry an altered account number, and no registry lookup will notice that. Treat the verdict as one necessary layer and pair it with account-side controls, such as confirming a new or changed account number through a channel you already trust.

Should I re-check a supplier I already know?

Yes, because the registry facts behind your onboarding check do not stand still. A supplier that verified as active last quarter can since have entered bankruptcy proceedings or liquidation, and paying into an estate creates exactly the mess the check exists to prevent. The call is cheap and deterministic, so the practical pattern is to re-run it before the first payment to any new supplier and periodically for the rest, or to follow registry changes as a feed and re-verify only the companies that actually changed.

What does a warn verdict mean?

A caution between pass and fail: the company is actively registered, but a consulted source affirmatively reports no signing authority defined. For a payment flow, treat it like fail: hold the invoice and review. In practice today you will rarely see it, because the open role data cannot prove an arrangement absent, only fail to show it, and that honest gap arrives as unknown instead. The verdict enum keeps warn so a future source that can prove absence maps to a caution rather than a pass.

Is the check free, and does the supplier need to consent?

The underlying facts are open registry data from Brønnøysund, published for reuse, so no consent from the supplier is involved in reading them. You can call Enhetsregisteret yourself without a key. Apier's company endpoints, including verify, require an API key even on the free tier, because company data carries per-key rate limits and an audit trail; the sandbox mirror of the same verdict is keyless and returns simulated data, so you can wire the flow end to end before registering anything.