When the practice becomes the implementation partner

A client asks their accountant what accounting system they should use. The accountant offers a view, informally, unpaid, as part of the relationship.

That question is worth more than it is usually treated as. The practice knows the client's transaction volumes, where their processes break, and what their reporting actually needs — which is more than any vendor knows and more than the client can articulate.

There is a service in that. There is also an obligation, and it is worth being clear about both before building anything on it.

Why the practice is well placed

You already know the constraints. Volume, complexity, how documents arrive, which processes are fragile, what the owner actually looks at. A vendor discovers this over weeks, imperfectly.

You will live with the outcome. If the system is wrong, you handle the consequences for years. That gives you an alignment a vendor structurally does not have.

You know what good looks like across many businesses. A client sees one implementation in a decade. A practice sees dozens, which is exactly the experience the client is missing.

You can standardise. A practice that has settled on a way of working can bring clients onto it, which is better for both sides than every client choosing independently. See standardising processes across a client base.

What the service actually consists of

Not reselling software. The valuable parts are the ones a vendor cannot do:

Deciding whether to change at all. Frequently the answer is no, and a practice willing to say so is worth listening to.

Preparing the data. Deduplicating suppliers, pruning the chart of accounts, reconciling opening balances. Unglamorous, determinative of the outcome, and precisely what a practice is equipped for — see data quality is the real constraint.

Designing the process. What gets automated, where thresholds sit, what stays human. Accounting judgements, and a client without a finance function has nobody else to make them.

Setting the controls. Approval limits, segregation, what the audit trail must capture.

Reviewing afterwards. Whether the thresholds still fit, whether the exception queue is being worked, whether anyone is sampling. Ongoing, and the part clients most reliably neglect.

That last one is the most defensible ongoing service, because it is genuinely needed and nobody else will do it.

The obligation nobody mentions

If you recommend a system and it goes badly, you own part of that in the client's eyes — regardless of what any engagement letter says.

Three things follow.

Recommend only what you actually know. A practice that has implemented something for its own book and for several clients has a basis for advising. One repeating a vendor's material does not, and the client cannot tell the difference until later.

Be explicit about what you are and are not responsible for. Advising on selection, implementing, and being accountable for the system working are three different engagements. Blur them and you will be assumed to have taken the widest.

Disclose any commercial interest. If you receive anything from a vendor whose product you recommend, say so in writing. It is a straightforward professional obligation and it becomes a significant problem only when it emerges later rather than when it is stated upfront.

The version that fails

A practice that treats this as reselling. Recommend the product, take a margin, hand over to the vendor, move on.

It fails because the value was never in the software selection — it was in the preparation, the process design and the ongoing review. Skipping those produces implementations that go badly, and the practice is the one the client calls.

The distinction is whether you are selling a product or selling your judgement about how the client's business should run. The second is harder, worth more, and does not create an obligation you cannot meet.

Whether to do it at all

Not every practice should. It requires genuinely knowing at least one system well, capacity to do implementation work alongside compliance, willingness to carry advisory risk, and someone who enjoys process design.

A practice without those is better served by having a clear, honest recommendation and a relationship with someone who does implementations — rather than taking on an obligation it cannot discharge.

As with advisory generally, doing this half-heartedly is worse than declining it deliberately. See the shift from compliance to advisory.

Common questions

Should an accounting practice advise clients on which system to use?

It is well placed to, since it knows the client's volumes, fragile processes and reporting needs better than any vendor and will live with the consequences of the choice. The important condition is recommending only systems the practice genuinely knows from its own use, because repeating vendor material creates an obligation the practice cannot discharge and the client cannot evaluate until later.

What does implementation work by a practice actually involve?

The parts a vendor cannot do: deciding whether to change at all, preparing the data by deduplicating suppliers and pruning the chart of accounts and reconciling opening balances, designing which processes are automated and where thresholds sit, setting the controls, and reviewing periodically afterwards. The ongoing review is the most defensible continuing service because clients reliably neglect it.

What are the risks of recommending software to clients?

You own part of the outcome in the client's eyes regardless of what the engagement letter says. That means recommending only what you know from experience, being explicit that advising on selection, implementing, and being accountable for the system working are three separate engagements, and disclosing in writing any commercial interest in the product — which is only a problem when it emerges later rather than upfront.

Why do practice-led implementations fail?

Almost always because the practice treated it as reselling — recommending the product, taking a margin and handing over to the vendor. The value was never in the software selection but in data preparation, process design and ongoing review, and skipping those produces implementations that go badly with the practice as the party the client calls.

Related: the shift from compliance to advisory · ai accounting for bookkeeping practices · how to evaluate AI accounting software