The Accounting API for the AI Era

TL;DRMost accounting software treats your books as a regulatory chore. We treat the ledger as the richest structured dataset your business produces. Open source under AGPL, Swedish double-entry, REST plus MCP. Built so AI agents and growth automations can run on top instead of around. This is the developer entry point.

The thesis is simple: accounting software was built for accountants. We're building accounting infrastructure for the systems on top of accountants. AI agents that close the month. Dunning automations that chase invoices. Live runway dashboards that read directly from the source of truth. Pricing experiments that know actual gross margin in real time.

None of this requires a new accounting paradigm. Double-entry bookkeeping has worked since 1494. What's new is that the ledger can finally be a first-class API instead of a UI with an API stapled on the side.

What accounted is

A Swedish double-entry accounting ledger with three architectural properties that matter:

1. API-first. Every write operation goes through the same validation layer whether triggered by a user click, a scheduled job, a REST call, or an MCP tool invocation. There's no "back door" UI logic. The API reaches almost everything the UI does; the few UI-only actions left, such as inviting a member, are the exception.
2. Deterministic core. The validation engine enforces debits-equal-credits, account-plan correctness, period locking, and Swedish VAT rules without any LLM in the loop. Agents propose; the deterministic core decides. Compliance is structural, not policy.
3. Append-only audit. Every state change is an event in an immutable log. This is Bokföringslagen-compliant by construction and makes time-travel queries trivial. It also means agent activity is always traceable: which session proposed which operation, who approved, when.

The product surfaces:

• REST API at app.accounted.se/api/v1: 280+ endpoints, OpenAPI 3.1, 900+ structured error codes.
• MCP server with 150+ tools for Claude, Cursor, and any MCP-compatible client, over OAuth 2.1 as a hosted connector or through the accounted-mcp stdio bridge.
• Webhooks: 28 event types, with the event log pollable as a fallback.
• SIE4 import and export for migration from legacy Swedish systems.
• Open source core under AGPL-3.0 on GitHub.

Why MCP changes the integration story

You can call any REST API from an LLM-driven application by writing wrapper code. It works. It's not the interesting thing.

MCP is the interesting thing. With an MCP server, the LLM client (Claude Desktop, Cursor, anything) discovers the available tools at runtime. It reads their schemas. It knows what each tool does, what arguments it needs, what it returns. It can chain them itself.

For accounting that means a user can type "close April 2026" into Claude and the agent will:

1. Call gnubok_year_end_readiness to find blockers.
2. Walk through uncategorized transactions via gnubok_list_uncategorized_transactions and gnubok_suggest_categories.
3. Stage gnubok_categorize_transaction for each.
4. Run gnubok_vat_review_widget for VAT period close.
5. Finally call gnubok_lock_period.

You wrote zero integration code. The agent did the orchestration. The deterministic ledger validated every step. Your approval was required at risk-classed checkpoints. The audit log captured the full session.

Deeper dive: MCP server for accounting (Swedish, with English code samples) and the Swedish-language workflows article.

What the surface makes possible

The architecture opens a category of applications that were awkward to build on legacy bookkeeping APIs, because those APIs were afterthoughts bolted to a UI. What the endpoints support today:

• Live runway and burn dashboards wired directly to the ledger, reading gnubok_get_kpi_report or the reports endpoints. See Live runway and burn rate from your ledger for the recipe.
• Dunning workflows that read the AR ledger on a schedule and escalate overdue invoices. See Dunning-agent på autopilot.
• Per-customer margin reporting using dimensions, so pricing decisions read actual gross margin instead of a guess. See Bruttomarginal per kund i realtid.
• Month-end close driven from a chat client, with every write staged for approval. See ChatGPT, Claude och din ledger.
• Accounting inside another product, where end customers never leave the host application. Deep dive: Embedded accounting for SaaS, including the parts that are still on you.

These are built with the tools you'd reach for in any normal product stack: TypeScript, Python, Make, n8n, Claude, Cursor. No special SDK required.

How to integrate

Three integration tiers:

Tier 1: REST API

The boring, reliable path. Mint a scoped API key in the dashboard at /settings/api, then start by asking which companies it can reach:

curl https://app.accounted.se/api/v1/companies \
  -H "Authorization: Bearer gnubok_sk_live_..."

Everything else is nested under a company ID: /api/v1/companies/{companyId}/transactions, /reports/general-ledger, /invoices, and so on. Same shape as any production-grade write API: an Idempotency-Key header on writes, dry-run on most of them, scope-based authorization, and structured errors with a docs link and, where there's a known fix, a recovery hint.

Use gnubok_sk_test_* keys while you build. They force every write into dry-run, but reads return your real company data: there is no separate sandbox.

Tier 2: MCP

