T:0 Engineer: Why Do AI Accountants Always Guess? Because the General Ledger Only Records Conclusions, Discarding Context

Over the past two years, a wave of AI accounting products has emerged, making nearly identical promises on their launch pages: agents embedded into ledgers, reconciliation cut from days to minutes, automated drafting of flux explanations (explaining why account balances changed), "close in hours, not weeks," and over 90% of manual work automated.

Recently, T:0, a financial technology subsidiary of cross-border payments company Airwallex, emerged from private beta and opened to US startups. Erik (@eya0), a member of T:0's engineering team, published a long-form essay on X titled "Why Every AI Accountant Fails, and Why Palantir Knew First".

Existing AI accounting products cannot answer "why." The problem is not model capability, but the flattened general ledger beneath their feet created by software. When accounting was born five hundred years ago, it already came with its own ontology (double-entry bookkeeping); the mistake is that most software chose to ignore it, discarding the links the moment entries are posted and leaving behind only a list of conclusions.

This is a product and architecture essay written by the T:0 team; customer cases and performance figures are the vendor's own claims. The author draws on the "Objects / Links / Actions" framework of Palantir (a US software company that builds data platforms for governments and large enterprises) to explain why fixing the ledger foundation is a prerequisite for AI to provide trustworthy answers in finance.

The General Ledger Only Records the "Ending," Throwing Away the "Story"

To understand this assessment, one must first understand what the general ledger (GL) underlying accounting software actually looks like.

The fundamental rule of double-entry bookkeeping is actually very simple: every transaction is recorded on at least two sides—one debit, one credit—and both amounts must balance. No matter which modern enterprise resource planning (ERP) system you open (such as SAP, NetSuite, or QuickBooks), the general ledger is essentially a flat transaction log: date, account, debit, credit, description—easily running into millions of rows.

Every journal entry is the ending of a story. As for the causes, consequences, and transaction trail of the story, the general ledger contains none of them.

In the essay, Erik illustrates this with a specific case of an annual subscription charge:

Figure 1: On the left, 7 isolated rows in the general ledger; on the right, the same transaction connected together.

A single business event turns into 7 isolated journal entries in the general ledger, spanning a week, across three dates, and dispersed among five accounts: accounts receivable, deferred revenue, processor clearing, fees, and cash in bank. Every dollar on the expense side follows the exact same pattern, from corporate card charges to payroll runs funded out of two accounts. The right side of Figure 1 depicts only this single revenue line; a complete map covers the entire general ledger: bills, payroll, corporate cards, transfers, and equity.

The rest of the story is scattered outside the ledger: payment processors, billing systems, bank feeds, and data warehouses. This is the very reason month-end close exists—a team of people working backward from conclusions to reconstruct the story; auditing is a second team repeating the exact same exercise, under higher stakes and with even less context.

Now, connect a frontier LLM to this flat general ledger and ask it the question that a CFO genuinely cares about:

"Why did deferred revenue change this month?"

The T:0 team said they ran this test: they exported a general ledger, handed it to a frontier LLM, and asked the same question three times, receiving three confident, beautifully written, yet mutually contradictory answers. This was not a failure of model capability; the answer simply was not in the data. The general ledger records conclusions while discarding connections. Asking an AI to explain a business solely from a flat general ledger is like asking someone to deduce the complete plot of a movie purely from the closing credits. You get fluent, grammatical, plausible-sounding prose, but it is nothing more than a guess.

The Industry's Solution: A Faster Bookkeeper

The engineering behind the products listed at the outset is real; reconciliation, drafting, and closing have indeed become faster.

The T:0 team's genuine reaction: So what?

Every single one of these products accepts the status quo of the general ledger—a flat list of conclusions, plus a collection of source systems that never talk to each other—and places an extremely fast agent on top. The agent is indeed faster at data archaeology: faster matching, faster drafting, faster closing. But it has not changed what is knowable.

If the data model itself cannot answer "why," neither can the agent sitting on top of it. It can only guess more fluently. And a fluent guess is precisely what CFOs, auditors, and boards of directors can never accept.

