Why does my MVA-melding submission to Altinn return 403?
Because the party submitting is not authorised to submit for the party being reported on, and that condition has four common shapes. The submitter lacks the required access package, most often holding a fill-in-only package where submission needs the Merverdiavgift package or accountant signing rights. The delegation exists but names a different reporting party than the one on the return. The token was minted with the wrong scopes, including the retired 2022-era submission scope where the current instance scopes are expected. Or the whole chain was established in the test environment and the submission is running against production. All four are checkable before you submit.
Who is allowed to submit an MVA-melding at all?
Skatteetaten documents the requirement in terms of Altinn access packages. Completing and submitting the VAT return requires the Merverdiavgift package, the one named Value added tax in English, or the package for accountants with signing rights. The Merverdiavgift package is assigned automatically to people whose registry roles pre-assign it, such as the managing director and the chair of the board, which is why filing simply works for founders and fails for everyone hired after them.
The trap inside this rule is that several packages allow everything except the last step. The responsible auditor, audit assistant and accountant-without-signing-rights packages are documented as allowing the return to be filled in but not submitted. A person holding one of those experiences a system that accepts every edit, validates the numbers, and then answers the submission with a rejection, which reads as a bug and is actually the permission model working as specified.
Getting the missing package to the right person is itself an authority question. Authorisations are delegated by someone entitled to hand them out, documented as the managing director, the chair of the board, an access manager or the main administrator of the business. So the fix for a fill-in-only 403 is not a support ticket: it is one of those people delegating the Merverdiavgift package to the submitter, or the submission moving to someone who already holds it.
Why is the delegation present and the submission still rejected?
Because the delegation has to match the return on three axes at once: the party, the era and the token. The party axis first. Authorisation is evaluated for the reporting party on the submission, so what matters is not whether a delegation exists but whether it names the organisation the return is about. Integrators observe this most in multi-client setups, where every client submits cleanly except the one whose grant was made for a sister company, or by a person whose own authority did not cover the delegation they performed.
The era axis is the Altinn 2 boundary. The old roles keep working through a transition window, and Skatteetaten documents that roles and delegation of roles in Altinn 2 are removed at the start of 2027, with some old grants lapsing earlier and needing to be delegated anew. A filing setup that has worked for years can therefore stop authorising without anyone at the client changing anything, and the fix is a fresh delegation of the current access package rather than an attempt to restore the old role.
The token axis is the quietest. The modernised MVA solution runs on Altinn 3, and the 2022-era scope named for MVA-melding submission is retired in favour of the current instance read and write scopes. A client still minting tokens with the old scope can hold a perfect delegation and still be rejected, because the token itself no longer matches what the surface expects. If your integration predates the change, checking which scopes your token request asks for costs one look at a config file.
| Symptom | Likely cause | Fix |
|---|---|---|
| Can fill in the return, 403 on submit | The submitter holds a fill-in-only package: auditor packages or accountant without signing rights. | Delegate the Merverdiavgift package, or have someone with signing rights submit. |
| One client rejected, the others fine (observed) | The delegation names a different reporting party, or was made by someone without the authority to make it. | Verify the delegation exists for that exact organisation number and was granted by an entitled person. |
| Valid delegation, token still rejected | The token asks for the retired 2022-era submission scope instead of the current instance scopes. | Update the token request to the current instance read and write scopes. |
| Works in test, fails in production | Test and production are separate trust domains; tokens and delegations do not carry across. | Re-establish the package, the delegation and the token chain in the production environment. |
| Worked for years, stopped this year | An Altinn 2 era grant lapsed in the transition; the old roles are being removed. | Delegate the current access package anew; do not try to restore the old role. |
How do I know before submitting that the acting party is authorised?
Treat the submission as the last step of a checklist rather than the first probe of one. Everything the 403 would tell you is knowable in advance: whether the company carries the MVA obligation at all, who at the company may act for it, whether the grant your integration relies on names the right party, and when the filing is actually due. A filing pipeline that verifies those up front turns authorisation failures from production incidents into onboarding checks.
This pre-flight is the part Apier does, and the only part it claims in this flow. The authority endpoints answer who may act for a company from the registry; the obligations endpoint evaluates whether the company carries the MVA obligation for its registration state; and the deadline surface answers by when, with the calendar adjustments already applied. Apier does not submit VAT returns: the submission stays in your filing channel, and the checks that decide whether it will be accepted move ahead of it.
The timing half of that pre-flight, which term the company is in, how the bimonthly terms are expressed and why the returned date can differ from the statutory one, is owned by the deadline calculation guide. This page stays what it is: the map from an authorisation rejection at filing time back to the check that would have predicted it.
Make the first call
The sandbox call returns the obligation set for a company with no key. The TypeScript sample runs the same pre-flight against the production surface, reading the MVA rules and their evaluation verdicts before anything is filed anywhere.
# Zero-auth sandbox: the obligation set for a company, from the rulebook.
curl -s https://www.apier.no/api/v1/sandbox/public/company/999999999/obligations// Pre-flight: is this company actually carrying the MVA obligation,
// before anything is submitted anywhere.
const res = await fetch(
"https://www.apier.no/api/v1/company/999999999/obligations",
{ headers: { Authorization: `Bearer ${process.env.APIER_API_KEY}` } },
);
if (!res.ok) {
// Every non-2xx answers the same structured envelope.
const { error_code, explanation } = await res.json();
throw new Error(`${error_code}: ${explanation.summary}`);
}
const { data } = await res.json();
// The MVA rules, with the evaluation verdict per rule.
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);
}Frequently asked questions
- Which Altinn access package does the MVA-melding require?
- Submitting requires the Merverdiavgift package (Value added tax) or the package for accountants with signing rights. The Merverdiavgift package is assigned automatically to pre-assigned registry roles such as the managing director and the chair of the board; everyone else needs it delegated. The auditor packages and the accountant-without-signing-rights package allow filling in the return but not submitting it.
- Why can I fill in the return but not submit it?
- Because filling in and submitting are separated by design. Several packages, including responsible auditor, audit assistant and accountant without signing rights, are documented as allowing completion only. If your role at the client is one of those, the return will accept every edit and then reject the submission, and the fix is a delegation of the Merverdiavgift package or submission by someone holding signing rights.
- The delegation exists. Why is this one client still rejected?
- Check which party the delegation names. Authorisation is evaluated for the reporting party on the submission, so a grant from one organisation says nothing about another. Integrators observe exactly this shape in multi-client setups: every client works except the one whose delegation was never actually made, was made by someone without authority, or was made for a different organisation number in the same group.
- Why does the submission work in test but fail in production?
- Test and production are separate trust domains with separate platform hosts, and nothing carries across: not tokens, not delegations, not test data. A delegation set up in the test environment authorises nothing in production, and a token minted against the test environment fails validation in production. Re-establish the full chain, package and delegation included, in the environment you are actually submitting to.
- Does Apier submit the MVA-melding for me?
- No. Apier's role in this flow is the pre-flight: the authority endpoints answer who may act for the company, the obligations endpoint answers whether the company carries the MVA obligation at all, and the deadlines endpoint answers by when. Verifying those three before filing is what removes the authorisation surprises; the submission itself happens in your filing channel, not through Apier.