Kan jeg finne ut hvilke plikter et norsk selskap har uten å spørre selskapet?

De fleste av dem, ja. Organisasjonsform, næringskoder, registreringsstatus og merverdiavgiftsregistrering er åpne registerfakta, og de fleste løpende rapporteringspliktene følger av disse pluss kalenderen. Det du ikke kan utlede av åpne data, er alt som avhenger av tall selskapet ikke har publisert, for eksempel antall ansatte eller omsetningsterskler som flytter et selskap mellom rapporteringsfrekvenser.

Hva er forskjellen på tier_1- og tier_2-data?

Hvert pliktsvar bærer et data_tier-felt. tier_1 betyr at evalueringen bare brukte åpne registerfakta. tier_2 betyr at kalleren hadde en aktiv delegering fra selskapet, slik at evalueringen også kunne lese selskapsinterne felter. Et tier_1-svar er ikke et delvis svar, det er et fullstendig svar over et smalere sett med inndata, og svaret sier hvilke regler det ikke kunne nå.

Betyr automatisering av regeletterlevelse at programvaren avgjør hva loven sier?

Nei, og en løsning som fungerte slik ville vært vanskelig å forsvare. Reglene ligger i databasen som versjonerte data i stedet for i applikasjonskode, hvert svar bærer den rulebook_version det ble evaluert mot, og de samme inndataene mot samme versjon gir alltid samme resultat. Du får et reproduserbart svar du kan peke på, ikke en vurdering.

Hvordan vet jeg når en plikt endrer seg?

To signaler. rulebook_version på hvert svar flytter seg når en regel endres, så en klient som lagrer den kan oppdage at et tidligere svar ble produsert under andre regler. Separat returnerer GET /api/v1/changes endringsarkivet for register- og policykilder, filtrerbart på kilde og dato, slik at du kan polle etter bevegelse i stedet for å evaluere hvert selskap på nytt etter en fast plan.

Kan jeg automatisere selve innsendingen, ikke bare fristsporingen?

Delvis, i dag. Validering av nyttelast kjører mot det reelle regelsettet gjennom tørrkjøringsflaten, og sandkassen tar imot et fullstendig innsendingskall slik at du kan bygge og teste hele veien. Bindende innsending til et offentlig system er styrt bak en godkjenning og er ikke noe du kan lansere på ennå. Statussiden for funksjonalitet sier hvilken side av den grensen hvert endepunkt ligger på.

Hvordan automatiserer jeg norske regeletterlevelsesoppgaver?

Du beregner dem i stedet for å slå dem opp. De løpende pliktene til et norsk selskap følger av tre ting som alle er maskinlesbare: organisasjonsform og næringskoder i Brønnøysundregistrene, registrerings- og merverdiavgiftsstatus, og kalenderen. Mat disse inn i et versjonert regelsett, så får du pliktlisten og datoene den gir, med regelversjonen stemplet på svaret. Apier eksponerer den evalueringen som /api/v1/company/{org}/obligations og /deadlines, slik at det du automatiserer er reaksjonen på svaret framfor utledningen av det.

Tre av de fire inndataene er åpne registerdata, så mesteparten av kjeden kjører før noen kunde har gitt deg noe som helst. Den stiplede inngangen er den du må be om.

Hvilke innsendinger kan avgjøres fra registerdata alene?

Flere enn de fleste team venter. Enhetsregisterets oppføring for et selskap bærer organisasjonsform, NACE-næringskoder, registreringsdato, kommune, om selskapet er registrert for merverdiavgift, og om det er konkurs eller under avvikling. Disse feltene er åpne data. Til sammen avgjør de mesteparten av den løpende rapporteringskalenderen: om et selskap rapporterer ansatt- og inntektsopplysninger i det hele tatt, om merverdiavgiftsmeldinger gjelder, og hvilke årlige innsendinger organisasjonsformen forplikter det til.

Det er derfor det nøkkelløse endepunktet /api/v1/public/obligations tar en entity_type og ingenting annet. Spør det om et AS, og det returnerer pliktmalen for et norsk aksjeselskap, med den rettslige henvisningen knyttet til hver oppføring som et felt framfor som prosa du må tolke. Spør endepunktet per selskap i stedet, så får du den samme evalueringen kjørt mot ett organisasjonsnummer, slik at malen snevres inn til de pliktene selskapet faktisk har.

