Inherited a mess: the triage order that stops you doing three months of work twice

Cleanup work goes wrong in a predictable way. You start where the ledger is ugliest, usually a bank account or a coding mess, because that is what the client complained about. Weeks in, you discover something structural. A prior year was never lodged. An entity is not the entity you thought it was. Half the transactions are missing because a feed was never connected. Everything coded since then has to be revisited. The pattern shows up repeatedly in practitioner threads. One post on r/Bookkeeping describes walking into this: "He hasn’t paid monthly or quarterly taxes in 6 months, his franchise tax isn’t paid, and I don’t even think he’s still a corporation… Everything is manual pay, no bank feeds or e-pay is set up. There are shop supplies being posted as income accounts." Read the order of discovery there. Unpaid statutory obligations, an entity status nobody is sure about, no feeds, and coding errors. Only the last one is bookkeeping. The first three change what the engagement is. Another, from r/Accounting: "Inherited a massive AR disaster (millions in discrepancies), zero BS reconciliations, and a 10-page P&L used as a general ledger." A P&L used as a general ledger is not a coding problem you fix line by line. It is structural, and it determines whether the prior numbers mean anything at all. These are recurring complaints in practitioner subreddits.

Completeness and access, before anything else. Not accuracy. Accuracy is meaningless if you are missing a quarter of the data. The first pass answers four questions. Do you have admin-level access to the ledger, the bank feeds, the payroll system and the tax agent portal, in your own name rather than the previous person's? Is every bank, card and loan account that exists in the real world represented in the file, and does each have a continuous feed or statement set for the period you are being asked to fix? What is the last period anyone actually signed off, and is there evidence of it? What is lodged, what is outstanding, and what is being pursued? If any of these fail, you stop and resolve them before touching a single transaction. A missing feed for one card across eighteen months is not a small gap. It is a reason to re-derive the whole period. Finding it in week one costs a day. Finding it in week six costs the six weeks. Access is underestimated. The previous bookkeeper has left, the logins were personal, and nobody knows which email the subscription sits under. That chase is rarely quick, so it starts on day one and runs in parallel with everything else.

Work outward from the things that can invalidate other work. Pass one is access and completeness: logins, feeds, the account list, the last sign-off and lodgement status. Getting this wrong invalidates everything, because missing data means redoing all coding. Pass two is bank, card and clearing: reconciliation to statements, undeposited funds, suspense and clearing balances. Getting this wrong invalidates all P&L coding and any reporting built on it. Pass three is statutory balances: payroll liabilities, tax accounts, loans, and director or shareholder accounts. Getting this wrong invalidates prior period comparatives and any advice you give. Pass four is history and presentation: chart of accounts, duplicate vendors, depreciation, dormant accounts and mapping. Getting this wrong affects reporting quality only, not the underlying numbers. Pass four is the tempting place to start, because it is visible and satisfying. A post on r/Bookkeeping lists exactly that kind of work: inactivating old accounts, catching up reconciliation and depreciation, and fixing the same loan payment posted to three different vendors. It is real work. It is also the pass you can safely do last, because nothing in it changes what passes one to three tell you. The rule is simple. Never do work that a later discovery can throw away.

Because you are currently doing your most expensive unpaid work on people who never become clients. From r/Bookkeeping: "I sometimes feel like I spend too much time on the front end with clients who don’t end up moving forward, ie. gathering transaction data and asking questions in order to get their quote." That is the trap. To quote accurately you want the data, and to get the data you chase a disorganised prospect for weeks. Either you quote blind and wear the risk, or you chase for free and lose the ones who go elsewhere. The way out is to split the engagement. Sell a paid diagnostic first: a fixed-scope assessment that runs passes one and two and produces a written finding of what is broken, how far back, and what the cleanup actually involves. The client pays for the diagnosis. The cleanup is quoted from evidence, not from a guess. Document chasing happens inside a paid engagement where you have signed authority to request access directly. This also changes who does the chasing. Once the client has said yes, a request list, a reminder schedule and an access checklist can run without a senior person composing emails. A thread on r/Entrepreneur describes the cost of not having that: "For a long time, client onboarding was just messy. Screenshots everywhere, people forgetting passwords, wrong permissions, long email threads just to get access. It didn’t always feel like a big problem, but it often meant days passed before we could actually start doing the work." Days per client, every client. That is the quiet cost.