A faster bookkeeper is still just a bookkeeper. The ceiling lies not in the model, but in the foundation.

To enable AI to deliver trustworthy answers in finance, one must first fix the foundation beneath its feet—and fixing foundations is precisely what made Palantir famous.

What Palantir Actually Figured Out

The word "Ontology" originally belonged to philosophy departments and database textbooks, but CEOs now discuss it on earnings calls. In Palantir's demos, the logic is always consistent: AI does not fail because models are weak, but because they have no solid ground to stand on. Therefore, before letting AI touch decision-making, an organization must build a digital twin—the objects that exist, the links between them, and the actions that change those objects—allowing AI to operate on this model rather than staring at a disconnected pile of raw tables.

Stripped of mystique, the concept of an ontology is actually quite simple, consisting of just three fundamental building blocks:

• Objects: The nouns of a business. An airplane, a shipment, a purchase order. They are not mere rows in a table, but entities endowed with attributes and lifecycles.
• Links: The relationships between nouns. This shipment fulfilled that order; this part belongs to that airplane.
• Actions: The governed verbs. Clearly defined, auditable operations—the only ones permitted to mutate object states and write back to source systems.

The author argues that this is precisely the key to how Palantir built a massive business: when models reason over typed objects and real relationships, their answers are grounded in reality; when they reason over raw tables, they can only produce plausible-sounding prose. Models are becoming commoditized; the real moat is the semantic layer beneath the model's feet.

Yet the hard part of Palantir's business is that every customer's world is different. An airplane is not a shipment, nor is it a patient. Palantir must deploy engineers to model from scratch for every customer and every object, because in day-to-day operations, the ontology is bespoke, requiring case-by-case choices for each client.

Accounting Is Born with an Ontology

In 1494, Luca Pacioli published Summa de arithmetica, geometria, proportioni et proportionalita, documenting the bookkeeping methods used by Venetian merchants of the era. Viewed through a modern lens, what he wrote was effectively a data structure definition (schema): every economic event is recorded as specific types of entries, debits and credits must balance, entries link to the events they settle, and transactions chain together. Double-entry bookkeeping is not merely an accounting convention; it is an ontology—quite possibly the longest-running one in production.

Unlike Palantir's clients, the ontology of accounting is entirely standard. T:0 surveyed the object models across 7 mainstream ERPs ranging from QuickBooks to SAP and found the exact same thirty-plus objects appearing in every single system: Invoice, Credit Memo, Payment, Refund, Prepayment, Bill, Payout, Payroll Run, and so on. These vendors were not copying one another; the objects are consistent because they correspond to real business events, and commerce looks much the same everywhere. The nouns were established hundreds of years ago.

There is another characteristic that sets accounting apart from every domain Palantir has ever modeled: in accounting, links are provable.

In an operational ontology, "this shipment is related to that vendor" is a modeling decision—useful, but an assertion made by the modeler. In accounting, however, a refund corresponds definitively to a specific payment, and a payment definitively settles a specific invoice. The entire graph must satisfy the ironclad law that debits equal credits everywhere. This is an inherent integrity check across the whole graph, predating the modern coining of the term "data validation" by five hundred years. In other domains, once an ontology is built, one can only hope it is correct; accounting comes with its own verification mechanism built in. For AI, this distinction is paramount: on an assertion-based ontology, you have no choice but to trust that the model's evidence is correct; on a provable ontology, you can verify.

This makes the current state of accounting software particularly peculiar: the ontology is right before our eyes—ancient, standardized, and arithmetically verifiable—yet no system is actually built on top of it. ERPs store the objects, only to discard the links the moment entries are posted. The journal entry is where the story goes to die.

Consequently, T:0 took the opposite approach to building its system.

The Connected Accounting Map

T:0 had a single starting point: preserve the story. Every number on a financial statement should be the terminus of a path that can be traced backward through every object and every link, all the way to the original business event that triggered it. T:0 calls this the "Connected Accounting Map."

The author claims in the essay that this map is already running in production, generating billions of accounting records annually for finance teams at companies including Reddit, GoodRx, Vimeo, and MasterClass.

