Why we're leaving QuickBooks

In February 2026, I asked an AI agent to do the boring part of our 2025 close. It did ninety boring things wrong.

While closing Hyperspeed’s 2025 books, I wired Claude Code to the QuickBooks API and asked it to match three months of Shopify Ads receipts to credit card transactions.

It matched the first receipt to the wrong charge. Off by one, it then matched the next receipt to the next wrong charge, and the next, and the next. By the time I caught it, ninety Shopify Ads receipts sat one slot off.

QuickBooks accepted every match. The credit card reconciliation refused to balance.

A few days later I found the same failure in a different shape. A transfer between two of our accounts had only one leg in QuickBooks. The bank feed for the other account had silently disconnected months earlier, and nobody had backfilled the missing window. QuickBooks never warned us. Transfer matching caught the gap.

Both failures said the same thing. QuickBooks kept the ledger, and we were the control system.

That is the hidden job inside QuickBooks: you catch the wrong matches, you notice the missing feed, you reconcile until the software’s version of reality matches the bank’s. We want to change that part — not the accountant’s judgment or the bookkeeper’s expertise, but the work underneath both. Chasing documents. Detecting gaps. Checking matches. Unwinding bad automation. Proving the books are complete.

So we are leaving QuickBooks.

What is the work we actually do at year-end?

The journal entries aren’t the hard part. The hard part is everything upstream.

You’re finding receipts for AWS charges from eight months ago and working out whether each vendor charged GST/HST. You’re matching USD receipts against CAD card lines that never tie exactly, because of intermediate FX, settlement timing, and card-network spreads. You’re noticing a missing bank-feed window because a transfer between two of your accounts only has one leg in the ledger. You’re deciding whether a new SaaS subscription is operating expense or part of COGS, and routing the uncertain items somewhere for review.

We call all of this “bookkeeping,” and most of it isn’t. The entries were always the easy part. What fills the weeks between “I should close the books” and “the books are closed” is the document work that has to happen before any entry is possible.

This is sharper for a small Canadian SaaS than for a comparable American one. To recover GST/HST input tax credits and file the T2 correctly, every USD vendor invoice needs receipt-to-bank-line fidelity, with FX conversion in between. That is the actual job of year-end close.

Why doesn’t outsourcing the mess fix it?

Hiring someone moves the work to a new desk. It doesn’t remove it.

We would still be the source of every receipt, every clarification, every “yes, this vendor charged HST.” The advice to just hire a bookkeeper assumes the work is journal entries. For us the labor is upstream — finding receipts, deciding whether a vendor is GST-registered, classifying a new SaaS subscription — and none of that goes away by handing the books to someone else. A bookkeeper adds a routing step.

This is not an argument against bookkeepers or accountants. It’s an argument against making skilled people do low-leverage coordination work. A good accountant shouldn’t be your receipt-chasing API. A good bookkeeper shouldn’t be the alerting system for a broken bank feed.

The software should collect the evidence, preserve the provenance, expose the uncertainty, and route the exceptions. Humans review what matters.

The current stack turns everyone into a bookkeeper: founders, accountants, agents. We don’t want a faster way to route the mess. We want less mess.

Why does QuickBooks let the mess in?

Because QuickBooks records what happened. It doesn’t control what should happen.

Shopify Ads bills Hyperspeed about thirty times a month, all from the same vendor, all for similar but not identical amounts — ad spend varies, billing pacing varies, and the daily caps don’t tie to obvious totals. The agent matched receipt one to the wrong charge. Nothing in QuickBooks told it that the match had consumed a transaction it shouldn’t have, so receipt two slotted into receipt one’s place, receipt three into receipt two’s, and on down the line. Three months later: ninety wrong matches, and a credit card reconciliation that wouldn’t balance.

The bank feed failed the same way. One of our accounts silently disconnected mid-year and QuickBooks didn’t notify us. On reconnect it didn’t backfill the missing window, it just resumed from a recent date. Recovery was manual: log into the bank’s web portal, sometimes extract figures from PDF statements, type each line back into QuickBooks by hand.

Same shape both times. Wrong state enters QuickBooks, QuickBooks records it faithfully, and the catch comes from an accounting invariant rather than from the software. A system of record is not a system of control.

