Enterprise AI Integration: Connecting an LLM to Your ERP

One of your dealers emails at 08:40 in the morning: "Hi, send us 40 of those 20 mm pipes from last time, plus 5 boxes of the gasket set with our special discount, same address." For that sentence to become an order line in the ERP, somebody has to read the email, find the product code, check stock and key in the document by hand. At 60 emails a day this is not an "artificial intelligence" topic — it is a line item in your cost of operations.

At the other end of the same factory, the warehouse manager asks IT for a report to answer "how many short shipments did we make to which customer last month" and joins the queue. By the time the answer arrives three days later, the question has gone stale.

These two scenes show where large language models (LLMs — AI models that understand text written in human language and produce text in return) genuinely earn their place in enterprise software. It is not about machines making decisions; it is about closing the gap between the free text people write and the structured data systems expect. In this article we look at enterprise AI integration around three questions: what do we gain, what does it cost, and does our data leak out?

01. What exactly does an LLM do in enterprise software?

Why is an LLM a translation layer rather than a decision maker?

What an LLM does is, in essence, translation. It converts free text into structured data: the phrase "40 of the 20 mm pipe" becomes the object {stock_code: BR-020, quantity: 40}. It works in the other direction too: it turns a table coming out of the database into a three-sentence summary a sales manager can read.

Keeping this definition sharp matters, because most of the disappointment we see in the field starts here. Ask an LLM "how much credit term should I give this dealer" and it will produce a confident sentence — but that is language generation, not a financial decision. The decision must stay inside your risk rules.

How do you connect a non-deterministic component to a deterministic system?

Stock, accounting and shipping systems are deterministic: the same input always returns the same result, and it has to. An LLM is probabilistic; it may answer the same question in two different wordings. The safe way to join these two worlds is to draw a boundary between them.

The rule: the LLM proposes, the system validates, a human approves, and code performs the write. The LLM never issues an INSERT against the database directly. Its output first passes schema validation (does the stock code really exist, is the quantity positive, does the dealer have credit available); then it is presented on screen to a person as "approve / correct".

In practice this means: when the LLM is wrong, the outcome is a user fixing a field, not a broken system. That is the design that makes the risk bearable.

02. How the architecture is built: where does the LLM plug into your existing systems?

We build this structure not by standing up a new platform from scratch, but by adding a ring on top of the layers you already run. The .NET 8 REST API layer that already exists in Think WMS and the B2B Dealer Portal is the natural connection point.

What is RAG — are we training the model on our company data?

No. This is the misunderstanding we meet most often. RAG (Retrieval-Augmented Generation) means finding the right document for the question asked and having the model read it at that moment, instead of training the model on your data. Your product catalogue, ERP procedures and technical documents are split into small chunks, each chunk is turned into a numerical representation (an embedding) and stored in a vector database; when a question arrives, the most relevant chunks are pulled and given to the model as context. The result: when you update your price list you do not retrain the model, you simply replace the document — and you can verify which document an answer rests on, because it cites its source.

03. Which processes produce concrete benefit? Five scenarios

The figures below are estimates drawn from workload measurements in comparable processes and from the ranges observed in pilots; they vary with each company's data quality. Read them as starting targets to be measured during feasibility, not as firm commitments.

a) How does natural-language order entry work in the B2B Portal?

Today's process: The dealer sends a free-text order by email or WhatsApp. A customer representative translates the products into codes and keys them into the portal or the ERP by hand. Product-code mix-ups and missing lines are the two most common errors.

The process with an LLM: The dealer types the same sentence into the portal's search box, or the incoming email is parsed automatically. The system matches against the product catalogue using RAG and presents a ready-made basket: "Did you mean this?" The dealer confirms, and the order flows into the ERP through the adapter layer.

Measurable gain: Roughly halving the 4–6 minutes of manual entry per order; a marked drop in returns and corrections caused by wrong product codes. At 60 orders a day, that adds up to a significant share of one person's workload.

Where it plugs in: The B2B Dealer Portal (React interface + ERP-agnostic adapter layer) and the PWA sales-rep module.

