How to Use AI in Accounting, 7 Jobs It Does Well and 3 It Does Not

Accounting gets pitched AI as a way to close faster. That is the least interesting thing it does, and it is the thing most teams try first.

The close is a process problem. Most of what slows it down is a person waiting on another person, and no model fixes that. The accounting function has a different set of jobs, and AI is genuinely good at some of them.

So this is seven jobs where it earns its place in an accounting function, three where it does not, and the line between them. If you want the close specifically, automating the month-end close covers that, and account reconciliation covers the single biggest piece of it.

Seven jobs it does well

1. Reading a contract and telling you what it means for revenue

Hand it a signed agreement and ask which performance obligations it creates and when they are satisfied. It will not give you the entry. It will give you the questions to ask, in about a minute, on a document that would otherwise sit in someone’s inbox for a week.

The useful form of the ask is narrow. Which clauses create a deliverable, which of those have their own acceptance criteria, and where does the contract go quiet on timing. That last one is the money question, because the gaps are what you end up arguing about in year two. Ask it broadly and you get a summary you already had. Ask it for the gaps and you get a list you can walk into a meeting with.

2. Explaining an inherited reconciliation

The schedule nobody currently on the team built, with the tab that feeds the tab that feeds the summary. AI reads that faster than a person does and describes the chain in plain language. This is the highest-return use in most accounting teams and almost nobody starts here.

Do it in two passes. First ask for the chain: what feeds what, in order, ending at the number that goes on the face of the statements. Then ask the harder question, which is which cells are typed in rather than calculated. Hardcodes are where inherited schedules go wrong, and they are invisible when you are scrolling. A model that can read formulas finds them in seconds.

You will also find timing conventions nobody wrote down. On the demo ledger I teach with, one store books utilities a month in arrears, because that manager works off a paper file and posts when the bill lands. Nothing in the workbook says so. A model reading eighteen months of postings points at the pattern and asks you whether it is deliberate, which is exactly the right question.

3. First-pass coding on high-volume, low-value transactions

The 400 identical lines that always go to the same account and still get touched by hand. Judgment calls stay with you. Rules-based coding already did this badly for years; the difference now is that it can read a vendor description written by a human.

Set it up so the model has to tell you how sure it is, then only review the ones it is unsure about. That inverts the normal review, where you scan everything and your attention runs out around line 60. On a few hundred lines you will typically hand-check a couple of dozen instead of all of them, and the couple of dozen are the interesting ones.

The side benefit is pattern detection you were not asking for. Run a coding pass across a few months and recurring shapes fall out on their own. A store manager expensing a lump sum to miscellaneous every single month, always on a personal card, always without itemization, reads as ordinary in any one period and reads as a control gap across six.

4. Drafting the flux commentary

Give it the variance table and the prior month commentary and it writes the first draft. You will rewrite half of it. Half of a page you did not have to start is still the difference between commentary that ships and commentary that gets skipped.

What it cannot do is know why a number moved. It will produce a plausible reason and it will sound sure, which is the single most dangerous output in this whole list. So give it the reasons. Most companies already collect them and then never read them. If your location managers or department owners write monthly notes, feed those in alongside the variance table and the draft stops guessing.

That changes the job from writing to editing, and editing is where an accountant is actually fast. Related reading if you want the prompt structure rather than the principle: AI prompting for finance.

5. Writing the policy memo nobody has time for

Capitalization thresholds, expense categories, the intercompany convention. Every team has three of these documented in someone’s head. AI drafts them from a conversation, and a draft you can correct beats a policy that stays verbal.

The fastest version is to talk rather than type. Explain the convention out loud the way you would to a new hire, paste the transcript in, and ask for it back as a policy with the decisions separated from the reasoning. You will spot the two places where your own explanation contradicts itself. That is worth the exercise on its own.

6. Testing a population instead of a sample

Use it as a first look, ahead of the real testing. Ask it to find every entry in the general ledger that breaks a rule you can state in a sentence, then check the ones it flags. If you cannot state the rule in a sentence, that is a signal the rule is not a rule yet.

The next section is one of these run end to end, because the shape of it matters more than the description.

7. Answering the question behind the audit request

Audit requests are often a plain question wrapped in a request for six schedules. Ask AI what the request is trying to establish, then answer that. It is faster and the follow-up list gets shorter.

A request for a rollforward, an aging, a subsequent receipts listing and three supporting invoices is usually one question about whether a balance is collectible. Answer the question in the cover note, attach the schedules underneath, and the second round of questions mostly disappears. This is a reading job, and reading is what the tool is best at.

One test, on a ledger with something wrong in it

Everything above is easier to argue about than to picture, so here is job six run start to finish on the demo dataset I use for teaching. It is a fictional seven-store coffee company, and the numbers below are demo numbers, not a client’s.

The ledger is 3,137 journal entry lines across eighteen months and seven locations. The rule, stated in a sentence: every journal entry should have debits equal to credits. That is about as basic as a test gets, and it is also the kind of thing that quietly stops being true when entries get posted by hand.

The whole ledger is out of balance by exactly $1,000. A sample would have to be very lucky to land on the one entry that causes it, and a person scrolling 3,137 rows will not find it before lunch. Grouping every line by its entry ID and comparing the two sides takes a model a few seconds, and there is one entry that fails: a June 2025 posting at the Williamsburg store, $8,200 of debits against $7,200 of credits, memo pointing at a weekend pop-up market.