Det registerdata ikke kan avgjøre, er alt som er knyttet til et tall selskapet ikke har publisert. Terskler for rapporteringsfrekvens er det vanlige tilfellet: en regel som endrer oppførsel over en omsetnings- eller bemanningsgrense kan ikke evalueres fra en oppføring som ikke inneholder tallet. Svaret er tydelig på dette i stedet for å gjette, og det betyr mer enn dekningsgraden.

Hva trenger jeg en delegering for å se?

Alt som tilhører selskapet framfor det offentlige registeret. Hvert pliktsvar bærer et data_tier-felt med én av to verdier. tier_1 betyr at evalueringen kjørte på åpne registerfakta. tier_2 betyr at kalleren hadde en aktiv delegering fra selskapet, slik at evalueringen også kunne lese de utvidede feltene selskapet har gitt deg tilgang til. Svaret bærer også en upgrade_path, som er den maskinlesbare versjonen av «dette må til for å få mer».

Den viktige egenskapen er at et tier_1-svar er fullstendig, ikke avkortet. Det er en full evaluering over et smalere sett med inndata, og enhver regel det ikke kunne nå rapporteres som utilgjengelig framfor å bli stille utelatt eller satt til en troverdig standardverdi. En etterlevelseskalender bygget på tier_1 er korrekt om det den dekker. En delegering utvider dekningen; den retter ikke et tidligere svar som var galt.

Å komme til tier_2 betyr at selskapet gir det registrerte systemet ditt tilgang gjennom Altinn. Det er en beslutning bare selskapet kan ta, og ingen mengde infrastruktur fjerner den. Veiledningen om delegering til systembruker dekker hva tildelingen faktisk er, og hvordan du håndterer en som senere trekkes tilbake.

Hvordan holder jeg en fristkalender oppdatert?

Ikke lagre datoer som din egen fasit. En frist er utledet, så den flytter seg når noen av inndataene flytter seg: selskapets registerfakta endres, regelsettet oppdateres, eller den lovbestemte datoen faller på en helg eller en helligdag og forskyves. Lagre gjerne svaret, men lagre det sammen med den rulebook_version det ble produsert under, og behandle en versjonsendring som en grunn til å evaluere på nytt framfor som et kosmetisk felt.

Endepunktet /deadlines tar from_date og horizon_months, så en nattlig jobb som spør om de neste tolv månedene per selskap holder som regel for en kalendervisning. For endringsdeteksjon uten et fullt gjennomløp returnerer GET /api/v1/changes endringsarkivet på tvers av register- og policykilder med filtre på kilde, enhet og dato, og hver rad bærer feltstien som flyttet seg. Poll den, evaluer selskapene den nevner på nytt, og la resten være.

Én ting til er verdt å bygge inn tidlig. Lagre korrelasjons-IDen fra svarhodet sammen med det du selv skriver til dine egne poster. Hvert Apier-svar bærer X-Correlation-ID, og den samme verdien skrives til sporingsloggen bak kallet, slik at når noen om seks måneder spør hvorfor produktet ditt fortalte en kunde at en frist var på en bestemt dato, kan du rekonstruere nøyaktig den evalueringen i stedet for å gjenskape den fra hukommelsen. Det er billig å legge til i starten og tungvint å ettermontere.