Note: These customer names and the "billions of records annually" appear only in the author's essay and are not mentioned in Airwallex press releases, the T:0 CEO's launch blog post, or the official website; they represent the company's own claims. T:0's publicly released materials state that its target customers are US startups.

This map consists of three parts:

Objects

Every economic event entering the system becomes a standard object the system understands: invoice, payment, refund, payout, bill, payroll run, bank transaction. Regardless of which source system it originates from, events of the same class take the same shape; the record knows what it is, who is involved, and which stage of its lifecycle it is in.

This sounds self-evident, but executing it is extraordinarily arduous. While the ontology is standard, data across real-world systems is anything but uniform. The most quintessential example is the word "deposit":

• QuickBooks: Refers to a batch of customer payments being prepared for deposit into the bank; T:0 parses this as "a batch of customer payments."
• NetSuite: Refers to an advance payment made by a customer prior to invoicing (a prepayment); T:0 parses this as "a prepayment awaiting its corresponding invoice."
• Commercial Bank Statement: Refers to any incoming cash; T:0 parses this as "a bank transaction awaiting confirmation."

One word represents three completely unrelated events, corresponding to three distinct accounting entries. If you misinterpret "deposit," the graph will connect a customer's prepayment to someone else's bank transaction, quietly corrupting every downstream conclusion without anyone noticing. This is why this work must be performed during data ingestion, source system by source system, before any AI enters the picture; the map cannot be retrofitted onto existing systems after the fact.

Links

Every object persists relationships as data. This payment settled that invoice; this processor settlement payout swept these 41 payments and deducted 41 processing fees; this refund reversed a specific charge, which in turn corresponded to a specific contract.

The expense side of the ledger follows the exact same logic: bill payments settle vendor bills, transfers fund payroll runs, and bank transactions confirm the money has actually arrived.

Figure 2: The money-in and money-out chains share identical shapes, and every link can be verified bidirectionally.

The bottom row of Figure 2 represents money out, sharing the same structure as the revenue side: starting with vendors and bills, and culminating in bank transactions. The journal entries for the three intermediate steps are:

• Bill line: Debit Expense, Credit Accounts Payable
• Bill payment: Debit Accounts Payable, Credit Bill Payment Clearing
• Payment outflow: Debit Bill Payment Clearing, Credit Cash in Bank

Like processor clearing on the revenue side, "bill payment clearing" is a transit account used while money is in flight: recorded when a payment is sent out and cleared when the bank debits it, normally netting out to zero. The same shape recurs across payroll, corporate card charges, reimbursements, and internal transfers.

The bottom of the diagram details how each link is verified: on the revenue side, payment = invoice balance, payout = total payments − total fees; on the expense side, bill payment = bill total; both sides ultimately require that cash hitting the bank = net settlement amount, and that debits equal credits everywhere.

Returning to that March $4,120 subscription case: in T:0, it is no longer 7 scattered journal entries, but a complete path: Contract → Invoice → Customer Payment → Payout → Bank Transaction, which both humans and machines can traverse bidirectionally (the starting point on the right side of Figure 1 is drawn as an Order). The $123.60 fee for this payment is attached to the payout, with every journal entry remaining linked to the object that generated it. You can also walk it in reverse: starting from that deposit in the bank, first unpack the 41 payments bundled into this payout, locate this $4,120 customer payment, and then trace it back to the invoice and contract.

Accounting demands that links be proven or not made at all: if it cannot be proven, do not link it. If a payout amount does not reconcile, or if a payment cannot find an invoice, the map does not guess; it records the gap and flags it explicitly. In finance, an honest gap is infinitely more valuable than a plausible-looking connection.

Actions

Objects and links describe the world; posting rules change it. Every journal entry in T:0 originates from rules: when an object of this type appears under specific conditions, inspect its linked objects and record this entry. Posting no longer involves on-the-spot judgment or "it's usually like this." Given the same event input, the accounting output is identical every single time.

