Bruksområde

Norsk compliance-infrastruktur for regnskapsbyrå

Maskinporten, Altinn 3 og Brønnøysund — uten at byrået bygger integrasjonen på nytt for hver klient.

Det som skalerer lineært med porteføljen

Å drive et regnskapsbyrå med flere klienter eksponerer tre operasjonelle flater som regnskapsprogramvaren for ett firma ikke ble designet for:

• Delegerings-administrasjon per klient. Hver nye klientavtale starter med at klienten gir byrået en Altinn 3 systembruker-delegering — og denne seremonien gjentas ved hver ansatt-endring hos klienten (innehaver eller daglig leder som slutter ugyldiggjør delegeringen), hver utvidelse av tilgangspakker (ny tjenestelinje krever nye pakker), og hver fornyelse. Multipliser med N klienter og driftskostnaden blir betydelig.
• Tverrgående tilstandsavstemming per klient. Hver klients regulatoriske tilstand ligger spredt over Brønnøysund (signaturrett, prokura, NACE, oppløst status), Skatteetaten (MVA-register, MVA-meldinger, skatteoppgjør), Nav (Aa-registeret som mater verneombud- og HMS-grenser) og Altinn 3 (hvilke delegeringer som er aktive, hvilke tilgangspakker de dekker). I dag avstemmer byrå-ansatte dette manuelt per klient — én kanonisk visning per klient er det et kompetent porteføljedashbord faktisk trenger.
• Kvartalsvis regulatorisk drift, ganget med porteføljestørrelsen. Stortinget oppdaterer terskler (Aksjeloven § 7-6revisor-grense: 7 MNOK omsetning / 27 MNOK eiendeler / 10 årsverk; verneombud ved 50 ansatte), innsendingskadens (MVA bimånedlig standard; årlig under småbedriftsterskelen), og regler per organisasjonsform (AS, ENK og NUF har ulik behandling for skatt, lønn og revisjon). Å holde seg oppdatert på tvers av N klienter er en researchbyrde som skalerer lineært med porteføljen.

Det tekniske svaret på alle tre er det samme, og Hvordan automatiserer jeg norske regeletterlevelsesoppgaver? dekker det fra ende til ende: hva regelboken vurderer, hvordan fristene utledes, og hvor et menneske fortsatt må signere.

Selve delegeringshalvdelen, hvor klienttilgangen oppstår i Enhetsregisteret og hvordan ett system autoriseres per klient, dekkes i Hvordan fungerer klientdelegering for regnskapsførere og revisorer i Altinn 3?

Det Apier leverer — åtte infrastruktur-komponenter

Hver komponent er tilgjengelig som REST, som MCP, eller begge. Staben og AI-assistenter byrået bruker ser samme avgjørelse; determinisme-kontrakten holder på tvers av flater.

• Auth Gateway. Maskinporten JWT client-assertion + token-mellomlagring + Altinn 3 systembruker-delegerings-flyt — bygget og testklient-verifisert, men ennå ikke i produksjon mot Maskinporten og Altinn (produksjonsvalidering pågår; se /docs/capability-status). Én Bearer API-nøkkel per byrå; rå OAuth-tokens forlater aldri gateway-et.
• Registry Engine. Kanonisk selskapstilstand avstemt på tvers av Brønnøysund (Tier 1, inkludert MVA-registreringsstatus) + Altinn (delegeringer) i dag; Skatteetaten-delene (MVA-meldinger, skatteoppgjør) og Nav (Aa-registeret-aggregater) er bygget, men ikke live — Skatteetatens lesescope er enten avslått eller fortsatt til behandling, og Navs er ennå ikke søkt om. Én kanonisk visning per klient, klar for porteføljedashbordet ditt.
• Universal Rulebook. Versjonerte regulatoriske regler med legal_reference-siteringer (Aksjeloven § 7-6, MVA-forskriften, A-opplysningsloven § 3, Bokføringsloven § 13). Deterministisk evaluering; samme inndata + rulebook_version gir byte-identisk utdata, så revisjonssporet per klient er reproduserbart.
• Deadline Engine. MVA-terminer, A-melding-kadens, skattemelding, årsregnskap og revisor-grense-kontrollpunkter — kalender-matematikk i Europe/Oslo med full DST-bevissthet og helg- og helligdags-justeringer innebakt. Kjør nattlig over klientporteføljen for å løfte fram forfall som nærmer seg.
• MCP Server. Hvert verktøy over er eksponert via Model Context Protocol på /api/mcp. Live som @apier-no/mcp på npm — se kodeblokken under. Samme auth, samme avgrensninger, samme determinisme-kontrakt som REST-integrasjonen.
• Intent-to-Action Parser. Innsending-forespørsler oversettes til strukturerte valideringsrør (mva_melding, a_melding). I dag kjører flaten kun dry-run-validering — ingen reell innsending går til myndighetene; live-innsending er bygget, men venter på Maskinporten-produksjonsvalidering og Altinn-scope-godkjenning (se /docs/capability-status). Når den aktiveres, krever live-innsending en engangs-godkjenningstoken, så porteføljebred automatisering omgår aldri en menneskelig kontrollport.
• AI-Agent Discovery. llms.txt, llms-full.txt, workflows.json, /api/v1/capabilities, /.well-known/mcp.json, /.well-known/ai-plugin.json — alle maskin-oppdagelses-flater fylt ut og stabile slik at ethvert AI-verktøy byrået innfører kan introspektere Apier ved konfigurasjonstid.
• Compliance Explainer. Hver Apier error_code oversettes til et norsk-bokmål Explanation-objekt (summary / why / fix_steps / legal_basis / handover) via POST /api/v1/explain. Staben ser en forsvarbar legal_basis når en klient spør hvorfor en innlevering feilet.

