Comarch ERP Optima and XL — Two Systems for Two Buyers

Comarch ERP Optima runs a large share of Polish small and mid-sized businesses and an even larger share of Polish accounting offices, and it has earned that position. Comarch ERP XL sits above it where complexity has moved into production, warehousing or multiple branches. Both are properly localised, actively developed, and correctly scoped for the buyers they serve. Both also hold structured, complete, legislatively disciplined data — which makes them good raw material for management reporting.

At a glance

What Comarch ERP Optima and XL are

Comarch ERP Optima is a Windows application that runs the books and the day-to-day commercial operations of a Polish company. It is organised into licensed modules mapping closely to the statutory books: the ledger, kept either as full double-entry commercial books (Księga Handlowa) or as the simplified tax ledger (Księga Podatkowa); invoicing; trade and stock; cash and bank; fixed assets; payroll; customer records. Each module posts into the same company database and each is priced separately, so two Optima installations at companies of similar size can look quite different.

Comarch ERP XL is a different product with a different centre of gravity — a functionally extensive ERP, in Comarch’s own description, with a flexible modular build grouped into more than a dozen cooperating areas. It carries production technologies and works orders, high-bay warehouse management, quality control with batch traceability, projects, service and repairs and EDI, with finance and accounting sitting alongside all of it rather than underneath it. Where Optima is built outward from the ledger, XL is built outward from operations.

The localisation is the real achievement in both, and it is harder than it looks. Polish tax reporting has moved further and faster than most European regimes over the past decade: the JPK files replaced the VAT return as the primary filing obligation, JPK_V7 folded the register and the declaration together, and KSeF has now made the structured invoice (faktura ustrukturyzowana) the standard form of a B2B invoice. Each of those reaches document capture, the ledger, the reporting and the printed output. Keeping two products current with all of it, on an annual release cadence, from single-user offices to multi-branch manufacturers, is a substantial ongoing commitment — and Comarch has met it.

Both products sit inside a wider Comarch estate. Comarch SA is a large Polish technology group with its own data centres, e-commerce platform, EDI network and BI stack, so an Optima or XL client may also run Comarch e-Sklep, BPM, HRM, WMS or BI Point — several of which hold data the finance team needs, and none of which share a database with the ERP.

The two product lines

Most buyers choose between Optima and XL on operational fit. It is worth understanding what else the choice determines, because the data consequences are not the same.

Two of those rows carry most of the weight.

The first is the Optima cloud row. Comarch’s own documentation for Comarch ERP Optima Chmura Standard states plainly that access to the databases is possible only through Optima installed on Comarch’s dedicated servers, and that there is no other route in. That is a defensible security decision and the right default for a small firm with no IT function. It also means a cloud client’s reporting layer cannot read the database the way it reads an on-premise one, so the extraction route has to be agreed with Comarch. It is the first question we ask when scoping reporting work on Optima.

The second is the XL database row. XL has run on PostgreSQL since release 2020.0, which Comarch positioned as a way to reduce platform licensing cost; Microsoft SQL Server remains supported and developed. Either is workable, but they are not interchangeable — extraction, incremental read and change tracking all differ, so confirm which engine an installation runs on rather than assuming.

Modules sit across both lines and are licensed individually. In Optima, Opis Analityczny — the analytical description module carrying cost centre and project tagging — is a separate purchase rather than a standard inclusion, and whether a client has it changes what is possible from history. In XL the equivalent is closer to standard.

Who Comarch ERP Optima and XL fit

Established Polish SMEs on Optima. Ten to two hundred people, one or two legal entities, full commercial books, stock, payroll. This is the core of the market and Optima serves it well. What these companies want next is usually not a different ERP — it is a management view of data Optima already holds correctly.

Accounting offices. An accounting office (biuro rachunkowe) may hold several hundred client company databases against a single configuration database, with batch operations across selected databases built in for exactly that reason. Optima’s efficiency at this scale is a genuine strength, and offices are its most concentrated and most loyal user group. Increasingly they are also the ones asking whether they can offer clients reporting on books they already keep well — a question the product answers one client at a time, and a layer answers across the whole client book.

