Automation moves the human. It does not delete him.
Every honest claim about what this tool does starts here. LedgerDock takes the typing away from an accountant and hands back a decision. That is a real trade, and it only wins if the proposals are good and the review is tight.
One question decides every feature
LedgerDock is an accountant's close tool. Its job is to close a set of books, month-end and year-end, and close them right. It is not company-management software, not daily bookkeeping, and not a smaller QuickBooks. Your clients run their companies somewhere else.
Every feature request gets one question: who is asking — the owner running the company, or the accountant closing its books? Owner questions — who owes me, what do I pay Friday, what is in stock, send an invoice — are out, however easy they would be to build. Accountant questions — does it tie, where is the evidence, what adjusts, what do I file — are in. Features that failed that test were not shelved. They were deleted.
There is a shortcut version of it: if it needs an aging report, it is not ours. AR, AP, open items, item masters, quantities — those are an owner's running problems, not a closer's tying problem.
There is no matcher, and that is the point
Most systems make matching an action: you pair two lines and the software composes a transaction out of them. We built that, used it, and deleted it. A composed transaction is a number no human typed and no document states — and when it is wrong, it is wrong inside the ledger.
Here, cross-source money meets in a clearing account. A transfer's two halves both land in Transfer Clearing. The payroll cash and the provider's report both land in Payroll Clearing. Nothing is paired and nothing is composed.
At the close the clearing account either holds 0.00 or it does not, and that zero is the match. A pairing can be suggested to you. It can never write anything.
The model proposes. The human approves.
Not rendered yet. The full script is below, and it is the whole scene.
Transcript
The old way: a person types an entry into the books. The bank feed arrives afterwards and puts a checkmark beside a line that already exists. The human does the thinking; the machine confirms. The new way: the feed comes first. Raw lines stream in, each one arriving already coded, with the reason attached. A transfer's two halves both land in Transfer Clearing. You approve them. At the close, the clearing account netting to zero is what proves the two sides were the same money. You stop typing transactions. You start approving them.
The old way put the human first
Traditional accounting systems are built around a person typing. Someone enters the transfer into the books. Later the bank feed arrives, and the software's job is to put a checkmark next to lines that already match what the person typed. That design is safe and simple, and it is also why month-end is a week of data entry.
LedgerDock runs the other way around. The bank feed is the starting point, not the confirmation. Raw lines come in first, and each one arrives already coded with the reason stated.
We do not remove the accountant from that. We move him. Fewer keystrokes going in, one tight review going out.
Setup is hard so review can be trivial
This is the rule every screen has to obey: all complexity belongs at setup time; review time must be dead simple.
It was learned the hard way. The person who builds this software got lost trying to assemble a complicated multi-part match while reviewing. If the author of the tool gets lost at review time, no working accountant has a chance.
So complexity lives at setup. The reader for each statement, the loan schedule, the depreciation basis, the chart of accounts — you configure them once, with your full attention on them.
Decisions then shows only what the model will not code on its own, and each card states plainly why it is asking: no precedent for this vendor, an amount outside the usual band, a descriptor that changed, a balance that does not tie. You approve, or you change the account and it learns. Lines the model cannot propose at all do not sit in the queue pretending to be decisions — you code them yourself in the reviewer.
Where the AI is, and where it is not
The model does three jobs: it builds the reader for a statement the first time we see one, it repairs that reader when the bank changes its layout, and it reads images.
It does not run your month. Once the reader exists, next month's statement is read by deterministic code replaying a saved recipe, and the footing check is arithmetic against the totals printed on the document itself. Deciding which lines need you is arithmetic too — this company's own prior codings, this vendor's own prior amounts. No model is consulted.
The model never produces a number. Not a transaction amount, not a total, not a balance. Every figure comes out of the document or out of the ledger.
So the answer to "what if the AI changes" is: your close does not.
The five rules everything obeys
- Nothing posts in response to an event No ledger row appears because a file arrived or a webhook fired. Entries post because a reviewed commit is made or a period is being closed.
- One account, one source, one commit A commit is the certification unit — one hash, one status, one undo boundary — so it covers exactly one account. Two statements for different accounts cannot be sealed together, and a file already inside a commit cannot be committed twice.
- Precedent is the gate; confidence is a display A line is coded without asking you only when this company's own record justifies it. Anything fuzzy — a suggested account, a proposed receipt match, a possible pairing — may suggest, and may never create or change a transaction.
- Matches never post Cross-source money meets in clearing accounts; the match is the assertion that clearing equals zero at lock.
- The lock is a certification Four assertions run before it, and anything still failing must be fixed or explained in writing. The explanation is sealed into the close alongside your name.
Two more that shape everything above:
- Documents are evidence, not entries. A receipt, a check image, a W-9 attaches to what it documents and posts nothing. There is no path from an attachment to a number, so the worst a wrong attachment can do is mislabel a photo — never corrupt a ledger.
- Formats are skills, not schemas. No document design ever gets its own table. The shape lives once in a global registry; what it means for your company lives in your company's own copy. That is why the tool stays small while the list of things it can read keeps growing.
Simplicity is the strategy, not a phase. Every addition answers one more question after the others: does this make the close more correct, or does it make the product more like the thing we refused to be?
An accountant's close tool. Month-end, year-end, closed right.