MCP-server — for AI-assistentene staben bruker

Hvis byrået bruker Claude Desktop, Cursor eller en annen MCP-kompatibel AI-assistent, lyser @apier-no/mcp opp Apiers MCP-verktøy inne i assistenten. Samme auth, samme avgrensninger per klient og samme determinisme-kontrakt — og hvert MCP-verktøy har en REST-motpart. Se /no/altinn-for-ai-agents for utviklerrettet detalj (engelsk).

Claude Desktop / Cursor-konfig

{
  "mcpServers": {
    "apier": {
      "command": "npx",
      "args": ["-y", "@apier-no/mcp"],
      "env": { "APIER_API_KEY": "apier_live_<your_key>" }
    }
  }
}

Kildekode og issues: github.com/PowerLaunch/apier-mcp. Pakkeside: npmjs.com/package/@apier-no/mcp.

Slik ser et kall ut

Én Bearer API-nøkkel per byrå; autoriteten per klient kommer fra hver klients aktive Altinn 3 systembruker-delegering.

REST — curl mot obligations-endepunktet

# Hent forpliktelsene for ett selskap (org.nr 991825827)
curl -H "Authorization: Bearer apier_live_<your_key>" \
  "https://www.apier.no/api/v1/company/991825827/obligations"

Dry-run uten autentisering mot syntetiske data: curl https://www.apier.no/api/v1/sandbox/public/company/999999999/obligations.

FAQ

Hva skiller Apier fra Tripletex, Fiken, PowerOffice eller Conta?

Det er regnskapsplattformer — staben fører bokføring og plattformen genererer innleveringer for ett selskap om gangen. Apier er det regulatoriske infrastruktur-laget under: én API som eksponerer forpliktelsesavgjørelser per klient, fristberegninger og Brønnøysund-baserte selskapsdata på tvers av hele klientporteføljen. Altinn 3-delegeringsflyten og sentral Maskinporten-megling er bygget og under produksjonsvalidering — se /docs/capability-status for gjeldende status. De kjører sammen med Apier, ikke i stedet for.

Kan staben handle på vegne av hver klient gjennom én Apier-konto?

Det er modellen Apier er bygget for: hver klient gir byrået en Altinn 3 systembruker-delegering (et engangsskritt på klientsiden, vanligvis utført av innehaver eller daglig leder), og Apier megler Maskinporten sentralt — ett virksomhetssertifikat, én Maskinporten-klient, N klient-delegeringer. Delegerings- og Maskinporten-flyten er bygget, men er fortsatt under produksjonsvalidering mot Altinn og Maskinporten — se /docs/capability-status for gjeldende status. Utløpte eller tilbakekalte delegeringer feiler lukket i gateway-et.

Hva er enkleste måten å onboarde en ny regnskapsbyrå-klient?

Klientsiden: innehaver eller daglig leder gir kontoen din en systembruker-delegering i Altinn 3, avgrenset til de tilgangspakkene arbeidet ditt krever (regnskap, lønn, MVA-rapportering, skatt — velg minimum nødvendig). Flyten tar omtrent fem minutter. Apier-siden er designet slik at integrasjonen ser klienten ved neste forespørsel når delegeringen er aktiv — ingen separat Apier-side-onboarding, ingen sjonglering av API-nøkler per klient. Delegeringsflyten er fortsatt under produksjonsvalidering; se /docs/capability-status.

Hvordan håndterer Apier revisor-grensesjekken på tvers av klientporteføljen vår?

GET /api/v1/company/{org_number}/obligations returnerer en avgjørelse som inkluderer revisor_required: true|false pluss legal_reference (Aksjeloven § 7-6,revisjonsgrense-regelen for AS-foretak — fritak krever at ALLE tre er oppfylt samtidig: under 7 MNOK omsetning OG under 27 MNOK eiendeler OG under 10 årsverk). Avgjørelsen har et explanation-felt slik at staben kan forsvare vurderingen overfor klienten. Kjør den nattlig over hele porteføljen; terskel-passeringer sender ut /api/v1/changes-hendelser du kan abonnere på og vise i den interne gjennomgangskøen.

Hvordan fungerer MVA-termin-kadensen — bimånedlig vs årlig, og hva med A-melding?

GET /api/v1/company/{org_number}/deadlines returnerer neste forfallsdato for hver innlevering i tidssonen Europe/Oslo med kadensen innebakt: MVAbimånedlig standard (Termin 1 jan-feb forfaller 10. april osv.), årlig for klienter under småbedriftsterskelen som har valgt det, og spesialtilfellene i Skatteforvaltningsloven. A-melding (månedlig arbeidsgiveroppgave) ligger på samme flate. DST-bevisst, helg- og helligdagsjustert, hver frist bærer legal_reference for revisjonssporet.

Hva skjedde for klientene våre 19. juni 2026 da Altinn 2 ble avviklet?

DigDir avviklet Altinn 2 19. juni 2026. Hver eksisterende klient-delegering som peker på Altinn 2-roller sluttet å virke den dagen — det er ingen automatisk overføring til Altinn 3-tilgangspakker. Hver klient må gi en fersk Altinn 3 systembruker-delegering. Apier eksponerer Altinn 2-rolle → Altinn 3-tilgangspakke-mappingen som et oppslags-endepunkt uten autentisering på /api/v1/tools/altinn-migration. Se /no/altinn3-overgang for fristen, mappingslogikken og forbeholdet om at én Altinn 2-rolle ofte deles på tvers av flere Altinn 3-pakker (eller omvendt).

Kom i gang

Gratis-nivået kommer med én API-nøkkel og nok kvote til å onboarde de første klientene. REST-flaten kan curl-es fra hvor som helst; MCP-serveren er én npx unna hvis byrået bruker MCP-kompatible AI-assistenter.