SlowBooks Pro 2026: a local-first replacement for QuickBooks Desktop

A replacement built after a hard drive died and took the licence with it

The README tells the story of how this project started, and it is unusual to find one. The author ran QuickBooks 2003 Pro for fourteen years for side business invoicing, then the hard drive died, and with it any way to reinstall the software, because Intuit's activation servers have been dead since around 2017. The licence that had been paid for was, in the author's words, worthless.

So he built a replacement and moved his own data out of the old .QBW file with IIF export and import. Early versions carried invented decompilation comments referring to QBW32.EXE offsets and Btrieve table layouts, written as a tribute to software that had stopped working. The README says the last of those comments came out in v2.14.0 and that the fiction now lives only in the origin story, and it states plainly that the project is an independent from-scratch reimplementation with no Intuit source code or binaries available, decompiled or used.

The product itself is presented as free and source-available, with no cloud, no account, no telemetry, no caps and no paid tiers. The licence field is a custom one that GitHub cannot classify, so the LICENSE file is the place to look, and the word source-available rather than open source is the author's own choice.

The desktop installer is the primary distribution, with a Windows executable and a macOS arm64 DMG, and Docker is offered as an optional path for Linux servers.

The register is the ledger, and bank feeds are a review queue

The feature list is long enough that a summary would be useless, so a few structural choices describe the shape of the application.

Banking is the one that differs most from the packaged accounting applications. The register is the ledger, so entries post directly, imports land as a review queue rather than as facts, and reconciliation happens over ledger lines. Statement import covers OFX and QFX files as well as CSV from Bank of America, Chase and PayPal, with de-duplication, and bank feeds come from SimpleFIN, where the README is explicit that you hold the bank credential and there is no middleman server. Auto-categorisation rules are shared between the feeds.

Around that sit accounts receivable with invoices, estimates, credit memos, recurring schedules, batch payments and multi-invoice payment allocation, accounts payable with purchase orders, bills, vendor credits and aging, and a double-entry core with automatic and manual journals, closing-date enforcement, an automatic audit log and a fifty-account contractor chart of accounts.

Inventory is perpetual, with weighted-average cost, automatic cost of goods sold and reorder points. Reporting covers profit and loss both plain and by class, balance sheet, trial balance, the general ledger, cash flow, sales tax with a pay-to-government flow, Schedule C and a printable PDF pack.

Payroll is the full US module: W-2, W-3, 940 and 941, deductions, garnishments, paid time off, onboarding and a token-accessed employee portal.

Tax forms carry a hash and an audit chain

The feature the README presents with the most emphasis is not an accounting one. Every W-2, W-3, 940 and 941 PDF carries a SHA-256 content hash and an audit identifier printed in the footer, and an auditor can recompute the hash to confirm the form has not been edited since it was generated. The verification trail lives in a local chain called document_audits. The README is careful with the claim, calling it a verification trail rather than a watermark.

That is a specific and checkable design: the artefact a third party receives can be verified without trusting the machine that produced it, and the chain that backs it stays on the local file rather than on a server somewhere else.

The accessibility work is in the same spirit of being explicit. The project states a goal of conforming to WCAG 2.1 AA, with every form field named so a screen reader can say it, AA contrast in both themes on every page and dialog, real dialogs rather than imitation ones, announced notifications, and every generated PDF tagged to PDF/UA-1 so that tax forms read to a screen reader. Known gaps and how to report a barrier are documented in docs/accessibility.md and on an accessibility page of the project site.

For a business where a form has to be read by someone using a screen reader, or filed and later audited, those two details matter more than the number of reports the application produces.

The newest release is a working bridge to QuickBooks Desktop

Version 2.23 is a compatibility release, and it is the most concrete thing in the changelog because it deals with the data formats QuickBooks Desktop still writes.

Invoices arrive from a QuickBooks Desktop Transaction Detail report saved as CSV, with their lines, jobs and numbers, and the report's Open Balance column decides whether the invoice is open or paid. The IIF export carries an invoice's job, items and quantities in the way Intuit's own sample files do, so a round trip keeps them, and the IIF import names the transaction types it does not take and counts them rather than dropping them silently.

Several fixes in the same release are about accounting correctness rather than import. A payment or bill payment recorded with an Idempotency-Key is booked once however many times the request arrives, which matters when a client retries. Editing a posted bill or invoice leaves a DELETE event for every old line, so the audit trail does not lose the previous version. Line quantities keep four decimal places, so an imported 2.125 stays 2.125 instead of reading as 2.12 and losing cents on the next edit. And the invoice form now says that creating an invoice posts it, which is a disclosure aimed at the person clicking the button.

