Part of: Why your month-end close keeps getting slower
The pattern shows up in every multi-entity QuickBooks migration I have been called into. The first entity works well. The second adds friction. At the third, the operator calls and says "something is wrong with QuickBooks."
Nothing is wrong with QuickBooks. QuickBooks Online is doing exactly what it was designed to do — manage the books for a single company efficiently. The problem is that a three-entity business is no longer a single-company accounting problem. It is a consolidation problem, an intercompany problem, and an elimination problem. QuickBooks was not designed for any of these.
Five things break between the second and third entity.
First: intercompany transactions require double entry. Each intercompany transaction is entered once in each entity with no system-level matching or elimination. The controller tracks them in a spreadsheet. By entity four, the spreadsheet is a project.
Second: the chart of accounts diverges. Each entity was set up by a different person at a different time. Consolidated reporting requires manual remapping every month.
Third: there is no native consolidation. The monthly consolidated view is a separate Excel workbook pulling trial balances from each entity. By entity five, the workbook is fragile and the person who built it is the only one who can maintain it.
Fourth: bank feeds get tangled. Shared vendors pay from multiple entities without clear allocation records. The reconciliation is manual.
Fifth: user access is binary — full access or no access. There is no role-based separation of duties that satisfies an audit.
The business did not outgrow QuickBooks because QuickBooks failed. It outgrew QuickBooks because the tool was right for entity one and wrong for entity three. This is a design problem, not a vendor problem.
Filed under
