AI Efficiency for Accounting | Volume 1 | Edition 10 | by Marcie D Terman | 12/10/2026

Imagine this, an accountancy practice has a recurring problem. Every quarter, a handful of clients slip through the cracks because one document is missing and nobody notices until the filing deadline is uncomfortably close. The information is scattered across email, shared folders and IRIS. Staff check manually. Reminders are inconsistent. Occasionally everybody assumes somebody else is dealing with it. 

One member of the team gets fed up. They understand the problem intimately because it’s their responsibility. At home they’ve been experimenting with an AI coding tool, trying out things. So they decide to try to build an application that shows every client in the practice. It has a list of the required payroll information of each client and tracks what has been delivered against what it knows is needed. It is meant to log the real-time position of where each client stands in the delivery of that information. And based on a defined schedule it can send reminders via email. There is also an internal alert that escalates issues when it gets within 10 business days of a deadline. It also knows the date of each quarterly deadline. They throw in 25 dummy accounts to see what happens.

It works.

The prototype solves one particular problem but it proves that this may be a direction the practice can explore to solve the existing problem. That is a very important moment.

THE FIRST QUESTION IS STILL: SHOULD YOU BUY OR BUILD?

Before doing anything else, ask whether an existing product already solves the problem well enough. Sometimes the answer will be yes, and if it does the job properly, integrates sensibly and fits the practice’s workflow, buying may be the right answer. There is no virtue in bespoke development for its own sake.

However, off-the-shelf software may not fit the requirements of the practice. It always comes with ongoing subscription costs—per-user or per-client licensing fees that recur month after month, year after year. If a software solution only solves part of your issue or forces your team into clunky workarounds, paying that perpetual cost quickly becomes poor value for money. Perhaps the software package offers a client experience that is wrong. Perhaps the integration with other software the practice uses is cumbersome. That is when building becomes worth considering. The right question is not: “Can we build this?” It is: “What is the best way to solve this particular business problem—operationally, commercially and safely?”

VIBE CODING HAS CHANGED HOW PROBLEMS GET EXPRESSED

In the near past the option of bespoke software was unapproachable simply due to cost. Developing software was both costly and time consuming, commodities not in endless supply in most businesses. In advance of starting the development process extensive periods of consultancy were necessary to understand how the business worked.

Now Vibe Coding provides a shortcut because the people within the practice who understand intimately how the business works and its internal processes can start the development process by simply describing in common language how they want an application to work, and the Vibe Coding package will turn that requirements list into executable code. AI coding tools—allow people to build functional software simply by describing what they need in plain English using tools like Cursor, Claude, Lovable or Bolt—have changed that. People who understand the work can now create rough solutions themselves. They can test an idea, show colleagues what they mean and discover very quickly what is useful and what is not. That is a genuine breakthrough that when recognized can provide a huge benefit to a small to medium sized business. The person closest to the problem is can begin to shape the solution. The prototype may therefore be extremely valuable even if none of its code ultimately survives. It may be the clearest working description of the problem and the desired outcome that the business has ever produced and can be used to shortcut the development process giving the practice a unique offering they can use to position themselves in their market.

THE VIBE CODED PROTOTYPE HAS DONE ITS JOB

The next step is not automatically to start transferring live client data into the vibe coded application. Running critical business operations on a prototype is not advisable. Sometimes the prototype will contain useful logic or interface work that can be refined internally. Sometimes it will mainly have proved:

• what the real problem is;
• what users actually need;
• what the workflow should look like;
• and what “better” productivity could feel like.

The prototype’s first job is to reduce uncertainty and validate the concept before committing time and budget.

WHY THE PEOPLE INSIDE THE BUSINESS MATTER MOST

The internal staff member who builds the prototype may not be a professional software engineer but they have incredibly valuable information that is not readily apparent to someone on the outside. They know:

• where the current process repeatedly fails;
• which workaround everyone uses;
• which exceptions happen in real life;
• which information really matters;
• and which parts of the current system nobody actually needs.

Business knowledge defines the problem. The prototype is the language used to express it clearly capturing the nuance of that particular company.

RAPID DOES NOT MEAN CASUAL