b) Can meeting notes be summarised automatically in Think CRM?

Today's process: A field salesperson visits five dealers during the day and writes the notes up in the evening — or does not. When they do, what remains is a sentence like "met, positive"; the manager cannot read a pipeline from those notes.

The process with an LLM: The rep leaves the visit as a voice note on their phone or types a short free text. The system turns it into a structured record: products discussed, reason for objection, payment term requested, next action and a suggested date. With the salesperson's approval, the proposal is written to the CRM.

Measurable gain: 2–3 hours of reporting time per sales rep per week; more importantly, a marked rise in the share of visits actually recorded. An empty CRM produces an empty report.

Where it plugs in: Think CRM (B2B dealer and B2C end-user modules).

c) Is it possible to pull a Power BI report with a question in plain language?

Today's process: The general manager asks "in which product group did revenue fall in the Marmara region last quarter". The report request goes to IT or the BI consultant, joins the queue, and comes back a few days later.

The process with an LLM: The executive writes the question in natural language. The LLM takes the schema of your data model (table and measure names) as context and produces a DAX or SQL query; the query runs under your permission rules and the result comes back with a chart. The generated query stays visible on screen, so the BI team can verify it.

Measurable gain: For routine, single-dimension questions, answer time drops from days to minutes. Complex analysis remains the BI consultant's job — the goal is to clear the simple questions out of IT's queue.

Where it plugs in: An ask-and-answer layer built on top of our Power BI reporting and BI consultancy service.

d) Can a gloved operator do goods receipt by voice in the warehouse?

Today's process: The operator picks up the handheld terminal, takes off a glove, selects a menu on screen and types a quantity. In cold storage, or on lines that need both hands, this step is both slow and a source of error.

The process with an LLM: The operator speaks: "Goods receipt, twelve boxes to rack number five." Speech is converted to text, the LLM turns it into the transaction object the WMS expects, and the terminal asks for confirmation on screen and by voice. After approval, the stock movement is created through the .NET 8 API.

Measurable gain: A few seconds saved per transaction in repetitive work such as goods receipt and counting — a meaningful total across thousands of transactions in a shift. The real gain is fewer wrong-rack and wrong-quantity records, because the hands stay free.

Where it plugs in: Think WMS (Android handheld terminal + .NET 8 REST API).

e) What does an internal question-and-answer assistant for ERP procedures deliver?

Today's process: The question "which document type did we use for a return invoice in Mikro?" lands on an experienced colleague's desk. If that person is on leave, the work stops. Institutional knowledge sits in people, not in documents.

The process with an LLM: Procedure documents, ERP user guides and past support records are loaded into the RAG layer. The employee types the question and the assistant gives the answer together with the source document and clause number. An answer without a source is not an answer.

Measurable gain: A significant share of repeated internal support questions resolved at first contact; shorter onboarding for new employees. A bonus: seeing which questions come up often, and writing the procedure that is genuinely missing.

Where it plugs in: Within IT consultancy, embedded inside your existing portal or intranet interface.

04. Where do the risks sit: what are you knowingly accepting?

What does hallucination mean operationally?

Instead of saying they do not know something, LLMs can invent a plausible-looking answer. This is called hallucination. Operationally it means: it may suggest a stock code that does not exist, or describe a procedure confidently and wrongly.

The remedy is not in the model but in the architecture. A product code is always matched against the real catalogue, so an invented code cannot enter the system. The document assistant is obliged to cite sources. And human approval is never removed from critical flows.

Where does our data go, and where do we stand on data protection law?

This is the question to raise in the first meeting. There are three options, each offering a different cost-privacy balance:

• Cloud model, enterprise agreement: You work under a commitment that your data is not used for model training. The fastest and cheapest start, but the data goes to a processor abroad.
• Hosting located in Türkiye: The middleware and vector database are kept on servers in Türkiye; only masked, minimum-necessary context is sent to the model.
• On-premise open model: The model runs on your own server and the data never leaves the building. It requires hardware investment and maintenance; it is the preferred option for sensitive content such as contracts and price lists.

