Hvorfor får jeg 403 ved innsending av MVA-melding til Altinn?

Hvem har lov til å sende inn en MVA-melding i det hele tatt?

Skatteetaten dokumenterer kravet i form av tilgangspakker i Altinn. Å fylle ut og sende inn MVA-meldingen krever pakken Merverdiavgift, eller pakken for regnskapsfører med signeringsrettighet. Merverdiavgift-pakken tildeles automatisk til personer hvis registerroller forhåndstildeler den, som daglig leder og styreleder, og det er derfor innlevering bare virker for gründerne og feiler for alle som er ansatt etter dem.

Fellen i denne regelen er at flere pakker gir alt unntatt det siste steget. Pakkene for ansvarlig revisor, revisormedarbeider og regnskapsfører uten signeringsrettighet er dokumentert å gi utfylling, men ikke innsending. En person med en av dem opplever et system som godtar hver endring, validerer tallene, og så besvarer innsendingen med et avslag, noe som leses som en feil og faktisk er tilgangsmodellen som virker etter hensikten.

Å få den manglende pakken til riktig person er selv et myndighetsspørsmål. Fullmakter delegeres av noen med rett til å dele dem ut, dokumentert som daglig leder, styreleder, en tilgangsstyrer eller virksomhetens hovedadministrator. Løsningen på en kun-utfylling-403 er altså ikke en supportsak: det er at en av dem delegerer Merverdiavgift-pakken til innsenderen, eller at innsendingen flyttes til noen som allerede har den.

Hvorfor er delegeringen på plass og innsendingen likevel avvist?

Fordi delegeringen må stemme med meldingen langs tre akser samtidig: parten, æraen og tokenet. Partsaksen først. Autorisasjonen evalueres for den rapporterende parten på innsendingen, så det avgjørende er ikke at en delegering finnes, men at den navngir organisasjonen meldingen gjelder. Integratører observerer dette mest i oppsett med mange klienter, der alle leverer rent unntatt den ene hvis tildeling ble gjort for et søsterselskap, eller av en person hvis egen myndighet ikke dekket delegeringen de utførte.

Æraaksen er Altinn 2-grensen. De gamle rollene virker gjennom et overgangsvindu, og Skatteetaten dokumenterer at roller og delegering av roller i Altinn 2 fjernes ved inngangen til 2027, med noen gamle tildelinger som utgår tidligere og må delegeres på nytt. Et innleveringsoppsett som har virket i årevis, kan derfor slutte å autorisere uten at noen hos klienten har endret noe, og løsningen er en fersk delegering av den gjeldende tilgangspakken, ikke et forsøk på å gjenopprette den gamle rollen.

Tokenaksen er den stilleste. Den moderniserte MVA-løsningen kjører på Altinn 3, og 2022-scopet navngitt for MVA-melding-innsending er utgått til fordel for de gjeldende scopene for instanslesing og instansskriving. En klient som fortsatt utsteder token med det gamle scopet, kan ha en perfekt delegering og likevel bli avvist, fordi selve tokenet ikke lenger stemmer med det flaten forventer. Er integrasjonen din fra før endringen, koster det ett blikk i en konfigurasjonsfil å sjekke hvilke scopes token-forespørselen ber om.

Hvordan vet jeg før innsending at parten er autorisert?

Behandle innsendingen som siste punkt på en sjekkliste, ikke som første sonde i en. Alt 403-en ville fortalt deg, kan vites på forhånd: om selskapet bærer MVA-plikten i det hele tatt, hvem hos selskapet som kan opptre for det, om tildelingen integrasjonen din lener seg på navngir riktig part, og når innleveringen faktisk forfaller. En innleveringsløype som verifiserer dette i forkant, gjør autorisasjonsfeil om fra produksjonshendelser til onboarding-kontroller.

