Why ledger-first beats spreadsheet-first.
Most accounting software you have ever used was a spreadsheet that grew a UI. Nonari starts the other way around — a strict double-entry ledger that grew workflows. Here is the tradeoff, in plain language.
The original sin: the spreadsheet shape
Walk into most accounting tools and you see a list of "transactions." Each row has a date, a description, an account, an amount. Sometimes the amount is positive, sometimes negative; you trust the shading to tell you which. Underneath that table — and frequently bolted on after the fact — is something pretending to be double-entry.
It is a spreadsheet that grew a UI. The "ledger" is reconstructed on demand by summing column slices. The "trial balance" is a SELECT with a GROUP BY. When you need a per-branch P&L, you get an export and a pivot table. When the auditor wants to see the change history, you get a sigh.
What ledger-first means in practice
Nonari treats the journal entry as the unit of truth. Every action — invoice, bill, expense, transfer, payslip, manufacturing job stage — produces a balanced JE: debits equal credits, full stop. The "transactions" view is a derived projection over those JEs. The trial balance is just summing journal lines.
It also means three other things, each of which we get for free because the foundation is right:
One — every dimension, every line
Branch, division, project, contact: those live as columns on the journal line, not as tags on the document. So a multi-branch P&L is one query, not a CSV export and a manual roll-up. Project profitability is real-time. Cost-centre allocation lands where you point it.
When you consolidate, you do not "import branch A into HQ"; HQ already has every line because every line was tagged on the way in. The numbers reconcile because they were reconciled the moment they posted.
Two — the audit log is the system, not an addendum
A spreadsheet-first product writes the audit log as a side-table that hopes to keep up. Misses happen — a programmer forgets to call the logger, a migration script bypasses the API. Nonari's audit log is enforced at the API layer; if you can write to the database without going through audit, that is a bug, and it gets a regression test.
Result: you can show your auditor the literal before/after of every change, ever, in the workspace. Filter by user, action, entity, date. Export to CSV. The trust is structural.
Three — period locks that actually lock
Closed your books for March? Try editing a March invoice. Nonari refuses, with a 409 and a friendly message: post a reversal in April, or unlock the period. There is no "delete" that silently un-posts the books. There is no PATCH that mutates a posted JE. The lock is honoured at every entry point — invoice, bill, expense, journal, manufacturing close — because the lock is a guard at the journal-service layer.
A spreadsheet-first product can paint a "locked" badge in the UI and call it a day; the data is still mutable. Ledger-first means the data really is the constraint.
What it costs us
Building the ledger first is slow. Every shortcut a spreadsheet-first product takes — "for now we will allow negative inventory", "let's fudge tax on the line", "we can normalise this later" — closes a door for us. We chose the slow path on purpose, because the alternatives compound badly.
It also means our edge cases are different. We have spent more time on three-way match logic, period reversals, multi-branch transfers, and inventory cost layers than we have on a "delight" feature anyone would notice in a demo. That is the deal we struck with the user: less razzmatazz, more nights of sleep.
What it earns you
The feeling that the trial balance always reconciles. Because it does. Because it has to.
A consolidated report that ties to every branch report, in three clicks. Because the dimensions are first-class.
An audit trail that you can hand a regulator without panic.
A system you can leave with — every entity exports as CSV + JSON, with referential integrity preserved — because we are betting on the books being your books, not ours.
A note on AI
A lot of people ask why we do not lead with the AI. The AI is real, and it is good, and we are quite proud of it. But the AI is a draftsman. The ledger is the law. If we built the AI first and the ledger after, we would be in the same trouble as the spreadsheet-first crowd: a product that produces plausible-looking transactions on top of a fragile foundation.
Build the foundation first. The drafting is the easy part.