:
August 20, 2026
Our vision for T:0: books as a living view of business events, and a platform AI agents can build on without breaking trust.
Here's the story of one order. In March, a customer signs an $8,400 annual subscription. In April, they add four seats. In May, they dispute a charge, and win. In June, they upgrade and renew early. One customer, one order, one relationship: a single business object living its lifecycle, looping through states the way real business always does.
Now ask the books what happened. The books answer with eleven journal entries, posted across four months by three people and two systems, none of which reference each other. The invoice entry knows nothing about the dispute. The dispute adjustment knows nothing about the renewal. The story of the order, the thing that actually happened, exists nowhere except in the memory of whoever handled each step.
Multiply that by every order, bill, payroll run, and transfer, and you have modern accounting: the most heavily instrumented operation in the history of commerce, documented after the fact like a field report.
Strip accounting down to its actual job and it's this: a faithful representation of what a business did, in a language lenders, auditors, regulators, and boards all agree on. Represent reality, faithfully. That's the whole mandate. And the industry fulfills it by hand, downstream of systems that already know everything.
We started T:0 with a simple conviction: this is backwards, and the technology to invert it finally exists. This post is the full argument: what the old world gets wrong, what we believe accounting becomes, and how we designed the platform so the coming wave of AI agents makes finance more trustworthy instead of less.
The business happens inside systems that know everything about it. The order system knows the order. The processor knows the payment. The payroll provider knows the run. The bank knows the cash. Then, downstream of all that knowledge, a team of people re-derives what happened and types the conclusions into a ledger. Every journal entry is a conclusion whose reasoning got thrown away.
It's like summarizing a novel by keeping the last sentence of every chapter, then hiring a team to guess the plot.
Everything painful about accounting operations follows from that one design flaw. The close is a month-end project to reconstruct stories from conclusions. Reconciliation is two systems being introduced to each other by hand, every month, forever. The audit is a second team repeating the reconstruction with higher stakes. And any question that matters kicks off a scavenger hunt across five systems and three inboxes.
The flaw isn't effort, and it isn't talent. It's the premise that accounting is something you write about the business after the fact. We think accounting is something you derive from the business as it happens. Everything we build follows from that inversion, and it comes in four layers.
Everything starts with a real-world thing and its lifecycle: an order, a transfer, a contract, a payroll run. Objects carry state, and their state transitions can cycle, because real processes cycle. A transfer might bounce between needs-information and ready-for-dispatch three times before it goes. The March customer loops through signed, upgraded, disputed, resolved, renewed. The model doesn't fight that looping. It's designed for it, because the looping is the business.
Every state change and every action on an object becomes an event. Events are immutable. Nothing edited, nothing deleted, only appended. This layer is the complete history of what happened, which is worth saying more plainly: it's the audit trail, kept as live data instead of assembled later as evidence. In the old world, the audit trail is the paperwork you produce when someone asks. Here it's the foundation everything else stands on.
Not every event matters to the books. A seat upgrade does; a password reset doesn't. Think of this layer as a lens: point it at the event stream and only the events with accounting significance come through. The filter is explicit, inspectable, and versioned, which means “what does accounting care about, and why” becomes a definition you can read instead of a habit you inherit from whoever had the job before you.
From that filtered stream, deterministic rules generate the actual accounting records and post them to the appropriate ledgers. Plural, because one event history can feed many books: a GAAP ledger, a tax ledger, a management view, each just a different derivation over the same immutable events. Same events in, same books out, every single time.
Read the stack top to bottom and the inversion becomes obvious. Accounting stops being something you do to the business after the fact. It becomes a view over what the business did. The audit trail stops being a byproduct of the books; the books become a byproduct of the audit trail. Correct the understanding of an event and every ledger downstream re-derives. Ask why any number exists and the answer is a walk back up the stack, ending at the real-world action that caused it.
The accountant's first objection lands here, and it's a fair one: not everything in the books is an event you can observe. Reserves, depreciation, accruals for bills that haven't arrived. These are estimates, and no event stream contains them. In this model they don't disappear, they become explicit: an estimate is a policy applied to event data. The depreciation schedule reads the asset's history. The payroll accrual reads days elapsed. The returns reserve reads actual return rates. Judgment still sets each policy, and that stays human. The difference is that the policy is written down, versioned, and applied identically every period, instead of living in a spreadsheet with one keeper.
This is what we call the connected accounting map: every object, event, and entry linked, traversable in both directions, with every link held to accounting's standard of proof. A payment provably settles an invoice. A payout provably sums from its payments and fees. Debits provably equal credits, everywhere. And the links do accounting work of their own. An invoice's entries derive from its events, but a settlement's entries derive from a connection: the moment a payment is proven to settle an invoice, the entry that clears the receivable follows from that link. Some of the books come from what an object did. The rest come from how objects connect. And when a link can't be proven, a payout that won't sum, a payment with no invoice, the map doesn't guess. It records the gap and puts it at the top of a worklist. A gap stated plainly is worth more than a connection asserted confidently.
The unglamorous prerequisite is that every source system speaks its own dialect. Take the word “deposit.” To QuickBooks it means a batch of customer payments headed for the bank. To NetSuite it means cash a customer paid before any invoice exists. To your bank it means money showed up, full stop. One word, three unrelated events, three different journal entries. T:0 settles the argument at ingestion: the batch becomes customer payments, the prepayment becomes a customer liability waiting for its invoice, the bank line becomes a transaction waiting to be confirmed. Every dialect resolves into the shared event model before anything downstream ever sees it.
Most companies never get this right, and it isn't for lack of trying. It's because every tool they own starts at the journal entry, so the reconciliation and visibility they want has nothing to stand on. So it's worth saying plainly what the right way looks like, and what it's worth:
Because every expected cash movement exists in the model before the cash moves, a payout, bill payment, or payroll funding predicts its own bank line: amount, account, window. The bank feed confirms expectations instead of being matched against mystery. What's left is a short list of true exceptions, each pointing at the exact link that failed. Why it matters: reconciliation stops consuming the first week of every month, and breaks surface the day they happen instead of thirty days later.
In-flight cash between processor and bank, itemized. Clearing account contents, aged, on demand. Unbilled work, unearned revenue, and unapplied payments as live positions rather than quarter-end discoveries. Why it matters: the CFO's picture of cash and obligations is current on a Tuesday afternoon, not three weeks after the period ends.
A ledger derived continuously from events is, in a meaningful sense, always closed. Why it matters: the teams furthest along this path have compressed six-day closes into three and week-long reconciliation grinds into hours, and the deeper change is qualitative. The close stops being a re-derivation project and becomes a confirmation that the derivation held. The human work that remains is the work that should remain: estimates, review, sign-off. The mechanical part disappears.
Every number carries its lineage back to real events, so evidence gathering becomes traversal. Auditors sample because tracing is expensive; when tracing is free, verification can cover the whole graph. The judgment side of an audit stays: estimates, controls, disclosures. What disappears is the hunting. Why it matters: audit prep measured in days, and year-round confidence instead of annual anxiety.
The thread through all four is the same: trust gets cheaper. Reconciliation headcount stops scaling with transaction volume. Questions that used to take a week of hunting come back answered, with evidence attached, in minutes. And the numbers everyone runs the business on stop being weeks old by the time they arrive.
The industry's current answer to AI is to attach agents to old-world systems: agents that match transactions faster, draft explanations faster, close the books faster. The engineering is real and the gains are real, but the ceiling is low, because an agent on top of written-after-the-fact books can only run the scavenger hunt faster. It cannot know what was never recorded beneath it.
We think the next few years play out in three moves. First, agents commoditize: every vendor has them, and speed claims stop differentiating anyone. Second, trust becomes the bottleneck: as agents take on more of the work, the question shifts from “how fast” to “how do we verify what it did,” and systems that can't answer with evidence stall at the pilot stage. Third, the foundation shifts: finance re-platforms onto systems where verification is structural, the way operations re-platformed onto systems of record two decades ago. Accounting doesn't get disrupted by smarter models. It gets rebuilt underneath them.
The end state we're building toward: books that derive themselves continuously, agents that operate the routine stack end to end, auditors that verify graphs instead of sampling papers, and finance teams whose scarce hours go to judgment, the one thing that stays human.
Here's where it gets interesting: most of those agents won't be ours. We think the finance stack's next decade belongs to agents built by us, by partners, and by customers themselves, and the platform is designed so that any agent inherits trust from the system it stands on instead of having to earn it from scratch. Five design commitments make that work:
The pattern across all five: trust is a property of the platform, not a promise of the model. That's the right way to let agents into accounting, and we believe it's the only way that survives contact with an audit.
The old world treats accounting as a writing task: watch the business, then write down conclusions about it, then spend the rest of the month defending the handwriting. Every tool in the category, including the newest AI, accepts that premise and tries to write faster.
We reject the premise. The business already writes its own story, event by event, in the systems where it actually happens. Accounting's job is to represent that story faithfully, and representation is a derivation problem, not a typing problem. Build the event history once, hold every link to the standard of proof, and the books, the reconciliations, the audit evidence, and the AI all become views over the same living record.
Accounting shouldn't be written. It should be derived. T:0 is the system that derives it.
