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. If the UI can do it, the API can. If the API can't, neither can the UI.
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 — 123 endpoints, OpenAPI 3.1, 482 structured error codes.
• MCP server as gnubok-mcp for Claude, Cursor, and any MCP-compatible client, or over OAuth 2.1 as a hosted connector.
• Webhooks — 24 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 provisioning gap you should know about first.

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: idempotency keys (118 of 123 endpoints), scope-based authorization, and structured errors that carry a recovery hint.

Use gnubok_sk_test_* keys against the sandbox while you build.

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, and write scopes must be ticked explicitly on the consent screen.

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

{
  "mcpServers": {
    "gnubok": {
      "command": "npx",
      "args": ["gnubok-mcp"],
      "env": {
        "GNUBOK_API_KEY": "gnubok_sk_test_...",
        "GNUBOK_CLIENT": "claude-desktop"
      }
    }
  }
}

The client discovers 130+ tools automatically. Every write 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. The core is AGPL-3.0, so embedding it in proprietary software needs a commercial licence; terms are set after a review of your volume and use case. Contact us via /byraer, and read Embedded accounting for SaaS first — it's honest about what isn't built yet.

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	130+ tools, official gnubok-mcp
Audit log	Often partial	Complete append-only event log
Source license	Proprietary	AGPL-3.0 core, commercial available
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 — 24 event types, with delivery inspection and retry. What's still open:

1. Long-running MCP operations with streaming for year-end and bulk reconciliation, where progress over minutes matters and today you get silence.
2. Programmatic company provisioning. /api/v1/companies is read-only; new companies go through the BankID web flow. This is the main blocker for self-serve embedded use cases.
3. Peppol / e-invoicing and K10 are the two most-requested compliance gaps.

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. Spin up a sandbox account at app.accounted.se/register (free, no credit card).
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 API-first architecture: every operation in the system is also an API endpoint, every endpoint is also a tool over MCP. There is no UI layer that the API can't reach. 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 for the core. Commercial licenses available for embedded use cases (white-labelled SaaS, agency platforms, multi-company deployments). The MCP server package, gnubok-mcp, is MIT-licensed. Full details 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 Anthropic or OpenAI key for the AI features. Bank connections run over PSD2 via Enable Banking.

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 server package (gnubok-mcp) is MIT-licensed and covers the agent path.