Manufacturers and distributors on XL. Works orders, bills of material, batch traceability, high-bay warehousing, several branches, sometimes a Comarch WMS or MES alongside. XL is bought for operational depth, and finance inherits far more analytical raw material than the statutory books require. Very often nobody has turned that into a margin view by product line or works order.

Groups that grew sideways. A Polish trading company on Optima, a manufacturing subsidiary on XL, a small foreign entity on something else. Each choice was sound for the entity that made it. What nobody owns is the view across them, and this is the context in which Comarch most often reaches us.

What Comarch holds — and why it is good material

Before the reporting question, it is worth being clear about the asset.

Comarch data is clean, and the reason is structural. Polish statutory obligation enforces a discipline that voluntary data entry never does: the JPK_V7 file has to tie to the VAT register, the register has to tie to documents, the ledger has to balance, and since the KSeF mandate the invoice itself is a validated structured document with a government-issued number attached. A Comarch database kept properly by a competent accountant is complete to document-line level, internally consistent, and stable across years. That is why data quality is rarely our first problem on a Comarch estate.

It is also richer than most users exploit. Both products carry an analytical description (opis analityczny) that tags documents and ledger entries with dimensions beyond the account — a cost centre (miejsce powstawania kosztów, MPK), a project, a location, or dimensions the client defines. Used consistently, they carry most of what is needed for real profitability analysis without anyone extending the chart of accounts (plan kont) to breaking point. Used partially, they are still a foundation worth building on. XL adds works order costing, batch and serial history and warehouse movements on top.

Compared with what we more often meet — spreadsheet bookkeeping, half-configured cloud tools, a decade of manual journals — a Comarch database is a good starting point. The quality of a management reporting layer is bounded by the quality of what feeds it.

What sits outside Comarch’s scope

Both products are scoped to one company, and that scope is a design decision rather than an omission — for the core user, one company and one set of books is exactly the right boundary. Three things sit outside it.

The view across companies. One company database per company means a group of five companies is five Optima databases, and the configuration database is a list of companies, not a consolidation. No common chart of accounts, no intercompany matching, no currency translation — all of it happens outside the system. For an accounting office the arithmetic is the same at a different scale.

The view across systems. Comarch has no opinion about whether revenue in your e-commerce platform matches revenue in the ledger, or whether the warehouse and the stock ledger agree. This is worth saying plainly: no ERP does this. Not Comarch, not Business Central, not SAP. Cross-system truth is a layer above every transaction system, which is the point we make at more length here . It bites harder on a Comarch estate than most, because the portfolio is broad enough that a client can run four Comarch products that do not share a database.

The management view. The statutory chart of accounts is built to satisfy the tax authority and produce a defensible trial balance (zestawienie obrotów i sald), and it does that well. It is not built to answer which customers make money after cost to serve, and neither is statutory consolidation . Comarch’s own reporting is capable within scope — Optima’s Analizy BI module, XL’s analytical reports, Comarch BI Point above both — but none of it is a semantic model a dashboard or an AI assistant can query across a group and across systems.

None of this is a reason to change system. It is a reason to add a layer.

How we elevate it

Getting the data out is the routine part. Direct read-only SQL against Microsoft SQL Server or PostgreSQL is our default wherever the server is reachable, which covers every on-premise and hosted installation; on Comarch Cloud the route has to be agreed with Comarch first. Comarch’s XML import and export handles document-level exchange, and Comarch ERP XL WEB exposes a REST API. Read-only throughout. Nothing is ever written back, and users notice no difference in how the system performs.

What happens next is the Comarch-specific work.

A management chart of accounts alongside the statutory one

The Polish statutory chart keeps doing its job. We map it to a second structure built to answer management questions — revenue by what you actually sell, cost by what you actually control, margin at the level you make decisions. On a Comarch estate this earns its keep twice over, because Optima and XL charts are almost never built the same way even inside one group: the Optima entity was set up by an accounting office to statutory convention, the XL entity during an implementation project around operational reporting, and the two disagree about where a cost belongs. Mapped once, versioned, owned by a named person, reviewed at each close. The design principles are in our guide to chart of accounts architecture .

The analytical description, put to work

