Hva betyr rollene i Brønnøysundregisteret?

Hvilke rollekoder bruker registeret?

Det åpne registeret organiserer roller i grupper, og kodene er stabile identifikatorer du kan matche på. Styregruppen heter STYR, og i den ligger fem rolletyper: LEDE for styrelederen som leder styret, NEST for nestlederen som er stedfortreder, MEDL for et ordinært styremedlem, VARA for et varamedlem som trer inn ved fravær, og OBS for en observatør som deltar uten stemmerett. Utenfor styret står DAGL, daglig leder, og INNH, innehaveren, en gruppe som bare finnes på et enkeltpersonforetak. To koder til, REGN for regnskapsfører og REVI for revisor, markerer registrerte profesjonelle tilknytninger og ikke posisjoner i selskapet.

Tabellen leser hver kode slik en integrasjon bør: hva registeret mener med den, og om den gir myndighet til å opptre. Den andre kolonnen er den agenter oftest tar feil av, så det er verdt å være direkte. Denne siden lister bare koder registeret faktisk bruker; møter du en kode utenfor dette settet, behandle den som data å slå opp, aldri som noe å gjette en betydning for.

Hvilke roller gir reell myndighet, og hvilke er bare verv?

DAGL er den operative rollen: daglig leder driver selskapet fra dag til dag, og det er den myndigheten koden noterer. For selskapet som sådan er utgangspunktet etter aksjeloven at styret opptrer for det, og styret opptrer i fellesskap: et sete der er medlemskap i et kollegium, ikke en personlig rett til å binde selskapet. Å lede styret endrer hvem som styrer møtet, ikke hvem som kan signere alene. Hele signeringsspørsmålet, medregnet hvordan fellesregler skrives, eies av veiledningen om signaturrett.

De øvrige styrekodene bærer enda mindre. Et varamedlem er registrert for at styret skal være vedtaksført ved fravær, og en observatør deltar uten stemmerett: ingen av dem har stående myndighet gjennom selve registreringen. REGN og REVI står helt utenfor selskapet. De er verdifulle signaler om hvem som fører bøkene og hvem som reviderer, men en tilknytning er ikke et mandat, og en agent som behandler en registrert regnskapsfører som en aktør for selskapet, har lest registeret feil. Å handle på vegne av en klient går i stedet gjennom uttrykkelig delegering i Altinn.

Hvorfor er ikke signaturrett og prokura rollekoder?

Fordi de registreres et annet sted. Det åpne rollevokabularet har ingen SIGN-gruppe og ingen PROK-gruppe: signaturrett- og prokuratekster er Foretaksregisteret-data, som ligger på en flate den åpne rollestrømmen ikke eksponerer. Det er et strukturelt faktum om registeret, ikke et manglende felt i ett svar, og det betyr at rolledata alene aldri kan svare på hvem som kan signere. Selve begrepsparet, generell rett til å binde selskapet mot daglig myndighet som ikke omfatter salg eller pantsettelse av fast eiendom, er tegnet opp i veiledningen om prokura og signaturrett.

Den ærlige konsekvensen er et trestatssvar. Når det åpne registeret ikke kan se signeringsrettighetene, rapporterer Apier dem som ukjent i stedet for å returnere en tom liste, fordi en tom liste ville vært en falsk påstand om at ingen har dem. Det ene tilfellet der en rollekode lukker spørsmålet, er enkeltpersonforetaket: innehaveren bærer personlig foretakets rettigheter og har alltid signaturrett alene, og myndigheten et ENK kan delegere, er prokura etter prokuraloven. INNH er dermed den eneste koden som samtidig er et signeringssvar.

Hvordan leser jeg rollene programmatisk?

Ett kall returnerer registerkonteksten for et selskap: GET /api/v1/company/{org}/context gir deg navn, organisasjonsform, status og representasjonsfeltene, med innehaver-settet utfylt for et ENK og signaturrett og prokura rapportert som ukjent når den åpne flaten ikke kan svare. Den generelle mekanikken rundt registerflaten, medregnet nøkler og rategrenser, dekkes av veiledningen om Brønnøysund-API-et.

Les de to tomme formene forskjellig. Ukjent betyr at spørsmålet ikke kunne besvares: kilden ble ikke lest, eller flaten kan ikke se den. En tom liste fra en autoritativ lesing betyr at registeret faktisk ikke har noe der, slik et selskap uten registrert styre reelt mangler STYR-rader. Kode som slår begge sammen til én falsy-verdi, vil før eller senere fortelle en kaller at et selskap ikke har styre når sannheten var at ingen spurte, og det skillet er forskjellen på en ærlig integrasjon og en som gjetter.

