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 gnubok 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 webhook, an SDK 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.gnubok.se/api for code-level integrations.
• MCP server as @gnubok/mcp-server for Claude Desktop, Cursor, and any MCP-compatible client.
• TypeScript and Python SDKs as thin clients.
• 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 people are building

The architecture opens a category of applications that simply couldn't be built on legacy bookkeeping APIs because the APIs were afterthoughts. Examples already in production:

• Live runway and burn dashboards wired directly to the ledger. Sub-100-line Python jobs. See Live runway and burn rate from your ledger for the recipe.
• Customer enrichment pipelines combining ledger data, Bolagsverket, and credit signals into unified profiles for sales tooling.
• Dunning agents that monitor receivables, send templated reminders at 30 days, escalate at 60.
• Pricing experiments that read true gross margin per customer and adjust quote ranges in CRM systems.
• Embedded accounting in SaaS products so end customers never leave the host application. Deep dive: Embedded accounting for SaaS (coming soon).
• Anomaly detection over VAT that flags weekly deviations greater than 15 percent and surfaces the driving transactions in Slack.

These aren't speculative. They're built with the same tools you'd reach for in a normal product stack: TypeScript, Python, Make, n8n, Claude, Cursor.

How to integrate

Three integration tiers:

Tier 1: REST API

The boring, reliable path. Issue a token in the gnubok admin (Settings > API > Create Token), pick a scope, and call:

curl https://app.gnubok.se/api/transactions \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "date": "2026-05-12",
    "description": "Stripe payout",
    "lines": [
      { "account": "1930", "debit": 997.60 },
      { "account": "3001", "credit": 1247.00 },
      { "account": "6570", "debit": 249.40 }
    ],
    "idempotency_key": "stripe-po_abc123"
  }'

Same shape as any production-grade write API: idempotency keys, scope-based authorization, structured error responses.

Tier 2: MCP

Install @gnubok/mcp-server in Claude Desktop or Cursor. Add your token as an environment variable. The client discovers ~70 tools automatically. Build agentic workflows by prompting; let the LLM handle orchestration.

Configuration:

{
  "mcpServers": {
    "gnubok": {
      "command": "npx",
      "args": ["-y", "@gnubok/mcp-server"],
      "env": { "GNUBOK_API_TOKEN": "your-token" }
    }
  }
}

Tier 3: Embedded

For SaaS platforms and agency operators that need multi-tenant deployments with rev share or per-tenant pricing. This is the path for building white-labelled accounting inside your existing product. Contact us via /byraer for the embedded tier.

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	gnubok
API surface	Afterthought, partial	First-class, complete
MCP server	None	~70 tools, official @gnubok/mcp-server
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

Three areas of active development in 2026:

1. Long-running MCP operations with streaming for year-end and bulk reconciliation flows where progress over minutes is important.
2. Resource exposure of historical ledger slices as MCP resources, so agents can read selectively without needing to know which tool returns what.
3. Webhook-driven event subscriptions so external systems can react to in-ledger events (period closed, invoice paid, anomaly detected) without polling.

All three land in the AGPL core. Pull requests welcome on GitHub.

Where to start

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

1. Read the API docs at /utvecklare.
2. Spin up a sandbox account at app.gnubok.se/register (free, no credit card).
3. Try the MCP server with Claude Desktop 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. gnubok 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-tenant deployments). The MCP server and CLI tools are MIT-licensed. Full details on the GitHub repo.

Can I self-host?

Yes. The full source is on GitHub. Self-hosted instances can use any LLM (Anthropic, OpenAI, local via Ollama) and any bank connection backend that supports PSD2. Managed hosting is offered as a separate tier for teams that want SLA and Swedish-region compliance without operating their own infrastructure.

Is there an SDK?

TypeScript and Python SDKs are published as official clients. They're thin wrappers over the REST API plus typed tool definitions for MCP integration. Both are open source under MIT.