How is Apier different from Tripletex, Fiken, PowerOffice, or Conta?

Those are accounting software platforms — your staff enters bookkeeping data and the platform generates filings for one company at a time. Apier is the regulatory infrastructure layer underneath: a single API exposing per-client obligation verdicts, deadline math, and Brønnøysund-backed company data across your full client portfolio. The Altinn 3 delegation flow and central Maskinporten brokering are built and undergoing production validation — see /docs/capability-status for current state. They run alongside Apier, not instead of it.

Can our staff act on behalf of every client company through one Apier account?

That is the model Apier is built for: each client grants your firm an Altinn 3 System User delegation (a one-time client-side step, typically by their innehaver or daglig leder), and Apier brokers Maskinporten centrally — one enterprise certificate (virksomhetssertifikat), one Maskinporten client, N client delegations. The delegation and Maskinporten flow is built but still undergoing production validation against Altinn and Maskinporten — see /docs/capability-status for current state. Expired or revoked delegations fail closed at the gateway.

What's the easiest way to onboard a new regnskapsbyrå client?

Client side: their innehaver or daglig leder grants your account a System User delegation in Altinn 3, scoped to the access packages your work requires (regnskap, lønn, MVA-rapportering, skatt — pick the minimum needed). The flow takes about five minutes. The Apier side is designed so your integration sees the client at the next request once the delegation is active — no separate Apier-side onboarding, no per-client API key juggling. The delegation flow is still undergoing production validation; see /docs/capability-status.

How does Apier handle the revisor-threshold check across our client portfolio?

GET /api/v1/company/{org_number}/obligations returns a verdict that includes revisor_required: true|false plus the legal_reference (Aksjeloven § 7-6, the audit-threshold rule for AS entities — exemption requires ALL three to be met simultaneously: revenue under 7 MNOK AND assets under 27 MNOK AND under 10 årsverk). The verdict carries an explanation field so your staff can defend the determination to a client. Run it nightly across your portfolio; threshold crossings emit /api/v1/changes events you can subscribe to and surface in your internal review queue.

How does the MVA-termin cadence work — bimonthly vs yearly, and what about A-melding?

GET /api/v1/company/{org_number}/deadlines returns each filing's next due date in Europe/Oslo timezone with the cadence baked in: MVA bimonthly default (Termin 1 jan-feb due 10. april, etc.), yearly for clients under the small-business threshold who've opted in, and the special Skatteforvaltningsloven cases. A-melding (monthly employer disclosure) is on the same surface. DST-aware, weekend / holiday-shifted, with each deadline carrying the relevant legal_reference for audit trail.

What happened for our clients on June 19, 2026 when Altinn 2 sunset?

DigDir decommissioned Altinn 2 on 19 June 2026. Every existing client delegation pointing at Altinn 2 roles stopped working that day — there is no automatic carry-over to Altinn 3 access packages. Each of your clients needs to grant a fresh Altinn 3 System User delegation. Apier exposes the Altinn 2 role → Altinn 3 access package mapping as a zero-auth lookup at /api/v1/tools/altinn-migration, and the /use-cases/altinn-migration page covers the deadline, the mapping logic, and the caveat that one Altinn 2 role often splits across multiple Altinn 3 packages (or vice versa).

Use case

Norwegian compliance infrastructure for regnskapsbyrå

Maskinporten, Altinn 3, and Brønnøysund — without your firm rebuilding the integration for every new client.

Apier is the regulatory infrastructure layer for Norwegian regnskapsbyrå operating multi-client portfolios — not a bookkeeping tool, not a client-facing dashboard.

What scales linearly with portfolio size

Running a regnskapsbyrå at multi-client scale exposes three operational surfaces that the per-firm accounting software wasn't designed for:

