Claude connected to NetSuite or your ERP through MCP: what a finance team can build

Once Claude is connected to an ERP such as NetSuite through an MCP connection, a finance team can prepare its recurring reports from the live general ledger instead of exports: the month-end pack, a cash and debtors view, variance commentary against budget, and the board finance page. Each is a skill the team writes in its own words, reads real data through a connection with permissions set per person, and is checked by a named person before it goes anywhere. This article sets out what to build first, what to check about the connection before trusting a number, and when a developer is still needed.

What an MCP connection to an ERP actually allows

An MCP connection is a small piece of software that sits between Claude and one system, and describes exactly what Claude may do there. For an ERP that means three kinds of action, best kept apart from the first day.

Read. Search transactions, pull a trial balance for an entity and a period, list open invoices, read a budget. This is where almost all the value is, and the only kind of action most finance teams should allow to begin with.

Prepare. Take what was read and turn it into the thing a person was going to write anyway: the commentary, the pack, the email to the debtor. The output lands in a document or a draft, not in the ERP.

Write, gated. Create a draft bill, post a journal, update a customer record. A connection can be built to allow these, and when it is, each one is held as an approval that a named person accepts or rejects. Nobody at Sentry AI recommends an ungated write into a ledger, and the connections we build do not have one. MCP explained covers how a connection is built and who controls it.

The point of separating the three is that the permission is set on the connection, not inside the skill. A skill written by the management accountant cannot do anything the connection was not given, however it is worded.

The first four things to build

Start with the reports the team already prepares every month: the baseline exists and the person who checks the output already knows what good looks like.

The month-end pack

What it reads, in plain words: the general ledger balances for the entity and the period, the same period last year, the budget for the period, and the subledger totals for debtors and creditors so the pack can say whether they tie. What the skill does: lays the figures out in the pack's existing format, flags any account that moved more than the team's own threshold, and writes a first draft of the notes. The human check: the financial controller reads every note against the ledger before the pack leaves finance. The skill states which entity and period it read at the top of the pack, every time.

Cash and debtors

What it reads: bank balances as the ERP holds them, open customer invoices by due date, the last payment and the last contact on each, and open supplier bills by due date. What the skill does: a one-page view of cash today, what is due in and out over the next few weeks, and a list of the debtors to chase, each with a draft email in the firm's own tone. The human check: the person who owns credit control reads each draft, changes what needs changing, and sends it.

Variance commentary

What it reads: actuals against budget by account or by cost centre, for the month and the year to date, and the notes the team wrote last month. What the skill does: writes the commentary in the same shape as last month's, names the lines that moved, and says where it could not find a cause. The human check: the budget holder for each cost centre confirms or corrects the cause. A skill that says it could not find why travel was over is doing its job; one that invents a reason is not.

The board finance page

What it reads: the month-end pack above, the cash view above, and the three or four figures the board has asked for every month. What the skill does: one page in the board's format, with the same numbers the pack already carries, so the board page and the pack can never disagree. The human check: the CFO or the owner signs it off. Build the pack first; the page is its summary.

Each of the four is written as a skill: a short set of instructions in plain words, with the format, the rules and an example. If you want to see how one is written from a process the team already has, the free process-to-skill skill walks Claude through writing it with you.

Dashboards versus reports

A Claude skill is enough when the output is a document a person reads and acts on, when it is prepared on a cadence (daily, weekly, monthly) rather than watched all day, and when the value is in the words around the numbers: the commentary, the exceptions, the draft email. The four reports above are all of that kind.

A BI tool still wins when many people watch the same live figures at once, when the view has to refresh without a person asking, or when the question is mostly a chart with no words. Connecting Claude to the ERP does not replace that layer; it means the person who used to export from it to write the commentary no longer has to.

Five things to check about the connection before trusting a number

A connection that is set up but never checked produces reports that look right and read from the wrong place. Before a figure from Claude goes into a pack, check these five and write the answers down.

1. Permissions per person. Does the connection carry each person's own ERP role and entity restrictions, or one shared service login? A shared login means the accounts payable clerk can read what only the controller should.
2. Which entity and which period. A multi-entity ERP will happily return the consolidated figure when the subsidiary was wanted. The skill should state the entity and period it read, and the person checking should look for that line first.
3. Posted or unposted. Most ERPs hold draft and unposted transactions alongside posted ones. A cash view that includes unposted bills is a different number from one that does not. Decide which the report wants and make the skill say which it read.
4. Read only by default, and who approves a write. List every action the connection allows. If any of them changes the ledger, name the person who approves it, and check that the approval step actually exists rather than being a note in a document.
5. What it costs in usage. A report that reads a large ledger uses more of a seat's allowance than a short question. Read the usage per seat after the first month, before deciding whether the finance team needs premium seats. The usage data we read for this is a short allowlist: tokens, model, cost, which tool and which skill. We never capture prompt text, Claude's answers or the arguments a tool was called with.

If a connection already exists and nobody has checked these five, that is the work the Claude usage and cost review does, in writing, before anything else is built on it. How accountability for what Claude does is set up more widely is on AI governance.

What your team can change themselves, and what still needs a developer

Your team can change a skill. The format of the pack, the threshold for flagging a movement, the tone of the debtor email, the order of the board page, the rule that says "say when you cannot find a cause". All of that is plain words in the skill, and the management accountant who owns the report should be the one editing it, testing a change on last month's figures before using it on this month's.

Your administrator changes the connection's permissions. Which people may use the connection, and which actions it allows. That is a setting, not code, and it sits with whoever administers your Claude organisation, usually alongside the ERP administrator.

A developer builds a new connection or a new action. If the ERP has no connection, or the one you have cannot read the budget table, or you want a gated write that does not exist yet, that is code. We build those in your own repository so the connection is yours and outlives us.

How we run this with a team

Sentry AI runs this the same way whether the connection exists already or not. Before anything is built, each report is timed as the team prepares it today and the number is written down with its frequency: hours a month for the pack, hours a week for the debtor chase. That is the baseline every later measurement is read against.

Then a day in your office. Each person on the finance team takes one of the four reports, builds the skill on your live connection with us beside them, runs it on a closed period where the right answer is known, and leaves able to change it without a developer. The training day is judged on the timed baseline, measured again a week later, not on how the day felt.

Where a connection to the ERP already exists, we start with the five checks above as a written review, so the day is spent building on a set-up the team trusts. Where none exists, the day comes first and the connection is built for the report the team wants most.

If your team is already on Claude and already connected, start with the usage and cost review. If you are on Claude and not yet connected to anything, book a Claude training day and bring the month-end pack.