Denne førflygingen er delen Apier gjør, og den eneste delen Apier påberoper seg i denne flyten. Fullmakt-endepunktene svarer på hvem som kan opptre for et selskap, fra registeret; plikt-endepunktet evaluerer om selskapet bærer MVA-plikten for sin registreringstilstand; og fristflaten svarer på innen når, med kalenderjusteringene allerede gjort. Apier sender ikke inn MVA-meldinger: innsendingen blir i din innleveringskanal, og kontrollene som avgjør om den vil bli godtatt, flyttes foran den.

Tidshalvdelen av den førflygingen, hvilken termin selskapet står i, hvordan tomånedersterminene uttrykkes og hvorfor datoen som returneres kan avvike fra den lovfestede, eies av veiledningen om fristberegning. Denne siden forblir det den er: kartet fra en autorisasjonsavvisning ved innlevering tilbake til kontrollen som ville forutsagt den.

Gjør det første kallet

Sandkassekallet returnerer pliktsettet for et selskap uten nøkkel. TypeScript-eksempelet kjører den samme førflygingen mot produksjonsflaten og leser MVA-reglene og evalueringsresultatene deres før noe leveres noe sted.

# Nøkkelløs sandkasse: pliktsettet for et selskap, fra regelverket.
curl -s https://www.apier.no/api/v1/sandbox/public/company/999999999/obligations

// Førflyging: bærer dette selskapet faktisk MVA-plikten,
// før noe sendes inn noe sted.
const res = await fetch(
  "https://www.apier.no/api/v1/company/999999999/obligations",
  { 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();
// MVA-reglene, med evalueringsresultatet per regel.
const mva = data.obligations.filter((o) => o.rule_id.startsWith("MVA"));
for (const o of mva) {
  console.log(o.obligation_name, o.evaluation_result, o.deadline_rule);
}

Ofte stilte spørsmål

Hvilken tilgangspakke krever MVA-meldingen i Altinn?

Innsending krever tilgangspakken Merverdiavgift eller pakken for regnskapsfører med signeringsrettighet. Merverdiavgift-pakken tildeles automatisk til forhåndstildelte registerroller som daglig leder og styreleder; alle andre må få den delegert. Revisorpakkene og pakken for regnskapsfører uten signeringsrettighet gir rett til å fylle ut meldingen, men ikke til å sende den inn.

Hvorfor kan jeg fylle ut meldingen, men ikke sende den inn?

Fordi utfylling og innsending er skilt med vilje. Flere pakker, blant dem ansvarlig revisor, revisormedarbeider og regnskapsfører uten signeringsrettighet, er dokumentert å gi kun utfylling. Har du en av dem hos klienten, godtar systemet hver endring og avviser så innsendingen, og løsningen er en delegering av Merverdiavgift-pakken eller at noen med signeringsrettighet sender inn.

Delegeringen finnes. Hvorfor avvises akkurat denne klienten?

Sjekk hvilken part delegeringen navngir. Autorisasjonen evalueres for den rapporterende parten på innsendingen, så det avgjørende er ikke om en delegering finnes, men om den gjelder organisasjonen meldingen handler om. Integratører observerer nettopp denne formen i oppsett med mange klienter: alle virker unntatt den ene der tildelingen aldri ble gjort, ble gjort av noen uten myndighet, eller ble gjort for et annet organisasjonsnummer i samme konsern.

Hvorfor virker innsendingen i test, men ikke i produksjon?

Test og produksjon er atskilte tillitsdomener med egne plattformverter, og ingenting følger med over: verken token, delegeringer eller testdata. En delegering satt opp i testmiljøet autoriserer ingenting i produksjon, og et token utstedt mot testmiljøet stryker i valideringen i produksjon. Etabler hele kjeden på nytt, pakke og delegering inkludert, i miljøet du faktisk sender inn til.

Sender Apier inn MVA-meldingen for meg?

Nei. Apiers rolle i denne flyten er førflygingen: fullmakt-endepunktene svarer på hvem som kan opptre for selskapet, plikt-endepunktet svarer på om selskapet i det hele tatt bærer MVA-plikten, og frist-endepunktet svarer på innen når. Å verifisere de tre før innlevering er det som fjerner autorisasjonsoverraskelsene; selve innsendingen skjer i din innleveringskanal, ikke gjennom Apier.