AI Integration with ERP (Optima, SAP, Subiekt) - Building a Decision Layer Over Your Business Data

Your ERP system is the heart of the company. It stores inventory levels, invoices, margins, contractors, and the full history of operations. The problem is that in most companies this heart doesn't think. The data is there, but to use it a person must manually transcribe, analyse, check, and correct it.

Your ERP stores the facts about your business - inventory, invoices, margins, clients. AI can turn those facts into decisions: automatically, safely, and in line with your system's logic. Learn the Closed-Loop AI architecture for Optima, SAP, and Subiekt.

AI integration with ERP is not about "connecting ChatGPT to invoices". It is about building a decision layer that understands transactional data, enforces business logic, and executes operations in the ERP according to the system's rules.

In this article I show what that architecture looks like in practice - from choosing the right integration method, through JSON Contracts and RAG, to test environments and security controls that no production system should launch without.

Which ERP Systems Can Be Integrated with AI?

In practice I most often work with three system families: Comarch ERP Optima, SAP (ECC / S/4HANA), and Subiekt nexo / GT. Each has a different communication architecture - which is why the approach must always be tailored to the specific system.

There is no "off-the-shelf AI plugin for ERP". Every deployment must be architecturally designed for the specific infrastructure - which is why many "AI ERP integrations" end up being nothing more than invoice OCR and manual clicking.

Closed-Loop AI ↔ ERP Architecture

A professional integration always operates in a closed decision loop. The ERP generates an event (new invoice, purchase order, warehouse document), middleware captures it, data is validated, AI makes a decision, and only then - through the official ERP API - a write occurs.

The most important engineering rule: AI never writes anything directly to the ERP database.

ERP systems have hundreds of inter-table dependencies, business logic, and validations that the AI does not know about. A direct SQL write will sooner or later corrupt data integrity. The AI generates a decision proposal in JSON format, and a dedicated adapter executes it according to the system's rules.

Middleware as a Mandatory Traffic Buffer

ERP is not a system designed for thousands of requests per minute. It has maintenance windows, can block access under high load, and often runs on on-premise infrastructure that is several years old.

Middleware (n8n or a dedicated service) acts as a buffer and controller:

• Queues tasks - when 500 documents arrive simultaneously, the system will not collapse.
• Retries operations - when ERP is temporarily unavailable, tasks enter a retry queue with exponential backoff.
• Enforces idempotency - the same invoice will not be posted twice, even if the server restarts mid-operation.
• Separates AI and ERP worlds - middleware is the translator and gatekeeper simultaneously.

Without this layer, the integration works fine… until the first serious load spike.

AI Decision Contract - JSON as the Common Language of AI and ERP

The AI cannot return descriptive text like "this looks like a cost invoice". It must return a strictly defined data structure (JSON), validated against a schema before any write occurs. This decision contract makes the AI a predictable system component rather than a creative assistant.

{  "document_type": "invoice_purchase",  "confidence": 0.97,  "contractor_id": "CONT-10482",  "amount_net": 4850.00,  "amount_vat": 1115.50,  "amount_gross": 5965.50,  "currency": "PLN",  "issue_date": "2026-04-22",  "payment_due": "2026-05-22",  "cost_account": "402-01",  "decision": "auto_approve",  "requires_human_review": false,  "idempotency_key": "INV-2026-04-22-CONT10482-7d3f"}

Key contract fields:

• confidence - if below 0.85, the document automatically enters manual review regardless of other fields.
• cost_account - AI assigns the account from the chart of accounts using RAG (company knowledge), not from the model's general knowledge.
• decision: auto_approve / human_review - binary field determining the processing path.
• requires_human_review - flag overridden by business rules (e.g. amount exceeds authorisation threshold).
• idempotency_key - unique key that prevents double-posting even when the system restarts.

If the JSON structure is invalid or required fields are missing, the document enters the manual review queue. The system never writes "by force".

RAG and Company Context Memory

The AI does not make decisions based on knowledge from the internet. Before every decision it receives context from your company, delivered through RAG and a local vector database:

• Contractor history - has this supplier been problematic before? What are their typical amounts and payment timelines?
• Chart of accounts - the current accounting structure from your ERP, synchronised automatically.
• Discount and margin policy - thresholds at which a decision requires human approval.
• Previous similar cases - similar, already approved or rejected documents are added to the context, so over time decisions fit your accounting team's practice better and better.

