AI Agents for Finance: What They Close and What They Draft

It is the third working day of the month. The finance lead at a 60-person company has a close to run, two people to run it with, and a forwarded article from the chief executive with one line typed above it: can AI agents take some of this off the team?

The honest answer is not yes or no. It is: which task.

Some finance work an agent can finish on its own, this quarter, with a review queue sitting behind it. Some it can only draft, because a person has to look before a number lands in the ledger. A small set it should never touch at all.

What decides the tier is not how hard the task is. It is whether the mistake is reversible. A chase email sent to a customer who paid last Thursday costs an apology and thirty seconds. A payment released against a duplicate invoice costs a phone call to a stranger's accounts team, and sometimes it costs the money.

This page sorts six finance jobs onto the right side of that line, and points at the page that covers each one properly.

What is an AI agent for finance?

An AI agent for finance is software that takes a recurring finance task, reads the records it needs from your ledger, bank feed and inbox, decides the next step, and either completes the task or hands a draft to a person for approval. It runs on a schedule or a trigger instead of waiting for someone to prompt it each time.

The difference from a chat assistant is where it stops. Ask an assistant for a dunning email and you get the text. You still open the ledger, find the customer, check what they owe, paste, and send. The writing was never the slow part.

Two words in that definition carry the rest of this post: completes and approval. Which of the two you get is a setting somebody chooses, and finance is the function where choosing it casually costs real money. The general version of the concept is covered in what an AI agent is, and the line between an agent and a rules engine is in AI agent versus workflow automation.

The finance jobs an agent can close, and the ones it can only draft

Finance is not one block of work. It is a dozen jobs with wildly different consequences when they go wrong, and the only useful page is one that separates them.

The test I use: can you take it back?

I sort every finance task by a single question: if the agent gets this wrong, what does the undo cost? The undo cost and the error cost are different numbers, and the undo is the one that should decide your autonomy setting.

Three tiers fall out of it:

• Reversible in minutes, by you. A wrong chase email, a mis-tagged expense, a paragraph of commentary that reads badly. Let the agent close these. The review is a spot check, not a gate.
• Reversible at close, by your team. A general ledger code that will need reclassifying, a reconciliation that will not balance. The agent drafts, queues, and shows its working.
• Reversible only if a third party agrees. A released payment, a filed return, an email of advice to a client. A named person decides, every single time, and the agent's job is to make that decision faster for the person who owns it.

That third tier is where most finance horror stories live, and it is the tier that vendor marketing is quietest about.

My routing, from the reversibility test above. The threshold on the first row is yours to set. Start it low enough that a mistake is an annoyance, and raise it after a quarter of clean runs.

Read the second column and the third together. Every row where the agent closes the work still has a human column, because "close" here means supervised: the person reads a weekly summary instead of each item.

The bottom row is the one people argue with. Advice is the job an agent looks most capable of, because a language model is fluent and confident about money. Fluency is precisely the problem there, and regulation is only half of why.

Can an agent do accounting, or only bookkeeping?

It does a great deal of bookkeeping and very little accounting, and the gap between those two words is where most disappointment comes from. Bookkeeping is recording what happened: categorise the transaction, match the payment to the invoice, keep the ledger tidy. That work is repetitive, high volume and checkable at a glance, which is exactly the shape an agent handles well.

Accounting is deciding what a thing is. Revenue recognition on a contract with three delivery milestones. Whether a cost is an accrual or a prepayment. A provision that depends on how likely a customer is to pay. Those calls carry a disclosure, sometimes a signature, and occasionally a regulator.

So the agent's real contribution at that level is a prepared draft and an exception list: here are the items I could not classify with confidence, here is why, here is what I would need to decide. That is a genuinely useful thing to receive on day one of close. The accounting still happens when a person reads the list.

Where the money actually goes wrong

Failure modes in finance automation are boring, repetitive and well known to anyone who has run an AP function. None of them are exotic, which is why the list is worth writing down before you switch anything on.

• A supplier emails the invoice, then the portal generates a second copy with a different reference. An agent that matches on invoice number alone treats them as two bills. This is the oldest error in accounts payable, and automation runs it at machine speed.
• A human miscodes one transaction. An agent applies a wrong rule to four hundred of them in a night, and every one of them looks consistent, which is exactly why nobody notices until the variance report lands.
• An email arrives saying the supplier's account has moved, and a confident agent updates the record. Supplier bank-detail fraud is among the most expensive attacks a finance team faces, and it is a text-processing task, which is to say it is a task an agent will do enthusiastically and wrongly.
• A customer is not paying because your delivery was short. The dunning ladder does not know that, so it escalates tone weekly at someone who is already annoyed with you.

Three of those four are prevented by the same control: the agent proposes, a person releases. The fourth is prevented by letting the agent read the support inbox as well as the ledger, so it knows a dispute exists before it sends anything.

None of this argues against giving an agent finance work. It argues for giving it the work where these failures cost an apology.

Stale bank feeds break this quietly

Bank feeds do not stream. They refresh on the bank's schedule, they break quietly when a login expires, and they backfill in lumps. An agent that reads the feed at 07:00 on Monday is reading a photograph of the account taken at some point it did not tell you about.

