Industry
Part of Accounting software: the properties nobody actually demonstrates
Accounting software framework: the ledger, the control accounts, and the joint
An accounting software framework: general ledger, subledgers and control accounts, the four doors data enters through, and which joint has to be reconciled.
Most confusion about accounting software comes from a vocabulary problem. People compare packages by feature lists without knowing what the parts are called or how they fit together, so a conversation about invoicing turns out to be a conversation about three different things.
This page is the architecture. What a ledger is, what sits around it, where data enters and leaves, and which of those parts is the one that has to be right. No package is named, because none of this varies between them: it is the shape of the problem rather than anybody's solution to it.
What to take away
- There is one general ledger and everything else feeds it. Understanding that single fact answers most questions about whether two systems can work together.
- A subledger holds the detail behind one general ledger line. Where a subledger and its control account disagree, the books are broken regardless of what any report says.
- Feeds bring in data. They do not bring in decisions, and every feed leaves a coding judgment for a person.
The general ledger, and everything else
The general ledger lists accounts and every entry ever posted to them, each entry balanced. That is the entire accounting system, and a course in financial accounting calls it a set of books, long before any software is involved.
Modules post totals to the ledger
- Sales subledger -> total receivables, sales, tax
- Purchase subledger -> total payables, costs, tax
- Bank module -> confirms entries exist
- Stock module -> stock value and cost of sales
- Payroll -> wage cost and amounts owed
- Fixed asset register -> asset value and periodic charge
Everything else in a package exists to make entries into the ledger or read them out.
| Part | What it holds | What it posts to the ledger |
|---|---|---|
| General ledger | Every account and every entry | Itself |
| Sales subledger | One record per customer, one line per invoice and receipt | Total receivables, sales, tax |
| Purchase subledger | One record per supplier, invoices and payments | Total payables, costs, tax |
| Bank module | Statement lines, matched to entries | Nothing; it confirms entries exist |
| Stock module | Items, quantities, valuations | Stock value and cost of sales |
| Payroll | Employees, gross pay, deductions | Wage cost and amounts owed |
| Fixed asset register | Each item, its cost and its charge | Asset value and the periodic charge |
Read the right hand column and the architecture becomes obvious. Every module summarizes itself into the ledger. The ledger holds no detail of its own about customers or items; it holds totals.
Control accounts, and why they are the joint
The receivables line in the general ledger is a control account. Its balance is meant to equal the sum of every customer balance in the sales subledger.
Control account versus subledger
Control account
- Holds
- Totals only
- Updated by
- Invoices and journals
- Journal effect
- Changes balance
- Check
- Must equal subledger
Subledger
- Holds
- One record per customer
- Updated by
- Invoices only
- Journal effect
- No change
- Check
- Must equal control
The two are maintained by different routes. An invoice entered against a customer updates both. A journal posted directly to the general ledger updates only the control account. That is the whole mechanism by which the two come apart, and it is why the ability to post a journal to a control account is a setting worth restricting.
Every joint in the architecture works the same way: a detail record on one side, a total on the other, and a check that the two agree. Bank against statement, payables against the supplier ledger, stock against a count, assets against the register.
The balance sheet is a list of those joints. A business that reconciles all of them monthly has a working system whatever software it uses.
Where data enters
Four doors, and each has a different failure mode.
- Typed in.Slow, and wrong in obvious ways that get caught.
- Captured from a document.An emailed invoice read into a draft entry. Fast, and wrong in one specific way: the same document captured twice looks like two transactions.
- Fed from a bank.Statement lines arriving continuously. These are not entries. A bank line is evidence that money moved, and turning it into an entry requires knowing what it was for, which the bank does not know.
- Posted from another system.A billing platform or a payroll provider writing totals in. Fast and accurate, and checkable only against that system's own records.
The fourth door is the one people misunderstand. If a billing system says receivables are a figure and posts that figure, the ledger will agree with it by construction. The agreement proves nothing about whether the underlying invoices are real.
Where data leaves
Reports, exports, and filings. The distinction worth holding is between a report, which is a view built from the ledger and can be rebuilt, and an export, which is a copy that immediately starts to age.
Most small business reporting problems are export problems: a figure copied into a spreadsheet, worked on, and then quoted a month later when the ledger has moved. Where a number is going to be used repeatedly, take it from a report each time rather than from a copy.
The export that matters is complete: every transaction, every ledger, and attached documents, in files you can open elsewhere. Test it before you commit, not when you leave, because it makes a decision reversible.
It must also outlast the software relationship, because the underlying records stay required for the periods federal guidance on record retention describes.
What the architecture asks of you
Two things, and neither is a software question.
First, the account structure. Which accounts exist, what each one means, and which of the five types it is. That decides which report every transaction appears on and it is a chart of accounts decision made by a person.
Second, the coding judgment at each door. A captured invoice arrives with a suggested account, and a bank line arrives with nothing. Somebody decides which account and which period, and the period part is the cut-off question the expense recording guide covers. No architecture removes that decision; it only changes how quickly a wrong one propagates.
Reading a feature list against this
When a package lists a feature, place it. Is it a subledger, a door, a report, or a control? That question turns most feature lists into three or four real capabilities and a lot of restatement.
It also exposes the gaps. A package with strong sales and purchase subledgers and no asset register is not incomplete by accident; it has decided that the register lives in a spreadsheet or with your accountant. That may be fine, but better to know in advance.
Find out by testing, not reading, as the guide to accounting software sets out, and the bookkeeping foundations guide also sets out the routine any package has to support.