The wrappers around double-entry change every decade. The control model hasn’t changed since the wrappers were paper.

Why doesn’t putting an agent on top of QuickBooks fix it?

Because an agent isn’t a human user. It acts in batches, with confidence levels, across many entries at once. QuickBooks has no concept of any of that. It treats every posting as a single human action: certain, sequential, hand-typed. Put an agent on top of that data model and you accelerate the mess.

The cascade was a structure failure. The agent could match receipts. What it couldn’t do was tell that its previous match had consumed a transaction it shouldn’t have, because QuickBooks gave it no way to know.

An agent-shaped ledger needs things QuickBooks doesn’t have:

Provenance on every entry: who or what posted it, when, and with what evidence attached.
A confidence score on every posting, so uncertain matches land in a review queue instead of the books.
Run grouping, so the unit of work is the run and not the line.
Idempotency, so re-running a pass doesn’t double-post.
Run-level rollback, so a bad run undoes in one move instead of ninety hand-reversals.
An exception queue that catches anomalous postings before they reach the books.

QuickBooks has none of it. Every match the agent makes looks identical to a human entry. The agent didn’t fail because it was incapable. It failed because the system around it treated it as a human user.

What does the mess look like when it disappears?

Evidence gets collected at the moment a transaction happens, so document chasing months later goes away. Confident matches land in the ledger automatically and uncertain ones land in a review queue, so manual receipt matching goes away. Bank-feed gaps get reported directly instead of surfacing as transfer asymmetry at year-end. Vendor classification is learned from prior decisions instead of redone each close. Rollback is one operation on a run. Every posting carries its own provenance, so “who entered what and why” is a query rather than archaeology in the audit log.

The judgment stays human. Whether an expense is capital or operating, how accrual policy is set, when revenue is recognized, how tax is treated, what gets approved at year-end, whether an uncertain match should hit the books or wait for review — people decide all of that. The software’s job is to give those decisions clear evidence and good controls.

What are we doing about it now?

We’re running Equated alongside QuickBooks for Hyperspeed’s books, and QuickBooks still owns the source of truth for the 2025 close. Equated gets trusted with one new workflow at a time, starting with what QuickBooks does worst.

Today that means dual-writing some transaction categories into both ledgers: same input, two systems, and we watch what diverges. Next is a parallel close, with Equated running alongside QuickBooks for 2026 and the outputs compared entry by entry. When the two match consistently, QuickBooks becomes archival. It moves to read-only once Equated covers the full close, and not before.

We aren’t pretending Equated is finished. This is what dogfooding looks like: buggy software, our own books, real stakes. What makes the cadence safe is the same thing that saved the February close. The accounting invariants catch us if we drift — reconciliation, double-entry, transfer identity. Every check that worked in QuickBooks still works in Equated, because those are properties of double-entry itself, not of any vendor’s software.

Frequently asked questions

Doesn’t QuickBooks have receipt capture and auto-matching?

Yes, and the capture works fine. Auto-match fails when the receipt total and the bank line don’t tie exactly, which is the common case for foreign-currency receipts. That leaves the matching manual.

Why not just close monthly?

For a business where bookkeeping doesn’t drive operating decisions, monthly close is wasted effort. Our signal lives in Stripe, credit-card statements, and the cash balance. Annual works for us. If your books drive weekly decisions, this advice doesn’t apply.

Why not just hire a bookkeeper?

The bottleneck is document handling, not bookkeeping labor. A bookkeeper still needs every receipt and invoice routed to them, and that hand-off is the rate-limiting step.

Doesn’t QuickBooks have an audit log?

It has an audit log of user actions. It doesn’t distinguish agent actions from human ones, group operations into runs, or support run-level rollback. That’s necessary for accounting software and nowhere near sufficient for software that hosts AI agents.

Are you saying AI replaces bookkeepers and accountants?

No. The current stack turns skilled people into receipt-chasers and reconciliation detectives. A good accountant should be reviewing evidence, handling exceptions, and applying judgment. Routine coordination work belongs to the software.

If you’re running a North American SaaS or ecommerce company, doing your own books, and the words “ninety wrong matches” felt familiar, we’re building Equated for you. Start below, or email hello@equated.co — two-line replies preferred.