How LLMs and AI Agents Are Used in Finance

LLMs and AI agents are useful in finance for reading unstructured documents, classifying messy data, and drafting communications, but they are not safe to use unsupervised for anything that must reproduce exactly, such as posting journal entries or approving payments. The pattern that works is scoped AI for genuine judgment steps, gated by a confidence threshold, wrapped in repeatable workflow code, with uncertain cases routed to a human reviewer.

This is the practical how-to map. If you want the underlying argument for why probabilistic AI cannot replace fixed process code in finance, see the Loopfour post on deterministic vs. probabilistic automation. This article is about which tasks sit on which side of that line, and what to do about the ones in the middle.

Where Do LLMs Actually Help in Finance?

The answer comes down to one property: LLMs are good at making sense of things that were not designed to be machine-readable. Finance teams live inside structured systems, but the inputs to those systems are often unstructured. Vendor invoices arrive as scanned PDFs with inconsistent layouts. Contracts describe payment terms in plain English. GL descriptions are whatever a staff accountant typed at 11 pm on a Tuesday. LLMs are well-suited to bridging that gap.

Here are the categories where they provide real leverage:

Reading contracts and extracting terms. A contract for a SaaS deal might define the performance obligations, payment schedule, and renewal conditions across 40 pages of legalese. An LLM can extract the SSP, contract start date, and billing cadence far faster than a human can parse the document manually. This directly accelerates ASC 606 revenue recognition workflows, where the inputs are structured but the source of truth is a contract.

Classifying GL lines. When a line item arrives labeled "AWS - prod-db-1" or "consulting fees - Q2," a human accountant knows which cost center and GL account it belongs to. An LLM trained on your chart of accounts can learn that pattern too, typically hitting high accuracy on the easy cases and flagging the ambiguous ones for review.

Drafting dunning and collections notes. Personalized collections outreach is time-consuming to write. LLMs can draft the first version of a dunning email, adjusting tone based on the invoice amount, days overdue, and customer relationship tier. A human reviews edge cases; the routine ones go out automatically.

Flagging anomalies and variance. An LLM or a statistical model can scan a set of journal entries for amounts that are unusually large, vendors that are new to the ledger, or timing that does not match the close calendar. This is pattern recognition, not posting, so the risk of error is low and the upside (catching a mis-coded expense before the books close) is real.

Summarizing variance commentary. For board decks and FP&A packages, LLMs can draft the narrative behind a revenue or expense variance faster than a finance analyst can stare at a spreadsheet. The analyst still owns the numbers; the LLM drafts the sentence.

Takeaway: LLMs earn their place in finance by reading what systems cannot read, not by making the decisions that systems are built to enforce.

Where LLMs Are Dangerous to Trust Unsupervised

The failure modes of LLMs are well-documented: they hallucinate, they are inconsistent across runs, and they do not know what they do not know. In finance, those properties are disqualifying for a specific class of tasks.

Posting journal entries. A journal entry is a write to the ledger. If an LLM posts a debit to the wrong account, or posts twice, or fabricates a number it was not given, you have a reconciliation problem that may not surface until month-end close or, worse, an audit. Posting must be a deterministic step driven by rules, not a probabilistic step driven by a model.

Approving payments. The approval step in an AP workflow is a control. It exists precisely to catch errors, duplicate invoices, and fraud. Routing an approval through a language model that might say "yes" based on a plausible-looking invoice is not an approval, it is a gap in the control.

Anything that must reproduce exactly. Revenue recognition under ASC 606 requires that the same inputs produce the same outputs, period after period. So does three-way match in AP. So does bank reconciliation. These are not tasks where "usually right" is acceptable.

The practical rule is: if a step requires the same output every time given the same inputs, it should be code, not a model.

Takeaway: The tasks LLMs cannot safely own are the ones where consistency is the whole point. Use code for those, and let LLMs handle the upstream reading and classification.

The Pattern That Works: Scoped AI Inside Workflow Code