Opis analityczny is where profitability analysis lives on Comarch, and it is the highest-return piece of work on most Optima estates. We audit how consistently the dimensions have been used across history, surface where they are thin, agree rules for filling them going forward, and encode those rules as validation so the discipline holds. Two Comarch-specific things shape it. In Optima the module is a separate licence, so some clients have years of well-tagged history and others none — and the answer to can we see margin by project for 2024 depends entirely on that. And where XL is in the group, its operational dimensions and Optima’s analytical description have to be reconciled to one set of definitions before either can be trusted, which is a data governance exercise before it is a technical one.

One view across every company database and every system

Each Comarch company database becomes one entity in a common data model , sitting alongside other Optima databases, XL, Business Central, an e-commerce platform or a payroll system — all producing the same standardised output. Group reporting in any currency, with currency translation handled once and drill-down from a consolidated total back to the Comarch document behind it. For an accounting office the same mechanism does something commercially different: one connection pattern across the client book, so the office can offer reporting on books it already keeps rather than building it client by client.

This is routine rather than aspirational: we work with 70+ companies across 11 countries, on 12+ different ERP and accounting systems. See Group Reporting & Consolidation .

On the governed layer, the rest is the platform doing its standing job: daily reconciliation against the ledger so the close confirms rather than rebuilds, a semantic model that Power BI and AI can both query reliably , and your business context accumulating so answers get sharper the longer it runs.

What becomes answerable

The clearest way to describe the difference is to list what a Comarch client can ask afterwards.

• Which customers are actually profitable, after delivery and service cost — not just gross margin on the invoice?
• What did that works order cost against standard, while it is still open?
• What is group EBITDA in EUR or PLN, when one entity is on Optima and another is on XL with a different chart of accounts?
• Why did overhead move this month, ranked by the cost lines that moved most against budget ?
• How much cash is tied up in stock that has not moved in six months, and what does that do to cash flow ?
• Where does the reported number differ from the booked number, and why?

Every one of these is answered from data Comarch is already holding. The information was there. What was missing was the structure to ask.

What it takes, and what does not change

Connection in days. First reports in the first week. For a single-entity Comarch ERP Optima client, the connection is a read-only login and the first governed reports follow inside a week. A full build — management chart of accounts, dimension repair, consolidation across several entities, the reporting suite — runs in phases over the following months. The distinction matters, and we would rather be precise about it than promise a finished model in a fortnight.

What we need from you: an NDA, read-only credentials, and a conversation about what the numbers should mean — plus, on Comarch Cloud, a conversation with Comarch about the extraction route.

What does not change: Comarch stays your system of record. Your accountant keeps working the way they work. No migration, no data cleanse project, no retraining, nothing written back.

Read-only access throughout. Your data stays in an EU-hosted Azure environment, aligned with ISO 27001 and GDPR, governed by you.

In practice

The closest published parallel to a Comarch group build is a multi-ERP consolidation. TEPEDE is a CEE large-format printing group running 8 entities across 6 countries on 6 different ERP and accounting systems — Comarch is not among them, but the shape of the work is identical. Chart of accounts mapping, currency normalisation, intercompany elimination and daily extraction produced a single group P&L, balance sheet and cash flow, and consolidation moved from a 20-day exercise to real-time.

When Comarch is eventually replaced

Some Comarch clients change system at some point, usually because they have outgrown the scope rather than because anything went wrong — often from Optima up to XL, the path Comarch designs for, and occasionally to an international platform when a group standardises.

Because the governed layer sits above the ERP, only the connection changes. The data model, the reports, the dashboards and the consolidation logic stay as they are. Clients who built the layer first find the migration measurably easier, because they can prove the new system’s numbers against the old system’s from day one — and they keep their reporting history through the change. That applies to an Optima-to-XL move as much as to a change of vendor.

This is not a theoretical claim. When JING Tea replaced its operational stack, the reporting layer carried through the change unaltered — the systems underneath moved, the numbers and the reports did not.

Comarch in the Polish context

Comarch is one of several capable systems serving the Polish market. Each gets its own article in the series .

From a data-layer perspective the choice matters less than it appears. Each becomes an entity in the same governed model, so the ERP decision can be made on operational fit rather than on reporting fear. The full matrix is on the series hub ; the POHODA and Business Central articles cover the two most likely neighbours.

Frequently asked questions

