How do software platforms calculate MVA and A-melding deadlines automatically?
They derive them rather than store them. A deadline follows from the entity type, whether the company is registered for the obligation, and the filing period. That gives a statutory date, which is then adjusted if it lands on a weekend or a Norwegian public holiday. Every timestamp is expressed in Europe/Oslo, so the UTC offset shown moves across the year and must never be hardcoded. Apier returns the adjusted date, the original one in adjusted_from, and the legal reference as a field.
How do weekends and public holidays shift a deadline?
The statutory date is the starting point, not the answer. When it falls on a Saturday, a Sunday or a Norwegian public holiday, the effective deadline moves, and the size of the move depends on how many non-working days it has to clear. The Norwegian holiday calendar includes movable feasts, so a date that was fine in one year can shift in the next without any rule changing. That is the part you do not want to be maintaining in application code.
The response makes the adjustment visible instead of hiding it. Where the endpoint returns a deadline that has moved, it also returns adjusted_from carrying the date it started as, and where nothing moved, that field is null. One of the entries the public deadline endpoint returns today shows this clearly: the sole proprietorship tax return for the 2025 income year comes back with a deadline of 1 June 2026 and an adjusted_from of 31 May 2026, because the original date was a Sunday.
Show both to your users when the pair exists. A customer who has read the rule and expects the end of May will otherwise think your product is wrong, and explaining the shift after the fact is a support conversation you can avoid entirely by rendering it up front.
What obligations differ between an AS and an ENK?
Enough that entity type is the first thing any deadline query needs. A limited company carries an annual accounting duty that a sole proprietorship does not, and the annual tax return differs in form and in date between the two. Some obligations apply to both, which is the case that catches people out: the same obligation name across two legal forms does not guarantee the same deadline.
Rather than encoding that in your own branching, read it off the response. Every deadline entry carries applies_to_entity_types, so filtering to the forms a company actually has is a comparison against a field. The zero-auth /api/v1/public/obligations endpoint takes an entity type directly and returns the template set for it, which is the fastest way to see the difference between an AS and an ENK side by side.
Registration status is the second input people forget. A company registered in the VAT register carries VAT reporting; one that is not, does not, and the same organisation can move between those states during a year. So an obligation set is a property of a company at a point in time rather than a property of its legal form alone, which is the argument for re-evaluating on a schedule instead of computing once at onboarding and storing the result.
| Filing | Period | Deadline as returned | Who it applies to |
|---|---|---|---|
| A-melding | One calendar month, reported the following month. | 5 January 2026 for the December 2025 period. | Every entity type in the set, where reportable payroll exists. |
| MVA-melding | Bimonthly terms, expressed as YYYY-Tn. | 10 April 2026 for the first term of 2026. | Entities registered in the VAT register. |
| Skattemelding (sole proprietorship) | One income year. | 1 June 2026 for the 2025 income year, adjusted from 31 May. | ENK. |
| Annual accounts | One financial year. | Derived from the financial year rather than a fixed calendar date. | Legal forms with a statutory accounting duty. |
How do I query Skatteetaten corporate income tax submission dates programmatically?
Through the same deadline surface as everything else, which is the point of having one. There is no separate corporate tax endpoint to learn: the zero-auth calendar endpoint takes an optional year and returns the recurring entries for it, and the per-company endpoint takes a from_date and a horizon_months and returns the window that applies to one organisation. Each entry carries its own legal reference as a field, so you can render the citation without maintaining a lookup table of your own.
One caution on caching. Cache the result if you want, but store the rule version alongside it, and treat a version change as a reason to re-evaluate rather than as a field to ignore. A deadline that was correct under one rule set is not evidence about the next one, and a stale date rendered confidently is worse for a user than a slow one.
A twelve-month horizon per company, refreshed nightly, is usually the right shape for a calendar view. If you want the narrower answer with the surrounding detail, the corporate tax return deadline guide covers that filing on its own, and the Skatteetaten obligations guide covers what else is reachable without a delegation.
Make the first call
The first request needs no key and returns the recurring calendar for a year. The second narrows it to one company and a window you choose. In both, read adjusted_from before you render a date.
# Zero-auth: the recurring deadline calendar for a year.
curl -s "https://www.apier.no/api/v1/public/deadlines?year=2026"// Per-company, forward-looking window.
const url = new URL(
"https://www.apier.no/api/v1/company/999999999/deadlines",
);
url.searchParams.set("from_date", "2026-01-01");
url.searchParams.set("horizon_months", "12");
const res = await fetch(url, {
headers: { Authorization: `Bearer ${process.env.APIER_API_KEY}` },
});
const { data } = await res.json();
for (const d of data.deadlines) {
// adjusted_from is null when the statutory date was already a
// working day, and the original date when it was moved.
console.log(d.obligation_name, d.deadline, d.adjusted_from, d.timezone);
}Frequently asked questions
- How are Norwegian filing deadlines calculated?
- From four inputs: the entity type, whether it is registered for the obligation in question, the filing period, and the calendar. The rule set produces a statutory date, and a calendar step then moves that date if it falls on a weekend or a Norwegian public holiday. The response returns both the date you can act on and, in adjusted_from, the date it started as.
- Why does the timezone offset change between responses?
- Because Norway observes daylight saving time. A deadline in January carries a plus one hour offset and the same deadline in June carries plus two, and both are correct expressions of the same Europe/Oslo wall-clock time. This is why a client should never hardcode an offset: parse the timestamp with its offset, or read the explicit timezone field, and let a date library do the rest.
- What is the adjusted_from field for?
- It tells you the deadline moved and what it moved from. When the statutory date is already a working day, adjusted_from is null. When the date fell on a weekend or a holiday, adjusted_from carries the original and deadline carries the shifted one. Showing the pair to a user explains a date that would otherwise look wrong against their own reading of the rule.
- Do deadlines differ between an AS and an ENK?
- Yes, and the difference is not only in the dates. The obligations themselves differ by legal form, and where an obligation applies to both, the deadline and the form can still diverge. Every deadline entry carries applies_to_entity_types, so filtering by the company's entity type is a field comparison rather than something you have to encode in your own logic.
- Can I get corporate income tax submission dates programmatically?
- Yes. They come back from the same deadline surface as everything else, with the entity types they apply to and the legal reference attached as a field. The docs carry a dedicated walkthrough for the corporate tax return deadline if you want the narrower answer with the surrounding context.