The last of these is the sort of thing that separates accounting software that is careful from software that is merely functional.

The whole app is agent-operable through a local REST API

The AI story in this project is unusual, because the emphasis is on where the data goes rather than on what the model can do.

Every install serves a self-documenting local REST API, 561 operations in version 2.23.5, and the README says it was built for Claude Code and Grok first, with any agentic command line tool able to work with it. An AI setup guide with a paste prompt is published on the project site.

The privacy position is stated in plain terms. What stays on your machine is the company file and the API. A cloud-backed tool's model does not, because what the agent reads from your books goes to that provider under that provider's terms, and only a model you run locally, and have checked makes no outbound calls, keeps everything at home. AI Insights has the same shape: it sends the figures it is given to the provider you chose, over public HTTPS only.

Providers can be chosen from eight options, Anthropic Claude and xAI Grok first, then Groq, Cloudflare Workers AI, OpenAI, Google Gemini, a Cloudflare Worker you host yourself, or any OpenAI-compatible endpoint you name. Keys are encrypted at rest with versioned, rotatable ciphertext.

That is a defensible design for a bookkeeping tool, and it also means the privacy story depends on choices made at install time rather than on a promise in the documentation.

FastAPI, Postgres and a container path beside the installers

The technical stack is visible in the dependency list, and it is a modern one with some deliberate pins.

The web layer is FastAPI with uvicorn, and the data layer is SQLAlchemy 2.0 with Alembic for migrations and sqlcipher3 for the encrypted company file. The SQLAlchemy pin carries a comment explaining that 2.1 changed the meaning of a postgresql:// URL, which broke every fresh image until the move was made deliberately. The requirements file also records the reason for several pins, including a starlette version chosen to clear three published vulnerabilities and a python-dotenv bump for a symlink following issue, so the pin list reads as a security log rather than as inertia.

Documents are rendered with Jinja2 and WeasyPrint, which is also the source of the PDF/UA-1 tagging. Receipt intake OCR is a second tier feature that deliberately adds no Python dependencies, because it shells out to a user-installed tesseract binary and to the poppler-utils tools instead.

The container path runs Postgres 17 on the compose network with the database published on port 5433 and the application answering on port 3001:

docker compose up

The image is built from python:3.13-slim, with the PostgreSQL client, tesseract and poppler installed as system packages. The Docker files also carry a documentation centre point, a Cloudflare directory and a packaging directory, along with an alembic.ini, a run.py and a desktop_launcher.py.

The wiring audit fails the boot instead of the feature

One engineering decision stands out, because it addresses a failure mode that plagues JavaScript and Python codebases.

Development and debug containers run a frontend and backend wiring audit before uvicorn binds the port. If the routes and the JavaScript have drifted apart, the boot fails rather than the feature failing later with a 404 in the middle of a task. Release images gate on the same check in continuous integration.

That is a small script with a large effect on how a large application behaves under change, and it is the sort of thing that is usually skipped in a project that has to ship quickly.

The development tooling is equally deliberate. The ruff configuration selects an explicit ruleset, E4, E7, E9 and F, with a comment explaining that ruff 0.16 widened its defaults and broke the build with no code changes, so the ruleset is pinned rather than widened by accident. Black is left at its own defaults of an 88-character line, and one legacy rule is waived for the test directory alone.

The release cadence matches the pace of the work: v2.23.3 on 2026-10-16, v2.23.4 on 2026-10-17 and v2.23.5 on 2026-10-18, with the last push on 2026-10-20. The project is being built in public, quickly, by one person.

Editorial conclusion

SlowBooks Pro 2026 fits a small business that wants its books on its own hardware, with no account, no telemetry and no paid tier, because the ledger, the reports, the payroll module and the bank feeds all run locally and the Server Edition adds users and roles without a second product. It is the wrong choice if you need the multi-user features of a mature hosted platform, because a single maintainer project carries the risk, and it is the wrong choice if audited tax filings are not your use case, since the SHA-256 audit chain is a verification aid and not a regulatory process. Before you commit, read the LICENSE file yourself, because the licence is a custom one that GitHub cannot classify, try the Docker path with docker compose up on a spare machine, and check the accessibility documentation to see whether the WCAG 2.1 AA work covers the screens your own users actually reach.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. VonHoltenCodes/SlowBooks-Pro-2026 on GitHub