This does not mean accounting judgment has vanished; rather, judgment has been relocated to where it belongs: made deliberately once by humans and codified into human-readable rules, rather than invisibly and repetitively remade across thousands of transactions every month. As for how AI alters judgment itself, the author notes this will be discussed in a separate essay.

This is also where AI enters the picture, with strict boundaries established—a rigid separation between read and write:

• Read side: AI is free to explore the entire map—answering questions, drafting reports, investigating anomalies, and explaining changes—with every conclusion backed by auditable evidence and accompanied by its traversal path.
• Write side: The AI designs, it never executes. It can propose posting rules, suggest classifications for new vendor spend, or draft policy-implementation workflows. But every proposal must undergo human review, be converted into rules, and be executed by a deterministic engine. AI generates proposals, not numbers; numbers come strictly from arithmetic.

Figure 3 compares the two side by side: for the Objects row, Palantir must model from scratch for each client, whereas accounting objects are universal across the industry; for the Links row, Palantir's connections are asserted by modelers, whereas accounting connections can be arithmetically verified; for the Actions row, Palantir uses governed operations that write back to source systems, whereas T:0 has AI design posting rules that are executed by a deterministic engine.

Figure 3: Item-by-item comparison between the Palantir operational ontology and the T:0 accounting map.

What an Agent on a Map Can Do

An agent on a list can only accelerate yesterday's workflows; an agent on a map can do what old workflows never could—and, according to the author, can do so unattended, because every statement it makes can be verified against the graph it traversed. It is precisely the constraints of the map upon the agent that give humans the confidence to delegate real responsibility to it (it should be noted that this autonomous operation is strictly limited to read-side investigation and verification; writing to the ledger still requires human-approved rules). The author states that among the following five capabilities, the first four represent how T:0's AI works today, while the fifth is the next direction. Here is the overview at a glance:

• Flux analysis: Previously concocting stories around the variance between two balances; on the map, querying the specific underlying contracts and bills along the links.
• Reconciliation: Previously matching the general ledger and bank transactions item by item; on the map, verifying against expectations already present in the graph.
• Audit: Previously sampling manually and extrapolating; on the map, exhaustively traversing the entire dataset year-round.
• Close: Previously scrambling to reconcile in a month-end crunch; on the map, remaining continuously in a closed state.
• What-If modeling: Calculating the impact of new terms on branches of the live ledger. Not yet implemented.

Flux Analysis: "Why" Becomes a Query, Not an Assigned Essay

Today's AI flux analysis (comparing account balances across two periods and explaining the changes) largely guesses based on narrative: the model looks at the variance between two balances and writes a story about that variance.

On a map, ask T:0 why deferred revenue changed, and it does not make up a story; it traverses along the links. For instance, it might return a breakdown like this: 214 contracts recognized revenue per scheduled performance, 12 underwent modifications, and 3 refunds reversed prior recognitions. The expense side works identically: ask "why did cloud costs increase by 40%," and it breaks down directly into the specific underlying vendor bills and card charges, rather than generating a plausible-looking paragraph. The AI traces chains that exist as data, presenting conclusions accompanied by evidence—because the evidence is the very path it walked.

Reconciliation: No Longer Requiring Matching

Bank reconciliation exists because the general ledger and the bank are like two strangers who do not know each other, requiring an intermediary to make the introduction. "Bank reconciliation 90% faster" is the favorite promotional metric among this crop of products.

In T:0, however, that introduction was completed long ago. A processor settlement payout, a bill payment, a payroll funding event—each node pre-announces a transaction expected in the bank, precise to the amount, account, and time window. Well before that March payout hit the bank, it had already specified how much cash would arrive, with the portion attributable to this subscription being $3,996.40. When bank transactions arrive, they are verified against expectations already present in the graph, rather than matched from scratch. The remaining handful of genuine exceptions are investigated individually by an agent equipped with full context: which link broke, what the graph expected, and what actually arrived. Matching faster is merely a feature; eliminating the need to match is architecture.

Audit: From Sampling to Full Traversal