Two paths. For claude.ai or Claude Desktop, add a custom connector pointing at https://app.accounted.se/api/extensions/ext/mcp-server/mcp and authorise over OAuth 2.1. No key to manage. The consent screen pre-selects every scope your role allows and lets you untick any of them; writes stage for your approval either way.

For a local stdio bridge with a long-lived key:

{
  "mcpServers": {
    "accounted": {
      "command": "npx",
      "args": ["-y", "accounted-mcp"],
      "env": {
        "ACCOUNTED_API_KEY": "gnubok_sk_test_...",
        "ACCOUNTED_CLIENT": "claude-desktop"
      }
    }
  }
}

This bridge serves the tools under the accounted_* prefix; the connector URL above and the legacy gnubok-mcp package use the gnubok_* names this article uses. Same tools either way. The client lists the common ones automatically and finds the rest of the 150+ with the search tool. Every write that touches the books stages a pending operation you approve before anything is booked.

Tier 3: Embedded

For SaaS platforms and agency operators putting accounting inside their own product. POST /api/v1/companies provisions a company in one call, and agencies get white label on top (see /byraer). The core is AGPL-3.0-or-later: its source-sharing terms apply to the ledger itself if you modify it and run it for others. Read Embedded accounting for SaaS first. It's honest about what's still on you.

For developers wanting to build their own UI or integration patterns on top of an open ledger: Building on an open source Swedish ledger.

What's different about this category

Five things that are structurally different from legacy Swedish bookkeeping software:

Property	Legacy bookkeeping software	accounted
API surface	Afterthought, partial	First-class, complete
MCP server	None	150+ tools, accounted-mcp bridge
Audit log	Often partial	Complete append-only event log
Source license	Proprietary	AGPL-3.0 core, extension exception
Self-hosting	Not possible	Fully supported

None of these are marketing differences. They're architectural commitments that make different applications possible.

What's on the roadmap

Webhooks shipped: 28 event types, with delivery inspection and retry. Programmatic company provisioning shipped too: POST /api/v1/companies creates a company with its BAS chart, first fiscal period and tax deadlines in one call. So did Peppol e-invoicing, sending and receiving, switched on per company on request. What's still open:

1. Long-running MCP operations for year-end and bulk reconciliation. The MCP Tasks extension is in place (the audit package already returns a handle to poll, for clients that support it), but year-end still runs as one long call.
2. K10 is still a compliance gap.

These land in the AGPL core. Pull requests welcome on GitHub — open an issue first for anything non-trivial.

Where to start

If you're a developer evaluating accounted for an integration:

1. Read the API docs at /docs/api, or the developer overview at /utvecklare.
2. Create an account at app.accounted.se/register. A new company starts with a 30-day trial.
3. Try the MCP server with Claude in read-only mode. Twenty minutes to see what agentic access looks like.
4. Open an issue or PR on GitHub if something doesn't work the way you expect.

The Swedish founder content lives at /blogg. The product story lives at /. The dev story lives here. The next cluster article is Building on an open source Swedish ledger.

Accounting infrastructure isn't a hot category. It should be. Once the books are an API, everything downstream gets cheaper, faster, and more reliable. We're building the API so the things on top of it become possible.

Frequently asked

Is this just another QuickBooks API wrapper?

No. Accounted is a Swedish double-entry ledger written from scratch with an API-first architecture: the web app, the REST API and the MCP tools all write through the same validation layer, and the API reaches almost everything the UI does. It's a different category, built for agents.

Why Swedish-only?

Swedish bookkeeping has specific compliance requirements (Bokföringslagen, BAS chart of accounts, Skatteverket filings, BankID) that don't generalize cleanly to other jurisdictions. Doing one country exceptionally well beats doing ten countries adequately. International support is a roadmap item, not a 2026 item.

What's the license?

AGPL-3.0-or-later for the core, with an explicit exception: extensions that talk to the ledger only through the documented Extension API may carry any licence, proprietary included. The stdio MCP bridges (accounted-mcp, and the legacy gnubok-mcp) are MIT-licensed. Full details in LICENSE on the GitHub repo.

Can I self-host?

Yes, with Docker and a Supabase project. The full source is on GitHub and the setup is documented in docs/SELF-HOSTING.md. Self-hosted instances bring their own AI backend for the in-app AI features (the Anthropic API, AWS Bedrock, or any OpenAI-compatible endpoint, local models included); the MCP server needs none. Bank sync runs over PSD2 via Enable Banking, on your own Enable Banking credentials.

Is there an SDK?

Not an official one. The REST API is plain HTTP with an OpenAPI 3.1 spec, and we publish llms.txt and llms-full.txt so a coding agent can generate a typed client for your language in minutes. The MCP bridge (accounted-mcp, MIT-licensed) covers the agent path.