Gjør det første kallet

Curl-kallet treffer det nøkkelløse sandkasse-speilet og returnerer en full simulert selskapskontekst, så du ser formen på hvert felt uten nøkkel; sandkassedata er syntetiske med hensikt. TypeScript-eksempelet gjør det levende kallet og skriver ut representasjonsfeltene denne veiledningen beskriver, medregnet det som er ukjent.

# Nøkkelløst sandkasse-speil: en full simulert selskapskontekst, uten nøkkel.
# Sandkassedata er syntetiske, så alle felter kommer utfylt.
curl -s https://www.apier.no/api/v1/sandbox/public/company/999999999/context

// Levende registerkontekst for ett selskap, med én Apier-nøkkel.
const res = await fetch(
  "https://www.apier.no/api/v1/company/999999999/context",
  {
    headers: {
      Authorization: `Bearer ${process.env.APIER_API_KEY}`,
    },
  },
);

if (!res.ok) {
  // Alle ikke-2xx-svar bruker den samme strukturerte konvolutten.
  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);

// Ærlighetsgrensen i praksis: på den åpne flaten rapporteres disse
// som ukjent når registeret ikke kan svare, aldri gjettet.
console.log("signaturrett:", data.signaturrett);
console.log("prokura:", data.prokura);

Ofte stilte spørsmål

Hvilken rollekode kan signere for selskapet?

Ingen av dem, ut fra koden alene. Det åpne rollevokabularet beskriver posisjoner: hvem som leder styret, hvem som driver daglig drift, hvem som eier et enkeltpersonforetak. Signaturrett er en egen registrering i Foretaksregisteret og har ingen gruppe i de åpne rolledataene i det hele tatt. Det ene stedet rolle og myndighet faller sammen, er INNH-koden på et enkeltpersonforetak, fordi innehaveren personlig bærer foretakets rettigheter og alltid har signaturrett alene. For alle andre organisasjonsformer må signeringsspørsmålet besvares fra signaturrett- og prokuradata, ikke fra rollekoder.

Hva er forskjellen på MEDL og VARA?

MEDL er et ordinært styremedlem: fullt sete, stemme, og en del av styrets felles myndighet til å opptre for selskapet. VARA er et varamedlem, en stedfortreder som er registrert for at styret skal være vedtaksført når et ordinært medlem er fraværende, og som ikke har noen stående myndighet bare i kraft av registreringen. En integrasjon som teller styrets størrelse, bør telle MEDL-seter sammen med LEDE og NEST, og behandle VARA-rader som reservekapasitet, ikke som aktive medlemmer.

Hva betyr INNH på et selskap?

INNH er innehaver-gruppen, og den finnes bare på et enkeltpersonforetak (ENK). Et enkeltpersonforetak er ikke et eget rettssubjekt: innehaveren bærer personlig foretakets rettigheter og forpliktelser, representerer det utad, og har alltid signaturrett alene, som ikke kan overføres til noen andre. Den myndigheten et ENK kan delegere, er prokura, etter prokuraloven. Ser du INNH, ser du altså den ene rollekoden som samtidig er et komplett svar på hvem som signerer.

Er regnskapsfører- og revisortilknytninger offentlige data?

Ja. REGN (regnskapsfører) og REVI (revisor) er registrerte tilknytninger som ligger i åpne registerdata, og de er nyttige signaler: de forteller hvilket regnskapsbyrå som fører bøkene og hvilken revisor som er engasjert. Det de ikke er, er myndighet. En registrert regnskapsfører eller revisor har ingen stående rett til å opptre for selskapet gjennom registreringen alene; å handle på vegne av en klient går gjennom uttrykkelig delegering i Altinn, som er en egen mekanisme adskilt fra registertilknytningen.

Hvorfor viser ikke den åpne rollestrømmen signaturrett?

Fordi det åpne rollevokabularet i Enhetsregisteret ikke har noen SIGN- eller PROK-gruppe: signaturrett- og prokuratekster er Foretaksregisteret-data, eksponert på en annen flate. Fraværet er strukturelt, ikke et hull i ett enkelt svar. Det styrer også ærlig API-atferd: et svar om signeringsrettigheter fra den åpne flaten er ukjent, aldri en tom liste, fordi en tom liste ville påstått at ingen har signaturrett. Apier rapporterer disse feltene som ukjent når registeret ikke kan svare, og fyller dem bare fra en kilde som faktisk kan.