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 på 27 MNOK; 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 Apier leverer — ni 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. Én Bearer API-nøkkel per byrå; rå OAuth-tokens forlater aldri gateway-et. Autoritet per klient avledes fra Altinn-delegeringer ved forespørselstidspunkt.
• Registry Engine. Kanonisk selskapstilstand avstemt på tvers av Brønnøysund (Tier 1) + Skatteetaten (MVA-register, MVA-meldinger, skatteoppgjør) + NAV (Aa-registeret-aggregater) + Altinn (delegeringer). É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 dry-run + live-innsending-rør (mva_melding, a_melding, skattemelding). Valideringsporter kjøres før hvert oppstrøms-kall; live-innsending krever 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.
• Sector Rules. Bransje-spesifikke obligasjonsoverlegg (regnskapsbyråstatsautorisasjon, fiskeri salgslagsgebyr, bygg HMS-kort, kraftleverandør NVE-rapportering) lagt oppå universal-regelboken for NACE-kodede foretak — relevant når porteføljen spenner flere bransjer.

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 hele Apier-verktøyflaten inne i assistenten. Samme auth, samme avgrensninger per klient, samme determinisme-kontrakt som REST-flaten. Se /use-cases/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 obligasjonene 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 obligasjonsavgjørelser per klient, fristberegninger, Altinn 3-delegeringer og sentralt megling av Maskinporten på tvers av hele klientporteføljen. De kjører sammen med Apier, ikke i stedet for. Apier dekker porteføljeoperasjonene på tvers av klienter som programvaren for ett firma ikke ble designet for.

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

Ja. Hver klient gir byrået en Altinn 3 systembruker-delegering (et engangsskritt på klientsiden, vanligvis utført av innehaver eller daglig leder). Apier megler Maskinporten sentralt på din konto — ett virksomhetssertifikat, én Maskinporten-klient, N klient-delegeringer. Tilgangspakkene per klient bestemmer hvilke Apier-endepunkter staben kan kalle for den klienten; 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: ingenting — integrasjonen ser klienten ved neste forespørsel det øyeblikket delegeringen er aktiv. Ingen separat Apier-side-onboarding, ingen sjonglering av API-nøkler per klient.

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 — for tiden 27 MNOK omsetning ELLER 27 MNOK eiendeler ELLER 50 ansatte). 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 skjer for klientene våre 19. juni 2026 når Altinn 2 legges ned?

DigDir avvikler Altinn 2 19. juni 2026. Hver eksisterende klient-delegering som peker på Altinn 2-roller slutter å 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 /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.