Asking the ERP in ChatGPT is not placing an order, invoice, or payment

Asking the ERP in ChatGPT is not the same as letting an agent place an order, invoice, or payment. These are three different levels of artificial intelligence over company data: query, prepare, and act. The first two already handle routine work safely; the third only fits low-cost, well-bounded tasks and, even then, under supervision.

Why “having AI” in the ERP does not answer the question

At Web2View, the request usually arrives wrapped in a single sentence: connect ChatGPT to the ERP so the team can ask and, as a bonus, post. That sentence mixes three permissions. Between an impressive demo and a reliable operation on live accounting data lies a chasm, and it is in that chasm that orders, invoices, and payments get lost.

A useful map separates how AI actually works on business data:

1. It answers. Reads live data and tells who owes, what is in stock, how revenue stands. It does not write. It is the quick answer instead of the report that waited for the next meeting.
2. It prepares. Drafts a collection reminder, assembles VAT-calculation numbers, or proposes a purchase order. A person approves with one click. The routine disappears; the responsibility stays with people.
3. It acts alone. Executes without that approval. Technically it is already possible. The sensible approach, for now, is a low-risk, well-bounded task.

Today, AI over the ERP safely supports the first two levels. The third only makes sense for low-risk tasks under supervision. The sensible strategy is to climb step by step, not jump to the third.

Level 1: the question that reads live data

A generic chat talks about almost anything. It does not know stock, sales, or cash. Without a link to the system, someone exports, pastes the number, and waits for context. AI in the ERP reads sales, stock, and financials in real time and answers with what is in the database, without that paste.

The same question shows the difference. “How much did we sell yesterday?” The generic chat does not have the data: it asks for the value or an exported report. AI connected to the sales module returns revenue, order count, and comparison with the weekly average. “What to buy urgently?” The generic chat suggests a generic purchasing process. AI in the ERP lists items below minimum, with real balances and consumption.

This is the safest level today. For most companies, it is also the first real contact with AI over their own data. An assistant such as ChatGPT or Claude, connected to the ERP, starts answering what used to wait for the meeting: how cash flow compares with the prior quarter; how much the top ten customers owe; what has been idle for more than a year and at what value; what expires in fifteen days; margin by category; who bought less this year; what changed during the week, summarized for Monday.

The generic chat does not become obsolete. It helps draft emails, explain a tax concept, and brainstorm marketing ideas—tasks without live internal data. AI in the ERP comes in when the decision needs up-to-date numbers: stock-outs, average ticket, overdue invoices, day’s production orders.

The shortcut that seems harmless is the one that leaks the most. Sending customer or financial exports to a public chat exposes the data. Contextual queries keep information inside the management environment, with access profiles and operational history. The gain is not chatting with the machine. It is an immediate answer with reliable data, instead of opening five screens or requesting a new spreadsheet from the analyst—today’s average ticket, stock-out item, overdue service order.

This reading depends on connection, not on a model that knows ERP because it read the manual. The MCP standard connects AI assistants to business systems. Without live data, what you have is a documentation chatbot: it tells where the button is, not who owes.

There is a hidden cost in the old way. Separate chat subscriptions, separate ERP, and hours exporting data for each question form a high hidden cost. You do not need to abandon the generic chat for everything. What makes sense is to centralize management questions where the data already lives.

When sales, stock, and invoices are not securely accessible to the assistant, the limit is not the model. It is the integration with what the company already uses. It is the type of ordering, management, and portal system linked to the ERP that we describe in online systems.

Level 2: the draft that only counts after approval

The second level adds writing. The person remains the final authority. AI drafts the reminder from the actual receivable, assembles the VAT-calculation numbers, and proposes the purchase based on stock. Someone reviews and confirms. Only then does the action run through the ERP’s official interface, with the validations the system already applies.

The principle has a name: human-in-the-loop. It is the most sensible way today to let AI write to the ledger. The routine of assembling text and gathering numbers disappears. The responsibility to execute does not change hands.

An overdue invoice shows the boundary without jargon.

1. At level 1, the question is who owes and how much. The answer comes from live financials. Nothing is sent.
2. At level 2, AI drafts the reminder with the real amount and leaves the text ready. A person reads and approves. The collection goes through the official channel.
3. At level 3, the agent would send and record without that approval. The question stops being whether the text is good and becomes who answers if the amount, the customer, or the channel is wrong.