Per-client delegation administration. Every new client engagement starts with the client granting your firm an Altinn 3 System User delegation — and that ceremony repeats on every staff change at the client (innehaver / daglig leder turnover invalidates), every scope expansion (new service line needs new access packages), and every renewal cycle. Multiply by N clients and the operational overhead compounds.
Cross-agency state reconciliation per client. Each client's regulatory state lives across Brønnøysund (entity registry — signaturrett, prokura, NACE code, dissolved status), Skatteetaten (MVA-register status, recent MVA-meldinger, skatteoppgjør), NAV (Aa-registeret aggregates feeding verneombud and HMS-thresholds), and Altinn 3 (which delegations are active, which access packages they cover). Today regnskapsbyrå staff reconcile these manually per client — one canonical view per client is what a competent portfolio dashboard actually needs.
Quarterly regulatory drift, multiplied by portfolio size. Stortinget updates thresholds (Aksjeloven § 7-6 audittrigger: 7 MNOK omsetning / 27 MNOK eiendeler / 10 årsverk; verneombud at 50 ansatte), filing cadence (MVA bimonthly default; yearly opt-in under the small-business threshold), and entity-type rules (AS vs ENK vs NUF behave differently for tax, lønn, audit). Staying current across N clients is a research burden that scales linearly with portfolio.

The engineering answer to all three is the same one, and How do I automate Norwegian regulatory compliance tasks? covers it end to end: what the rulebook evaluates, how deadlines are derived, and where a human still has to sign.

The delegation half specifically, where client access arises in the Enhetsregisteret and how one system is authorised per client, is covered in How does client delegation work for accountants and auditors in Altinn 3?

What Apier provides — eight infrastructure components

Each component is consumable as REST, as MCP, or as both. Your staff and any AI assistants your firm runs see the same verdicts; the determinism contract holds across surfaces.

Auth Gateway. Maskinporten JWT client-assertion + token caching + Altinn 3 System User delegation flow — built and test-client-verified, not yet running against production Maskinporten and Altinn (production validation in progress; see /docs/capability-status). One Bearer API key per firm; raw OAuth tokens never leave the gateway.
Registry Engine. Canonical company state reconciled across Brønnøysund (Tier 1, including MVA registration status) + Altinn (delegations) today; the Skatteetaten (MVA-meldinger, skatteoppgjør) and NAV (Aa-registeret aggregates) slices are built but not live — the Skatteetaten read scopes were denied or are still in processing, and NAV's has not been applied for yet. One canonical view per client, ready for your portfolio dashboard.
Universal Rulebook. Versioned regulatory rules with legal_reference citations(Aksjeloven § 7-6, MVA-forskriften, A-opplysningsloven § 3, Bokføringsloven § 13). Deterministic evaluation; same input + rulebook_version produces byte-identical output, so your audit trail per client is reproducible.
Deadline Engine. MVA terminer, A-melding cadence, skattemelding, årsregnskap, revisor-threshold checkpoints — calendar math in Europe/Oslo with full DST-awareness, weekend / holiday adjustments built in. Run nightly across your client portfolio to surface upcoming due dates.
MCP Server. Every tool above exposed over the Model Context Protocol at /api/mcp. Live as @apier-no/mcp on npm — see the snippet below. Same auth, same scopes, same determinism contract your REST integration uses.
Intent-to-Action Parser. Filing requests resolved into structured validation pipelines (mva_melding, a_melding). Today the surface runs dry-run validation only — no real submission goes to the government; live submission is built but gated on Maskinporten production validation and Altinn scope approval (see /docs/capability-status). When it activates, live submission requires a one-time approval token so portfolio-wide automation never bypasses a human gate.
AI-Agent Discovery. llms.txt, llms-full.txt, workflows.json, /api/v1/capabilities, /.well-known/mcp.json, /.well-known/ai-plugin.json — every machine discovery surface populated and stable so any AI tooling your firm adopts can introspect Apier at config time.
Compliance Explainer. Every Apier error_code resolves to a Norwegian-bokmål Explanation envelope (summary / why / fix_steps / legal_basis / handover) via POST /api/v1/explain. Your staff sees a defensible legal_basis when a client asks why a filing failed.

MCP server — for the AI assistants your staff use

If your firm uses Claude Desktop, Cursor, or another MCP-compatible AI assistant, @apier-no/mcp lights up Apier's MCP tools inside the assistant. Same auth, same per-client scopes, same determinism contract — and each MCP tool maps to a documented REST endpoint. See /no/altinn-for-ai-agents for the developer-facing detail.

Claude Desktop / Cursor config

