The Tool Isn't the Bottleneck. You Are.
There is a pattern showing up in accounting workflows that nobody seems to want to say out loud: AI tools are creating more work for some practitioners, not less. Not because the technology is bad. Because the gap between what the tool can do and what the user understands about the work is wider than anyone anticipated, and that gap has a cost.
I want to put a name on it and talk about what it actually looks like in practice.
Negative productivity
I have started calling it negative productivity. In accounting workflows, it means this: you use an AI tool, it generates output, the output looks reasonable, and then you spend the next several hours figuring out what it got wrong and fixing it. By the time you are done, you have put in more time than if you had built the thing yourself. The tool did not save you work. It relocated it, disguised it, and made it harder to find.
I built an ASC 842 lease accounting template not long ago with AI assistance, and I lived this firsthand. I already had an established template with a sign convention I had thought through: lease payments entered as positive numbers. The tool looked at the workbook, decided it had a better approach, and flipped every payment to a negative. No warning. No question. Just a quiet override of a decision I had already made intentionally.
That was annoying, but it was catchable. What was harder to manage was the scope problem. Because I had not constrained the prompt carefully enough, the tool did not stay in the section I was working on. It went through the entire workbook, found things it interpreted as problems, and started solving them. Some of those were not problems at all. Some of the solutions created new ones. I spent hours untangling it, not because the tool had failed in any dramatic way, but because I had handed it too much rope and it used all of it.
The lesson I took from that is the one I keep coming back to: broad instructions are a gamble. You might get lucky. You might get a workbook full of decisions the tool made on your behalf that now have to be reviewed, reversed, or explained.
Why structure is the whole game
The practitioners I have seen get consistently good results from these tools share one habit. They define the structure of the output before they start prompting. Not the general idea of what they want. The actual structure: what each section produces, how the pieces connect, what the sign conventions are, what the tool is not supposed to touch.
That level of specificity is not a prompting skill. It is an accounting skill. You can only define a structure that clearly if you understand the output well enough to have built it yourself. And that is the thing that does not get said enough in conversations about AI fluency: the tool is downstream of your knowledge, not a replacement for it.
Asking AI to build something you do not fully understand is not prompting. It is outsourcing your judgment to a system that will fill every gap you leave with something plausible. Plausible is not the same as correct, and in accounting, the difference between those two things tends to show up at the worst possible moment.
What this means at the senior and manager level
If you are a senior associate or manager, you are probably using these tools yourself and watching people around you use them too. Both of those vantage points matter here.
For your own work, define the structure before you open a prompt window. What does the final deliverable look like? What does each component need to do? What have you already decided that the tool should not override? The clearer those answers are going in, the less cleanup you will do coming out.
For the people around you, the hardest version of this problem to catch is output that looks right. Someone who does not fully understand the work they are producing may not recognize when the tool has made a bad decision on their behalf. Review at this level cannot just check for obvious errors. It has to include some sense of whether the person who produced the output actually understood what they were looking at.
The conversation worth having with leadership
Firms are pushing AI adoption right now, and a lot of that pressure lands on senior and manager level staff to implement it without a lot of guidance on what good implementation actually looks like. "Use it to go faster" is not a framework. It is a setup for negative productivity at scale.
If you have the standing to push back on this or shape how it gets rolled out on your team, the most useful question to raise is not about the tools. It is about the review layer. Who is checking the output? Do they understand the underlying work well enough to catch what the tool gets wrong? Is there a defined structure for what the output is supposed to look like, or is everyone figuring that out one prompt at a time?
Those are accounting questions. They have to be answered before the technology becomes useful rather than just fast.
The bottleneck
These tools are going to keep improving. The models will get better, the integrations will deepen, and the outputs will become more sophisticated over time. None of that changes the core dynamic.
Right now, for a lot of practitioners, the limiting factor is not the model. It is not the data. It is the user. The tool will only ever be as effective as the person directing it, and no future version of the software is going to close a gap in accounting knowledge on your behalf.
The practitioners pulling real value out of these tools are the ones who use them on work they already understand well enough to verify. They define the structure. They constrain the scope. They catch the sign convention flip before it becomes three hours of cleanup.
That combination is not as common as the hype around AI would suggest. Which means, at least for now, it is worth something.