The teams that get this right do not replace their finance workflows with AI. They embed AI as a scoped step inside a workflow that otherwise runs as fixed code. Here is how the anatomy works:

1. The workflow triggers on a defined event (invoice arrives, contract is countersigned, bank file drops).
2. Deterministic steps handle data retrieval and validation: fetch the PO, pull the vendor record, check for duplicates.
3. Where a genuine judgment step is required (extract the payment terms from a PDF, classify the GL line), the workflow calls an LLM with a narrow prompt scoped to that task only.
4. The model returns a result with a confidence score. If the score is above the threshold, the workflow proceeds. If it is below, the item is routed to a human reviewer with the model's draft as a starting point.
5. The human's decision is written back into the workflow and the run record. Future similar items can be used to improve the model's accuracy.
6. All downstream steps, including the write-back to the ERP, the approval notification, and the close calendar update, run as deterministic code.

This is the confidence threshold pattern. The AI is not the decision-maker; it is the first reader. The threshold is the circuit breaker.

A team processing 3,000 invoices a month might find that 80 percent of invoices have clearly readable, consistent fields and high model confidence. Those flow through automatically. The remaining 20 percent, typically non-standard formats or new vendors, go to a reviewer. That reviewer handles 600 invoices instead of 3,000. The model did not eliminate the human; it focused the human on the work that requires judgment.

Takeaway: The confidence threshold is what turns 3,000 invoices into 600 that need a human, focusing your team on judgment work instead of data entry. It is also what separates a useful AI step from a liability.

Finance Task Map: Good Fit or Not?

Why "AI Agent" Does Not Mean Autonomous in Finance

The term "AI agent" has come to mean a model that can take actions, browse, call APIs, and chain steps together. In general software that is fine. In finance it requires a much more specific definition.

A finance agent that can read a contract, extract terms, post the revenue schedule, and send a confirmation email is useful only if every step other than the reading is constrained. The agent must not be free to decide the revenue recognition method. It must not be free to choose which account to post to. Those decisions belong in the workflow code, and they were made when the workflow was built, reviewed, and deployed.

Loopfour is built on exactly this model. The platform wraps scoped AI calls inside fixed workflow code. The AI handles what code cannot handle (reading a PDF, classifying a messy description), and code handles the rest. The customer team approves exceptions; Loopfour engineers maintain the workflow logic. Finance teams that try to run autonomous LLM agents against their ERP typically spend more time cleaning up inconsistencies than they saved on processing.

Takeaway: "AI agent" in finance should mean a workflow that uses AI for specific bounded steps, not a model with open-ended access to your ledger.

FAQ

Can an LLM read and process invoices reliably?

LLMs can extract structured data from PDF invoices with high accuracy on standard formats. Accuracy drops on handwritten, low-quality scans, or highly non-standard layouts. The right pattern is to use the model for extraction and route low-confidence results to a human reviewer rather than assuming the model is always right.

What is a confidence threshold in a finance AI workflow?

A confidence threshold is a minimum score that an AI model must reach before its output is accepted without human review. For example, a GL classification model might need 90% confidence before the code auto-posts the classification. Anything below that threshold goes to a reviewer. The threshold is set based on the cost of errors in that specific step.

Are LLMs safe to use for ASC 606 revenue recognition?

LLMs are useful for reading source contracts and extracting the inputs to an ASC 606 calculation (performance obligations, SSP, contract terms). The calculation itself should run as deterministic code. Using a model to perform the revenue allocation or post the journal entries introduces inconsistency that creates restatement risk.

What is the difference between an AI finance workflow and a chatbot?

A chatbot responds to questions. An AI finance workflow executes a defined sequence of steps, some of which may include an AI model for a specific judgment task, and writes its outputs back to source systems. A chatbot does not change the GL; a workflow does, which is why workflows require much stricter design.

How do finance teams start using LLMs without taking on too much risk?

Start with read-only classification tasks, GL line classification or invoice field extraction, where errors are caught before anything is written to a system. Build in the confidence threshold and human review queue from day one. Only extend to write-back steps after the model's accuracy is validated on your own data.