AI integration with ERP and CRM — connecting a model to the systems you already run

“Will this work with our ERP?” is the question we hear before any other. The honest answer is not “yes”. It is: integrating AI with an ERP, CRM or accounting system is a question of scope and cost, not of possibility — and of which of four routes it takes. If the system has an API, or even just file import, it can be connected to a language model; the differences between systems affect price and timetable, not whether the project is worth doing.

We write for companies running the systems that actually sit in Polish offices — Comarch, enova365, Symfonia and Subiekt, the ERP and accounting packages most Polish firms use, and on the CRM side Livespace, a Polish CRM, alongside Pipedrive and HubSpot — not for developers: four patterns, what leaves the company in each of them, and the questions to ask a partner before signing. We list these systems because they are the most common in Polish companies; we are not a partner of any vendor and we do not review their products. The interface details were read from vendor websites on 6 September 2026; vendors change them without notice. Where personal data is involved, we describe the technical and organisational side, not the legal one.

What “AI integration with ERP” actually means

Three different things hide behind the phrase. The first is AI features the vendor has built into its own product — a product feature, not an integration; you check it in the vendor’s current documentation, and we do not review it. The second is your process with a model inside it, reading from the ERP or CRM and possibly writing back to it: an order from an email becomes a document in the system, a cost invoice gets a proposed posting. That is what this article is about. The third, “chat with your ERP data”, is the read-only case of the second.

Four verbs describe the scope of an integration: read, suggest, write and trigger the next action, sending a confirmation for instance. Each one costs more and carries more risk than the last. So the first version always reads and suggests, writing starts in human-approval mode, and loosening supervision is a decision taken on pilot data, not an assumption in the quote. AI integration with a CRM follows the same rule: an entry prepared for approval — yes; an email sent to a customer unread — no.

Before you choose a pattern: three questions about your system

Does the system have a documented interface — and is it in your licence? A REST API, the vendor’s own WebAPI, a programming library such as Sfera in Subiekt, or even XML or CSV file import — the difference between them is a difference in build and maintenance cost. In several popular systems the interface is a separately licensed module, priced by the vendor or its partner.

Who has access? The IT department, the vendor’s partner, and sometimes nobody, because whoever implemented the system has left the company. Getting access is often the longest single item in the schedule, so we start arranging it in the same week we pick the process.

Which fields does the process actually need? This is where data minimisation is settled: matching an order needs item codes and quantities, not necessarily the contact’s phone number. The test is the same as in any implementation: try exporting the last hundred cases of the process as one table. Not describe how to do it — do it.

Four integration patterns

Pattern 1. The system’s API or webhook

The simplest route when the system has a documented REST API — HubSpot, Pipedrive, BaseLinker (a Polish multichannel e-commerce hub), wFirma (Polish online accounting) or Symfonia WebAPI. With a webhook the system announces the event itself; with polling the integration asks every few minutes whether anything has changed — simpler, but slower and at the cost of rate limits. And limits are a design constraint, not trivia: BaseLinker allows 100 requests a minute, HubSpot 100 or 190 per 10 seconds for private apps depending on the plan. Three rules we do not negotiate: a separate technical user for each integration, read scope separated from write scope, and every write logged with what it was based on.

Intermediate options: file import and a read-only view

When there is no API, two honest routes remain. The model prepares a file in the system’s import format — Comarch ERP Optima officially imports and exports documents through XML files — and a person imports it and confirms: slower, but cheap and with a natural approval step. Or there is no write path at all: the model gets a report export or a read-only view, and a person types the result in. In systems running on SQL, that view is sometimes a query straight against the database — usually outside vendor support, so read-only, on a separate account and with the partner’s knowledge.

Pattern 2. Intermediate layer: n8n, Make or Power Automate

When a process spans several systems and steps, a workflow automation tool arranges them into one chain: a mail trigger, field extraction by the model, validation, a Send and Wait step asking for approval, a write through HTTP Request. n8n has ready-made nodes for HubSpot and Pipedrive; for the Polish ERPs it does not, so the write goes as an HTTP call to a WebAPI or as a file for import. Minimisation and logging are enforced in this layer — this is where it is decided which fields go to the model at all — and that is why it matters whether it runs on your own infrastructure in the EU or in the vendor’s cloud, because it stores execution history alongside the data. Everything about n8n itself — pricing, licence, retention, the comparison with Make — is in the n8n guide.

