Scalability is not a capacity question
Most accounting software describes scalability in terms of volume: more transactions, more users, more storage, more entities on the plan. Those limits are real, but they are rarely what forces a business to change systems. A business that outgrows its accounting software almost never does so because it ran out of rows.
What actually breaks is structural. The books get more complicated than the system's ledger design anticipated, and the accounting team starts doing outside the system what the system was supposed to do inside it. That work the export, the spreadsheet, the manual reconciliation is the real signal, and it appears long before any capacity limit is reached.
Three structural properties determine whether that happens: how the ledger is put together, whether journal behaviour can be changed by the business, and whether reporting is part of the ledger or a separate step downstream of it.
1. Ledger architecture: how many places a transaction lives
In a module-based system, accounts payable, accounts receivable, and the general ledger are separate subsystems that post into a shared chart of accounts. That works cleanly while transactions are simple. It stops working cleanly when the same transaction has to be represented in more than one module an intercompany charge, a partial payment across periods, a credit note applied against several invoices because the modules each hold their own version of the record and the two have to be brought back into agreement.
Mid-level tool are built this way, and so is Entry tool at a smaller scale. It is a mature, well-understood design; the cost of it is that period-end includes a reconciliation step between modules that grows with the complexity of the books, not with their volume.
A combined ledger removes that step by not creating it. AOC Accounting posts AP, AR, and GL activity into one ledger and uses the chart of accounts to prevent the double entries that arise when separate modules record the same transaction independently. There is no cross-module reconciliation because there is one ledger to reconcile.
2. Journal flexibility: who gets to change how a transaction behaves
Every accounting system has journal types the templates that govern how a class of transaction is numbered, sequenced, documented, and reversed. The question that matters for scalability is who controls them.
In most systems they are fixed by the vendor. A business that needs a non-standard transaction sequence, a specific document numbering scheme for a new entity, or automatic period-end reversals on a particular class of accrual has three options: change its process to match the software, handle the difference manually outside the system, or pay for customisation. In enterprise systems, the third option exists and is genuine but it typically means a consultant, a change request, and a project timeline.
AOC Accounting makes journal types user-defined: the transaction sequence, the document printing format, and the auto-reversal rules are configured by the business inside the system. When a process changes, the configuration changes with it. No implementation partner, no development ticket.
3. Reporting: part of the ledger, or downstream of it
The most common workaround in a growing finance function is the export. Data leaves the accounting system, gets reshaped in a spreadsheet, and comes back as a report. It happens because the system's reporting layer can only cut data along the dimensions it was designed for usually one or two, such as account and period while the business has started asking questions that need three or four at once.
A report by entity, department, project, and cost centre is not an unusual request for a business with a few years of growth behind it. Whether the system can answer it directly is a structural property, not a feature toggle. AOC Accounting supports up to 10 analysis dimensions per function, and reports are generated from the same ledger the transactions were posted to, so there is no export-and-rebuild step between a question and its answer.
A system stops scaling at the point where the accounting team starts doing outside it what it was bought to do inside it.
Where the capability tiers actually sit
Entry tool is inexpensive and quick to start, and for single-entity books with standard reporting needs that is a real advantage. Its ledger and reporting were built for simple books, so it is usually the first of these three properties to give way.
Mid-level tool sit closer to AOC in capability, with mature module-based architectures and rigid journal structures. They handle complexity well; they handle it as separate ledgers. AOC's position is the scalability of the larger systems without the enterprise implementation cost a combined ledger and user-defined journals in a system a growing business can run itself.
The practical test before buying
The useful question to ask a vendor is not whether the system scales. It is: what does closing the books look like in this system when there are three entities, a shared cost centre, and a report needed by project and department at once? The answer will describe either configuration inside the system or work outside it, and that distinction is what scalability means in practice.
AOC Accounting is built by Strategic Asia, a Singapore-based company that has run this combined-ledger system since 2015.