LedgerDock is a close tool for accountants. Bank feeds and documents come in, the model proposes the entries, and you approve them. At the end the period locks as a signed record — four assertions against the books, your name, and a written reason for anything still open.
It is not daily bookkeeping software, it does not do your judgment for you, and no language model sits between a statement and your ledger.
The old way puts the human first: someone types the entry, and the bank feed arrives later to put a checkmark next to it. LedgerDock runs the other way. The feed is the starting point, lines arrive already coded with the reason stated, and a person still decides.
Nothing reaches the ledger on its own. The Decisions screen shows only what the model will not code on its own — and even the lines it codes confidently are not in the books yet. Nothing is posted until you commit it, and every ledger row traces back to the commit that approved it.
The model never invents an amount. Rows are pulled by deterministic code, and the extraction has to foot against the totals printed on the statement itself before it is accepted. If it does not tie, it does not land.
Open any figure on a report and the transactions behind it expand in place. Each one names the commit that recorded it, who approved it and when. Trust comes from being able to follow the number down, not from an accuracy claim.
Export everything gives you one zip of CSVs: chart of accounts, transactions, the ledger, every commit, loans, fixed assets, vendors, the decision log and the audit log. Encrypted identifiers are never in it. No export ticket, no exit fee.
Bank and card feeds come in through Plaid, read-only. Everything else you drop as a file. Both end up in front of a person before anything can post.
A skill is the "how to read this" for one source. For a PDF statement the model builds it on the first read, foots it against the totals printed on that document, and saves it — next month the same statement reads itself.
Read rows land in staging, not in the ledger. The app calls one of these rows a fact. This is where work is still work — given an account, a class, a split — and nothing has been asserted yet.
Decisions shows what needs a person: usually a couple of dozen items out of several hundred. Each card names the vendor, the amount, the account it proposes, and in plain English why it is asking.
Approved work is sealed into a commit — the unit of recording. It is hashed and chained to the one before it, and every ledger line it writes carries its id. One commit covers exactly one account.
Four assertions run against the books. Anything still failing must be fixed, or explained in writing — and the explanation is sealed into the close beside your name.
Six steps, and a checklist that will not let you lock quietly — anything that does not tie has to be fixed or explained in writing.
No. LedgerDock is built for the close — month-end and year-end. The list of things it will not have is deliberate and it is not going to shrink: no invoicing, no bill pay, no payment application, no open items, no agings, no item master, no quantities or costing, no check printing, no payroll calculation or filings, no matcher that composes transactions out of two lines, and nothing real-time. Payroll arrives as an import through a clearing account; it is not calculated and it is not filed.
If LedgerDock ever became company-management software, that would be a different product decision, not a feature request.
There is not one, on purpose. An aging is a tool for chasing money, not for tying a balance. AR and AP are accounts here, not modules: the balance is asserted against the figure you were given, with the source recorded, and it ties or it does not. The chase list belongs in the software the client already runs.
Yes — not as a separate module. The candidate list is a query over the payments you already recorded, recomputed every time you open it, and the missing-W-9 list sits beside the close checklist every December. The filing line follows the year: $600 through 2025, $2,000 from 2026.
No. An entry reaches the ledger only after a person commits it. The model builds the reader for a statement, repairs it when a bank changes its layout, and reads images. It does not run your month: once the reader exists, next month is read by deterministic code and checked by arithmetic.
For the close, LedgerDock is the ledger. It keeps exactly two subsidiary ledgers, loans and fixed assets, because both generate their own schedules from a few inputs and nothing outside the system holds them.
The rule behind that: a table exists only when a close assertion has to tie to detail that lives nowhere else. A bank balance does not — it ties to a statement. AR, AP and inventory do not — they tie to a figure someone states, and we record the figure and its source. Balances that verify externally get an assertion, not machinery.