How do AI agents ensure compliance with Norwegian bookkeeping laws (bokføringsloven)?

How do LLM agents align with SAF-T tax code requirements in Norway?

Start with a correction, because the question usually contains a wrong assumption. Apier does not generate, export or validate SAF-T files, and an agent built on this API should not present itself as doing so. The ledger and its export format belong to the accounting system. What this API answers is the layer above the ledger: which obligations apply to an entity, when they fall due, who may act for the company, and whether a payload passes validation.

The design principle that follows is worth stating on its own. An agent should never invent a classification. If a transaction needs a tax code, that code comes from the accounting system or from a person qualified to assign it, not from a model asked to pick the most likely one. A language model will produce a plausible code for an ambiguous transaction with exactly the same fluency it produces a correct one, and nothing downstream can tell the difference from the output alone.

So the useful division is: the accounting system owns the ledger, deterministic rules own the obligations and dates, a qualified human owns the judgements, and the agent orchestrates between them. That leaves the agent doing what it is genuinely reliable at, which is working out which question to ask and turning a structured answer into something a person can read.

How do you create an auditable execution trail for an agent doing bookkeeping work?

Two properties make a trail worth having. The first is reproducibility: every response carries the rule version it was evaluated under, and identical inputs against that version always produce an identical result. That turns “why did the system say that” from an argument into a re-derivation. The second is a shared identifier: a correlation id travels on the response header and lands on the audit row behind the call, so one value stitches together the request, the evaluation and the record.

What the API records is its own half: who acted, on which organisation, doing what, under which rule version, and whether the action was initiated by a person or by a machine. That last field matters here more than anywhere else. An audit trail that cannot distinguish an accountant from an autonomous caller cannot answer the question a reviewer will actually ask.

Your half is the part nobody else can capture: which tool the agent chose, what it was asked, what it concluded, and what it told the user. Log that against the same correlation id and the two halves join. The audit inspection guide walks through reconstructing a single action end to end, which is a good exercise to run once before you need it in earnest.

What must a human still approve?

Anything binding, and anything that is a judgement rather than a lookup. The binding half is enforced rather than recommended: the scope that would release a binding action sits in a reserved prefix that cannot be granted to any API key, so an agent's own credential can never approve the agent's own filing. There is no configuration in which that is possible, which means it is not a question about how carefully you scoped the key.

The judgement half is not something software can enforce, and it is where the design attention belongs. Classifying an ambiguous transaction, deciding whether an exception applies, interpreting an unusual arrangement: these are questions a model will answer fluently and cannot be trusted on. Build the agent so it surfaces the question rather than resolving it, and so the surfacing is the normal path rather than an error state that a user learns to click past.

Worth restating plainly at the end: this page is about how to build software, not about what your business is required to do. It names no provision of Norwegian bookkeeping legislation and makes no claim about how any rule applies to a particular case. For that, ask a qualified accountant or lawyer, which is also the answer your agent should give when a user asks it the same kind of question.

Make the first call

The first request needs no key and names no company: it returns the obligation template an agent reasons over. The second reads back what happened, and the field worth reading first is initiated_by.

# Zero-auth: the obligation template, with no company named.
curl -s "https://www.apier.no/api/v1/public/obligations?entity_type=AS"

// Reconstruct what the agent did. Your own rows only.
const res = await fetch(
  "https://www.apier.no/api/v1/company/999999999/audit",
  { headers: { Authorization: `Bearer ${process.env.APIER_API_KEY}` } },
);

const { data } = await res.json();
for (const entry of data.entries) {
  // initiated_by distinguishes an operator from an autonomous caller.
  console.log(entry.timestamp, entry.action, entry.initiated_by);
}

Frequently asked questions

Can an AI agent be responsible for bookkeeping compliance?

No. Responsibility stays with the business and the people accountable for its records, and no software arrangement moves it. What an agent can do is carry out defined work, call deterministic tools rather than deciding legal questions itself, and leave a record that shows what it did and on what basis. This page describes how to build that. It is not accounting or legal advice.

Does Apier generate SAF-T files?

No. There is no SAF-T generation, export or validation in the API, and an agent should treat the accounting system as the system of record for the ledger. What Apier answers is the layer above the ledger: which obligations apply to an entity, when they fall due, who may act for the company, and whether a payload passes validation.

What should the agent never decide on its own?

Anything that is a judgement about the law rather than a lookup. Which tax treatment applies to an unusual transaction, how to classify something ambiguous, whether an exception is available. Those belong to a qualified human. An agent that produces a confident answer to a question like that is producing text, and the text reads the same whether it is right or wrong.

What makes an agent's work auditable?

Reproducibility plus a record. Every response carries the rule version it was evaluated under and a correlation id echoed on the header, so a past decision can be re-derived rather than argued about. Store both alongside whatever your agent concluded, and the audit trail behind the call joins to your own records on the same identifier.

Can an agent file on the business's behalf?

Not as a binding government submission today. Validation runs against the real rule set, but binding submission is gated behind approvals that have not landed. And the scope that would release a binding action is reserved and cannot be granted to any API key, so an agent cannot approve its own filing regardless of how it is configured.