The result is a specific and embarrassing failure: the agent chases a customer who paid on Friday. Once is forgivable. Every Monday for a month is a customer relationship problem, and it is the fastest way to lose internal support for the whole idea.

The fix is unglamorous. Make the agent state the feed's last refresh time in every output it produces, and have it skip any invoice settled inside the staleness window; bank reconciliation with an agent works through where that window should sit. Set the window before you let anything send.

What it plugs into

Two categories of tool matter here, and conflating them is the reason a lot of finance AI projects stall in month two. There are the agents your ledger vendor has built into the ledger, and there is the agent that works across the tools your ledger cannot see.

What the ledger vendors have named so far

Intuit and Oracle have both named an agent layer, and for some teams the embedded one covers the first job on the list. Check what your own ledger has announced before you buy anything.

Product names and capabilities as stated in each vendor's own announcement, on the dates shown. Nothing in this table was re-checked against a live page while writing, so confirm against your own release before planning around a feature.

The Oracle row deserves a second read even if you will never touch NetSuite. A vendor that puts its own ERP installed base at more than 43,000 customers across 219 countries and territories, announcing agentic workflows, still shipped an explicit switch between approving each key decision and letting the agent act alone. They shipped the choice as an explicit setting rather than shipping autonomy alone. That is the same boundary this whole page is built on.

The work that never reaches the ledger

An embedded agent is governed by the ledger's permission model and scoped to the ledger's data. That is a genuine strength. It is also a perimeter, and most of the hours your team loses happen outside it.

Think about where an invoice actually begins. A supplier emails a PDF. Somebody checks it against a purchase order in a different system. Somebody chases an approval in a chat tool. Only then does anything become a ledger record. The embedded agent picks up the last step of that journey and has no view of the first three.

Used together the division is clean and neither replaces the other. The ledger agent owns the work inside the books, and the cross-tool agent owns the work that has to reach them. Giving an agent access to email safely is the practical version of that conversation, because the cross-tool half needs access granted deliberately, scope by scope. Grant it one scope at a time.

What this costs

I am not publishing a ledger price table in this post. Intuit and Oracle change packaging often, NetSuite list pricing is not public at all, and I could not load a single vendor pricing page while writing this. A price table that is wrong in five weeks is worse than no table.

What I can tell you is the shape of the bill.

The two bills you are actually comparing

The first bill is your ledger tier. Embedded agents rarely carry their own line item, which sounds like good news and is really a tiering question: the agent you want may sit a plan above the plan you are on. Ask your account team whether the capability in your release carries an incremental cost, and get the answer in writing before you build a business case on it.

The second bill is the cross-tool agent that handles everything before and after the ledger. That is the part Gravity does, so treat the next paragraph as interested testimony and check it against the alternatives in AI agents for business.

Free tier

Your first agent is free, with no card.

Pricing

Pro is $5 a month during the alpha, and Max is $20 a month for more agents and usage. Buy more usage from the account if you run out. As of October 2026.

Status

Private alpha. You apply, and the first agent is free.

If a run fails

A run that fails on a platform error, with no usable output, is refunded under the refund policy.

Set that next to what the work costs today. Most teams compare agent against agent and skip the comparison that decides it: one monthly line against the hours somebody currently spends reading an aging report and writing the same four emails.

Which should you start with?

Accounts receivable chasing, for almost every team. It is the highest-volume job on the list, so the agent gets enough runs inside one month to prove or disprove itself. The output is an email, which anyone can check in seconds. And the worst outcome is an apology.

Month-end reconciliation is a bad starting point, even though it is the job most finance leads name first because it is the one that hurts most. The work is judgement-heavy, the output is hard to check quickly, and a mistake misstates the books. Start there and your first bad week ends the programme.

Management report assembly is the strong second choice, particularly if someone on your team currently spends the first Friday of the month copying numbers into slides. The agent assembles, a person writes the commentary and signs it. Our page on financial report generation covers the assembly-versus-commentary split in detail.

Accounts payable comes third, and only with a value threshold. Let the agent code and queue anything under a number you are comfortable losing, and route everything above it to a person. Raise the threshold after a quarter of clean runs, not before.

Bookkeeping categorisation is the right first job if you are the bookkeeper rather than the finance lead, because the review queue is already part of how you work.

Client-facing advice stays with you, permanently. If you are an advisor, the agent's job is preparation: the pack, the research, the meeting notes. Everything that reaches the client goes through you. AI agents for financial advisors is the page for that shape of practice.

Ninety days, one agent at a time

Here is the sequence I would run if the close from the opening of this post were mine:

1. Weeks 1 to 4. One agent, AR chasing only, drafts held for approval. Nothing sends without a person clicking. Count how many drafts you edit.
2. Weeks 5 to 8. If the edit rate is low, let the routine chases send and keep disputes in the queue. Add the staleness check on the bank feed before you do this, not after.
3. Weeks 9 to 12. Add the second job. Report assembly if the month-end Friday is the pain, AP coding under a threshold if the invoice pile is.
4. End of the quarter. Review the exception queue instead of the success rate. What the agent could not do tells you more about the next agent than what it could.

Finance is not the only function where this ordering works, and it is the one where getting it wrong is most expensive. If you want to see how the same logic applies across other roles, AI agents for every profession runs the exercise job by job.

FAQ

Sources