The chasing, tracking and checking. Not the judgement. Things that automate well in a cleanup practice: a structured request list per engagement, with each item marked outstanding, received or waived and visible to both sides; scheduled reminders that escalate on a fixed cadence and stop when the item arrives; an access register recording which systems you hold, at what permission level, and under which login; a completeness check comparing the accounts in the ledger against the account list the client confirmed; and a weekly status summary generated from the request list rather than written by hand. Things that do not automate: deciding whether a prior period is salvageable, deciding whether an unreconciled balance is an error or a real liability, and deciding whether to take the engagement at all. Those are diagnosis, and diagnosis is the job. The honest counter-argument is that practices try this, buy a tool, and quietly stop using it. That does happen, and the reason is ownership rather than tooling. The person who set it up moves on, nobody else knows how the reminders are configured, one workflow breaks silently, and the team quietly reverts to email. Any automation that only one person understands is a liability disguised as an efficiency.

Someone who stays. Preferably two people, and preferably the people who actually run onboarding rather than a contractor who builds it and leaves. This is the whole argument behind buildAutomation. We train two or three of your own staff to map the process, build the workflows and debug them when they break, so the practice owns the result instead of renting it. The transferable skill is not dragging nodes around a canvas. It is diagnosis and process mapping: being able to look at a stalled onboarding and say precisely which step failed and why. For a bookkeeping or accounting practice, the first thing worth building is almost never the ledger work. It is the request-and-access pipeline that sits in front of it, because that is where the unpaid days go, and because it is a well-bounded process with a clear finish state. Concede the limits. If cleanups are an occasional job for your practice, this is not worth building. If they are a steady part of your workload, the front end is where your unpaid days are going.

What is the first thing to check when taking over messy books? Access and completeness. Confirm you hold admin access to the ledger, feeds, payroll and tax portals in your own name, then confirm every real-world bank, card and loan account appears in the file with continuous data. Missing data invalidates all coding work done after it. Should I quote a cleanup before seeing the data? No. Sell a paid diagnostic that runs the access and completeness checks and produces a written finding. Quote the cleanup from that evidence. This stops you doing weeks of unpaid data gathering for prospects who never sign, and stops you underquoting blind. How far back should a cleanup go? Only as far back as someone will rely on the numbers. Establish the last period anyone signed off and what remains unlodged. A recurring complaint in practitioner threads is rebuilding history nobody needs. Can onboarding document collection be automated? The chasing can. A structured request list, escalating reminders that stop when an item arrives, and an access register all run without a person. Deciding whether what arrived is sufficient cannot be automated, because that is professional judgement, not a workflow step. Why do practice automations stop working after a few months? Because nobody owns them. The person who configured the reminders leaves or gets busy, one step fails silently, and the team reverts to email. Automations survive when two or more staff can debug them, which is a training problem rather than a tooling problem. Is this an Australian-specific problem? No. The practitioner complaints behind this piece come from bookkeeping and accounting subreddits, and the specific taxes and filings they name are not Australian. The triage order holds regardless of which statutory obligations apply where you practise.

Quotes are reproduced verbatim and attributed to the subreddit, not to individuals. r/Bookkeeping: https://www.reddit.com/r/Bookkeeping/comments/1s3r1lu/horrid_books_new_employee/ . r/Accounting: https://www.reddit.com/r/Accounting/comments/1s622px/smb_unreasonableuneducated_owner_im_losing_it/ . r/Bookkeeping: https://www.reddit.com/r/Bookkeeping/comments/1v4yrsc/cleanup_rates_vs_data_entry/ . r/Bookkeeping: https://www.reddit.com/r/Bookkeeping/comments/1nc2fg3/feedback_on_onboarding_process/ . r/Entrepreneur: https://www.reddit.com/r/Entrepreneur/comments/1r015r8/client_onboarding_was_quietly_slowing_us_down/ . No statistics are cited in this article. Where a claim describes how common something is, it is described as a recurring practitioner complaint, not as a measured figure.