Accounting shouldn't need a GUI
SpeyBooks exists because developers deserve accounting tools that work the way they do.
The problem
Most accounting software is built for accountants. Fair enough. But if you're a developer running a sole trader business or a limited company in the UK, you end up clicking through dashboards to do things that should be a single API call.
You want to generate an invoice from your CI pipeline. You want to reconcile bank transactions with a script. You want your accounting data in a format you can query, version, and automate. What you get instead is a web form that asks you to pick a date from a calendar widget.
The existing tools are fine products. They just weren't built for the way technical people work.
What SpeyBooks is
SpeyBooks is accounting software built API-first. Every feature that exists in the web interface is also available through the REST API — 198 endpoints across 31 resources. If you prefer the command line, use the API. If you prefer a GUI, the portal is there. Both are first-class.
It handles double-entry bookkeeping, invoicing, expense tracking, bank reconciliation, VAT returns, and dividend management for UK businesses. All monetary values use minor units (integers in pence), matching the Stripe convention. No floating point. No rounding surprises.
SpeyBooks is built for UK developers and contractors who want to generate invoices from code, reconcile transactions programmatically, and export their ledger without permission or proprietary tooling. Sole traders and limited companies.
If you need multi-seat approval workflows or enterprise procurement integrations, we're probably not the right fit today. That may change as the product grows, but right now the focus is on individuals and small companies who value control over complexity.
What it does
A quick overview of what's actually in the box, because the feature set has grown well beyond basic bookkeeping:
Self-service migration
Upload your Xero, FreeAgent, or QuickBooks exports. The wizard infers the format, imports contacts and balances, then verifies your ledger to the penny. No re-keying. No migration service.
Auto-categorisation
A lattice-scored inference engine that evaluates every rule, ranks by specificity, and produces an evidence trail for each decision. Not keyword matching — auditable logic you can inspect and override.
Limited company features
Director Loan Account tracking with S455 exposure calculated at 33.75% and Benefit in Kind at HMRC official rate. Dividend declarations with board minutes and PDF vouchers. Year-end snapshots for review with your accountant.
Developer shell
A terminal built into every page of the app. All API endpoints are discoverable via tab completion, ghost text, and clickable entity IDs in responses. Toggle it with Ctrl+J from anywhere.
Bank CSV import
Upload bank CSV exports. The ingestion engine infers the schema, detects columns, and verifies row conservation and balance integrity before committing the import. UK presets for NatWest, Starling, Monzo, and more. Smart Map overrides for edge cases.
Invoicing, reports, and VAT
Full invoice lifecycle with PDF generation, quote-to-invoice conversion, and email delivery. P&L, Balance Sheet, Trial Balance, Aged Debtors, VAT returns. Webhooks for real-time event subscriptions.
All of this is available through the features page in detail, including the 18-card feature grid and interactive demos.
How we think about it
API-first, not API-also
The API isn't an afterthought bolted onto a dashboard. It's the product. The web interface consumes the same API you do.
Transparent by default
Every release is documented in the changelog. Bugs are tracked on a public transparency page. No silent updates.
Your data, not ours
No tracking cookies. Self-hosted Umami analytics — no third-party pixels, no PII. Data stored in the UK. Full ledger export via API, CSV, or SQL. We do not sell or monetise your financial data.
Small and intentional
SpeyBooks is bootstrapped. One developer, no investors, no growth-at-all-costs. The upside: decisions are made for users, not shareholders.
Defence in depth
Your financial data is isolated at the database level using PostgreSQL row-level security. Every query is filtered by your organisation before it ever reaches the application. Even if the code has a bug, the database won't return another tenant's data. It's not a feature we bolt on later — it's how the system was designed.
Technology
SpeyBooks is built on Node.js with a Fastify API, React frontend, and PostgreSQL. Payments through Stripe. Email through AWS SES. Hosted on GCP in the UK. The marketing site is Astro. API documentation is a bespoke Astro application with a custom sidebar, scroll-synced code panels, full-text search, dark/light mode, and OpenAPI-driven content generation.
Portal frontend architecture and data flow
The frontend is a three-layer single-page application. Page routing sits at the top (React Router), feature components in the middle, and a shared data layer at the bottom (TanStack Query for server state, Axios for API calls). This keeps data flow predictable and components focused.
One rule matters more than any other in an accounting frontend: the client never calculates totals. Components send raw inputs — quantities, unit prices, tax codes — and the server returns authoritative numbers. The UI only displays what the API computes. We call this "display math only." It means there's one source of truth for every figure, and it lives on the server.
On the backend, the Fastify API follows a controller → service → repository pattern. All monetary values are integers in minor units (pence) throughout the stack. The database uses DECIMAL columns; conversion happens at the API boundary.
Row-level security
Multi-tenant accounting software has one job above all others: never show you someone else's data. Most platforms handle this in application code — every database query includes a WHERE organisation_id = ? filter. That works until someone forgets to add it, or a new query slips through code review without one.
SpeyBooks pushes tenant isolation down to PostgreSQL itself using row-level security. Every request sets a session variable identifying your organisation. The database enforces policies on every table — SELECT, INSERT, UPDATE, DELETE — ensuring that only rows belonging to your organisation are visible or writable.
This means tenant isolation isn't dependent on every developer remembering to add a WHERE clause. It's structural. The database rejects cross-tenant access regardless of what the application code does. A missing filter returns zero rows, not someone else's invoices.
RLS is enforced across all 25 tenant-scoped tables, including invoices, transactions, contacts, accounts, and bank reconciliation data. Admin operations use a separate database role that bypasses RLS under controlled conditions. The policies are verified by an automated test suite that confirms cross-tenant isolation, safe defaults when no context is set, and correct admin bypass behaviour.
The codebase is strict TypeScript throughout, with Zod validation on every API input, parameterised queries only, and an audit trail on all sensitive operations. These aren't bullet points — they're engineering decisions that matter when your books are involved.
Who built it
SpeyBooks is built by William Murray, a software engineer based in the Scottish Highlands with 30 years of experience in UNIX systems. He runs SpeyTech, a technology practice focused on deterministic computing and developer tools.
SpeyBooks came from solving his own problem: needing accounting software that worked the way a developer thinks. The existing options were either too enterprise, too consumer, or too expensive for what they offered. So he built one.
William also maintains several open source projects and wrote C From Scratch, a book on safety-critical C programming.
Want to try it?
SpeyBooks is in early access. The first 50 users get a 90-day free trial.