The brief from the client is always some version of the same sentence: "we're a bit behind." A bit behind usually means somewhere between six and twenty-four months. The bank feed has gaps. Nobody can say with confidence what has and hasn't been coded. And the client wants a fixed quote before you've opened a single statement.
Catch-up jobs are common enough that most practices have done several, and profitable enough — done properly — that they're worth taking on. They are also the easiest engagement type to lose money on, because the instinct is to treat them as an oversized version of normal monthly bookkeeping. They aren't. A backlog has its own failure modes, and a method that ignores them turns a quotable job into an open-ended one.
Scope it before you touch it
The single biggest source of lost margin on a catch-up job is starting work before the scope is fixed. Three things need to be established first, in this order.
Count statement-months, not transactions. A client with 40 transactions a month and a client with 400 transactions a month who are both eight months behind do not have the same job, but the driver of cost is the number of months you need bank statements for, not the raw transaction count. Get every statement for every month in the gap before you quote — a request that turns into three follow-up emails is itself part of the cost, and it should be resolved before the fee is fixed, not during the job.
Treat any month with no matching statement as its own line item, not a rounding error. A missing month is not "we'll catch it when we get there." It is a gap that can hide an opening-balance problem for every month after it. Flag it in the scope document as a dependency: this engagement is quoted assuming statements for months X–Y are supplied; a missing month extends the timeline and the fee.
Check what has already been lodged. Ask for copies of any BAS or IAS already lodged for periods inside the backlog. A period that has already been lodged is not a fresh coding exercise — it's a correction, and corrections carry different obligations and, usually, a different fee, because you may be filing an amendment rather than a first lodgement.
Reconcile in order, and prove each month before moving on
The temptation on a large backlog is to code everything first and reconcile at the end. Resist it. Code and reconcile one month at a time, oldest first, and do not move to the next month until the current one's closing balance matches the bank statement's own closing balance.
The reason is not process for its own sake. An error in month one — a duplicate import, a transaction coded to the wrong account, an opening balance that was never actually right — does not stay contained to month one. It carries forward as a discrepancy in every subsequent month's opening balance, and if you code eighteen months before checking any of them, you find that discrepancy at the end, with no way to tell which of eighteen months introduced it.
Reconciling in order turns an eighteen-month forensic exercise into eighteen one-month checks, each of which either passes or tells you exactly where to look.
The opening balance for month one is the actual starting point, not an assumption. If the client has never been reconciled, don't assume the first available statement's opening balance is correct — confirm it against the bank's own records, or against the prior year's closing position if one exists. An engagement that inherits a wrong starting number produces eighteen months of numbers that are wrong by the same fixed amount.
Where backlogs actually go wrong
Duplicate imports. A backlog often means statements arrived from more than one source over time — a CSV export here, a PDF here, a period where the client's old bookkeeper had already coded some of it manually. Overlapping date ranges from different sources are the single most common cause of a backlog that reconciles to the wrong number on the first attempt. Check for overlap before importing, not after.
Vendor coding that drifted. Eighteen months is long enough for a vendor's transaction description to change — a payment processor rebrands, a supplier changes their merchant name, a recurring EFTPOS description picks up a new reference format. A coding rule built on month three's description silently stops matching by month eleven, and the result isn't an error, it's just uncoded transactions sitting there waiting to be missed.
GST codes that need last year's rules, not this year's. If any part of the backlog falls in a prior financial year, use the GST treatment that applied at the time, not the current one. This matters most for anything where the ATO's guidance or thresholds changed between the transaction date and today — check the applicable rule for the period in question rather than assuming current guidance applies retrospectively.
Suspense as a parking lot, not a bin. Anything you genuinely cannot code from the available information goes to suspense, dated, with a note of what's missing. A backlog with forty items silently parked in suspense across eighteen months is not caught up — it's a smaller, better-organised backlog with a due date attached to a BAS.
Pricing it so it doesn't eat itself
Quote the catch-up as its own engagement, separate from the ongoing monthly work it will become once current. This is the second-biggest source of lost margin, after starting without a scope: folding catch-up work into "we'll just bill the normal monthly rate until we're caught up" almost always undercharges for the actual effort, because a backlog month takes longer than a current month — there's no established rule set, no prior period to check against, and a higher chance of exceptions.
A structure that holds up in practice: a fixed fee per backlog month, higher than the ongoing monthly rate, with the scope document naming exactly which months it covers and what's excluded (amendments to already-lodged periods, for instance, priced separately if they're needed). Once the backlog is cleared and the client is on a current month, the engagement reverts to the normal ongoing rate. Two engagements, two scopes, one client.
What "caught up" actually means as a deliverable
The end state is not "we've coded everything." It's a reconciled trial balance for every month in the gap, each one matched to its bank statement's closing balance, with anything that couldn't be coded sitting in a dated suspense entry rather than silently absorbed into an account it doesn't belong in.
That standard matters because it's what makes the client's next BAS defensible. A client who was eighteen months behind and is now current, but whose catch-up work can't show a clean reconciliation for each of those months individually, has a tidier-looking file and the same underlying risk they started with.
Where ReconLink fits
ReconLink reads the PDF, CSV and Excel statements Australian banks actually produce, checks each imported batch against the statement's own closing balance before you commit it, and flags overlapping date ranges so a backlog assembled from multiple sources doesn't silently double-count a month. It codes around 99% of lines before you look at them, and every coded line shows the rule it used — useful on a catch-up job specifically, because it makes drifted vendor coding visible instead of silent. It chases the client by email for the statements you're still missing, on a schedule, so that chasing doesn't sit on your own to-do list.
$99 a month, ex GST, unlimited clients and unlimited seats. Thirty days free, no card.
It won't decide whether a coded line is right, and it won't make the call on how to price the engagement. Both of those stay judgement calls for the person doing the work — a catch-up job is exactly the kind of engagement where that judgement is most of what the client is paying for.
Frequently asked questions
Should a catch-up job be quoted per transaction or per month? Per month, driven by the number of statement-months in the backlog rather than raw transaction volume. Transaction count affects effort within a month, but the structural cost driver — missing statements, unverified opening balances, drifted coding rules — scales with months, not line items.
What's the right order to reconcile a backlog in? Oldest month first, confirming each month's closing balance against the bank statement before moving to the next. Reconciling out of order or coding the whole backlog before checking any of it makes it far harder to isolate where an error entered.
How do you handle a backlog month that falls in an already-lodged BAS period? Treat it as a correction rather than a first-pass coding job. Confirm what was actually lodged, and scope any amendment separately — it carries different work and usually a different fee than coding an unlodged period.
What's the most common reason a catch-up job loses money? Starting work before the scope and fee are fixed, and pricing catch-up months at the same rate as ongoing monthly work. Backlog months take longer because there's no established rule set or prior period to check against.
Is "everything is coded" the same as "the client is caught up"? No. The deliverable is a reconciled trial balance for every month in the gap, each one matched to its bank statement's closing balance, with anything uncodeable in a dated suspense entry. Coded-but-unreconciled looks finished and isn't.
The short version
A backlog client is not a bigger version of a normal monthly engagement — it has its own failure modes, from duplicate imports to drifted vendor coding to already-lodged periods that need correcting rather than coding. Scope it in statement-months before you touch it, reconcile oldest-first with each month proved before the next, and price it as its own engagement. The deliverable is a reconciled trial balance for every month, not a coded ledger — that's the difference between actually caught up and looking caught up.