Whichever option you choose, masking fields that contain personal data (dealer contact name, phone, address) before they are sent to the model is our standard practice. Compliance with data protection law is not a product feature; it is a design decision.

How does token cost become predictable?

LLM usage is billed on the volume of text processed (tokens). At first glance that makes budgeting look uncertain; calculated per process, however, it is predictable. Parsing one order or summarising one meeting note costs on the order of a few cents per transaction.

What we do during the feasibility study is this: take the monthly transaction volume of the process, measure average token consumption per transaction and set a ceiling. Per-user and per-process limits, a cache for frequently asked questions, chunk limits on long documents — these are not technical details, they are budget control tools.

Where should it not be used?

To be honest, this part of the list matters as much as the usable areas:

• Accounting entries and financial calculation: Journal entries, VAT calculation, cost accounting. That is the rules engine's job; an LLM is not a tool designed for arithmetic.
• Official declarations and e-documents: e-Invoice, e-Waybill, statutory filings. An error in format or content has legal consequences.
• Work that requires exact, repeatable results: Stock balances, account reconciliation, price calculation. You get these by writing a query, not by asking a model.
• Irreversible triggers: Starting a shipment without approval, automatic payment, correspondence that goes straight to the customer.

05. How is this packaged and bought?

Our approach is not to open a large, vague budget under the name "AI project". Enterprise AI integration resembles a process improvement exercise more than a software purchase; that is why we follow a four-step path with an exit at every step:

1. Discovery and feasibility (1–2 weeks): We observe the processes on site and see the state of your data and documents. Output: candidate processes, expected benefit range, cost estimate and a risk list. The conclusion may be "not yet meaningful for this process"; we prefer to say so up front.
2. Pilot (4–6 weeks, one department): One process, a limited set of users, a measurable target. The pilot's success criterion is written at the start: for example, the targeted reduction in order entry time.
3. Rollout: If the pilot holds, extension to other departments and products, plus authorisation and training.
4. Monthly usage and maintenance: Model usage fee, monitoring, keeping documents current and improvement. This item is not optional — an unmaintained RAG layer goes stale within a few months.

Why don't we sell a separate "AI module"?

Because the user does not want to use artificial intelligence; they want to enter the order quickly and see the report without waiting. Modules that need a separate screen, a separate licence and a separate habit end up on the shelf, unused.

That is why we embed LLM capability into the WMS goods receipt screen, the CRM visit form and the portal's search box. The user does not learn a new tool; the screen they already use asks for fewer clicks. The commercial consequence: the investment goes into deeper use of a product that is already in use, not into a module nobody opens.

06. Which process should you start with?

Choosing the right pilot is the single most decisive call in the project. Start with a process that meets all three criteria:

1. Repetitive: Done dozens of times a day. In one-off work, the gain cannot be measured.
2. Text-heavy: Its input is free text, speech or documents. Numeric, rule-bound work is already classic software territory.
3. Reversible on error: A wrong suggestion must be correctable — while it is a proposal on screen, not after the shipment has left.

Using these three criteria you can cut your own processes down to a short list. In most manufacturing and distribution companies the list starts with order entry and internal document Q&A; both have high daily volume, text input, and errors that can be fixed on screen.

One warning: when you draw up the list, pick the most repeated process, not the most visible one. A demo that looks impressive in a management meeting and a feature that genuinely saves time across a shift are often not the same thing. The point of a pilot is not to put on a show, but to document a measurable difference.

You also need to look at the data side from the outset. Where the same material appears under three different names in your product catalogue, or procedures were never written down, the first job is not to install an LLM; it is to sort those two out. That is also what we spend the most time on during discovery.

Let us work out together where to start: in a free discovery call we will go through your current ERP (Mikro, Logo or another), your data quality and your processes to talk about which step will genuinely produce a gain — and if it will not, we will say that too. Our team at Gebze GTÜ Teknopark is always open to a conversation about building a system that works on the floor.