There is a lot of writing about AI in accounting and not much of it is written by people who are responsible for a close.
I use Claude, ChatGPT, and Codex daily to build finance tools, and n8n for workflow automation. What follows is where these tools have genuinely earned a place in my work, where I do not let them near, and the rule I use to tell the difference.
The rule
The question is not "can this tool do the task?" It is "what happens when it is wrong, and would I notice?"
A tool that drafts something a person reviews before it has any effect is low risk, because being wrong produces a visible draft that gets corrected. A tool that takes an action nobody inspects is high risk, because being wrong produces a silent error that surfaces later, usually somewhere expensive.
That distinction does more work than any list of approved use cases, because it survives contact with tools that change every few months.
Where these tools genuinely help
Writing procedures. Documentation is the classic task that everyone agrees is important and nobody has time for. Describing a process out loud and getting back a structured first draft removes the blank page, which is most of the resistance. The draft is never right, and it does not need to be. It needs to be close enough that editing it is faster than writing it, which it reliably is.
Explaining unfamiliar guidance. Getting an accessible explanation of a standard or an unfamiliar area, with the specific question you actually have rather than a general overview, is a real accelerant. The critical discipline is that this is orientation, not authority. It tells you what to go read and what questions to ask. The conclusion still has to come from the standard itself, and anything with a reporting consequence gets verified against the source. These tools are confidently wrong often enough that treating output as citable is a genuine risk.
Building the tooling. This is where the largest gain has been for me. I am an accountant, not a software engineer, and before these tools the gap between "I know exactly what report I need" and "I have that report" required someone else's time and a queue. Now I can build a dashboard, write a reporting query, or wire up a workflow myself. The close checklist dashboard I built, where every task links to its SOP, and the KPI dashboards covering AP, AR, and inventory both came out of that shift.
First pass analysis. Pointing a model at a variance file and asking what stands out is useful as a starting point. It surfaces things worth looking at. It does not tell you what happened, and the explanation it offers for a variance should be treated as a hypothesis to test, not a finding.
Cleaning up messy inputs. Restructuring an inconsistently formatted vendor file or normalizing descriptions across sources is exactly the kind of tedious, pattern based work these tools are good at, and the output is immediately verifiable by looking at it.
Where I do not use them
Anything that produces a number nobody checks. If a model calculates something and that number flows into a report without a person confirming it, you have introduced an error source with no detection mechanism. The issue is not that the tool is bad at arithmetic. It is that the failure is silent.
Judgment that carries a reporting consequence. Whether a performance obligation is distinct under ASC 606, whether an accrual is appropriate, whether a control deficiency rises to a significant deficiency. These require someone who will stand behind the answer. A model does not stand behind anything.
Anything involving confidential data going somewhere it should not. This is a policy question before it is a technology one. Know what your company permits, know where the data actually goes, and do not assume. For workloads involving private data I run local models instead, which removes the question entirely.
Controls themselves. A model can help you document a control or think through its design. It should not be the control. An automated review that a person does not perform is not a review, whatever the process map says.
Where n8n fits
n8n is a different category of tool and the confusion between the two causes problems.
n8n moves data between systems on a schedule or a trigger. It is deterministic. It does what you configured, every time, and when it breaks it usually breaks loudly. That reliability is exactly what you want holding a recurring process together.
A model is not deterministic. Given the same input it may produce a slightly different output, and it will occasionally produce a confidently wrong one.
The useful pattern is to let n8n own the structure and hand the model only the specific step that needs judgment, with the result routed to a person when it matters. n8n fetches the data on schedule, the model summarizes or classifies, n8n routes the result to the right place and escalates anything uncertain. The workflow is reliable; the one genuinely fuzzy step is contained and visible.
Inverting that, letting a model decide what to do next in an unsupervised loop over financial data, is how you build something nobody can explain to an auditor.
Practical advice
Start with something that does not matter. Automate a report you build for yourself. Get it wrong a few times somewhere the stakes are zero. The judgment about what these tools are reliable at is experiential, and it is much cheaper to acquire on a personal project than on the close.
Verify before you trust, every time, for a while. Check the output against the source until you have a calibrated sense of where it is reliable. That sense is specific to your data and your use case, and it does not transfer from someone else's experience.
Write down what you built. An automation nobody understands is a liability the moment you are unavailable. The documentation standard for something you built yourself is the same as for anything else in the close.
Keep a person at the control points. This is the one rule that does not bend. Approvals, exception resolution, anything that moves money or creates an obligation. The automation can prepare the decision perfectly. It should not make it.
The honest summary
These tools have measurably changed what I can build and how fast I can document things. They have not changed what I am willing to let run without review, because that boundary is set by the control environment rather than by the capability of the tool.
The accountants getting the most out of this are not the ones using it for the most tasks. They are the ones who worked out early which tasks tolerate being wrong and confined it there.