Hva som avgjør om en løpende norsk innsending gjelder et gitt selskap, og hvilke av inndataene som er åpne registerdata.
Pliktområde	Hvem det gjelder	Hva som utløser den
Ansatt- og inntektsrapportering	Enhver enhet som utbetaler lønn eller annen rapporteringspliktig godtgjørelse, uansett organisasjonsform.	At det finnes rapporteringspliktig lønn i det hele tatt. Åpne registerdata sier at enheten finnes og hvilken form den har; om den utbetaler lønn nå er selskapets egen tilstand.
Merverdiavgiftsrapportering	Enheter registrert i Merverdiavgiftsregisteret.	Merverdiavgiftsregistrering, som er et åpent registerfelt. Rapporteringsfrekvensen kan i tillegg avhenge av omsetning, som ikke er åpen.
Årsregnskap	Organisasjonsformer med lovbestemt regnskapsplikt, særlig AS.	Organisasjonsform alene, som er åpne registerdata. Innsendingsvinduet følger regnskapsåret.
Årlig skattemelding	Gjelder på tvers av former, men skjemaet og fristen er ulik for et AS og et enkeltpersonforetak.	Organisasjonsform, som er åpen. Hvilke skjemaer som følger med kan avhenge av selskapsinterne tall.
Bransjespesifikk rapportering	Enheter der den registrerte aktiviteten faller inn under en regulert sektor.	NACE-koder, som er åpne registerdata, selv om det detaljerte pliktsettet varierer med tilsynsorgan.

Gjør det første kallet

Det første kallet trenger ingen nøkkel: det returnerer pliktmalen for et norsk aksjeselskap. TypeScript-utdraget er ekvivalenten per selskap, og feltet det er verdt å lese først i svaret er data_tier.

# Nøkkelløst: pliktmalen for et norsk AS.
curl -s "https://www.apier.no/api/v1/public/obligations?entity_type=AS"

// Evaluering per selskap. Én header, ett normalisert svar.
const res = await fetch(
  "https://www.apier.no/api/v1/company/999999999/obligations",
  { headers: { Authorization: `Bearer ${process.env.APIER_API_KEY}` } },
);

const { data, _meta } = await res.json();

// data_tier forteller om en delegering utvidet svaret.
console.log(data.entity_type, data.data_tier);
for (const obligation of data.obligations) {
  console.log(obligation.obligation_id, obligation.legal_reference);
}
console.log("evaluert mot regelverk", _meta.rulebook_version);

Ofte stilte spørsmål

Kan jeg finne ut hvilke plikter et norsk selskap har uten å spørre selskapet?: De fleste av dem, ja. Organisasjonsform, næringskoder, registreringsstatus og merverdiavgiftsregistrering er åpne registerfakta, og de fleste løpende rapporteringspliktene følger av disse pluss kalenderen. Det du ikke kan utlede av åpne data, er alt som avhenger av tall selskapet ikke har publisert, for eksempel antall ansatte eller omsetningsterskler som flytter et selskap mellom rapporteringsfrekvenser.
Hva er forskjellen på tier_1- og tier_2-data?: Hvert pliktsvar bærer et data_tier-felt. tier_1 betyr at evalueringen bare brukte åpne registerfakta. tier_2 betyr at kalleren hadde en aktiv delegering fra selskapet, slik at evalueringen også kunne lese selskapsinterne felter. Et tier_1-svar er ikke et delvis svar, det er et fullstendig svar over et smalere sett med inndata, og svaret sier hvilke regler det ikke kunne nå.
Betyr automatisering av regeletterlevelse at programvaren avgjør hva loven sier?: Nei, og en løsning som fungerte slik ville vært vanskelig å forsvare. Reglene ligger i databasen som versjonerte data i stedet for i applikasjonskode, hvert svar bærer den rulebook_version det ble evaluert mot, og de samme inndataene mot samme versjon gir alltid samme resultat. Du får et reproduserbart svar du kan peke på, ikke en vurdering.
Hvordan vet jeg når en plikt endrer seg?: To signaler. rulebook_version på hvert svar flytter seg når en regel endres, så en klient som lagrer den kan oppdage at et tidligere svar ble produsert under andre regler. Separat returnerer GET /api/v1/changes endringsarkivet for register- og policykilder, filtrerbart på kilde og dato, slik at du kan polle etter bevegelse i stedet for å evaluere hvert selskap på nytt etter en fast plan.
Kan jeg automatisere selve innsendingen, ikke bare fristsporingen?: Delvis, i dag. Validering av nyttelast kjører mot det reelle regelsettet gjennom tørrkjøringsflaten, og sandkassen tar imot et fullstendig innsendingskall slik at du kan bygge og teste hele veien. Bindende innsending til et offentlig system er styrt bak en godkjenning og er ikke noe du kan lansere på ennå. Statussiden for funksjonalitet sier hvilken side av den grensen hvert endepunkt ligger på.