# Accounting systems and mock data

Norwegian SMBs run their books on a handful of platforms: **Tripletex**
(~150 000 businesses), **Visma eAccounting**, **Fiken** (~80 000 SMBs). Together
they cover most of the market.

## Current status — read this before using any of it

| Provider | Status in this build |
|---|---|
| Tripletex | **Mocked.** Fixture data. Approval pending. |
| Fiken | Not connected |
| Visma | Not connected |
| Altinn / Skatteetaten | Not connected (needs Maskinporten) |

Run `norsk_providers` to confirm — it is authoritative, this table is not.

## What "mocked" means and how to handle it

Mocked operations return **fixture data through the real contract**. The
parameters work, the filters work, the response shape is exactly what the live
adapter will return. The *numbers are invented*.

Every mocked response is labelled:

```json
"meta": { "source": "mock:tripletex (fixture tripletex/faktura.list.json)" }
```

**If `meta.source` starts with `mock:`, say so in your answer.** Not as a
footnote — as part of the statement. "There are three unpaid invoices totalling
555 750 NOK" is a lie if those invoices are fixtures. "Using mock data (Tripletex
is not yet connected), the fixture shows three unpaid invoices totalling
555 750 NOK" is honest and still useful for demonstrating the flow.

Never combine a mocked figure with a real one into a single computed answer
without flagging it. A ratio of mock revenue to real registry revenue is
meaningless.

## The operations

```
norsk_call(id="tripletex.faktura.list", params={ubetalt:true}, limit=20)
norsk_call(id="tripletex.kunde.list",   params={navn:"Orkla"})
```

Invoices carry `fakturanummer`, `kunde`, `belopNok`, `fakturadato`,
`forfallsdato`, `betalt`, `restbelopNok`. Filters: `ubetalt` (unpaid only),
`kundenavn` (substring), `fraDato`.

## The cross-provider flow this exists to demonstrate

Accounting-system records carry customer org numbers, which join straight into
the public registry:

```
norsk_call(id="tripletex.kunde.list")                          # -> orgnr per customer
norsk_call(id="brreg.enhet.get",    params={orgnr:"910747711"}) # is it still active?
norsk_call(id="brreg.regnskap.get", params={orgnr:"910747711"}) # can it pay?
```

That is the thing no single-provider integration can do: your unpaid invoices
enriched with each customer's registered status and financial position. The
registry half is **real live data** even when the invoice half is mocked — be
precise about which is which.

## Why not just connect them

Tier-1 access is a process, not a config value:

- **Tripletex** — consumer token application, 2–3 weeks
- **Visma** — self-service sandbox, then production review
- **Fiken** — 99 kr/month, then partner access for multi-tenant use
- **Altinn / Skatteetaten** — Maskinporten, which needs a virksomhetssertifikat
  and scope approval; weeks, with legal review

Mocking behind the identical contract means the agent-facing behaviour is built
and tested now, and swapping in the live adapter changes one registry line and
the operation's `status` field.

## When a user asks to connect their account

There is no connection flow in this build — `norsk_connections` is specified but
not implemented, and no credentials are stored anywhere. Tell the user their
accounting system is not connected yet and that only public-register data is
live. Do not imply you can authenticate on their behalf.