How Apier models Norwegian regulatory obligations as versioned data — the rules, deadlines, and entity-type nuances an agent needs to reason correctly.

What this guide covers

This guide explains how Apier represents the regulatory obligations that apply to a Norwegian company — the legal duties around tax filings, payroll reporting, annual accounts, registration, and insurance. It covers the model an AI agent reads, the statutes each obligation cites, and the difference between obligation intelligence (what Apier provides today) and execution authority (which requires an Altinn System User — see the companion guide on Altinn 3 System Users). The factual content here is sourced strictly from the merged Rulebook seed in src/lib/supabase/migrations/011, 012, and the citation corrections in 014. Every Lovdata reference is tagged for native-speaker re-verification before any production decision.

What a regulatory obligation is

In Apier's data model, an obligation is a structured row in the rules table — not free-form prose, not LLM-generated summary. Each rule carries:

A stable rule_id (e.g. MVA_REGISTRATION_THRESHOLD).
A version number that increments when a citation or content field is corrected.
A list of conditions (field + operator + value, expressed as JSONB) that must all be true for the rule to fire.
A list of outcomes describing what obligation triggers, at what frequency, with which deadline rule and legal basis.
The entity_types the rule applies to — AS, ENK, NUF, ANS, or DA.
An is_active flag and a legal_reference_verified_at timestamp recording the last time a human checked the citation against Lovdata.

When an agent calls GET /api/v1/company/{org}/obligations, the evaluator reads the live rule set, applies each rule's conditions against the company's known facts, and returns one of three verdicts per rule: applicable (the company must comply), not_applicable (a condition rules it out), or insufficient_data (a Tier 2 field the agent does not have access to is needed before a verdict can be computed).

The Apier Rulebook approach

Apier stores rules as data, not as code. That choice has three consequences worth understanding:

Versioned, append-only history. Every change to a rule writes a new row in rule_versions (snapshot trigger from migration 010). The previous version stays present, marked inactive. An agent that asked Apier the same question yesterday can replay the exact rule set that produced yesterday's answer.
Per-rule legal verification. Migration 014 added a legal_reference_verified_at column. Category B endpoints (the company-specific surfaces under /api/v1/company/{org}/...) only return rules where this column is non-null. A rule whose Lovdata citation has not been re-checked is effectively invisible to consumers until a human verifies it.
Origin tracking. Migration 018 added an origin column on rule_versions so every change records why it happened — initial seed, human review, Lovdata drift response, audit finding, customer question, or legal correction. Forensic queries can trace the lineage of any answer back to a specific authoritative event.

The upshot: when Apier returns an obligation, you can reconstruct the rule that produced it, the citation it relied on, and the date a human last cross-checked that citation. You cannot get the same guarantee from an LLM-generated regulatory summary.

Universal obligations (seeded in migrations 011 + 012)

The following table lists the obligations the Rulebook ships with today, sourced verbatim from src/lib/supabase/migrations/011_seed_mva_amelding_rules.sql and 012_seed_skattemelding_arsregnskap_forsikring_rules.sql. Every statute citation appears in those migrations and is tagged for Lovdata re-verification before production use.

Rule ID	Obligation	Statute
`MVA_REGISTRATION_THRESHOLD`	Register for MVA when 12-month turnover crosses NOK 50,000	[VERIFY VS LOVDATA — Lovdata: Merverdiavgiftsloven § 2-1]
`MVA_FILING_ANNUAL`	Annual MVA filing when turnover < NOK 1,000,000	[VERIFY VS LOVDATA — Lovdata: Skatteforvaltningsforskriften § 8-3-3]
`MVA_FILING_BIMONTHLY`	Bi-monthly MVA filing (six terminer per year) when turnover ≥ NOK 1,000,000	[VERIFY VS LOVDATA — Lovdata: Skatteforvaltningsloven § 8-3]
`MVA_RATE_STANDARD`	Standard MVA rate of 25%	[VERIFY VS LOVDATA — Lovdata: Merverdiavgiftsloven § 5-1]
`MVA_RATE_FOOD`	Reduced MVA rate of 15% on food (næringsmidler)	[VERIFY VS LOVDATA — Lovdata: Merverdiavgiftsloven § 5-2]
`MVA_RATE_REDUCED`	Low MVA rate of 12% on transport, hotel, cinema and certain other services	[VERIFY VS LOVDATA — Lovdata: Merverdiavgiftsloven § 5-3]
`AMELDING_MONTHLY`	Monthly A-melding when the company has employees	[VERIFY VS LOVDATA — Lovdata: A-opplysningsloven § 4]
`AMELDING_NOT_REQUIRED_ENK`	A-melding not required for an ENK with no employees	[VERIFY VS LOVDATA — Lovdata: A-opplysningsloven § 4]
`SKATTEMELDING_ENK`	Skattemelding for næringsdrivende (ENK) by 31 May	[VERIFY VS LOVDATA — Lovdata: Skatteforvaltningsloven § 8-2]
`SKATTEMELDING_AS`	Selskapsskattemelding (AS) by 31 May	[VERIFY VS LOVDATA — Lovdata: Skatteforvaltningsloven § 8-2]
`NAERINGSOPPGAVE_AS`	Næringsoppgave 2 filed with the AS skattemelding by 31 May	[VERIFY VS LOVDATA — Lovdata: Skatteforvaltningsloven § 8-2]
`AARSREGNSKAP_AS`	Annual accounts (årsregnskap) to Regnskapsregisteret by 31 July	[VERIFY VS LOVDATA — Lovdata: Regnskapsloven § 8-2]
`REVISOR_THRESHOLD_REVENUE_AS`	Auditor required for AS when annual revenue ≥ NOK 7,000,000	[VERIFY VS LOVDATA — Lovdata: Aksjeloven § 7-6 første ledd nr. 1]
`REVISOR_THRESHOLD_ASSETS_AS`	Auditor required for AS when balance-sheet total ≥ NOK 27,000,000	[VERIFY VS LOVDATA — Lovdata: Aksjeloven § 7-6 første ledd nr. 2]
`REVISOR_THRESHOLD_EMPLOYEES_AS`	Auditor required for AS when headcount exceeds 10 årsverk	[VERIFY VS LOVDATA — Lovdata: Aksjeloven § 7-6 første ledd nr. 3]
`YRKESSKADEFORSIKRING`	Continuous occupational-injury insurance for any employer	[VERIFY VS LOVDATA — Lovdata: Yrkesskadeforsikringsloven § 3]
`FORETAKSREGISTER_AS`	Mandatory registration of an AS in Foretaksregisteret	[VERIFY VS LOVDATA — Lovdata: Foretaksregisterloven § 2-1]