Pattern 3. MCP server: when the model is to “see” company systems

MCP (Model Context Protocol) is an open standard developed under the Linux Foundation — since 9 December 2025 within the Agentic AI Foundation; the current specification is dated 28 July 2026. Technically it is JSON-RPC: an MCP server exposes company systems as named tools with defined permissions — “find a business partner”, “create an order for approval” — and the client (Claude, ChatGPT, Copilot or your own agent) calls them instead of a separate integration for each program.

It pays off for a company when one connector has to serve many client applications, and the market is already doing it: HubSpot runs an official remote MCP server, n8n can be an MCP server (the MCP Server Trigger node) and a client (MCP Client Tool), Make exposes scenarios as MCP tools. We build MCP servers too — and this is where an agent begins in practice. What such a project looks like — one API, one client, read-only first — is set out on our AI and MCP integrations page.

The risks are just as concrete: the specification says tool descriptions are to be treated as untrusted unless they come from a trusted server, content a tool returns may carry injected instructions, and user consent for each tool call is something the specification merely recommends to the client application — whether the client you are buying actually asks for it has to be checked with its vendor. The US NSA warned in May 2026 that the pace of MCP adoption had outrun its safeguards. So permissions are designed before the model is chosen — as we set out under AI agent implementation.

Pattern 4. RPA, the clicking robot — a last resort

RPA impersonates a user: it opens a window, clicks, types. It makes sense only for systems that run on the desktop alone, where nobody will write a connector. It is fragile — a change to the window layout breaks the robot — it leaves a weak audit trail, because the log shows a user rather than an integration, it needs a per-workstation licence, and it is hard to run unattended safely. A bridge, or screen reading at low volume — yes; a plan for writing at scale — no.

System by system: what the ERP, CRM and accounting packages popular in Poland offer (as at 6 September 2026)

Each entry is an interface type, a note on licensing and what it means for the choice of pattern — not a product review.

Comarch ERP Optima and Comarch ERP XL

The official route for exchanging documents in Comarch ERP Optima is export and import through XML files, and only authorised Comarch partners receive the description of their structure. According to partner documentation, Comarch Optima has no public REST API: there is a separately licensed WebAPI based on SOAP and the oldest interface, COM, which requires a local installation; there are also third-party REST wrappers — a category, not a recommendation. Conclusion: the file route, or work through a partner. Comarch ERP XL exposes functions through the CDN_API.DLL library installed with the system — a programming interface, not a network service. Comarch Betterfly (formerly Comarch ERP XT) has an API for two-way data exchange with e-commerce.

enova365

The vendor offers the Integrator module, licensed as an add-on: SOAP (WCF) and REST, XML and JSON, two-way working — retrieving, adding and updating invoices, goods and business partners among other things — plus scheduled import and export. Good material for pattern 1 or 2, if Integrator is in your licence; its price comes from the vendor or a partner, not from us.

Symfonia ERP

Symfonia ERP WebAPI is REST with JSON over HTTPS, available on an annual subscription and licensed separately for the Trade module (business partners, goods, stock levels, orders, documents, payments) and for Finance and Accounting (business partners, settlements, documents, chart of accounts). By default the licence allows ten concurrently open sessions — an integration must not take them away from people. The vendor quotes the price.

Subiekt nexo and Subiekt GT (InsERT)

In both programs the programming interface is Sfera. Sfera for Subiekt GT is a COM (OLE Automation) add-on sold per workstation — it runs locally, alongside the program. In Subiekt nexo Sfera is among the features available in the PRO edition, documented in the nexo SDK; there is also an event-driven Sfera, reacting to operations in the program. In both cases a developer writes the connector.

Microsoft Dynamics 365 Business Central

The online edition has a REST API and OData V4 with documented limits — 6,000 requests per user in a five-minute window, five concurrent calls, up to 200 webhook subscriptions — and the SOAP endpoints are being retired. Copilot in Business Central is a vendor feature, not an integration with your process.

