The question we get most often from finance leads evaluating Claude is "which model should we use?" It is usually asked once, expecting one answer, to be set and forgotten.
That framing costs money in two directions. Teams that standardize on the largest model pay premium rates to classify 4,000 supplier invoices. Teams that standardize on the cheapest model get a plausible-sounding intercompany elimination that is wrong in a way nobody catches until the auditor does.
A 3–8 person finance team running on Business Central or NetSuite does not have one workload called "financial analysis." It has about a dozen distinct jobs with different failure costs. Model choice should follow that decomposition.
First, split "financial analysis" into jobs
Before picking a model, write down what you are actually asking for. In a typical month-end for a 50–200 employee company, the work sorts into six categories:
- Extraction. Pull line items, dates, VAT codes, and currency off 300 PDFs and a bank statement export.
- Matching and reconciliation. Tie 1,200 bank lines to open AR/AP, flag the 40 that do not tie.
- Deterministic computation. Sum, FX-translate, accrue, eliminate, roll forward.
- Mapping and judgment. Does this new supplier's "platform enablement fee" belong in COGS or S&M? Is this contract modification a separate performance obligation?
- Narrative and explanation. Why did gross margin move 180bps versus forecast, and which three drivers explain most of it.
- Structure and design. Build the consolidation logic for a newly acquired entity, define the reconciliation rules, write the recurring instruction that runs every month from now on.
Categories 1 and 2 are volume work. Category 3 should never touch a language model at all. Categories 4 and 6 are where reasoning depth pays for itself. Category 5 sits in the middle.
The tiers, and what each one is actually for
Model names change every few quarters. The tiering logic has been stable for two years, so learn the tiers rather than memorizing version numbers.
Opus-tier (Claude Opus 5). The deepest reasoning available at a price most finance teams will actually run daily, and the slowest of the three. Worth it when the output is a decision or a structure rather than a transcription. Concretely: designing the elimination logic for a three-entity group with intercompany loans in two currencies; interpreting a lease modification against IFRS 16; building the first version of a revenue recognition schedule for a contract type your team has not seen before; reviewing a consolidation that already balances but that you do not trust.
Above Opus sits Claude Fable 5, Anthropic's most capable widely released model. In finance work it earns its premium in one specific situation: a long, autonomous run where nobody is watching each step — a full close executed end to end, a multi-week migration of historical data, an agent working overnight against a specification. For a controller asking questions interactively, Opus 5 is the sensible ceiling.
The economics are simple. If a task takes a senior accountant three hours and the difference between the tiers is a few euros of inference, tier selection is not the variable that matters. Use Opus.
Sonnet-tier (Claude Sonnet 5). The default for finance operations. Fast enough for interactive work, strong enough for multi-step reasoning over structured data, cheap enough to run every day. This is what should handle month-end mechanics once the rules exist: running the reconciliation against defined match criteria, drafting variance commentary from actuals plus budget, generating the management pack, answering "show me every prepaid that expires before Q4."
Most teams find that once the judgment has been encoded once (by a human, or by Opus, and then reviewed), Sonnet executes it repeatedly at a fraction of the cost with no observable quality drop.
Haiku-tier (Claude Haiku 4.5). High volume, narrow task, well-defined output shape. Invoice field extraction, document classification, routing a mailbox, deduplicating a supplier list, first-pass anomaly flagging on transaction descriptions. When you are processing thousands of items and each item's failure mode is "a human corrects it in the review queue," you want throughput and low unit cost.
The pattern that works: Haiku extracts, Sonnet decides, a human approves, Opus is called in on the exceptions Sonnet flags as uncertain.
Never ask any Claude model to do the arithmetic
This is the single largest determinant of accuracy in a finance workflow, and it has nothing to do with model choice.
Language models generate tokens. They can produce a number that looks right and is not. The fix is not a bigger model. The fix is to let the model choose the method and let deterministic code produce the value: SQL against the ledger, a Python calculation, the ERP's own FX translation routine, the workflow engine's accrual logic.
In Artifi, this is architectural. Agents do not compute balances in their heads and write them down. They query the ledger, and every write goes through one governed gateway: validation, then risk-lane approval, then an audit trail entry. The AI cannot free-hand a journal entry, regardless of which model is behind it. When a controller asks "why is this number what it is," the answer is a query and a posting record, not a chat transcript.
Once you have that separation, model choice becomes a cost and latency question instead of a correctness gamble. That is the point.
Where thinking depth and context length actually change the answer
Two capabilities matter more than the tier label for finance work.
Thinking depth. On the current models this is no longer a switch you flip with a fixed token budget — Claude decides how much to think per request, and you steer it with an effort level from low through max. Depth pays when a task has interdependent steps and an error in step two poisons step six: consolidation, deferred tax, multi-element revenue allocation, any "walk the balance from opening to closing" exercise. It costs more tokens and more wall-clock time. Running variance commentary at maximum effort is waste; running a group consolidation with minority interests at the cheapest setting is false economy. Start at high for anything judgment-heavy and step down where your own testing shows quality holds — on Opus 5 the lower settings are stronger than most teams expect.
Long context matters when the analysis requires the whole picture at once. Twelve months of GL detail for a trend analysis, a 90-page credit agreement plus the covenant calculation, three years of statutory filings for a jurisdiction review. The practical constraint is rarely the window size. It is that dumping raw data into context is expensive and dilutes attention. Better pattern: retrieve the relevant slice with a query, then reason over that slice.
For folder-scale work, this is where Cowork earns its place. A finance lead can drop a quarter of supplier invoices in as files and have them parsed, mapped, and imported through the same governed gateway, without an integration project and without pasting anything into a chat box.
A routing table you can copy
| Workload | Tier | Notes |
|---|---|---|
| Invoice and receipt field extraction | Haiku | Review queue catches the residual |
| Bank statement parsing, transaction classification | Haiku | Rules first, model for the tail |
| Reconciliation against defined match rules | Sonnet | Exceptions escalate |
| Monthly variance analysis and commentary | Sonnet | Numbers come from the ledger, not the model |
| Management pack and board reporting | Sonnet | Output as an Artifact (PDF/Excel) |
| Statutory filing prep, known jurisdiction | Sonnet + plugin | Domain rules live in the plugin |
| New GL mapping decisions, ambiguous cost classification | Opus | Encode the decision, then Sonnet applies it |
| Multi-entity consolidation design | Opus, high effort | Then run monthly on Sonnet |
| Revenue recognition for a new contract type | Opus, high effort | Human sign-off, always |
| Audit review of a completed close | Opus | Adversarial read of your own work |
| Building a recurring workflow or scheduled job | Opus once | Executes on Sonnet thereafter |
The recurring shape: design once on the expensive model, execute forever on the cheap one.
Build a 20-item eval set from your own close
Public benchmarks will not tell you which model handles your chart of accounts, your entity structure, or your Estonian VAT edge cases. Build a small internal test set instead. It takes an afternoon and it settles arguments permanently.
Pick 20 tasks from the last two closes where you know the correct answer:
- Five extraction items, including one bad scan and one foreign-language invoice.
- Five classification items, including two that your team argued about.
- Five reconciliation cases, including one partial payment and one FX-rounding mismatch.
- Three analysis questions where the right answer requires reading a contract, not just the ledger.
- Two consolidation or elimination scenarios with a known correct output.
Run all three tiers. Record accuracy, cost, and latency per item. What usually comes out: Haiku is fine on 80% of items 1–10 and unacceptable on 16–20; Sonnet is close to Opus on 1–15 at a fraction of the cost; Opus separates clearly only on items 16–20 and on the two contested classifications. That result is your routing table, calibrated to your data.
Re-run it when a new model ships. It is a 30-minute regression test at that point, not a project.
Surface choice matters more than model choice
Teams over-index on model and under-index on where the work happens. In practice the surface determines whether the workflow gets used at all:
- Claude.ai chat and Cowork for anything ad hoc: drop a file, ask a question, import a folder.
- Artifacts when the deliverable is a formatted PDF, an Excel model, or an interactive dashboard that a board member will open without asking questions about it.
- Plugins when the requirement is packaged domain expertise, for example a statutory filing routine for a specific jurisdiction, versioned and testable.
- Scheduled jobs for anything recurring: the flux report on day three, the AR aging chase on Mondays, the covenant check monthly.
- MCP connectors to bring third-party systems in. If your billing platform or bill-pay tool has an MCP connector, Claude reads from it and posts through the governed gateway. That is usually days of configuration, not an integration project.
A Sonnet-powered scheduled job that runs on day two of close and lands in the controller's queue beats an Opus session that someone has to remember to start.
What this means for a 3–8 person finance team
Three practical conclusions.
Default to Sonnet for daily finance operations. Escalate to Opus for design, judgment, and review. Push volume extraction down to Haiku. Keep every number in deterministic code and every write behind an approval gateway.
Then stop re-litigating model choice each time a new version ships. Run your 20-item eval, update the routing table, move on. The durable asset is not the model. It is the encoded workflow, the mapping rules, the audit trail, and the review queues that let a five-person team close a multi-entity group in days instead of weeks.
That layer is what Artifi builds: the ledger, the connectors, the governed gateway, and the agents that operate inside it, so the model tier becomes a cost decision rather than a risk one.
If you are on Business Central or NetSuite with a small finance team and want to see how the routing works against your own close, that is the conversation to have.