Migration 014 recorded three citation corrections that are reflected in the table above:

MVA_FILING_ANNUAL originally cited Skatteforvaltningsforskriften § 8-3-6 (notification duty); the correct authority for annual filing under the threshold is § 8-3-3.
AMELDING_MONTHLY originally cited A-opplysningsloven § 3 (scope); the actual leveringsfrist provision is § 4.
AMELDING_NOT_REQUIRED_ENK carries the same § 3 → § 4 correction.

The auditor (revisor) thresholds are split into three sibling rules — revenue, balance-sheet total, and employee count — rather than expressed as a single OR condition. The evaluator ANDs conditions inside a single rule, so three separate rules correctly implement "any one threshold crossed → audit required" while letting the evaluator report which threshold actually fired.

Entity-type-specific notes

Norwegian entity types behave differently across the Rulebook. The seed data encodes the following:

AS (Aksjeselskap, limited company). Every universal rule applies — MVA, A-melding (when there are employees), skattemelding, næringsoppgave, årsregnskap, the three revisor thresholds, yrkesskadeforsikring (when there are employees), and Foretaksregister registration.
ENK (Enkeltpersonforetak, sole proprietorship). Files skattemelding for næringsdrivende rather than selskapsskattemelding. The A-melding obligation is suppressed when the ENK has no employees (AMELDING_NOT_REQUIRED_ENK). Årsregnskap is not in the universal seed for ENK.
NUF (Norwegian-registered foreign branch). Subject to the universal MVA and A-melding rules. The skattemelding, næringsoppgave, årsregnskap, and revisor rules in the seed are AS-only and therefore do not fire for NUF.
ANS / DA (partnerships). Subject to the universal MVA and A-melding rules. The corporate-form-specific rules (skattemelding AS, årsregnskap AS, the three revisor thresholds, Foretaksregister AS) do not apply.

The three MVA rate rules and the yrkesskadeforsikring rule list every entity type and behave identically across them.

How deadlines are computed

Apier's deadline engine is a pure function: it takes the obligations the evaluator returned, the company's filing-status snapshot, and the date you are asking about, and emits a list of due dates. Three properties matter for an agent reasoning about Norwegian deadlines:

Europe/Oslo timezone. Every rule's effective_date is stored in Postgres as TIMESTAMP '...' AT TIME ZONE 'Europe/Oslo' rather than a hardcoded +01:00 or +02:00 offset. Daylight saving transitions are resolved at the database layer, not in application code.
Norwegian holiday adjustment. A deadline that falls on a public holiday or a weekend is moved forward to the next business day. The engine handles this without the agent needing its own holiday calendar.
Per-rule deadline shape. Each rule carries a deadline_rule string — mva_termin_10th_second_month, a_melding_5th_of_following_month, annual_may_31, annual_july_31, informational, continuous, or not_required. The engine maps these strings to concrete dates relative to a target period.

A consumer never has to implement any of this. The deadlines surface returns ISO 8601 timestamps in Europe/Oslo with the offset baked in.

Querying Apier for obligations

Two endpoints are most relevant. The first returns the per-rule verdicts for a specific Norwegian organisasjonsnummer:

curl -H 'Authorization: Bearer apier_test_<your_key_here>' \
  https://apier.no/api/v1/company/999999999/obligations

The second returns the upcoming filing calendar:

curl -H 'Authorization: Bearer apier_test_<your_key_here>' \
  https://apier.no/api/v1/company/999999999/deadlines

The /api/v1/company/{org}/deadlines endpoint accepts an optional from_date query parameter (ISO 8601 date in Europe/Oslo) and a horizon_months integer between 1 and 60; the default horizon is 12 months. The /api/v1/company/{org}/obligations endpoint does not take a horizon — it returns the per-rule verdicts for the company's current state. Both responses carry a _meta block with the rulebook version, the data freshness timestamp, and the verification timestamp of the weakest cited rule — agents that depend on a specific minimum verification age should branch on _meta.last_verified directly.

Limitations

Apier provides obligation intelligence — it tells you what a company must do legally and when. It does not file anything for you, give legal advice, or guarantee that a third party will accept a filing. Two important boundaries:

Filing requires an Altinn System User. The companion Altinn 3 System Users guide walks through what a System User is and why one is required before any agent-driven submission can succeed.
Citations are verified, not guaranteed. The legal_reference_verified_at timestamp records when a human last cross-checked the citation against Lovdata. Norwegian law changes; the Rulebook tracks the date of last verification, not a perpetual guarantee. For any production-critical decision, re-confirm against the authoritative source at Lovdata.

For the broader compliance disclaimer, see the project's terms at apier.no. For domain reading on Norwegian regulatory infrastructure, the authoritative sources are Altinn, Skatteetaten, Brønnøysundregistrene, and Digdir.

Understanding Norwegian Company Obligations