Shop-to-ERP integration: Magento, BaseLinker and Comarch

An order lands in the shop, someone retypes it into the ERP, the warehouse ships the goods, and the stock level in the shop updates "whenever someone finds a moment". With a few orders a day it is merely annoying. With several sales channels, marketplaces and B2B customers it ends in selling goods that are not there and invoices corrected by hand.

This guide is for e-commerce managers, shop owners and wholesalers with online sales. We explain what should flow in which direction, how the three integration models differ, what to watch for in Magento and BaseLinker, what KSeF (Poland's National e-Invoicing System) changes and which questions to ask an integrator vendor.

A map of flows: what flows in which direction

In short: the shop and marketplaces are the source of orders, the ERP is the source of stock levels, prices and documents. Before you choose a tool, write out every object with its direction and master system.

From the shop and marketplaces to the ERP

• Orders with lines, discounts, delivery cost and payment method.
• Customers: invoice data, tax ID (NIP), delivery address. The key is to look up an existing counterparty in the ERP by tax ID or email instead of creating a new one with every order.
• Payments: information that the order is paid, with a transaction identifier. Without it the finance department reconciles payments by hand.

From the ERP to the shop

• Stock levels: from the warehouses assigned to the channel. Available stock (physical minus reservations) is right for channels that have no reservations of their own, e.g. a hub or a feed. To Magento with Inventory Management you send the physical stock of the source, and from the ERP you subtract only the reservations from other channels (details below).
• Prices and price lists: list price, promotions, prices for B2B customer groups.
• Statuses: accepted, in progress, shipped, cancelled, and also the parcel number.
• Documents: an invoice or a receipt, corrections, sometimes a goods issue document.

A source of truth for every object

The most common cause of problems lies not in the technology but in the same object being edited in two places. A price changed in the shop's panel is overwritten at the next synchronization from the ERP, and a description corrected in the ERP overwrites a better description from the shop. Write down in one table: product (register), description and photos, stock, price, customer, order, document. For each, name the master system and block editing in the others.

Three integration models

In short: a ready-made integrator is the quickest start with a typical process. A hub (e.g. BaseLinker) organizes many sales channels, but an integrator still connects it to the ERP. A custom integration gives full control where the standard ends.

A ready-made integrator

A program or service for a specific pair: shop–ERP or BaseLinker–ERP. For BaseLinker, integrations with ERP programs such as Comarch ERP XL and Comarch Optima are supplied by third-party companies (on the XL integration page Base.com notes that it does not create its own integrators of this kind). Responsibility for operation, updates and support therefore lies with the integrator's vendor, not with the platform.

A hub or middleware

BaseLinker collects orders from Allegro, the shop and other marketplaces, and an integrator passes them to the ERP. It is a good solution when there are many channels and the ERP is to accept orders from only one place.

Your own hub on n8n or your own service, which accepts webhooks from the shop, queues operations and writes them to the ERP, is in practice a variant of a custom integration. You do not pay an integrator subscription, but you maintain your own workflows, and the queue, retries, protection against duplicates and marketplace handling have to be built yourself.

A custom integration

A connection directly through the ERP API, a database or exchange files. Comarch ERP XL has its own API for this, described in the documentation XL017 – Using the ERP XL API, through which documents are created in line with the program's logic, rather than by writing directly into tables.

Magento (Adobe Commerce) and the ERP: specifics

In short: in Magento you have to distinguish physical stock in sources from the quantity salable. The ERP should update the sources, and bulk operations are worth sending asynchronously.

Many warehouses, reservations and B2B prices

The Inventory Management module in Magento splits inventory into sources (warehouses, points) and stocks assigned to sales channels (Stocks and sources). Magento calculates the salable quantity itself: it adds up quantities from the sources and subtracts reservations from unshipped orders (Source algorithms and reservations). A typical mistake: the integrator sends Magento a stock level already reduced by reservations from the ERP, and Magento subtracts its own reservations a second time. So decide which reservations the ERP counts and which the shop does: send Magento the physical stock of the source, and from the ERP subtract only reservations from other channels, not from this shop's orders.

B2B prices are a separate topic. Adobe Commerce with the B2B module has shared catalogs with prices for specific companies (Shared catalog overview). If individual prices are calculated in the ERP, moving every customer–product combination to the shop quickly stops paying off. Then a separate B2B portal that asks the price system directly often works better. We write about this in the guide a B2B portal for wholesalers: a ready-made platform or a custom portal?

Queues instead of "live at all costs" synchronization

The Magento REST API has asynchronous and bulk endpoints: a request goes to a message queue, gets an identifier, and a consumer processes it in turn. For thousands of price and stock changes it is better than a series of single calls. The same rule applies in the other direction: an order that cannot be written to the ERP at a given moment should wait in a queue with a retry, not disappear with an error in a log.

BaseLinker with Comarch ERP XL, Optima and Subiekt

In short: BaseLinker is connected to Comarch ERP XL and Optima by third-party integrators. For Subiekt GT and nexo, Base.com has its own tool, Base Bridge. In every case check not only orders and stock levels, but also documents, corrections and returns.

What integrators usually handle, and what to look for

The integration pages in the Base.com catalogue usually list importing orders into the ERP, synchronizing stock levels, prices and product data, and creating sales documents. For Subiekt, Base.com provides Base Bridge within the subscription, and third-party integrators work alongside it (Subiekt nexo PRO). The differences between vendors show up in the details:

• whether a correction and a return in BaseLinker create a correction in the ERP, or whether it has to be issued by hand,
• whether the integrator recognizes an existing counterparty by tax ID,
• how it maps payment methods, delivery methods and VAT rates,
• what it does with rounding differences when the shop calculates from gross prices and the ERP from net,
• whether it passes the parcel number and the payment information to the ERP.

Allegro, InPost and payments in one flow

The biggest benefit of a hub appears when an Allegro order, an InPost label and a payment status come together in one record. The condition: the ERP must get the order with a source identifier, so that an Allegro return can be linked to the right document rather than searched for by the customer's surname.

KSeF in e-commerce

In short: invoices for businesses with a tax ID are issued in KSeF, and for consumers it is voluntary. The most important technical decision: which one system sends invoices to KSeF.

Sales invoices: B2B and consumers

Since 1 February 2026 invoices in KSeF have been issued by companies with sales above PLN 200 million in 2024, and since 1 April 2026 by the other taxpayers (MoF: implementation stages). Until 31 December 2026 taxpayers whose sales documented by invoices do not exceed PLN 10,000 gross per month may invoice outside KSeF. Invoices from cash registers and receipts with a tax ID up to PLN 450 may also still be created outside KSeF (MoF: below PLN 10,000). According to the Ministry of Finance, issuing invoices for consumers in KSeF is voluntary (Consumers and individuals).

In practice the shop has to collect the tax ID and company data reliably at the order, because they decide whether the invoice has to go to KSeF. An "invoice" document in the shop's panel is usually a record in the shop, not an e-invoice. It is sent to KSeF by the system that issues it: the ERP, an invoicing program or BaseLinker.

Many shops send business customers a PDF invoice from the shop module or in an email. For a buyer with a tax ID the invoice is the document in KSeF, and a copy passed outside KSeF must be a visualization with a QR verification code and the KSeF number. The "invoice" template in Magento or WooCommerce therefore has to be switched off for customers with a tax ID, or replaced with a document from the ERP or BaseLinker.

According to Base.com help, the BaseLinker integration with KSeF (as of October 2026) sends only documents issued in Base.com, handles ordinary invoices and corrections (advance, final and VAT-margin invoices are announced as "coming soon") and does not fetch cost invoices. Base.com also asks you to use a single sending channel so that invoices do not get duplicated in KSeF. If the ERP issues the invoices, sending from BaseLinker should be switched off.

Purchase invoices from suppliers and wholesalers

Since 1 February 2026 every company receives supplier invoices from KSeF. Since they arrive as structured data anyway, they can be matched automatically to purchase orders and goods receipts. We describe how in our KSeF integration with Comarch ERP XL.

A checklist before choosing an integration

In short: before you sign a contract, ask the vendor for a test on your data and for answers to the questions below in writing.

Orders and customers

1. How often do orders reach the ERP and can it be sped up for selected channels?
2. What happens when the ERP is unavailable for an hour?
3. How do you protect against the same order being written twice?
4. How do you recognize an existing counterparty (tax ID, email, both)?
5. How do you map payment methods, deliveries and VAT rates?
6. What about discounts on the whole order and rounding differences?

Stock levels and prices

7. Which reservations do you subtract from stock and does the shop not subtract them a second time?
8. From which warehouses, and can they be assigned to channels separately?
9. How often do you update stock levels and only those that changed?
10. Do you support prices for customer groups and B2B price lists?
11. Which system is the master for products, and which for descriptions and photos?

Documents and KSeF

12. Which documents are created in the ERP: an invoice, a receipt, a goods issue, an order?
13. Do corrections and returns create documents automatically?
14. Which system sends invoices to KSeF and how does the KSeF number return to the order?
15. Do the parcel number and status go back to the shop and the marketplace?

Maintenance

16. Where are synchronization errors visible and who gets the notification?
17. Can a single operation be retried without a service intervention?
18. How quickly do you support a new version of the ERP, the shop or a marketplace API?
19. Is there a test environment and a change log for every operation?
20. What happens to the data and configuration when we cancel the service?

When to go for a custom integration

In short: when to the questions from the checklist you most often hear "no" or "needs a workaround", and the workarounds are performed by hand by someone every day.

Typical signals: individual prices and terms for B2B customers, several warehouses and branches with different reservation rules, non-standard documents in the ERP, a need to send stock levels to partners and comparison sites, and also a situation in which the integrator works, but nobody knows what to do when something gets stuck.

What we use of this in Business Panel

Our Business Panel, deployed in a company from the wholesale industry, works on data from Comarch ERP XL and the B2B platform:

• data from XL is synchronized to the panel's database cyclically, every few minutes, so the team's work does not load the ERP with every query,
• product feeds (Google XML and CSV for partners) get available stock from XL: stock from selected warehouses minus active reservations, with products matched by code and EAN,
• every feed generation stays in the history, with the number of matched and unmatched lines and stock changes against the previous run,
• the panel is connected to the B2B e-commerce platform (orders, customers, catalogue) and receives events from other systems through webhooks,
• purchase documents are created in XL with a retry queue, so a brief failure of the connection to the ERP does not lose operations.

Sales orders are fulfilled by the B2B platform and the ERP. The panel does not retype them and does not issue sales invoices.

We know shops on Magento, WooCommerce, Shopify and PrestaShop, and BaseLinker, Allegro and InPost, from deployments for clients. The full list of systems is on the technologies and integrations page. If in your case the integration is also meant to relieve the team of manual handling of orders and email, take a look at AI automation, and if you are starting with KSeF, at the KSeF integration with Comarch.

Have a question about your case? Write to us. We start with a free consultation.