AI Integration with ERP and Corporate Systems

A financial controller spends two hours a day manually entering invoice data into the ERP. The sales department waits 24 hours for a response from logistics because checking availability requires searching three systems. The helpdesk solves the same configuration issues because the knowledge resides in a senior’s head, not in the system. These aren’t technology problems. They’re problems of inconsistent integration between the systems you already have. AI doesn’t replace ERP or CRM—it connects to them and fills the gaps that previously required human intervention at every step.

The first concern we encounter in client conversations: "Will we have to rebuild the ERP?" No. The AI model acts as a middleware layer—it reads data from the system via API, processes it, and writes the result back. SAP, Microsoft Dynamics, Comarch ERP, Optima, Symfonia—each of these systems has an API or at least a data export that allows integration without touching the core configuration.

Practical differences between approaches:

For the vast majority of companies, the entry point is the first row. A pilot doesn’t require changing the ERP vendor contract or hiring developers familiar with the system’s internals.

A good candidate for AI integration has three characteristics: high repetition, structured input data, and measurable manual processing time. Five processes we most commonly encounter in projects:

Invoice posting and processing. OCR extracts fields from a PDF document (VAT ID, amount, date, line items), the model maps them to accounting accounts according to the chart of accounts, and saves them to the ERP as a proposed posting for approval. Incorrect invoices go to an exceptions queue with a discrepancy description.

Order classification and routing. A new order from e-commerce or EDI goes to an agent, which checks availability, verifies the customer’s payment terms, and assigns the order to the correct fulfillment path. Exceptions (out of stock, credit exceeded) are automatically escalated with full context.

Service ticket triage. A helpdesk ticket describes the problem; the model categorizes it, assigns priority, and suggests a response based on a database of resolved cases (RAG on ticket history). The consultant approves or corrects—without starting from scratch.

Reporting and data narrative. Data from the ERP (sales, inventory, receivables) goes to the model, which writes a narrative of deviations from the plan. Instead of a grid of numbers, the manager gets a sentence: "Margin in category X dropped by 4 pp. compared to last month, mainly due to increased delivery costs."

Master data completion. A new contractor entered into the system has an incomplete record—missing PKD code, legal form, or contact details. The model verifies the data from available sources and presents the completion proposal for operator approval.

Every AI integration with an operational system should have four layers. Missing any one usually surfaces after a few weeks in production as either a security incident or an error that’s hard to explain.

Data extraction layer. The source system (ERP, CRM) exports data via API or cyclic export. At this stage, you apply masking or pseudonymization of PII. Personal data of clients, PESEL numbers, financial data of individuals—you cut or pseudonymize before passing it further. The cloud model never sees personally identifiable data. More on this pattern in the article about PII anonymization before AI.

Model invocation layer. The prompt is built from a template and masked data. The invocation goes through an LLM router, which selects the model for the task and cost, logs every call, and enforces daily budgets. Structured output with a forced JSON schema eliminates half of parsing errors—instead of text, the model returns an object with defined fields.

Validation and guardrails layer. The model’s response is validated before saving: we check schema compliance, value ranges (whether the invoice amount is within reasonable limits), and guardrails block operations outside the defined scope. Instead of silently saving an anomaly, the system routes it to an exceptions queue with an explanation.

Action and human-gate layer. Reversible actions (proposed posting, order classification) are saved as drafts for approval. Irreversible actions (sending an order to a supplier, changing an invoice status to "paid") wait for human confirmation. This isn’t about trust in the model—it’s the principle that an irreversible action with an error costs far more than a second of human approval. The human-gate pattern is covered in more detail in the article about the role of humans in the loop.

ERP and CRM contain data whose leakage is costly legally and reputationally. A few principles we implement in every project:

Sensitive data (personal data of clients, financial data of individuals, HR data) never reaches the cloud model in an identifiable form. If GDPR requirements or company security policy demand it, the entire stack—embeddings and model—runs locally on the client’s infrastructure (self-hosting). Latency increases, but data doesn’t leave the network.

