What do the company roles in Brønnøysundregistrene mean?

Which role codes does the register use?

The open register organises roles into groups, and the codes are stable identifiers you can match on. The board group is STYR, and inside it sit five role types: LEDE for the styreleder who chairs the board, NEST for the nestleder who deputises, MEDL for an ordinary styremedlem, VARA for a varamedlem who steps in when a member is absent, and OBS for an observatør who attends without voting. Outside the board sit DAGL, the daglig leder, and INNH, the innehaver, a group that only appears on an enkeltpersonforetak. Two further codes, REGN for a regnskapsfører and REVI for a revisor, mark registered professional connections rather than positions inside the company.

The table reads each code the way an integration should: what the register means by it, and whether it carries authority to act. The second column is the one agents get wrong. This page enumerates only codes the register actually uses; if a payload hands you something outside this set, treat it as data to look up, not to guess.

Which roles carry real authority, and which are membership?

DAGL is the operational role: the daglig leder runs the company day to day, and that is the authority the code records. For a company as such, the default under aksjeloven is that the board acts for it, and the board acts jointly: a seat on it is membership in a collective, not a personal right to bind the company. Chairing the board changes who runs the meeting, not who may sign alone. The full signing question, including how joint rules are written, belongs to the signing authority guide.

The remaining board codes carry even less. A varamedlem is registered so the board can stay quorate when an ordinary member is absent, and an observatør attends without voting: neither holds standing authority through the registration itself. REGN and REVI sit outside the company altogether. They are valuable signals about who keeps the books and who audits, but a connection is not a mandate, and an agent that treats a registered accountant as an actor for the company has misread the register. Acting on a client's behalf runs through explicit Altinn delegation instead.

Why are signaturrett and prokura not role codes?

Because they are registered in a different place. The open roller vocabulary contains no SIGN group and no PROK group: signaturrett and prokura texts are Foretaksregisteret data, held on a tier the open role feed does not expose. That is a structural fact about the register, not a missing field in one response, and it means role data alone can never answer who may sign. The two concepts themselves, general authority to bind the company versus day-to-day authority that excludes selling or mortgaging real property, are drawn out in the prokura versus signaturrett guide.

The honest consequence is a tri-state answer. When the open register cannot see signing rights, Apier reports them as unknown rather than returning an empty list, because an empty list would be a false claim that nobody holds them. The one case where a role code closes the question is the ENK: the innehaver personally carries the enterprise's rights and always holds signaturrett alone, and the delegable authority an ENK can grant is prokura under prokuraloven. INNH is therefore the only code that doubles as a signing answer.

How do I read the roles programmatically?

One call returns the registry context for a company: GET /api/v1/company/{org}/context gives you the name, entity type, status and the representation fields, with the innehaver set populated for an ENK and signaturrett and prokura reported as unknown whenever the open tier cannot answer. The general mechanics of the registry surface, including keys and rate limits, are covered by the registry access guide.

Read the two empty shapes differently. Unknown means the question could not be answered: the source was unread or the tier cannot see it. An empty list from an authoritative read means the register really has nothing there, the way a company without a registered board genuinely has no STYR rows. Code that collapses both into one falsy value will eventually tell a caller that a company has no board when the truth was that nobody asked, and that distinction is the difference between an honest integration and a guessing one.

Make the first call

The curl hits the zero-auth sandbox mirror and returns a full simulated company context, so you can see the shape of every field without a key; sandbox data is synthetic by design. The TypeScript sample makes the live call and prints the representation fields this guide describes, unknowns included.

# Zero-auth sandbox mirror: a full simulated company context, no key.
# Sandbox data is synthetic, so every field arrives populated.
curl -s https://www.apier.no/api/v1/sandbox/public/company/999999999/context

// Live registry context for one company, with one Apier key.
const res = await fetch(
  "https://www.apier.no/api/v1/company/999999999/context",
  {
    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();
console.log(data.name, data.entity_type, data.status);

// Honesty boundary in practice: on the open tier these are reported
// as unknown when the register cannot answer, never guessed.
console.log("signaturrett:", data.signaturrett);
console.log("prokura:", data.prokura);

Frequently asked questions

Which role code can sign for the company?

None of them, by code alone. The open role vocabulary describes positions: who chairs the board, who runs daily operations, who owns a sole proprietorship. Signing authority is a separate registration in Foretaksregisteret, and it has no group in the open roller data at all. The one place role and authority coincide is the INNH code on an enkeltpersonforetak, because the innehaver personally carries the enterprise's rights and always holds signaturrett alone. For every other entity type, answer the signing question from signaturrett and prokura data, not from role codes.

What is the difference between MEDL and VARA?

MEDL is an ordinary board member: a full seat, a vote, and a share in the board's joint authority to act for the company. VARA is a varamedlem, a deputy who is registered so the board stays quorate when an ordinary member is absent, and who carries no standing authority of their own while merely registered. An integration that counts board strength should count MEDL seats together with LEDE and NEST, and treat VARA rows as reserve capacity rather than as acting members.

What does INNH mean on a Norwegian company?

INNH is the innehaver group, and it only appears on an enkeltpersonforetak (ENK). A sole proprietorship is not a separate legal person: the innehaver personally carries the enterprise's rights and obligations, represents it outward, and always holds signaturrett alone, which cannot be reassigned to anyone else. The delegable authority an ENK can grant is prokura, under prokuraloven. So when you see INNH, you are looking at the one role code that is also a complete answer to who signs.

Are accountant and auditor connections public data?

Yes. REGN (regnskapsfører) and REVI (revisor) are registered connections that appear in open registry data, and they are useful signals: they tell you which accounting firm keeps the books and which auditor is engaged. What they are not is authority. A registered accountant or auditor holds no standing right to act for the company through that registration alone; acting on a client's behalf runs through explicit Altinn delegation, which is a separate mechanism from the registry connection.

Why does the open roles feed not show signaturrett?

Because the open Enhetsregisteret roller vocabulary has no SIGN or PROK group: signaturrett and prokura texts are Foretaksregisteret data, exposed on a different tier. That absence is structural, not a gap in any one response. It also dictates honest API behaviour: an open-tier answer about signing rights is unknown, never an empty array, because an empty array would falsely claim that nobody holds signing authority. Apier reports these fields as unknown when the register cannot answer, and populates them only from a source that actually can.