AI ERP for small business: a buyer's guide

What an AI ERP for small business should mean

An AI ERP for small business is an ERP whose assistant answers from your own records and help content, sees only what the user may see, prepares work for human approval instead of changing the books on its own, and logs every action. It matters because an assistant with loose access to a ledger can leak payroll data or post a wrong entry faster than any person.

Much ERP software with AI now shows a chat box, so a chat box alone tells you nothing. What separates a useful AI ERP from a risky one is the plumbing behind it: where answers come from, whose permissions apply, what the AI is allowed to change, and what record is left. This buyer's guide turns those questions into a checklist you can score during a demonstration.

The guide is written for owners and finance leads of small and mid-sized trading, service and manufacturing companies choosing a cloud ERP with AI. For the accounting side of AI in general, see our guide on AI in accounting; for choosing an ERP in Saudi Arabia specifically, see our guide on that topic.

Bolted-on chat versus AI built into the ERP

A bolted-on assistant is a general chat model placed beside the ERP. It knows nothing about your company unless someone pastes data into it, and anything pasted leaves the ERP's permission model. It can still be useful for drafting an email or explaining a standard, but it cannot answer what your overdue receivables are without someone exporting them first.

An ERP system with AI built in calls the ERP's own functions to answer. When a user asks for sales by branch this week, the assistant should run the same report the user could run on screen, under the same permissions, and return the figure with a note of where it came from. The model interprets the question and phrases the answer; the ERP produces the number.

The test in a demonstration is simple. Ask a question whose answer you already know from your own data, such as last month's purchases, then ask the same question logged in as a user who is not allowed to see purchases. The first answer must match the report exactly; the second must be refused.

Grounded answers: the first thing to test

A grounded answer is one the assistant can trace to a source: a report, a document, a help page or a policy. Ungrounded answers are where language models invent things, such as a menu path that does not exist or a VAT rule that changed last year.

Ask the vendor what happens when the assistant cannot find a source. The right answer is that it says so, or shows search results, rather than improvising. Anthropic, for example, documents a citations feature for Claude that returns the exact passages supporting a claim, and states that those citations are guaranteed to point to the documents supplied, as of September 2026. A vendor using any model can build the same discipline: no source, no answer.

• Every factual answer shows its source, and the source opens.
• Figures match the equivalent on-screen report to the cent.
• Questions outside the assistant's scope get a clear refusal or a search result, not a guess.
• Answers about tax or accounting rules cite a current source, because every model has a knowledge cutoff.

Permission scoping: the AI must see what the user sees

The most common design flaw is an assistant that runs with a powerful service account. Then a warehouse clerk can ask the assistant for salaries, and the assistant can answer. The rule to demand is that every AI query runs as the signed-in user, through the same permission checks, branch restrictions and company boundaries as the screens.

For an ERP with several branches or companies, test the boundaries explicitly. A user limited to one branch should get that branch's figures only, and an accountant serving several client companies should never see one client's data while working in another. For outside AI tools that connect to the ERP, ask whether access uses a personal token tied to one user, what that token can do, and how an administrator revokes it.

Approval workflows: Read, Draft and Auto

A sound AI ERP separates three modes. In Read mode the AI answers and flags but changes nothing. In Draft mode it prepares a document, such as a journal, a bill or a purchase order, that waits for a person to approve it. In Auto mode it acts alone, which should be reserved for low-risk work such as reminders, reports and flags. Ask the vendor which mode each AI feature uses and whether you can change it.

Worked example. At month-end the AI drafts an electricity accrual from the last three bills in the ledger: EUR 1,180, EUR 1,240 and EUR 1,330, which total EUR 3,750 and average EUR 1,250. The draft reads Dr Utilities expense 1,250 / Cr Accrued expenses 1,250, with a reversal on the first day of next month.

The reviewer checks four things. The three bills exist and the average is right: 3,750 divided by 3 is 1,250. No September bill is already posted, so the accrual is not a duplicate. The accounts are correct. But the supplier's letter announcing a 10% tariff rise from 1 September was never in the ledger, so the AI could not know it. The reviewer rejects the amount and posts Dr Utilities expense 1,375 / Cr Accrued expenses 1,375, because 1,250 x 110% = 1,375, and notes the reason. That is the approval step doing its job: the AI saved the arithmetic and the lookup, and the person supplied the knowledge the system did not hold.

Audit trail of AI actions

When an auditor asks who prepared an entry, the answer cannot be the AI. The ERP should record that the AI drafted it, from which inputs, with which model version, and which named person approved or rejected it and when. Without that record, AI-prepared entries look like unexplained postings, which is exactly what journal-entry testing looks for.

Ask to see the log during the demonstration, not a slide about it. It should be searchable by user, date and action, and it should survive for at least as long as your accounting records must be kept.

• The question or trigger that started the AI action.
• The records and documents the AI read.
• The draft it produced, and any changes the reviewer made.
• The approver, the decision, the reason and the time.
• Refusals and permission denials, which show the boundaries working.

Open standards: MCP and your own AI assistant

Your staff may already use a general assistant such as Claude, and they will want it to reach the ERP. The Model Context Protocol (MCP) is an open standard, introduced by Anthropic in November 2024, for connecting AI assistants to the systems where data lives. An ERP that offers an MCP server lets any compatible client use a defined set of ERP tools instead of screen-scraping or pasted exports.

