Loading
Every ledger has invoices, bills, a chart of accounts and a bank feed. Listing them proves nothing, and comparing them line by line is how procurement wastes a quarter.
What differs is where the postings come from. A ledger fed by the documents that already exist behaves differently from one fed by imports, even though both produce a trial balance.
Every entry below names the products it is joined to. Those joins are the specification, not a footnote.
Assembled from delivered work and approved expenses, priced from what actually shipped.
Claims with approval trails that land on the project they belong to and the invoice that recovers them.
Payment state, tax treatment and control accounts reading the same numbers the rest of the company already agreed.
Receivables with reminders that know the relationship, so chasing does not undo the account team’s work.
Accounts, reconciliation and cash on hand matched against the ledger rather than typed into it twice.
Vendors, orders and bills on the supply side of the same ledger the sales side writes to.
Stock, warehouses and movements valued in the ledger as they move, not counted at year end.
Bills of material and production runs that consume stock and produce cost, both landing in the same accounts.
What the company owns, what it is worth now, and the depreciation posting that keeps the two agreeing.
Budgets and cost centres compared against actuals from the ledger, not a spreadsheet copy of it.
Returns built from invoices already recorded, with the tax treatment decided when the invoice was raised.
Several branches or currencies in one set of books, consolidated without a month-end merge.
Salary, statutory dues and attendance-driven cost posted into the ledger from Nest's approved runs.
Invoicing reads delivery, purchasing reads the goods received, payroll postings read the pay run, and the ledger receives all of it as it happens. There is no nightly job and no reconciliation between systems, because there is only one system.
Analysis lives in dimensions rather than in account codes, so the chart stays small while the reporting gets finer. Cost centre, branch, project and entity ride on every posting, which is what makes consolidation a filter rather than a merge.
The month-end sections — trial balance, P&L, balance sheet, cash flow — are views of the same ledger rather than reports built from it, so they are current to the last posting.
Open a figure and you land on the invoice, the timesheet or the approval that produced it, including who approved it and when. Corrections are postings of their own, which is slower to read and far easier to defend.
Not add-ons and not an enterprise tier. These behave the same whether you run one product or all seven.
If you are comparing ledgers, skip the feature grid and read invoicing and the payroll postings. Those are the two places a ledger either reads the rest of the business or does not.
If your close is the problem, read banking and payments chasing. Daily reconciliation and behaviour-led collections remove more days from a close than anything in the ledger itself.
Yes. Every feature listed here works with Books alone. Where one says it joins another product, that join simply waits — switching the other product on later needs no migration, because the record it wants is already there.
No. Custom fields, permissions, automations, the audit trail and the API behave the same on the smallest plan as on the largest. The list on this page is the whole list.
Work backwards from the handover that costs you most. The feature that removes a manual step between two teams is worth more than the one with the longest description.
Fourteen days, every module, no card. Or half an hour with someone who will use your own numbers.