Purchasing follows the same pattern. AI lists what expires in fifteen days and proposes the order. The person confirms. The ERP validates.

Chatbot and agent separate here. A well-designed chatbot queries a base—order status in the ERP, purchasing policy, supplier manual—and answers in natural language. It changes nothing. When it starts changing, it has become something else and needs the controls of something else. Posting, changing, or sending requires restricted write permission and logging of each action.

Two criteria keep agents out where a rule suffices. If the decision fits a “if this, then that” table that changes only a few times a year, it stays as a fixed rule, even when the document is read by AI. If it depends on context, such as accepting or rejecting a different deadline from the contract, the person decides and the agent only prepares the case.

This arrangement—result assembled beforehand, human review at the moment of posting—is what we use when AI enters repetitive processes. The design is described in AI in operations.

Level 3: act alone only when the error is cheap

An AI agent is not a chatbot with a stronger verb. It combines a language model with tools that read and write in systems. It interprets the input, chooses the next step, and executes within defined limits. It is the most flexible of the three approaches and the only one whose result can vary for the same input. This changes the test: one successful execution does not prove the next.

An agent without approval already makes sense when the task is well bounded and the error is cheap: sentinel and alert, classification and reconciliation by clear rules, report preparation. Unsupervised accounting entries remain a bad idea. Not because the technology prevents it. For three reasons:

- hallucination: the model can be confidently wrong;
- responsibility: who signs a defective invoice;
- audit: you must prove who did what and why.

The cost of the error is the criterion the demo hides. Reporting the wrong delivery status creates rework. Issuing an order with the wrong price creates loss. The more expensive the error, the more the task requires predictability or human review before execution. Orders, invoices, and payments change the system, and the error is not cheap. They do not fit as loose actions of the third level. They fit as drafts of the second—or as deterministic routines, which is another tool.

What is not an agent: RPA and integration

RPA, robotic process automation, is software that repeats, on screen or by integration, the sequence of clicks and keystrokes a person would make, in a fixed script. It does not interpret. If the screen layout, file format, or rule changes, the robot stops or errs until someone adjusts the script. The same input always produces the same result, which eases auditing and keeps execution cost low. Posting a pre-checked inbound invoice to the ERP is RPA or integration work, not an agent deciding the invoice.

The path also matters. Screen RPA is the resource when the system has no integration. When an API exists, direct integration is usually more stable than the robot. If the agent participates, it uses these same APIs as tools, with the ERP’s validation along the way.

In purchasing and logistics, almost every process mixes the three. The design that works uses each in the segment where it is cheapest and most reliable: chatbot to answer, rule or RPA for what is deterministic, agent to interpret free text or variable documents, person for what is costly to get wrong.

The input tells who interprets. Fixed-layout files, ERP screens, and standard spreadsheets fit RPA or direct integration. PDF quotes in a different format for each supplier, freely written emails, and photos of delivery receipts call for interpretation. AI enters to read. That does not authorize writing alone.

What to ask before turning on write access

Anyone announcing AI in the ERP must answer to operations. Three questions separate live data from theater:

1. Does the AI see our live data or is it a chatbot trained on documentation? One thing is pointing to the button. Another is saying who owes us.
2. Is there an audit trail for every query and every action?
3. What happens on error—who sees it?

The task completes the filter. Is the input structured or variable? Is the decision rule written and stable, or does it depend on context? Does the task only query, or does it post, change, and send? How much does an error, rework, or loss cost? Is there an API, or only the screen?

If the answer is that it changes orders, invoices, or payments, human approval stays in the flow, write access stays restricted, and every action stays logged. Querying does not require that apparatus. Writing does.

The choice between chatbot, agent, and RPA depends less on technology and more on three traits: whether the input arrives in a predictable format, whether the decision rule is written, and whether the result needs to alter any system.

Climbing levels without mixing the three

The first step is a question about live data, inside the management environment, without pasting spreadsheets into a public chat. The second is a draft—reminder, calculation numbers, purchase proposal—approved by a person and posted through the ERP’s official interface. The third is reserved for alerts, classification by clear rules, and reports: low-cost, well-bounded tasks under supervision.

Asking speeds up management. Preparing removes routine without removing responsibility. Acting alone only enters when the error is cheap and the task boundary is written. Orders, invoices, and payments are not the third step. They are the reason the second step exists.