Most accountants have tried AI by now. Ask a general chat assistant a tax question and you tend to get a confident answer, sometimes with a section reference that does not hold up, and plenty of practices have filed it under good for emails. The practices pulling ahead drew a different conclusion. They put it on the assembly work that ties back to a trial balance and already has a reviewer, and connected it to the systems that work lives in. The signing stayed with them.
Some New Zealand practices are starting to run their year-end this way. The gap between them and everyone else is small this year. It gets wider every season, because each correction a firm makes to its drafts is written back into the method, and a firm that starts next year starts without any of them.
The work that suits it
Two things make a job a good fit. It has something to tie back to, a trial balance or last year's file, so a wrong answer shows up as a difference rather than hiding in fluent prose. And it already has a reviewer, so whatever the AI produces lands in a process that was built to check someone else's work.
Most of the compliance year looks like that. AI goes wrong on judgement nobody checks. It is at its most useful on assembly somebody will.
The year-end file
This is the obvious place to start, because it is the highest-volume work in most practices and it has a trial balance underneath it. The AI reads the ledger and last year's file, builds the lead schedules line by line, ties each one back to the trial balance or states the difference, and lists the queries it could not clear. Depreciation, accruals, prepayments and reclassifications come out as draft adjusting journals with the schedule that computed them attached. The reviewing accountant starts at review instead of assembly.
What changes is where the hours go, not who is responsible. The junior who used to build the file now checks a draft of it. The partner still signs, and can stand behind more jobs without reading any less carefully, which is how a practice takes on growth without hiring at the same rate.
Checking what someone else drafted
Review is the other half, and it matters more once some of the drafting is done by AI. A reviewer can point it at a finished workpaper pack and ask what a good manager would ask. Does every figure tie? Has every account in the trial balance made it into a workpaper? It should also want each tax position to state its basis, and last year's open points to be closed.
The coverage question is the one people underrate. A page of green ticks tells you two numbers agree. It does not tell you an account was left out, because an account that was never mapped produces no tick at all.
The tax calendar
Much of a practice's year is dates. In New Zealand that means provisional tax by balance date and option, FBT, payday filing and the extension-of-time list. In Australia it is PAYG instalments, the BAS, the FBT year to 31 March and STP. The dates come round every year, even where the treatment differs by client.
AI handles the recurring parts well. It can draft the instalment schedule and the client letter that goes with it. It can reconcile the payroll filings to the ledger and show which clients are behind. IRD and ATO mail is the same shape of job. It sorts the letters by client and deadline and drafts the routine replies for approval. Anything that cannot wait, it sends straight to the person responsible.
The caution is rates and dates. A model that states a threshold from memory will sometimes state last year's. A workflow worth relying on looks each one up against the source when it runs, and records when it did.
Asking the client for things
Every practice knows the pattern. The annual questionnaire goes out the same for every client, the answers come back partial, and someone spends weeks chasing. AI can build the request from the client's own ledger instead, so the new loan or the account that moved turns up as a specific question with the reason attached. The client gets one request instead of a form, and any chasers after it go out in the firm's tone. Someone at the firm still presses send.
Questions with an answer you can check
Tax research is the use most people try first, and the one that burned them. A generic assistant will answer a tax question fluently whether or not it has read anything, and a better model does not fix that on its own. What fixes it is an answer tied to sources somebody can open and check.
There are two ways to get one. The first is a research tool built for it. Nylon, the tax and law research tool formerly called Law Cyborg, has an MCP connector, so a firm that already relies on it can call that research from inside the AI it works in rather than switching windows. In Nylon's words, you "stay inside your preferred AI platform", "backed by Nylon's research". The second is method written into the workflow: research that says which sources it actually opened, names the ones it could not get to, argues against its own conclusion, and says at the end whether it finished. The research skills in our pack work that way. Either way, the research note becomes a draft the reviewing accountant can check rather than a guess they have to redo.
The files nobody wrote a template for
The generic tools are written for generic jobs. A livestock valuation, deferred milk income at balance date, construction retentions and an imputation credit account that runs to 31 March whatever the company's balance date all need rules looked up against current sources and applied to one client's records. Australian examples include Division 7A loans and the franking account. These are the files that eat an afternoon, and they are where a partner can tell quickly whether an AI setup was built by people who have seen one.
What stays with the accountant
Some things should not move into an AI workflow at all. Lodging, signing, taking a final tax position and moving client money stay with the firm's own people. Everything the AI produces is a draft, and the practitioner who signs remains responsible for it.
A practice also has a problem most single businesses do not. It holds hundreds of clients' records, and one client's figures must never inform another client's work. That has to be enforced in the connections rather than left to the model's good behaviour. And where staff are already pasting client figures into a personal AI account, that is the first thing to fix, because none of these controls reach it.
The AI becomes where you work
The larger change is where the work happens. A practice has run for years on a row of browser tabs: the ledger in one, the documents in another, then the practice manager, the IRD portal and the research database. Connectors change that. The AI the firm already uses becomes the place people work from, and it calls out to those systems when a job needs them, under the permissions the firm has set. You ask for the job in one place, and the trial balance comes from Xero, the client's documents from FYI Docs, the research from Nylon or whichever tool the firm trusts and, once that connection is built, the job's status from the practice manager. My initial view is that most specialist tools will end up like this: less a place you go, more a source your AI calls on.
Some of this can start from exported files. Done properly, most of it needs the AI to reach the ledger. Xero's own connector in Claude's directory is read-only and its tools return summaries, which suits an owner checking the quarter. A year-end file needs the trial balance and the detail underneath it, down to the fixed-asset register and the transaction listings. A practice also needs to act as well as ask: post the adjusting journal, record the payment, fix the contact, raise the invoice. And it needs to do that across a client list, where the expensive mistake is a journal landing in the wrong client's file.
We built our own Xero connection for that reason. It covers 312 operations, every one Xero publishes for its Accounting, Assets and Payroll NZ APIs. It picks a client by name, and it will not write anything until the write names the organisation it lands in; where two clients match, it lists both and asks. It does not cover Australian payroll yet.
We built one for FYI Docs as well. The AI finds the client and the job by name and brings that job's documents into the workflow, so the evidence behind a workpaper comes from where the practice already keeps it.
Why this year
Every workflow above improves the same way. Someone at the firm corrects a draft, and the correction is written into the skill so the next draft does not need it. A practice that starts this year goes into next season with a year of its own corrections built in. One that waits starts from the same generic draft everyone else gets.
The market is moving in the same direction. Compliance work is priced against a market that keeps compressing, and the firms whose files arrive assembled will be quoting against the ones still building them by hand. The graduates notice as well. The ones a firm most wants to keep did not join to key numbers into workpapers, and they know which practices have stopped asking them to.
What we built, and what it is not
We implement Claude in accounting practices for a living and wrote the pack described below, so I am inclined to see a use for it everywhere. Weigh this section accordingly. A partner can try any of these jobs on a de-identified file with their own AI account, and I would encourage it. Putting one into production across a client list is a different job. The connections have to be scoped and the review gates designed, and then the workflow runs on held-out jobs before anyone relies on it. That is where most of the effort goes, and it is what firms hire us for.
We wrote an accounting pack of twenty-five skills for New Zealand public practice, and an Australian sibling built from it. Each skill is a written description of how one job is done, checked against IRD or ATO sources when it runs rather than remembered. The New Zealand pack is running on real client engagements; no Australian firm has run the Australian one in production yet. They are built as Claude skills, and where a firm runs Copilot or ChatGPT we scope the workflow for that instead. The workflow map lays out twenty of the jobs the New Zealand pack covers.
The pack is where a firm's version starts. It moves away from ours as it takes on the firm's own templates, review standards, client mix and risk settings, and that adaptation is most of what an implementation is. We start with one workflow, usually the year-end file, and build it over six weeks at a fixed fee we quote after a free first conversation.
If you would rather try one job yourself first, pick one with a trial balance behind it, so there is something to check the answer against. This page is how we suggest going about it.