You're looking at a list of ten prospective clients with one question underneath it, whether saying yes to all ten means hiring. You already run receipt capture, a workflow tool, proposal software and a reporting layer, and the answer still isn't obviously no, so you go looking for what else can be automated, and every practice automation list you find covers the same five categories. None of them mention the task that'll decide the answer, because it happens on your clients' sales ledgers rather than inside your practice.
A fee is agreed once at onboarding and then held fixed, so any task whose hours grow while the fee doesn't is a margin leak, and it doesn't show up as a line in the accounts, it shows up as a hire. What decides it is how many more client organisations one person can carry before that hire.
The biggest time drains in a bookkeeping practice, and the one that is never on the list
The recurring time drains are well documented: purchase-ledger and receipt capture, chasing clients for records, bank reconciliation, payroll runs, VAT, BAS and sales tax preparation, client onboarding, workflow admin and month-end reporting. Every one of them appears in every practice automation list.
Allocating incoming customer payments across client sales ledgers is the drain that never appears, and its hours scale with something your fixed fee doesn't track. The fee was priced against transaction volume and complexity as they looked that month, while these hours scale with the client's payer count and with how each of those payers formats their remittance advice. A client can add four customers who pay on consolidated remittances, and nothing in your fee changes while the work does.
The software category does exist and is sold as cash application software, but it's sold to the finance team inside one business, so it lands in no practice app-stack list and no practice tooling review. Inside most practices the work hasn't got a name of its own either, and it gets logged as bank rec, or as that client, or as general admin on that client's job.
The stack every practice already has
Five categories, and almost every practice has something in each.
- Purchase-ledger and receipt capture. Dext, Hubdoc, AutoEntry. Supplier bills go in and coded transactions come out.
- Practice management and workflow. Karbon, BrightManager, Pixie, Xero Practice Manager.
- Client onboarding and proposals. Ignition, GoProposal. Engagement letters, pricing, AML checks.
- Reporting and advisory. Fathom, Syft, Futrli. Management packs built off the ledger.
- The ledger itself. Xero or QuickBooks Online, plus bank feeds and per-client reconciliation rules.
Four of the five touch the purchase ledger, your own practice workflow, or reporting built on finished data. Only the ledger touches the sales side, and all it gives you there is a bank feed and a reconciliation screen, which leaves the allocation itself to you.
Four tests for whether a practice task is worth automating
Run these against any task in your book. A task that fails the first two is rarely worth automating, however much you dislike it.
- Does it recur for every client, every week? Annual and one-client tasks don't compound, and a tool you deploy once across the whole book is a different investment from one you deploy per client.
- Do its hours scale with something your fixed fee doesn't track? If they track the same variable your price tracks, growth is neutral, and if they track something else, the client having a good month costs you margin.
- Is it variance-heavy? If the input differs every time, it can't be handed to the cheapest available person without a review layer on top, and paying for that review is what makes a cheap task an expensive one.
- Does the client notice immediately when it slips? Work that shows up in a client's aged debtors report can't wait a week, and that urgency is what makes it interrupt everything else.
Score the standard stack and the pattern is obvious. Purchase-ledger capture passes the first two, and its low variance is why it was solved first. Practice management scales with the client count your fee already tracks. Proposals and onboarding don't recur weekly, and reporting is periodic.
Customer payment allocation passes all four, and it's the only one still done by hand at most practices. It recurs weekly for any client with trade customers, every payer formats differently, and short payments, credits and out-of-order payments arrive without warning. It also fails in front of the client, because a payment that hasn't been allocated is still an open invoice, so the client's credit control acts on a debtor list that says the money never arrived.
What ten new clients actually costs
Put rough numbers on it, banded and illustrative rather than drawn from any one practice. Take one person carrying twenty client ledgers, where the clients selling to trade customers get a remittance advice with each payment.
- A quiet client. Three or four payers, a handful of remittances a week, most of them covering a single invoice, so call it half an hour a week.
- A heavy one. Fifteen to twenty remittances a week, several of them consolidated across a dozen invoices or more, with a credit note and a deduction in the mix. At around a quarter of an hour each, that's four to five hours a week.
Two heavy clients is more than a day a week on this one task, at whatever fee was agreed the month each of them was onboarded, and that's the number that decides the ten, because ten clients don't arrive as ten equal loads. How many of them are the second kind is what settles it, and their accounts won't tell you, since what drives it is the length of their payer list. You can absorb two of them, and five is a hire.
Why this one never made the list
Customer payment allocation means reading a payer's remittance advice against a lump credit in a client's bank account, and deciding which open invoices it settles and by how much. Three things keep it out of a practice tooling review.
- The document arrives at the client. A remittance advice is emailed by the payer to whoever's on their contact record, which is almost always someone at the client and hardly ever anyone at the practice, so it reaches you forwarded, in a batch, usually late.
- It arrives in whatever format the payer uses. There are as many layouts as there are payers, and a payer can change theirs without telling anybody.
- The hours scale with the client's payer count. Transaction volume is what a fee is normally priced on, and two clients on near-identical fees can sit nowhere near each other on allocation hours.
Purchase-ledger capture had an easier problem to work with, one document covering one transaction with one supplier, in the same layout every month. A remittance advice has none of those properties, and what gets checked is whether the allocation ties out to the cash that landed. So the work is almost never itemised on an engagement and rarely repriced when a client's payer list grows, and until it has a name inside the practice it's hard to price it or hand it over.
How a practice takes on more clients without hiring
A practice adds clients without adding staff by removing the steps whose count multiplies by client and by payer, rather than by doing those steps faster. Done by hand, allocating one payment is eight steps: retrieve the document from an inbox, work out which client it belongs to, open that client's ledger, read the payer's layout, transcribe the references, find each open invoice, decide the allocation line by line, then post it and attach the document. Seven of those are mechanical and they collapse into one, reading a proposed allocation next to the document it came from and either approving it or deciding what to do with the lines that don't tie, which is the only part of the job that ever needed a bookkeeper.
- Setup happens once per practice. Adding a client is a ledger connection and that client's invoice prefixes, so the tenth is the same work as the second.
- Review moves from every payment to exceptions only. The queue is sized by how odd your clients' payers are, so the number of payments that arrived stops driving it.
- The reviewer no longer has to be the person who knows that client's payers. With the proposed allocation and the document side by side, checking it is a judgement anyone competent can make, which is what makes the work delegable and holiday cover workable.
- The inbound step stops being a person. Remittances forwarded to a dedicated address are read on arrival, so nobody's opening attachments to start the job.
- Deciding which client's ledger a payment belongs in stops being a step. The mechanics across a book of separate organisations are in the multi-entity workflow.
The person who allocated payments for a handful of clients now reviews exceptions for many more, and exceptions reach a person by design, since whether a short payment is a contractual deduction, a dispute or the payer's error is a client conversation and it should stay one. Where you set the line between what posts on its own and what comes to you is covered in when to let matches post without review.
A hire or an offshore team adds hours without removing any of those steps, and neither of them touches the variance, because work whose input differs every time still needs a review layer over the new person, so you're paying for the doing and then again for the checking.
How this runs across a book of clients
One RemitClear account holds every client ledger you've connected, so one login covers the whole book and a person moves between clients inside it. QuickBooks Online matches and applies credit notes the same way Xero does, so the review screen someone works from doesn't change with the ledger a client happens to be on. Unattended posting is off by default and gets switched on one client ledger at a time, so a new client starts with every payment waiting for a person to approve it.
Summary
Allocating incoming customer payments across client sales ledgers is missing from every practice automation stack, and its hours scale with a client's payer count while the fixed fee tracks transaction volume. Run the four tests against your own book this week and count the heavy clients. If payment allocation passes all four, watch it run on one client's payers before you reprice that client's engagement, which is what remittance matching for bookkeeping practices is for.
