Letting an agent into your books: Fortnox and Bokio

Squidler agents can now connect to Fortnox and Bokio. Both are Swedish accounting systems, so this one is genuinely local: if your books live somewhere else, this post is not for you. If they live in one of these two, your agent can now read them, and — if you let it — work in them.

Reading was the easy half. An agent with access can answer "what did we spend on consultants last quarter", tell you which supplier invoices fall due this week, pull the figures you need at month-end, or notice that a customer who always pays on time suddenly has not. It knows your business already, because it has been in your conversations. Now it can check.

The hard half was write access.

Everything starts read-only

A connected company is read-only until you change that, and you change it per area rather than all at once. Your agent can be allowed to register supplier invoices while still being unable to touch payments, or to maintain customers while staying out of the ledger entirely.

That granularity is not decoration. "Can this thing change my accounting?" is the question anyone sensible asks first, and "yes, but only invoices, and here is the list" is a better answer than a single switch labelled write access.

Fortnox publishes no read-only scopes

This is where it got interesting, and it is worth saying plainly because it shapes the whole design.

Fortnox's API has no read-only permissions. Its own documentation says so. Every connection that can read your invoices can also write them — there is no scope you can request that says look, do not touch. So when we promise you read-only, no part of Fortnox is enforcing that promise. We are.

That meant building the boundary ourselves: a classifier that inspects every request before it leaves our process and refuses anything that would change your books when you have not allowed it. Refusals are recorded, so there is a trail.

The subtle part is that you cannot do this by looking at the HTTP method. GET is supposed to be the safe one, and mostly it is — but GET /invoices/{id}/email sends the invoice to your customer. So does /einvoice. So does /eprint. Three ways to put something in front of a customer, all dressed as innocent reads.

So we do not classify by method. We classify by what the endpoint does, and anything we do not recognise is treated as a write and refused. If Fortnox adds a new action tomorrow that we have never seen, it fails closed — your agent gets a refusal rather than an adventure.

Bokio is the opposite case, and a nicer one: it publishes separate read and write scopes per area. There, when you grant read-only, Bokio refuses the writes too. Our gate still runs, but it is a second lock rather than the only one.

One agent, many clients

If you are an accounting bureau, one grant covers one company. So an agent holds a separate connection per client ledger, each with its own access level — write on your own books, read-only on a client's, or nothing at all until they are comfortable.

We built it that way because that is how the work is actually shaped. A byrå does not have "the books". It has forty sets of them, belonging to forty people with different appetites for how much a machine should touch.

What this is not

It is not a bookkeeping robot and it will not replace your accountant. It does not decide how something should be booked. It reads what is there, does the parts you have explicitly allowed, and asks when it is unsure.

The realistic version is duller and more useful than automation: fewer trips into the accounting system to look something up, less chasing, and a colleague who already knows the context because you have been talking to it all week.

Connect a company under Settings → Integrations. Everything starts read-only, and you can change or disconnect it whenever you like.