Do we need to replace Comarch ERP Optima or XL to get proper management reporting? No, and we would usually advise against it. Keep Comarch for what it does well — statutory correctness, VAT and JPK, KSeF, clean transaction capture — and build the reporting layer above it. Replacing a working ERP to solve a reporting problem is an expensive way to solve the wrong problem. If you are unsure, we have written about when a new ERP earns the investment .

Is Onetribe a replacement for Comarch? No. Comarch remains your system of record and your team keeps using it exactly as they do now. We read from it, never write to it. If you change ERP later, the reporting layer stays.

Comarch and KSeF — does e-invoicing change the reporting picture? It improves it. KSeF became mandatory for taxpayers with prior-year sales above PLN 200m on 1 February 2026 and for the remaining entrepreneurs on 1 April 2026; the smallest businesses follow from 1 January 2027. Comarch built KSeF communication into both products and licenses it as a document-volume subscription. For finance, the sales invoice is now a validated structured document carrying a government-issued number, which makes matching and reconciliation more reliable than PDF and paper ever were. What KSeF does not do is answer a management question. It is a compliance channel, not a reporting model.

What database does Comarch ERP Optima use, and what does XL use? Comarch ERP Optima is a client-server application on Microsoft SQL Server, versions 2016 to 2022, and works with any edition from the free Express upward; the server needs Polish_CI_AS collation and mixed-mode authentication. Comarch ERP XL runs on 64-bit Microsoft SQL Server and, since release 2020.0, can also run on PostgreSQL.

Can Comarch connect to Power BI? Yes. The practical route is a read-only extract into a governed model, with BI reporting on the model rather than on the Comarch tables directly. Pointing Power BI straight at the database works once and gets harder to maintain from there — the tables are transactional by design, and the definitions need to live somewhere that survives a version upgrade. Reading this way does not slow Comarch down: we read incrementally on a read-only login. The exception is Optima in Comarch Cloud, where the database is reachable only through Optima itself.

Can Comarch ERP Optima consolidate several companies? No — it holds one company per company database, the right design for its core user and the reason it works so well for accounting offices. The configuration database lists the companies on an installation and supports batch operations across them, but it is not a consolidation engine: no shared chart of accounts, no intercompany elimination, no currency translation. Consolidation is a layer above Comarch, and the most common reason multi-entity Comarch users come to us.

Does Comarch ERP Optima have an API? There is no public REST API for Optima. Integration runs through XML document import and export, COM objects on the local Windows machine, a SOAP Web API in selected areas, Comarch’s own connectors to its e-commerce, workflow, HR and BI products, and — for most reporting purposes — a direct read on the SQL Server. Full technical documentation goes to authorised Comarch partners rather than being published openly. Comarch ERP XL WEB is the exception and the direction of travel.

Is Comarch Business Intelligence enough? For a single company, Optima’s Analizy BI module and XL’s analytical reports do real work, and Comarch BI Point goes further. Comarch has been building BI alongside its ERP products for the better part of two decades; this is not a token add-on. Where it runs out is where every vendor’s BI runs out: across companies and across systems, where you need group definitions, reconciliation against non-Comarch sources, and a governed data layer an AI assistant can query without inventing an answer. If Comarch is your only system and one company is your whole business, start there. On AI: Comarch ships ChatERP, an assistant inside Optima, XL and Enterprise — in beta, built with an emphasis on Polish-language models, able to answer procedural questions and execute actions like issuing an order. That is a useful surface for operating the system. It is not a ruling on meaning: ChatERP works one installation’s data, no MCP endpoint is published for either product, and the definitions a group answer depends on live above both — why AI fails on raw ERP data .

Official Comarch resources

• Product overviews — Comarch ERP Optima · Comarch ERP XL
• Knowledge bases (Baza Wiedzy) — Optima · XL · Optima in Comarch Cloud
• Optima hardware and software requirements
• KSeF in Comarch ERP systems
• Comarch ERP Optima for accounting offices
• Comarch Business Intelligence

Onetribe is not a Comarch partner or reseller. We build the governed data layer above your ERP, whichever ERP that is.

Next steps

• Every source system we connect — the series hub, with the full matrix
• How we consolidate any combination of ERPs — group reporting
• Why your ERP doesn’t govern your data — the cross-system layer, in detail
• Discuss your Comarch estate — free assessment