{
  "mcpServers": {
    "apier": {
      "command": "npx",
      "args": ["-y", "@apier-no/mcp"],
      "env": { "APIER_API_KEY": "apier_live_<your_key>" }
    }
  }
}

Source + issues: github.com/PowerLaunch/apier-mcp. Package page: npmjs.com/package/@apier-no/mcp.

What a call looks like

One Bearer API key per firm; the per-client authority comes from each client's active Altinn 3 System User delegation.

REST — curl against the obligations endpoint

curl -H "Authorization: Bearer apier_live_<your_key>" \
  "https://www.apier.no/api/v1/company/991825827/obligations"

No-auth dry-run against synthetic data: curl https://www.apier.no/api/v1/sandbox/public/company/999999999/obligations.

FAQ

How is Apier different from Tripletex, Fiken, PowerOffice, or Conta?: Those are accounting software platforms — your staff enters bookkeeping data and the platform generates filings for one company at a time. Apier is the regulatory infrastructure layer underneath: a single API exposing per-client obligation verdicts, deadline math, and Brønnøysund-backed company data across your full client portfolio. The Altinn 3 delegation flow and central Maskinporten brokering are built and undergoing production validation — see /docs/capability-status for current state. They run alongside Apier, not instead of it.
Can our staff act on behalf of every client company through one Apier account?: That is the model Apier is built for: each client grants your firm an Altinn 3 System User delegation (a one-time client-side step, typically by their innehaver or daglig leder), and Apier brokers Maskinporten centrally — one enterprise certificate (virksomhetssertifikat), one Maskinporten client, N client delegations. The delegation and Maskinporten flow is built but still undergoing production validation against Altinn and Maskinporten — see /docs/capability-status for current state. Expired or revoked delegations fail closed at the gateway.
What's the easiest way to onboard a new regnskapsbyrå client?: Client side: their innehaver or daglig leder grants your account a System User delegation in Altinn 3, scoped to the access packages your work requires (regnskap, lønn, MVA-rapportering, skatt — pick the minimum needed). The flow takes about five minutes. The Apier side is designed so your integration sees the client at the next request once the delegation is active — no separate Apier-side onboarding, no per-client API key juggling. The delegation flow is still undergoing production validation; see /docs/capability-status.
How does Apier handle the revisor-threshold check across our client portfolio?: GET /api/v1/company/{org_number}/obligations returns a verdict that includes revisor_required: true|false plus the legal_reference (Aksjeloven § 7-6, theaudit-threshold rule for AS entities — exemption requires ALL three to be met simultaneously: revenue under 7 MNOK AND assets under 27 MNOK AND under 10 årsverk). The verdict carries an explanation field so your staff can defend the determination to a client. Run it nightly across your portfolio; threshold crossings emit /api/v1/changes events you can subscribe to and surface in your internal review queue.
How does the MVA-termin cadence work — bimonthly vs yearly, and what about A-melding?: GET /api/v1/company/{org_number}/deadlines returns each filing's next due date in Europe/Oslo timezone with the cadence baked in: MVA bimonthlydefault (Termin 1 jan-feb due 10. april, etc.), yearly for clients under the small-business threshold who've opted in, and the special Skatteforvaltningsloven cases. A-melding (monthly employer disclosure) is on the same surface. DST-aware, weekend / holiday-shifted, with each deadline carrying the relevant legal_reference for audit trail.
What happened for our clients on June 19, 2026 when Altinn 2 sunset?: DigDir decommissioned Altinn 2 on 19 June 2026. Every existing client delegation pointing at Altinn 2 roles stopped working that day — there is no automatic carry-over to Altinn 3 access packages. Each of your clients needs to grant a fresh Altinn 3 System User delegation. Apier exposes the Altinn 2 role → Altinn 3 access package mapping as a zero-auth lookup at /api/v1/tools/altinn-migration, and the /use-cases/altinn-migration page covers the deadline, the mapping logic, and the caveat that one Altinn 2 role often splits across multiple Altinn 3 packages (or vice versa).

Get started

Free tier ships with one API key and enough quota to onboard your first clients. The REST surface is curlable from anywhere; the MCP server is a single npx away if your firm runs MCP-compatible AI assistants.