What is a klientadministrator?

The administrator role for the client side of a firm's accesses. Where the ordinary access managers handle the firm's own rights, the klientadministrator manages the accesses the organisation holds on behalf of its clients and customers, whether those arise from a registered relationship in the Enhetsregisteret or from a delegation. Assigning clients to an agent system user is performed by a klientadministrator or the managing director.

Do we need a delegation from every client if we are their registered accountant?

Not for the packages themselves. When a client registers your firm as its accountant or auditor in the Enhetsregisteret, the matching access packages arise from the registration automatically, with no delegation screen. What remains a deliberate act is pointing a SYSTEM at the client: assigning the client to your agent system user is done at the firm, by a klientadministrator or the managing director.

What is an agent system user?

A system user created to represent clients rather than the firm itself. A standard system user acts for one organisation; an agent system user is the variant for accountants and auditors, where one registered system acts for many client organisations, and each client is delegated to it individually. The client delegation API lists the agents, the clients available, and the clients already assigned.

What changed from Altinn 2 client roles?

The unit of access and the lifetime of old grants. Client access in Altinn 3 is carried by access packages that arise from the registered relationship, not by roles delegated per service. Skatteetaten's transition guidance documents that Altinn 2 roles and delegation of roles are removed at the start of 2027, and that some old grants lapse earlier and must be delegated anew under the new model.

How does Apier serve an accounting firm here?

By making the portfolio state readable. list_acting_capacity resolves which registry roles a person holds for a client organisation and what those roles permit. The fullmakt endpoints answer the delegation state per client org: full, partial or none, with the missing scopes named and Norwegian fix steps you can hand to the client. Both run behind one Apier key, so the per-client authority question becomes a loop instead of a support thread.

How does client delegation work for accountants and auditors in Altinn 3?

In two halves, one automatic and one deliberate. The automatic half: when a client registers your firm as its accountant or auditor in the Enhetsregisteret, the matching access packages arise from that registration by themselves, with no delegation screen. The deliberate half: acting through software requires an agent system user, one registered system representing many clients, and each client is assigned to it individually by a klientadministrator or the managing director at your firm. The packages follow the registered relationship; the per-client assignment to a system is an administrative act someone at the firm performs.

The top row costs the firm nothing: the registry does the work. The dashed arrow is the half that is easy to forget, and its absence is why a system sees no clients even though every registration is in order.

Where does client access come from in Altinn 3?

From the register, not from a delegation screen. When a client company registers an accounting firm in the Enhetsregisteret, the accountant packages arise from that registration automatically: accountant with signing right, accountant without signing right, and accountant payroll. A registered auditor gets the same mechanism with the responsible auditor and audit assistant packages. The grant follows the registered relationship, so it survives staff turnover on both sides and ends when the relationship is deregistered.

This is the piece that changed most from Altinn 2, where client access was carried by roles delegated per service and per person. The package model moves the bundling into a shared catalogue and ties the professional packages to the registry. The old grants do not carry across indefinitely: Skatteetaten's transition guidance documents that Altinn 2 roles and delegation of roles are removed at the start of 2027, with some grants lapsing earlier and needing to be delegated anew.

Which packages replaced which roles, and why sensitive packages have no pre-assigned roles at all, is owned by the role mapping guide. This page assumes the packages exist and asks the operational question that follows: how a firm turns registry-granted authority into software acting for a hundred clients.

Who at the firm hands client access onward?

The klientadministrator. Altinn's administrator roles split the firm's own accesses from the accesses it holds on behalf of others, and the klientadministrator owns the second half: managing what the organisation may do for its clients and customers, whether that authority arises from a registered relationship in the Enhetsregisteret or from a delegation. The portal flow for assigning clients to a system requires exactly this role or the managing director.

The flow itself is short and per client. From the system access overview, the administrator opens the agent system user, chooses to add clients, and adds them one at a time before confirming. The list only offers clients whose relationship is actually established: the end-user guide is explicit that an empty client list means the client relationship is not set up, which makes that empty modal a registry symptom rather than a portal bug.

It is worth pausing on what this half is for. The packages already exist, granted by the registry, and the firm's people already hold them. The assignment step exists because a SYSTEM acting for a client is a bigger decision than a person doing so: it is the point where the firm chooses, client by client, which parts of the portfolio its software may touch, and it is reversible client by client too.

How is an agent system user authorised per client?