CRM: Livespace, Pipedrive, HubSpot

AI integration with a CRM is technically the easiest, because all three systems have a REST API. Livespace provides one free of charge on every account from the Automation plan upwards. Pipedrive authorises with an API token or OAuth 2.0, has webhooks and a daily token budget: 30,000 times the plan multiplier (Lite 1×, Growth 2×, Premium 5×, Ultimate 7×) times the number of seats. HubSpot limits private apps to 100 requests per 10 seconds on the Free and Starter plans and 190 on Professional and Enterprise, and runs an official MCP server with OAuth 2.0. The difficulty is not technical but procedural: what the model may prepare in the CRM and what it must not be allowed to send, we set out on the page on AI in the sales team.

Invoicing and accounting software: wFirma, Fakturownia — and KSeF

AI integration with an accounting system usually starts with the invoicing software. wFirma provides a REST/JSON API once access is requested in the app; up to 1,000 documents generated through the API a month free of charge, above that individual pricing. Fakturownia, another Polish invoicing service, has a REST API in JSON or XML with a token from the account settings — invoices, products, customers, stock documents, payments; whether it is in every plan, check with the vendor. Both suit patterns 1 and 2 in the “AI prepares, a human approves” mode we described under accounting automation.

KSeF — Poland’s mandatory national e-invoicing system — changes the context of every invoicing integration. According to ksef.podatki.gov.pl (as at 29 May 2026), only KSeF 2.0 has been running since 1 February 2026; from that date the obligation to issue e-invoices covered taxpayers with 2024 sales above 200 million zł, from 1 April 2026 everyone else, and the smallest — with monthly sales up to 10,000 zł — will be covered from 1 January 2027. The KSeF 2.0 API documentation has been public since 30 June 2025. What is left to automate after KSeF we set out in the article on KSeF and accounting automation.

BaseLinker (for companies selling online)

BaseLinker’s API is JSON through a single POST endpoint, a token in the header, a limit of 100 requests a minute and over 150 methods — from orders to stock documents. In a trading company BaseLinker is often already the intermediate layer between the shops and the ERP; the model then connects to it rather than to each channel separately. Where we start in retail is on the page on AI in a trading company.

What leaves the company: fields, region, training, permissions

“Does ERP data go to OpenAI or Anthropic?” — in every pattern that is a design decision, not a property of the model. In patterns 1 and 2 only the fields the integration sends reach the model provider, and you choose them. In pattern 3 the model sees what the tool returns, so tools are designed narrowly: “stock level for an item code” rather than “the whole product record with its history”. In pattern 4 the contents of the screen leave. In the four-step flow — your system, the intermediate layer, the model provider, back to the system — most is settled at the second step: data that was never sent needs no guarantees at all. The whole flow is on the page on data security and GDPR.

In the terms of service you check the processing region and whether content is used for training: the business tiers of the large providers switch it off by default, consumer tiers are sometimes the opposite — check the terms of the specific service rather than assuming. The model provider’s role is established separately for each operation; why, we set out in GDPR and an LLM rollout.

Every write path gets a permissions matrix: read scope, write scope, operations requiring human consent and activity log — the same four items every agent project of ours starts from. Most internal integrations are not high-risk systems within the meaning of the AI Act, but the classification is settled case by case by your lawyer — the duties they identify are implemented under the AI Act technical compliance sprint. This describes the technical and organisational side, not legal advice — the legal assessment belongs to your lawyer or data protection officer.

What an AI integration with an ERP costs, and how long it takes

We will not give you a range without knowing your interface. Six things decide the cost:

1. Quality of the interface. Cheapest first: REST API in the licence, a WebAPI or Integrator module to buy, a COM library with a local connector, file import, RPA.
2. The partner’s share. Optima’s XML structure goes to Comarch partners only; Sfera needs a developer. Every extra party means coordination and a separate invoice.
3. Number of systems. Count integrations, not features: each system is its own authentication, mapping, error handling and access to arrange — we set this out in the article on what an AI implementation costs.
4. State of the data. Business partners spelled three ways and item records with no codes are work that is not called integration but costs like integration.
5. Level of certainty. A proposal for approval is cheaper than a write under statistical supervision, because the latter means building the monitoring.
6. Maintenance. ERP version updates, retired API versions (Business Central is retiring SOAP; Pipedrive introduced new limits over the course of 2025) and retired model versions — the vendor sets the timing, not you.