When a tool allows you to build something in an afternoon, it is easy to assume that deployment is equally simple. If software is going to be used by real people and touch sensitive client and practice data, internal teams need to answer fundamental operational questions:

• Who can access which information?
• How is that information transmitted?
• What permissions are applied to each user?
• How is client data separated and protected under UK GDPR?
• What happens when an integration with an external system stops working? Would you be aware?
• Can changes be audited?
• How is the data backed up?
• How is the backed up data recovered?
• What happens if there is an unexpected failure?
• Is the system secure against outside interference?
• What if there are legal or regulatory changes that require multiple internal systems to change? 
• Do those changes create unexpected outcomes in follow-on-systems down a chain?

Speed in prototyping is brilliant. Speed in production without governance or oversight is an unacceptable risk to a company in the accountancy sector.

AI IS NOT JUST PROMPTING

Knowing how to prompt a frontier model to generate a working feature is useful, but building a dependable AI workflow requires broader thinking:

• Which model is appropriate for the task?
• Is AI needed at all, or is conventional software logic better?
• How are model outputs validated before they hit client files?
• What data should the model be prevented from seeing?
• Is retrieval-augmented generation needed?
• Can a smaller, lower-cost model handle the job?
• Does the model need to run within a private, secure environment?
• Is client data adequately protected?
• How is human oversight managed?

Prompting is a creative entry point. System design is what keeps it working predictably day in, day out.

THE BIGGEST MODEL IS NOT ALWAYS THE RIGHT MODEL

There is a tendency to put a frontier AI model (like GPT, Claude or Gemini) behind every feature because it feels like the most capable option. Sometimes that is appropriate but sometimes it is like using an elephant gun to shoot a mosquito. A tightly defined classification, extraction or routing task inside a practice workflow may be better handled by:

• a smaller model;
• deterministic logic;
• retrieval;
• rules;
• or a combination of approaches.

That is cheaper, faster, more predictable and easier to control. The principle should be simple; Use the least complicated technology that reliably solves the problem.

SECURITY AND COMPLIANCE ARE FRONT-END CONSIDERATIONS

Once real financial or client information is involved, security and regulatory compliance—such as UK GDPR and ICAEW/ACCA data privacy rules—cannot be an afterthought.

Internal builds must account for:

• authentication and role-based permissions;
• data separation and UK/EU data residency;
• encryption in transit and at rest;
• audit logging;
• model access boundaries;
• backup and recovery protocols.

Good internal development means making those security decisions explicitly before putting software near client data.

THIS IS ABOUT SOLVING ONE PROBLEM AT A TIME

Regardless of methodology, hiring in an outside resource or managing the process internally, the most successful technical projects are split into individual blocks and built separately. Vibe coding gives internal teams a superpower: the ability to tackle specific friction points without waiting for broad IT transformations. The most effective approach is tightly focused:

• Find the problem causing the most immediate pain or wasted staff hours.
• Prototype a solution to test the workflow.
• Ensure it works alongside the tools the practice already relies on.
• Evaluate whether to adopt, refine, or replace it.
• Then decide what problem is worth tackling next.
• Keep the effort practical, measurable and commercially sensible.

Always have a tangible objective and a way of measuring success.

THIS IS WHAT WE WILL BE TALKING ABOUT ON 11 NOVEMBER

On 11 November, we are running a practical session for business people who are experimenting with vibe coding, and for managers who want to encourage that kind of initiative inside their teams. We’ll look at what happens when a useful prototype starts becoming something the business wants to rely on, and how to decide whether the next step is:

• buy an existing product;
• continue building internally;
• or bring in professional engineering support.
• We’ll also explain the Intentive Method: how experienced developers can work directly with staff inside the business to solve one important problem quickly, securely and in context.
• Bring the prototype, the problem or the idea.

https://www.eventbrite.com/e/2003063144787?aff=oddtdtcreator

Closing

Vibe coding has changed the economics of discovering what software a business needs. The person closest to the problem can now test an idea rather than merely describe it. That is a genuine breakthrough. The next step is not to throw away that immediacy and return to slow, disconnected development. It is to combine it with professional engineering. Not to rebuild the whole business. Just to take the problem that is causing the most pain and solve it properly.

Your business problem. The people who understand it. Experienced developers. Three days to working software.

Then we tackle what’s next.