Auditors sample because the cost of manually tracing any number back to its source is prohibitively high; verifying every transaction item by item is impossible, leaving sampling as the only option—for example, manually pulling 60 items and extrapolating to the population.

In T:0, every number arrives with its provenance intact, turning verification into traversal. Any incoming transaction on a bank statement can be unpacked into every individual payment within it, and traced back to respective invoices and contracts. Instead of humans sampling 60 items and extrapolating, agents continuously traverse the entire graph year-round, reporting findings along with the paths traveled. Auditing is no longer an annual excavation, but a property the system continuously maintains.

Close: No Longer a Noun

Month-end close exists because disconnected systems gradually drift apart and must be periodically forced back into alignment.

If the ledger's links are maintained continuously, in a sense it remains in a permanently closed state, turning close into a confirmation milestone rather than an ordeal to survive. According to T:0, finance teams using the map cut close times by 90%; the essay cites another example where close was reduced from 6 days to 3 days. While the market boasts about closing in days instead of weeks, the true end state is that "close" ceases to be a noun.

The OpenAI finance team has also targeted a zero-day close, which remains under construction; see "OpenAI CFO on reshaping finance with AI: five takeaways and a scorecard you can use".

What-If Modeling: Simulating the Future on Live Ledger Branches (Not Yet Implemented)

A connected map records the world as it happened, but it can also be branched (forked) just like code.

Under the author's vision, when a what-if question is posed to the AI, it does not daydream; instead, it forks the history of real events, applies different revenue policies, contract structures, or pricing models, and lets the deterministic engine replay the real world on that branch to output a diff between the two worlds. What the books would look like under new contract terms is calculated directly on live transactions, rather than modeled in a spreadsheet. Accounting has always been a discipline of recording the past; a forkable map transforms it into a tool for rehearsing the future.

Looking back at these five capabilities: they are all AI capabilities, yet none of them is a model capability. The models are the exact same ones everyone else uses; the difference lies in what they are given to stand on. Place the smartest agent on a flat ledger and it will guess; place it on a map and it will know.

Three Lessons

For teams seriously contemplating the deployment of AI in rigorous financial settings, T:0 summarizes three lessons:

1. The ontology is standard; the data is messy. T:0 originally assumed the bottleneck would be AI, but it was not—the hard part is normalization. Across 7 ERPs and dozens of payment platforms, every vendor shapes the same five-hundred-year-old objects into different dialects (as with "deposit" mentioned earlier). There are no shortcuts; every edge case bypassed eventually turns into an unreconciled balance on someone's books.
2. In finance, a probabilistic link is worse than no link at all. The AI industry is used to working at 95% confidence: that is plenty good for recommendation systems, but fatal for an audit. A link that is probably right will eventually be wrong in someone's revenue numbers, and a single such discovery destroys trust across every other link in the system. T:0's rule is simple: a link is either proven or it does not exist, and missing links must be conspicuously surfaced. Trust accrues like interest, but a single default wipes out years of gains.
3. AI earns trust by showing the path, not by spinning reasoning. CFOs, auditors, and boards of directors will not trust an AI because its explanation sounds rigorous; they only trust evidence. The only AI conclusions that withstand audit scrutiny are those mapped to a path on the graph: these objects, these links, this rule, this journal entry. Build a foundation where every answer can be traced to its origins, and trust ceases to be a leap of faith—it becomes a verification.

Conclusion

The industry is racing to mount smarter agents atop the same archaic general ledgers. In the author's view, the race is running in the wrong direction: models provide fluency of expression, but only the map provides truth. And in accounting, truth is the entire value of the product.

Palantir proved that organizations are willing to restructure their data around an ontology to make AI trustworthy, the author notes, at the cost of having to build bespoke ontologies client by client. Accounting has never needed a construction crew; its ontology has been right before our eyes since 1494—universal across the industry, equipped with native verification mechanisms, simply waiting for software to take it seriously.

T:0 positions itself as precisely that software: not a cleverer bookkeeper, but a ledger where every number still remembers its own origin, paired with an AI that can finally read it.

Palantir demonstrated the value of an ontology to operations; T:0 wants to demonstrate it to finance.