What Makes Accounting Complex

Transaction volume is the number most businesses watch when they wonder whether they have outgrown their accounting tool. The things that make a set of books hard to keep are structural, and they usually arrive well before the volume does.

Volume is the easy kind of growth

Accounting tools handle more of the same thing well. Doubling the sales invoices in a month adds data entry and not much else. The same account codes, the same document type, the same report at the end. A business can move from 200 invoices a month to 800 and feel the extra hours without anything structural changing. That is the growth owners expect, and it is the growth most software is priced around.

The harder kind arrives quietly. It starts when the business does something that does not fit the shape the books were set up for. The first project billed in stages. The first cost shared between two departments. The first invoice raised in a second currency. None of these add much volume. Each one asks a question the existing structure has no field for, and the answer nearly always gets built outside the system.

Complexity arrives as dimensions, not rows

A single sale can need to be readable several ways at once: by customer, by service line, by project, by office, and by period. An entry-level tool typically offers the account code plus one or two tracking fields, which is enough for a business with one way of looking at itself. Once a third and fourth way matter, the extra information has nowhere to sit, so it goes into the description field, into an invoice-numbering convention, or into a mapping table on someone’s laptop.

That is the point where reporting stops being a query and becomes assembly work. AOC handles this by supporting up to 10 analysis dimensions per function, applied at the moment a transaction is entered rather than reconstructed afterwards, so a report by project and a report by office are drawn from the same records instead of being built separately from an export.

A business with 300 transactions a month and four ways of looking at them is harder to keep books for than one with 3,000 transactions and one.

The transaction that belongs in two places

Some of the most awkward entries in a growing business are single events with more than one home. A shared office cost split across three service lines. A deposit that covers part of a project that will be delivered over two quarters. A cost paid by one company and recharged to a related one. A supplier invoice that is half stock and half a capitalised item.

Where a tool can hold only one view of a transaction, the second view is produced by hand later, usually at month end, usually by the one person who knows the convention. The entry itself is not difficult accounting. The difficulty is that the record and the report have been separated, and a correction to one no longer flows to the other.

Rules that end up living in someone’s memory

Every business accumulates its own routines. An accrual raised at close that has to reverse on the first of the next month. A recurring charge that runs on the same day each month. A document sequence the auditor expects to be unbroken. An approval that has to happen before a payment run.

When journal behaviour is fixed by the vendor, business-specific routines have nowhere to be recorded, so they get held as calendar reminders and handover notes. In AOC, journal types are defined by the business, including the transaction sequence, the document printed, and whether the entry reverses itself in the following period. A routine defined that way keeps running when the person who invented it is on leave.

What complexity costs before anyone counts it

The cost is rarely visible as a line item. It shows up as the number of days between the period ending and the board pack going out, and as the share of those days spent moving figures rather than deciding anything. It shows up when two reports carry the same label and different totals, because one came from the ledger and one came from a spreadsheet that was mapped to the ledger three months ago.

It also shows up in how expensive a single correction becomes. In a set of books held in one place, a miscoded invoice is one journal and a reprinted report. Where the reporting layer was assembled by hand, the same correction means redoing the assembly, and the temptation is to leave small errors alone until the next quarter.

What a system does not simplify

Software does not settle the judgment calls underneath the structure. When revenue on a staged project should be recognised, what basis a shared cost is allocated on, and what an intercompany recharge should be priced at are decisions for the business and its adviser, and a flexible system will record whatever answer it is given without improving the answer.

Designing the dimensions is real work too. Deciding what a project is, whether a client group sits above the customer, and which of the ten dimensions the business will actually maintain takes a session with whoever understands operations, done once, before anything is configured. A system with room for ten dimensions and no agreement about what they mean produces a mess faster than a rigid tool does. Neither does any of this repair data already captured without the detail. Going back to tag two years of history is a project of its own, which is one reason the structural questions are worth settling earlier than they feel urgent.

Four signals worth watching

These are observable in any business without a review or a vendor conversation. Any one of them on its own is manageable. Two or three together usually mean the structure, rather than the workload, is what needs attention.