An agent system user is the client-facing variant of the system user model: where a standard system user acts for the one organisation that created it, an agent system user represents clients, and carries a user type of agent to say so. One registered system, one agent system user at the firm, and then one delegation per client hanging off it. The delegations are tied to the access packages the work needs, the same accountant and auditor packages the registry granted.

The assignment half is also reachable as an API rather than a portal flow. The client delegation API lists an organisation's agent system users, the clients available for delegation, and the clients already delegated, and adds or removes clients programmatically; the operations are guarded by their own read and write scopes. A vendor serving accounting firms can therefore build client onboarding into its own product instead of sending administrators to the portal for every new engagement. The mechanics of standing up the underlying system and its first token are owned by the setup walkthrough.

Apier's role in this picture is the read side: making the portfolio's authority state something a firm queries rather than discovers. list_acting_capacity resolves which registry roles a person holds for a client organisation and what those roles permit, and the fullmakt endpoints answer the delegation state per client org with the gaps named and Norwegian fix steps attached. The same audience this page serves is the one the accounting firm use case walks end to end.

Client access by situation: what grants it, and who performs the act. The package rows follow the registry; the system rows are administrative acts at the firm.
Situation	What grants access	Who performs it
Firm is the registered accountant	The three accountant packages arise from the Enhetsregisteret registration automatically.	The client, by registering the firm; no delegation screen.
Firm is the registered auditor	The responsible auditor and audit assistant packages, by the same mechanism.	The client, by registering the auditor.
No registered relationship	Nothing arises automatically; the client delegates a package explicitly.	Someone with authority at the client, by manual delegation.
Software acts for the portfolio	An agent system user, with each client assigned to it individually.	A klientadministrator or the managing director at the firm.
Client onboarding built into a product	The client delegation API: list agents, list clients, add and remove.	The vendor's integration, under the client delegation scopes.

Make the first call

The sandbox call answers who may act for one company, with no key. The TypeScript sample is the portfolio version: the delegation state per client org, read in a loop before any client work is scheduled, with the gaps and fix steps in the body instead of in a downstream rejection.

# Zero-auth sandbox: who may act for a company, from the registry.
curl -s https://www.apier.no/api/v1/sandbox/public/company/999999999/authority

// Portfolio pre-flight: the delegation state per client org, read with
// one Apier key against apier.no, before any client work is scheduled.
const clients = ["999999999"]; // your client org numbers

for (const org of clients) {
  const res = await fetch(`https://www.apier.no/api/v1/fullmakt/${org}`, {
    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(`${org}: ${error_code}: ${explanation.summary}`);
  }

  const { data } = await res.json();
  // "full" | "partial" | "none", with Norwegian fix steps per gap.
  console.log(org, data.overall_status, data.fix_steps);
}

Frequently asked questions

What is a klientadministrator?: The administrator role for the client side of a firm's accesses. Where the ordinary access managers handle the firm's own rights, the klientadministrator manages the accesses the organisation holds on behalf of its clients and customers, whether those arise from a registered relationship in the Enhetsregisteret or from a delegation. Assigning clients to an agent system user is performed by a klientadministrator or the managing director.
Do we need a delegation from every client if we are their registered accountant?: Not for the packages themselves. When a client registers your firm as its accountant or auditor in the Enhetsregisteret, the matching access packages arise from the registration automatically, with no delegation screen. What remains a deliberate act is pointing a SYSTEM at the client: assigning the client to your agent system user is done at the firm, by a klientadministrator or the managing director.
What is an agent system user?: A system user created to represent clients rather than the firm itself. A standard system user acts for one organisation; an agent system user is the variant for accountants and auditors, where one registered system acts for many client organisations, and each client is delegated to it individually. The client delegation API lists the agents, the clients available, and the clients already assigned.
What changed from Altinn 2 client roles?: The unit of access and the lifetime of old grants. Client access in Altinn 3 is carried by access packages that arise from the registered relationship, not by roles delegated per service. Skatteetaten's transition guidance documents that Altinn 2 roles and delegation of roles are removed at the start of 2027, and that some old grants lapse earlier and must be delegated anew under the new model.
How does Apier serve an accounting firm here?: By making the portfolio state readable. list_acting_capacity resolves which registry roles a person holds for a client organisation and what those roles permit. The fullmakt endpoints answer the delegation state per client org: full, partial or none, with the missing scopes named and Norwegian fix steps you can hand to the client. Both run behind one Apier key, so the per-client authority question becomes a loop instead of a support thread.