Most accounting software keeps payables, receivables, and the general ledger as separate modules that pass balances to each other. AOC records all three in one ledger. Here is what that means mechanically, and what changes in a month-end close because of it.
The structure most systems use
Accounting software has historically been organised around modules. Payables is one subsystem, receivables is another, and the general ledger is a third. Each keeps its own record of transactions, and at defined points — usually a posting run, sometimes a nightly job, sometimes a manual step at period end — the subledgers push summarised entries into the general ledger.
There are good reasons this design became standard. It lets different teams work in separate areas without interfering with each other, it suits organisations where purchasing and credit control are genuinely separate departments, and it made sense when systems ran on hardware that benefited from processing batches rather than individual transactions. Entry-level tools inherited a lighter version of the same shape, and mid-market systems still sell it explicitly as modules.
The consequence of the design is that a single commercial event exists in more than one place. An invoice is a record in receivables and, after posting, a set of entries in the general ledger. Those two representations have to agree. Keeping them in agreement is what subledger reconciliation is, and it is a recurring task rather than a one-off setup step.
What AOC does instead
AOC Accounting uses a combined ledger. Payables, receivables, and the general ledger are not separate stores that synchronise — they are the same ledger, and a transaction is written to it once.
The chart of accounts is what makes this work. Every transaction, whatever its origin, is coded against accounts in one chart, and the system uses that structure to prevent the same event being recorded twice. There is no supplier invoice sitting in a payables table waiting to be mirrored into a general ledger table, because there is only one table. The payables view and the general ledger view are two ways of reading the same posted records, filtered differently.
Mechanically, this means a few specific things about how work flows through the system:
What the single-ledger structure does
- One posting, not two. A transaction is entered once and is immediately part of the general ledger. There is no separate posting run to move subledger activity into the GL.
- Chart of accounts as the control. The account structure governs every entry, and it is what prevents the duplicate recording that arises when separate modules each hold a copy of the same event.
- No cross-module reconciliation. Because there is no second copy of a transaction, there is no subledger-to-GL agreement to check, chase, or explain.
- Live balances. The general ledger reflects a transaction at the moment it is entered, rather than at the next posting cycle.
- Reports run against the ledger directly. A report reads posted records, so it is available immediately rather than after an export and rebuild.
- Up to 10 analysis dimensions per function. Department, project, entity, cost centre, and similar tags sit on the transaction itself, so any view of the ledger can be cut by them.
What changes at month end
The clearest place to see the difference is a close. In a modular structure, a meaningful part of closing is confirming that the subledgers and the general ledger say the same thing: aged payables agrees to the creditors control account, aged receivables agrees to debtors, and where they do not, someone traces the difference back to a posting that did not carry across, a manual journal made directly to a control account, or a transaction entered after the last posting run.
None of that work exists in a single ledger, because the two figures being reconciled are the same figure. The aged payables listing and the creditors balance are drawn from the same posted transactions.
What remains at close is the accounting work itself — accruals, prepayments, depreciation, provisions, foreign exchange revaluation, review. That work is unchanged. What is removed is the internal agreement checking that exists only because the system holds the same transaction in more than one location.
Subledger reconciliation is not an accounting requirement. It is a consequence of a system design that stores the same transaction twice.
Why this matters more as a business grows
At low transaction volumes the difference is small. A business posting a few dozen invoices a month can reconcile subledgers quickly, and the modular design carries almost no cost. This is part of why entry-level tools work well for early-stage businesses and why they are a sensible starting point.
The cost grows with two things: volume, and the number of dimensions the business reports on. Volume increases the number of items to trace when a reconciliation does not balance. Dimensions increase the number of ways the ledger needs to be sliced — once a business is reporting by project, department, and entity, each additional module boundary is another place where those tags have to be preserved consistently.
A single ledger with dimensions attached at transaction level does not multiply that work. Adding a reporting dimension changes what can be filtered; it does not change how many places a transaction lives.
Features and benefits
The features below all describe AOC Accounting and what each one gives a business using it.
| Feature | What it means for you |
|---|---|
| Combined AP, AR and GL in one ledger | A transaction is entered once and is immediately part of the general ledger — no posting runs, no subledger-to-GL reconciliation. |
| Chart of accounts prevents double entries | The account structure itself is the control against the same event being recorded twice, rather than a manual check performed after the fact. |
| User-defined journal types | Transaction sequences, document printing and auto-reversal are configured by the business, so a new process is set up in the system instead of handled by a recurring manual journal. |
| Reports available immediately | Reports read the ledger directly, so a trial balance or aged listing is produced at the point it is asked for, not after an export into a spreadsheet. |
| Up to 10 analysis dimensions per function | Project, department, entity and cost-centre reporting come out of the same ledger, so adding a reporting view does not require a parallel record to be maintained. |
| Live balances | Management figures reflect what has been entered, not what was entered before the last posting cycle. |
What it does not change
A single ledger is a structural choice, not a substitute for accounting discipline. Entries still need to be coded correctly, approvals still need to happen, and a chart of accounts that is poorly designed will produce reports that are hard to read regardless of how the ledger is stored. The structure removes a category of reconciliation work; it does not remove judgement.
It also does not make a migration free. Moving to any new system means mapping balances and history and agreeing a chart of accounts. What the structure changes is what has to be carried across afterwards — the spreadsheets and manual steps built to bridge module boundaries do not need an equivalent in a system that has no module boundaries.
Where this fits
AOC is aimed at the space between simple starter software and full enterprise infrastructure: businesses whose ledger and reporting needs have grown past a basic tool, but which do not need or want to pay for and staff an enterprise implementation. The combined ledger is the main structural reason that gap can be covered without either extreme.
See a single ledger with your own chart of accounts
Walk through a close in a combined ledger and see which of your current steps stop being necessary.
AOC Accounting is built by Strategic Asia, a Singapore-based company that has run this combined-ledger system since 2015.
