The question we get most often from finance leads evaluating Claude for accounting is some version of: "Does it work with our stack?" It sounds like a yes/no question about a compatibility matrix. It isn't. It's four questions wearing one coat:
- Can Claude read the data out of the system?
- Can Claude write back into it?
- Who approves the write, and where is that recorded?
- What makes it happen on the 3rd of the month without someone remembering to ask?
A tool can pass question one and fail the other three, and you'll still see it listed as "Claude compatible." That's the gap this guide is about.
The four tiers of "works with Claude"
Every system in a finance stack lands in one of four tiers. Sort yours before you evaluate anything.
Tier 1: Native MCP connector. MCP (Model Context Protocol) is the open standard Claude uses to talk to external systems. When a vendor ships an MCP server, Claude can call its functions directly: list invoices, fetch a trial balance, create a bill. You connect it once and it's available in chat. This is the best case and the list of vendors offering it grows monthly, so check the current connector directory rather than trusting any blog post's snapshot, including this one.
Tier 2: API, no connector. The system has a documented REST API but nobody has wrapped it in MCP. This works, but it's an engineering task, not a settings toggle. Someone writes an MCP server that maps the API's endpoints to tools Claude can call, handles auth, and scopes permissions. A day or two for a simple read-only wrapper, considerably more for anything that writes.
Tier 3: File-based. No usable API, but the system exports. Bank statements as CSV or CAMT.053, invoices as PDF, subledger detail as Excel, payroll journals as a fixed-width text file. This tier is underrated. Claude parses these well, and with Cowork you can point it at a folder of 300 supplier invoices instead of pasting them one at a time. Most of the month-end work that finance teams assume needs an integration project is actually Tier 3 work in disguise.
Tier 4: Screen-only. Legacy on-prem systems, some local statutory tools, anything where the only interface is a Windows form. RPA vendors will tell you this is solvable. In practice it's brittle, breaks on UI updates, and you should plan around it: either export from the underlying database on a schedule, or accept that this system stays manual and design the workflow so it isn't on the critical path.
Sorting your stack into these four tiers takes about twenty minutes and tells you more than any vendor demo.
What a "Claude skill" actually is (and isn't)
The word "skill" gets used loosely. Concretely, a skill or plugin is packaged domain procedure: instructions, reference material, and often executable scripts that Claude loads when the task calls for it. It's the difference between an accountant who knows GAAP in the abstract and one who has your close checklist, your chart of accounts mapping, and last quarter's audit findings on the desk.
Four things get confused with each other. Keep them separate when you're evaluating:
- Connectors are access. They determine what Claude can see and touch.
- Skills/plugins are procedure. They determine whether Claude does the task the way your controller would.
- Artifacts are output. Formatted PDFs, Excel models, an interactive variance dashboard generated on request.
- Scheduled jobs are trigger. Any recurring instruction, run without a human initiating it.
A stack that's strong on connectors and empty on skills gives you an intern with badge access to everything. Our Estonian statutory filing plugins are the clearest example of the difference: the connector gets Claude the trial balance, the plugin knows the specific form, the local mapping rules, and the filing sequence. Same model, same data, entirely different output quality.
This is also why capability gaps don't always mean roadmap waits. ASC 606 multi-element arrangements or 1099 e-filing don't need to be core product features to be delivered; they're packaged as plugins. The extensibility surface is where the domain depth lives.
Category by category: what to expect
ERP and general ledger (Business Central, NetSuite, Xero, QuickBooks). As of this writing all four are Tier 1 — each vendor ships a first-party MCP server. That is a recent change, and it is worth knowing that Tier 1 covers a wide range of effort:
- QuickBooks Online is the easiest. Intuit runs a hosted MCP server, and there's an official QuickBooks connector in Claude's directory: sign in with the Intuit account that owns the subscription, authorize, done. No developer app, no API keys, no server to run.
- Xero publishes its MCP server as open source, but you run it yourself and register an OAuth app to get credentials. An afternoon for someone technical, not a settings toggle.
- NetSuite exposes MCP through Oracle's AI Connector Service — records, saved searches, SuiteQL, reports — installed and configured as a SuiteApp by whoever administers your account.
- Business Central has a Microsoft-supplied MCP server, but it is version-gated. If you are on an older on-prem or unupgraded environment, check your version before assuming it is available.
So the practical question is no longer "is there a connector," it's "who installs it and how long does that take." Reads are straightforward once it's in place: trial balance, GL detail, dimension values, open AP and AR. Writes are where the design work lives, which is the next section — and note that a connector granting write access is exactly the moment the governance question stops being theoretical.
Business Central and NetSuite are where we've concentrated, because that's where our ICP sits: 50 to 200 employee companies with 3 to 8 person finance teams, usually multi-entity, usually with a close that takes longer than anyone admits.
Banking. Statement import is Tier 3 and works well: drop the CAMT.053 or CSV into Claude, get matched transactions back. Direct bank aggregation is different. We don't do Plaid, and we say so in evaluations rather than fudging it. If your reconciliation depends on live aggregated feeds rather than statement files, ask specifically about that, because "bank reconciliation: yes" hides a lot.
AP and bill pay. Strong category for Claude. Invoice extraction from PDF is reliable, three-way matching against PO and receipt is a procedure you can encode, and duplicate detection across a supplier's invoice numbering quirks is exactly the kind of fuzzy-but-rule-bounded work models handle well. If your bill-pay platform has an MCP connector, Claude can read approved bills from it and post the accruals through your ledger without an integration project on either side.
Expense and payroll. Usually Tier 3, and that's fine. Payroll journals arrive as a file once or twice a month; the work is mapping to accounts and dimensions, not real-time sync. Encode the mapping in a skill and the recurring instruction handles it.
Statutory and tax filing. Highly jurisdiction-specific, which is precisely why plugins beat core features here. A generic "tax module" is worse than a plugin that knows one country's forms properly.
Close management and BI. Reporting is the easiest win and the one people ask for last. Every report we produce is dual-channel: the platform generates it, and Claude generates it on demand as an artifact. "Give me the entity-level EBITDA bridge versus budget, last three months, as a PDF for the board pack" should not require a BI ticket.
Reads are easy. Writes are the whole game.
Any competent engineer can give a model read access to your ERP in an afternoon. That demo always looks good. The hard part starts when the model needs to post something.
The design question is not "can the AI write to the ledger." It's "through what path, with what validation, and who signs." Our answer, and the thing we'd tell you to demand of any vendor: agents post to the GL through the same workflow gateway humans use. Reads are role-scoped. Every write runs validation, then a risk lane that determines whether it auto-posts or queues for approval, then lands in an audit trail that records what was proposed, by which agent, on what evidence, and who approved it. The AI cannot free-hand a journal entry, because there is no code path that lets it bypass the gateway.
This matters for two reasons beyond the obvious control one. First, your auditor's question is "show me the approval chain," not "which model did you use," and a gateway architecture answers that question in the same format it always had. Second, it's client-agnostic. MCP is a standard, not a Claude feature. If half your organisation runs Microsoft CoPilot rather than Claude, the same governed gateway serves both, because CoPilot Studio speaks MCP too. You're not betting the control environment on one assistant vendor.
How to test your stack in one afternoon
You don't need a procurement process to find out where you stand.
- List your systems and tier them. Four columns, twenty minutes. Note which ones have a documented API.
- Test reads first. Start with your ledger, since all four major ones now ship a connector. Get it connected read-only and ask Claude something you actually care about: "reconcile these two account balances and tell me what's driving the gap." Judge the answer the way you'd judge a new hire's first attempt.
- Test Tier 3 with volume, not samples. One PDF invoice proves nothing. Point Cowork at a folder of a month's worth and check the error rate on the ones with unusual formats, foreign currency, or credit notes.
- Ask the write question explicitly. Not "can it post journals" but "show me the audit trail of a posted journal, including what was proposed and who approved it." If the answer is a screenshot of a chat log, keep looking.
- Ask what happens on the 3rd of the month. If every task needs someone to type a prompt, you've bought a faster calculator, not an automated process. Recurring instructions need to be scheduled, and their output needs to arrive somewhere a human is already looking.
Where Artifi fits
We build the layer that makes Tier 1 real for finance: a ledger and workflow engine that Claude operates through MCP, with the governance path described above, plus the domain plugins that turn "Claude has access" into "Claude does the close." Reconciliation, bills, consolidation, statutory reporting, multi-jurisdiction tax, investor reporting.
We're honest about what isn't there: no Plaid, no cash-basis mode, no inventory. If those are load-bearing for you, we'll tell you in the first call rather than the fourth.
Pilots run at €500/month for three to six months, which is deliberately priced to be a decision an individual finance lead can make. If you want to know where your specific stack lands, send us the four-column list from step one.