As of September 2026, Anthropic's help centre states that custom connectors using remote MCP are available in Claude, including Claude Desktop, on Free, Pro, Max, Team and Enterprise plans, with Free users limited to one custom connector, and that Claude connects to the remote server from Anthropic's cloud rather than from the user's device. It also warns to connect only to servers from organisations you trust, notes that a malicious server may carry hidden instructions, and advises reviewing the permission scopes a server requests when you connect. Those are the right questions to ask about any ERP's MCP server.

Ask which tools the MCP server exposes, which of them can write, how tokens are issued and revoked, and whether tool calls appear in the audit log. A read-only server with a short list of permission-checked tools is a sound starting point; a server that can post journals should require the same approval as a person would.

Data protection and data residency

An AI feature adds at least one new party to your data flows: the model provider. Ask where the ERP data is hosted, where AI requests are processed, and which sub-processors are involved. For EU and UK businesses, in general terms, GDPR requires a processor contract under Article 28 and a valid transfer mechanism under Chapter V for data sent outside the EEA; Canadian businesses have their own privacy laws to check. This is not legal advice.

Ask whether your data is used to train models. Model providers publish their own terms: as of September 2026, Anthropic states that by default it does not use inputs or outputs from its commercial products, including the API, for training. Your ERP vendor should be able to say which provider it uses, under which terms, and what it keeps: prompts, answers and logs, and for how long.

If the AI will ever score customers' creditworthiness, note that the EU AI Act (Regulation (EU) 2024/1689) lists creditworthiness assessment of natural persons among the high-risk uses in Annex III. Most small-business ERP features, such as help answers and drafting bills, sit far from that line, but a vendor should know where its features fall.

AI ERP for manufacturing and trading companies

In manufacturing, the useful AI jobs sit where data is plentiful and explanations are slow: explaining production variances, summarising maintenance history before a repair-or-replace decision, flagging bills of materials whose standard costs look stale, and drafting purchase suggestions from reorder levels. The same rules apply: figures from the ERP, drafts for approval, a log.

Take a material usage variance. The standard is 2 kg of resin per unit, and 500 units were made, so standard usage is 1,000 kg at EUR 3 per kg, or EUR 3,000. Actual usage was 1,080 kg. The usage variance is 80 kg x EUR 3 = EUR 240 adverse. A good AI ERP for manufacturing computes that from the work orders and drafts the commentary, naming the work orders with the largest overrun; the production manager confirms the cause, such as a mixer calibration fault, before the commentary goes into the management pack.

For trading companies the equivalents are margin explanations by product and branch, slow-moving stock lists and supplier price-change alerts. In both cases, ask the vendor to run the feature on a copy of your own data during the trial.

Questions to ask an ERP vendor about AI

Send these questions before the demonstration and ask for written answers. Vague answers to the first four are the most telling.

• Which AI features are live today, and which are on the roadmap? Show me only live ones.
• Does every AI query run as the signed-in user, with the same permissions and branch limits as the screens?
• Can the AI change any record without a person approving it? Which ones?
• Where does each answer come from, and what happens when there is no source?
• Which model provider do you use, where is AI processing done, and is my data used for training?
• Is every AI action logged with inputs, output, model version and approver, and can I export the log?
• Do you offer an MCP server or another open connection, and what can it read and write?
• Can I switch AI features off per user, per role or entirely?

Red flags and a scoring checklist

Treat these as red flags: accuracy percentages with no method or source; an assistant that answers every question, including ones it cannot know; AI features that post to the ledger with no approval step; demonstrations only on the vendor's sample data; one service account behind all AI queries; and no written answer on training use or data location. Also be wary of AI features described only in the future tense but priced as if live.

Score each vendor with the weights below, which total 100. Give the full weight when the feature is shown working on your data, half when it is described in writing but not shown, and zero otherwise. A score under 60 suggests the AI is a demonstration feature rather than something to run a ledger on.

• Grounded answers with sources and a no-source fallback: 15
• AI runs under the user's own permissions and branch limits: 15
• Approval step for every AI change to records: 15
• Data terms in writing: processor contract, no training by default, retention, location: 15
• Numbers computed by the ERP, not by the model: 10
• Audit log of AI actions, searchable and exportable: 10
• Open connection standard such as MCP, with scoped tokens: 10
• Trial on your own data, and AI features you can switch off: 10

How Skyline Nexus ERP approaches AI

Skyline Nexus ERP is a cloud ERP whose assistant sits on every screen and answers how-do-I questions from the ERP's own help library in the language the user writes in. Each answer is verified before it is shown: the help page it cites must exist and must be one of the passages retrieved for that question, otherwise the user gets plain search results. Live figures come from eight whitelisted reports, such as sales, purchases and expenses for a period, customer and supplier dues, stock alerts and top products, under the same permissions and permitted locations as the report screens; the model only chooses which report was asked for and never writes database queries.

For outside assistants, Skyline Nexus ERP offers an MCP server that Claude Desktop and other MCP clients connect to with a personal token issued by an administrator. It exposes help search, help pages, the eight live figures and support-ticket creation, scoped to the token user's own business, and nothing else is writable. Roles and permissions, the approval threshold for journals and the Audit Trail with old and new values apply across the ledger.

AI drafting for approval, covering journals, bills, invoice capture and bank matches, together with ledger reads through MCP and scheduled automations, is being rolled out on the Skyline Nexus ERP roadmap. Tell us which of these matter to you and we will confirm your go-live date, and score us with the checklist above.