Then the second finding, which is the one I did not go looking for. That same $7,200 of pop-up cash sits in the general ledger and never made it into the reporting feed, so Williamsburg’s June revenue is understated in the management accounts by that amount. One sentence-long rule, two findings, and the second one is worth more than the first.

None of that is clever. It is arithmetic across a population, which is the thing computers have always been good at and the thing nobody had time to do on every account every month. What changed is that you no longer need to build anything to run it. You describe the check in English.

Three jobs it does not do

It does not decide the treatment

A model will give you a confident answer on a judgment call and it has no idea what your auditor accepted last year, what your parent requires, or what precedent you set in Q2. The treatment is a decision with your name on it. Use AI to assemble the argument, not to make the call.

The tell is that the confidence does not move with the difficulty. Ask it something settled and ask it something genuinely contested, and both answers arrive in the same steady tone. A colleague hedges when the ground is soft. This does not, so the hedging has to come from you.

It does not know your chart of accounts

Not the codes, the meaning. Which of your three marketing accounts is really rebates, why account 6120 has been dead since the reorg, what the suspense account is holding. That knowledge lives in people, and nothing here changes that. Data quality in finance is the wider version of this problem.

The demo ledger has a clean example. One location roasts beans and sells them to the other six, and that internal revenue sits in its own account with a memo saying no elimination has been posted. A model reading the ledger sees revenue, because it is booked as revenue. Only a person knows the group cannot count it. Every consolidation has one of these, and the model will be wrong about yours until somebody tells it.

Which is a workable problem, as long as you treat it as a briefing job rather than a modelling job. Write the caveats down once, in plain language, and hand them over at the start of the session. Data governance in finance covers the version of this that scales past one analyst.

It does not fix a broken close

If the close takes twelve days because three people are waiting on a fourth, AI makes each of those four people slightly faster and the close still takes twelve days. Sequence problems need sequence fixes. Closing the books is about the process, and it is the honest starting point if that is your bottleneck.

There is a decent test for which problem you have. Time one task end to end, then time how long it sat in a queue before anyone touched it. If the waiting is bigger than the doing, no tool on this page helps you.

How to check its work

Accounting is the one function where being wrong has a paper trail, so verification is not optional here the way it is when you are drafting an email. Four checks cover most of it.

Make it show you the row. Any figure it gives you should come with the entry or the cell it came from. If it cannot point at the source, treat the number as a hypothesis. This one habit catches most of what goes wrong, because a model that is inventing cannot produce a row reference that survives being looked up.

Ask the same question two ways. Once by account, once by location. Once as a total, once as a list that should add to that total. Answers that hold up under both cuts are usually real. The failure mode you are hunting is the confident, fluent, wrong answer, which is well documented in the research: the 2023 survey A Survey on Hallucination in Large Language Models is the readable overview if you want to understand why it happens rather than just guard against it.

Ask what would have to be true for the answer to be wrong. This is the question that gets you the caveats, and it works far better than asking whether it is sure. You will get back the assumptions it made about your data, and one of them is usually the thing you needed to know.

Never let it be the last thing that touched a number. A person signs. If your organization wants that written down properly, the NIST AI Risk Management Framework is the standard most internal policies are being built off right now, and it is short enough to actually read.

What does not go into the box

Before any of this touches real records, settle where the data goes. What matters is which product you are using, and what its terms say about training and retention. Those answers differ between the consumer tier and the business tier of the same tool, and the consumer tier is what most people sign up for on their own.

Two practical rules have held up for me. Anything with employee names or compensation in it does not go into a general-purpose chat window, ever, regardless of tier. And anything covered by a customer contract with a confidentiality clause needs someone other than you to have read the terms first.

Everything else is a judgment call, and it gets easier once it is written down. An AI policy for finance is the version of this you can hand to a team, and it is worth doing before the first person uploads a trial balance rather than after.

The line between the two lists

Every job on the first list is reading, drafting or checking. Every job on the second is deciding, remembering or coordinating.

That is a more useful rule than any tool comparison, because it survives the next model release. When something new lands, ask which of those six verbs it is doing. If it is one of the first three, try it. If it claims one of the second three, be slow.

The rule also tells you where the vendor demos are cheating. A demo that shows a model deciding something is showing you the part that does not work yet, dressed as the part that does. Watch for what the demo skips, which is almost always the moment a human would have said hold on.

The order to try them in

Take the reconciliation nobody wants to inherit and ask AI to explain it back to you. It costs twenty minutes, it needs no budget and no procurement, and it tells you more about whether this is worth your time than any pilot will. You already know whether the explanation is right, which makes it a safe first test.

Second, run one population test on a rule you can already state. Pick something you would be embarrassed to find, because those are the ones that build the case internally when you find them.

Third, put it on flux commentary, and only after you have somewhere to feed it the reasons from. Doing this one out of order is how teams end up with confident, wrong narrative in a board pack, which sets the whole effort back further than doing nothing would have.

The coding work comes last, even though it is the one with the obvious hours attached, because it is the only one on the list that needs the volume, the access and the review process all sorted at the same time. Get the first three working and the fourth becomes an argument you can win with your own numbers.

When you are ready to widen it, automating accounting processes covers the process side, automating accounts payable covers the highest-volume piece, rolling AI out to a finance team covers doing it with more than one person, and finance automation is the hub for the rest. If a term on this page was new, the AI glossary for finance has it.

Professional bodies are publishing usefully on this now. The ICAEW technology faculty on artificial intelligence and the AICPA and CIMA technology hub are both worth a look before you write anything into a policy.