Time: one system with a REST API and a test database is weeks; several systems with partners along the way, months — and access is often the longest item. Model fees alone, at a few hundred documents a month, run to a few dozen zlotys; the money sits in the integration work and its maintenance. Which is why a range quoted without asking about the interface is worthless, whoever quotes it.

A worked example: emailed orders into the ERP with a salesperson’s approval

The figures are illustrative and are there for working through your own case — they do not come from a client implementation.

A trading company receives 600 orders by email a month; a salesperson retypes each one into the ERP in about 7 minutes, which is 70 hours a month. In pattern 2 the model extracts the line items and matches them to item codes from the ERP, validation checks codes and quantities, Send and Wait sends the salesperson a summary for approval, and after approval an HTTP Request creates the order through the WebAPI — or, where there is no API, writes an XML file for import. Approval takes about a minute: 10 hours a month instead of 70, and errors surface before confirmation rather than after the order goes out.

Model cost per the Claude API pricing of 6 September 2026 (Claude Sonnet 5: US$2 per million input tokens, US$10 per million output; billed in dollars): 600 times roughly 6,000 input tokens is 3.6 million, so $7.20; 600 times roughly 800 output tokens is 0.48 million, so $4.80 — around $12 a month in total. The intermediate layer: 600–1,200 executions fit inside n8n Cloud Starter (€20 a month on annual billing for 2,500 executions, price of 5 September 2026) or a self-hosted install. The interface licence — WebAPI, Integrator, Sfera — is priced by the vendor or its partner; we do not quote somebody else’s price.

The fixed part is the build: three or four integrations (reading business partners and item codes, writing the order, mail, the approval channel), testing and handover — that is what the quote covers. If an hour of a salesperson’s time costs you X zł, then 60 hours times X times twelve months, minus maintenance and subscriptions, is your annual figure. Work it out yourself before somebody works it out for you.

When not to integrate — or not yet

• The ERP or CRM already does it. Do not build what you can buy on subscription — we will say so even when it means no work for us.
• The volume is too small. The cost of an integration is largely fixed; if the process takes two hours a month, it is almost certainly not worth it.
• There is no interface and no partner. RPA is a bridge, not a plan — the decision about the system comes first, the decision about AI second.
• The data is not in the system anyway. Orders in inboxes and on scans, the decision history in someone’s head — the first stage is putting the flow in order, and that is not an obstacle but the actual scope of that stage.
• There is no process owner and no rules. An integration will entrench the argument about the shape of the process instead of settling it.
• You have not tried the read-only version. A CSV export plus a model proves the value without a single write integration. Start there.
• Somebody requires unsupervised writing from day one. We do not build that — not towards customers, and not towards systems.
• HR and payroll modules. Employee personal data is a separate regime, and we do not score candidates in recruitment under any pattern — the full list of what we do not do is published separately.

What to ask your ERP partner before you sign anything

1. Does our licence cover WebAPI, Integrator or Sfera — and if not, what does it cost and who switches it on?
2. Is there a test database, and how do we refresh it?
3. Which objects can be read and which written — and does a write through the interface pass the same validation as a manual entry?
4. Will we get a separate technical user with the minimum scope of permissions?
5. What are the request and session limits?
6. Where can the log of operations performed by the integration be seen?
7. What happens to the integration when the version is updated — who tests, who pays?
8. Who maintains the connector after the project ends, and on what terms?
9. Can we have read-only access to start with?
10. Can the last hundred cases of the process be exported as one table — today?

What next

In a four-stage rollout — audit, pilot, implementation, handover — the interface question is settled during the audit, and the pilot always runs in human-approval mode. You do not need to know which pattern is yours; you need to know which process and which system. How we pick the process, where the human stands and what the cost depends on is on the page on AI automation in a company.

Tell us about your process and the system it lives in. We will tell you which of the four routes we would take — including when the answer is “not worth it yet”.