This means the AI operates on your company's data rather than on assumptions and general accounting knowledge.

KSeF and AI-ERP Integration

Since February 2026 every company in Poland receives invoices through KSeF, and ERP systems download them as structured XML - Optima, nexo and Symfonia have their own modules for this. That changes AI's role: for domestic invoices it no longer needs to read the document, and instead handles what a person used to do - coding, matching to the purchase order, detecting duplicates and routing exceptions. The simplest architecture in 2026: the ERP's KSeF module downloads the invoice, middleware reads it from the ERP, AI proposes coding according to the JSON contract, and the adapter writes the decision. I cover the post-KSeF document workflow in more detail in the post on invoice automation.

Autonomy Levels - What AI May Do in the ERP

The most common design mistake is a single decision: "does AI have access to the ERP: yes or no". It's better to split it into levels and move operations up only when the numbers justify it:

Most of my rollouts stop at level 1 or 2, and that's good news: draft mode alone takes most of the work off people while keeping risk under control. This table is also a ready answer to an auditor's question: "who approved this document?".

DEV / STAGE / PROD Environments

In accounting systems there is no room for experiments on a live database. A correct deployment requires three environments - and this is an element that is dramatically absent from most AI deployments.

I first build the logic and prompts in DEV. Then I test on a copy of the ERP database in STAGE - real data, no risk. Only when all edge cases pass does the solution move to production.

Failure Scenarios and Safeguards

This is where the difference between an "AI demo" and a production system becomes clear. Every scenario below must have a technical safeguard before the system goes live.

I do not handle only the happy path - I handle every path.

Security and RBAC

Security in AI-ERP integration is a foundation, not an option:

• Principle of least privilege - AI has read-only access to selected data views (e.g. invoice view), never to the full database.
• Write only through the adapter - no API key has permission to write directly to the ERP SQL database.
• Key encryption - API keys and credentials stored in a secure vault (environment variables with encryption at rest).
• Full audit trail - every AI-executed operation is logged with timestamp, event source, and decision outcome.
• ERP never exposed to the internet - communication runs over VPN or a private network, never through a public endpoint.

For the IT department: full control, full accountability, zero black boxes.

Real Applications: Far More Than Invoice OCR

Once the Closed-Loop architecture is in place, the possibilities extend well beyond document recognition:

• Automatic replenishment orders - AI monitors inventory levels and places a supplier order when stock falls below the minimum threshold.
• Sales blocking on low margin - the system blocks invoice issuance when the calculated margin falls below a defined threshold - before the salesperson clicks send.
• Intelligent debt collection - AI analyses payment history and the tone of contractor correspondence, suggesting collection priority and communication style.
• Sales proposal generation - based on current stock, purchase prices, and margin policy, AI generates a client proposal without the salesperson's involvement.
• Automatic cost categorisation - every purchase is assigned to the correct accounting account without manual entry by the accountant.
• Cash flow forecasting - AI analyses payment history and open receivables to generate a weekly cash flow forecast.

Why Zapier and Make Are Not Suitable Here

Zapier and Make are excellent for marketing automations and simple integrations. In the ERP context they lack several critical elements:

• No transactional queues with delivery guarantees.
• No idempotency mechanism at the operation level.
• No advanced JSON schema validation before writes.
• No control over write logic - data enters without business-rule verification.
• Accounting data passes through the tool vendor's servers, so you need a data processing agreement and a check of the processing region. Self-hosted n8n or your own service solves this. When simple automation stops being enough is covered in the post on when Zapier and Make are not enough.

In ERP systems this is not a matter of convenience - it is a matter of data integrity and business security.

Frequently Asked Questions

Summary: ERP Stops Being an Archive, Starts Being a Brain

AI integration with ERP is not another automation. It is building a decision layer over the company's transactional data.

ERP stops being a data archive - it becomes a source of decisions executed automatically, safely, and in line with the system's logic.

Every professional deployment requires the right integration method for the specific ERP, a middleware layer as buffer, a JSON Decision Contract as the communication language, RAG with company data, three test environments, and full RBAC.

If you're planning AI-ERP integration, start by choosing one process and deciding which autonomy level it should start at. I help with this as part of AI process automation - from process mapping to the adapter and tests on a database copy.