Why AccountMD exists

It started as a spreadsheet nobody wanted to maintain

The best B2B software replaces a spreadsheet that people are already filling in by hand. AccountMD began as exactly that.

DS
David Sacks

@DavidSacks

Good heuristic for creating SaaS startups: find a commonly used spreadsheet (eg cap tables) and turn it into a dashboard (eg Carta). Replace email attachments with workflows. Spreadsheets are the long tail of datasets that don’t have their own SaaS tool.

Dec 2018

Read on X →

I went looking for a spreadsheet worth replacing, and noticed people abuse them in two telling ways. The first is Goal Seek — dragging one assumption back and forth until the model lands on the number you need: a target return, a break-even price. The second is the trail of saved copies — v1, v2, final, final-FINAL — because a sheet forgets the instant you overwrite a cell, even when you need to know what it said last quarter.

AccountMD is built to do both properly: let you optimise toward a target instead of nudging cells by hand, on top of an immutable ledger that appends every change instead of overwriting it — so the past is never lost and a correction adds to the record rather than erasing it. Consolidating entities across crypto and fiat, with actuals fed live from Xero, is just a feature that falls out of getting those two things right.

That second part — a book that never forgets — is the foundation, and it’s the part you can play with right now. The trick isn’t saving copies; it’s that history is a query: the books store what changed, and any past state is recovered by asking for it as of a moment in time. You can only optimise, or trust, a book that works that way. Here’s what that looks like:

Declarative accounting

Two ways to keep a book

Same ten journal lines, same chart. One book remembers every state it ever held; the other forgets the moment you edit it. Play with both.

Immutable book
Each commit appends to an immutable log — nothing is overwritten. To fix a mistake you append an adjusting line; the original entry and its correction both stay on the record, and every past state stays queryable, plotted as its own series.
DateTypeAmount
No versions yet — commit one to plot it.

Honest cost: the log only grows by what changed (0 entries), never by full copies. At scale you materialise the current state for speed and answer the past with as-of queries — but you never lose it.

Mutable book
Only one book exists. Every edit overwrites in place — the chart shows just the present, and the evidence the books ever said something else is gone.
DateTypeAmount
Net: $1,700
Time-travel: as of knowledge-time…nothing to travel to

The slider is inert: there is no history. 0 edits0 past states unrecoverable.

The trap: it looks tidy — one clean line, no clutter. That tidiness is the data loss.

The axes are the same on both: X = entry date, Y = cumulative net (revenue − expense). The only difference is what happens to the past when you change your mind.

Why it matters

What immutability buys you

Everything below falls out of the same property: state is derived from an append-only log of events.

Full audit trail

Every version is preserved, so you can answer “what did the books say on day N?” without a backup.

Corrections, not erasures

Fixing a mistake appends an adjusting entry. The original error — and its fix — both stay on the record.

Time-travel queries

Reconstruct any historical state on demand; reporting periods become a filter, not a snapshot you had to remember to take.

AccountMD