For integration with high-risk systems (HR data, medical data, financial scoring), a DPIA is required before production launch. The AI Act imposes additional requirements on systems assessing individuals—ICP classifiers operating on personal data fall into the high-risk category with obligations for documentation and decision explainability. More in the article AI Act and GDPR 2026—corporate obligations.

Every model invocation is logged with an operation identifier, timestamp, and result—without personal data. This log isn’t unnecessary bureaucracy: it’s an audit trail required for inspections and the basis for quality measurement.

An AI integration pilot with ERP is a fixed-scope project that ends with a measurable result—not an open-ended AI license. The typical path:

The first step is a process audit: how much time it takes today, what the input and output data are, where exceptions occur, and how they’re handled. Without this measurement, you can’t confirm that AI delivers ROI. Assess your process readiness with the readiness assessment tool.

The second step is technical integration: connecting to the source system’s API or configuring export, building a data pipeline with PII masking, setting up the router and guardrails, and deploying in shadow mode (the model works in parallel with humans, results are compared but not automatically saved).

The third step is calibration: for 2–4 weeks, you collect shadow mode results, measure accuracy (how many model proposals operators approve without corrections), identify exception categories, and adjust guardrails. Only after reaching the agreed accuracy threshold (usually 85–95%, depending on the process) do you switch to automatic proposal saving with human sample control.

Time and cost ranges depend on the scope and complexity of the source system’s API. Calculate options for your process with the ROI calculator.

No shadow mode before production. Launching automatic saving to ERP without a shadow phase means the first model errors go straight into the system. A few weeks of shadow mode and collecting exception data is cheaper than two hours of manually cleaning anomalies in the database.

Skipping schema validation on output. The model returns valid JSON in 98% of cases. Those 2% end up in the system as null, empty string, or outdated value—silently. Forced JSON-Schema and validation before saving turn those 2% into a visible exception in the dashboard, not a hidden data error.

Integration without quality monitoring. Model accuracy degrades over time: ERP data changes, document types evolve, new exceptions appear. Without measuring accuracy (how many proposals operators approve without changes, how many go to exceptions), you don’t know when the model needs recalibration.

One model call per record. When processing hundreds of invoices daily, token costs can be surprising. Token cost optimization through prompt caching, batching, and routing to a cheaper model for simple tasks can reduce operational costs by 40–70%.

Describe the process you want to automate and the source data—the model will show how to design the integration pipeline, PII masking, and guardrails schema. This is a starting point, not a ready project (playground: PII masked, zero retention):

In the vast majority of cases, yes. Integration relies on the system’s API (REST, SOAP, EDI) or data export (CSV, XML). You don’t need access to the source code or changes to the vendor’s configuration. Most Polish ERP systems (Comarch, Symfonia, Sage, Microsoft Dynamics) have documented APIs or at least export capabilities sufficient for a pilot.

The main risk is an incorrect automatic write that’s hard to reverse. That’s why we apply the principle: the model proposes, humans approve for irreversible actions. For the first few weeks, the model works in shadow mode—results are compared with manual decisions but aren’t automatically saved. Only after measuring accuracy (usually over 90% of proposals approved without changes) do you switch to automatic saving with random sample control.

It depends on the data type. Non-personal data (product codes, aggregate amounts, order categories) isn’t subject to GDPR restrictions. Personal data (individual’s VAT ID, contact details of individual clients, HR data) requires either masking before sending or a local model. During the audit, we classify process data and select the appropriate architecture—cloud with masking or fully local.

A pilot for one process (e.g., invoice posting) typically takes 3 to 8 weeks from scope signing to measurable results. The biggest variable is the availability of the source system’s API and the quality of input data. If invoices arrive as low-quality scans without a text layer, OCR requires calibration, which extends the project. A detailed timeline and cost depend on the scope—contact us to start with concrete numbers.

Not in the literal sense. AI eliminates repetitive mechanical tasks (manual field entry, searching data across multiple systems, writing reports from data), not decisions requiring business context. Employees who currently enter invoices can focus on verifying exceptions, analyzing deviations, and improving data quality—adding more value and being less monotonous. The most common pilot effect isn’t staff reduction but time reallocation to higher-value work.