What is Accounting as Code?

You wouldn’t manage your infrastructure by clicking through a web portal. You wouldn’t deploy code by filling in a form. So why is your accounting software still a point-and-click dashboard?

Accounting as Code is the idea that financial operations — invoicing, reconciliation, reporting, tax compliance — should be programmable, version-controlled, and automated through APIs. Not occasionally, as an afterthought. As the primary interface.

The Problem with Dashboards

Most accounting software is built for accountants. That sounds obvious, but the consequences for developers are real.

When your accounting tool is dashboard-first, you get:

• Manual data entry where automation should exist
• Export-to-CSV workflows instead of API calls
• Opaque calculations you cannot inspect or verify
• Vendor lock-in because your data lives in someone else’s format

If you run a limited company and bill clients monthly, you probably spend 2–3 hours a month doing things a script could handle in seconds. Creating invoices, categorising bank transactions, reconciling payments, generating VAT returns — all of it manual, all of it repetitive.

That’s not a workflow. That’s a tax on your time.

What Accounting as Code Looks Like

Accounting as Code means your financial operations are API calls. Here’s a concrete example.

Dashboard approach: Log in → Navigate to invoices → Click “New” → Fill in 8 fields → Click “Save” → Click “Send”

Code approach:

curl -X POST https://api.speybooks.com/v1/invoices \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "contact_id": "con_42",
    "line_items": [{
      "description": "February consultancy",
      "quantity": 1,
      "unit_price_pence": 500000,
      "tax_code": "T1"
    }],
    "send": true
  }'

The response gives you a prefixed ID (inv_143), the computed totals in pence (no floating point), the VAT breakdown, and a PDF URL. One request. Repeatable. Scriptable. Testable.

Now wrap that in a cron job or a GitHub Action, and your invoicing runs itself.

The Five Principles

Accounting as Code is built on five principles that developers already understand from other domains:

1. API-First, Dashboard-Optional

The API is the product. The dashboard is a convenience layer that consumes the same endpoints you do. There are no hidden internal routes, no features that only work through the UI.

This matters because it means anything you can do manually, you can automate. And anything we build, you can verify.

2. Immutable Records

Financial records should be append-only. You don’t edit a transaction — you create a reversing entry. This is how double-entry bookkeeping has worked for 500 years, and it maps directly to concepts developers already know: event sourcing, append-only logs, Git history.

Every change is traceable. Every state is reconstructable. No silent mutations.

3. Server-Side Truth

The server computes all totals, tax amounts, and balances. The client displays them. We call this “display math only” — the frontend never calculates a penny.

This eliminates an entire class of bugs where the UI shows one number and the database stores another. When you GET /invoices/inv_143, the numbers you see are the numbers that exist. Full stop.

4. Plain-Text Formats

Monetary values are integers in minor units (pence for GBP). Dates are ISO 8601. IDs are prefixed strings (inv_, txn_, con_). Responses are JSON.

No proprietary formats. No binary blobs. No surprises. Everything is greppable, diffable, and parseable with standard tools.

5. You Own Your Data

Your financial data is yours. Export it any time. Delete your account and it’s gone — properly gone, not soft-deleted behind a flag. No data mining, no behavioural analytics, no selling aggregated insights to third parties.

This isn’t a feature. It’s a baseline.

Who Is This For?

Accounting as Code is for developers who:

• Run a UK limited company (freelancer, contractor, or small agency)
• Already use APIs and automation in their daily work
• Want their accounting to fit into their existing workflow, not the other way around
• Care about data ownership and privacy
• Prefer reading API docs to watching onboarding videos

If you’ve ever written a Stripe integration, you already understand the developer experience we’re aiming for. Prefixed IDs, minor units, idempotency keys, webhook events. That’s the baseline.

What This Isn’t

Accounting as Code is not “no accountant required.” You should still work with an accountant for year-end filings, tax planning, and anything involving HMRC correspondence. What changes is that the day-to-day bookkeeping — the 90% that’s repetitive — becomes automated and verifiable.

It’s also not “accounting for programmers only.” The dashboard exists and works well. But the API is the primary interface, and the dashboard is built on top of it. If you prefer clicking, you can click. But if you’d rather curl, you can curl.

A Different Category

SpeyBooks isn’t a better Xero. It’s not competing on features, integrations, or bank connections. It’s a different category entirely: accounting software that treats developers as the primary user, APIs as the primary interface, and privacy as a default — not a premium add-on.

We store amounts in pence because that’s correct. We don’t connect to your bank because the security trade-off isn’t worth it. We enforce double-entry at the database level because application-level validation is not enough.

These aren’t limitations. They’re design decisions.