Picture a Monday morning in a growing online store. The warehouse worker releases goods that the system shows as available – except that the last unit went out to a different customer back on Saturday. The accountant manually retypes order numbers from Baselinker into the invoicing program. And the sales rep keeps refreshing his inbox, because a customer is asking about an invoice nobody has issued yet. Every one of these people is working conscientiously. And the company still loses money, nerves and reputation. The problem is not the people. The problem is that data travels between systems by copy and paste. A well-designed integration of an online store with Baselinker and an ERP removes this hidden tax on growth, turning manual retyping into a predictable, automatic flow of information. I will show you here how to genuinely automate sales, warehousing and invoicing – from the perspective of someone who designs such rollouts and then maintains them.
Spis treści
Why retyping orders by hand is a hidden cost in e-commerce
The scenario we meet at clients who come to us for an integration is surprisingly repetitive. A store on WooCommerce, PrestaShop or Shoper lives to its own rhythm, Baselinker handles orders and shipments, and the ERP – say Subiekt GT, enova365, Comarch ERP Optima or WAPRO – looks after the warehouse and the accounts. Each of these systems does its own job well. Only nobody designed the bridges between them. And the bridge ends up being a human being who retypes the same data from one window into another several times a day. As long as there are a dozen or so orders a day, it somehow works. The trouble starts exactly when business is going well.
Manual retyping is not a cost you will see in an expense report. There is no invoice for it and no separate budget line. It shows up only in its consequences, and those can be painful. The most expensive are incorrect stock levels, because they lead straight to selling the same last unit twice. The customer places an order, gets a confirmation, and two days later an email with apologies and a refund. In the world of marketplaces such a slip-up is not just lost margin, but also a lower seller rating on Allegro or Amazon – and that hits the visibility of your listings directly.
The second silent cost? Delayed invoices. When a sales document is created manually and with a delay, cash flow suffers and accounting turns into fire-fighting at the end of the month. On top of that come complaints caused by mismatched data: a different address on the courier label than on the invoice, a quantity that does not match, the wrong VAT rate. Every such small mistake eats up the time of a team that could be developing the offer, and instead is straightening out the consequences of a typo.
From a contractor’s point of view, though, something else is the most interesting – where the bottlenecks really form. Because they rarely sit where the company first looks for them. The order – warehouse – accounting process has several critical contact points where data has to change owner. And it is exactly at those boundaries that information gets lost. The classic points of friction are:
- Receiving the order – the moment when data from the store’s cart has to reach the management system, with the product, the price and the invoicing details correctly assigned.
- Reserving and releasing goods – this is where stock levels drift apart if the warehouse does not know in real time what has been sold in another channel.
- Change of shipping status – the customer expects a tracking number automatically, not after phoning the office.
- Issuing the sales document – the step from a paid order to an invoice with the correct accounting numbering.
- Handling a return or a correction – the stage most often skipped, even though it generates the most manual work.
But the most important thing is the warning signal that lets you catch the right moment for automation. The time for integration comes when the number of orders grows faster than the support team. If for every additional hundred orders a month you have to add office hours, the model stops scaling. Hiring more people to retype data is like pouring water into a leaking bucket. In practice we see that companies which put off integration until full chaos sets in pay more later – both for the rollout itself and for cleaning up the backlog of messy data. The earlier you put the process in order, the cheaper and calmer it is. Automation is therefore not a luxury for the biggest players. It is a natural stage in the maturing of an e-commerce business that wants to grow without inflating its support costs at the same pace.
How the store – Baselinker – ERP integration works on the technical side
To order an integration knowingly, it helps to know what happens under the hood. In this puzzle Baselinker plays the role of the middle layer – a kind of operational hub for e-commerce. It is where orders from different sources meet: your own store, Allegro, Amazon, eBay, other marketplaces. Baselinker manages orders, keeps its own product warehouse, handles statuses, generates courier labels and talks to shipping systems. Thanks to that, you do not have to build separate bridges to every channel individually – we integrate with one standardized platform that collects traffic from many places. That is an enormous saving in complexity on the implementation side.
The key is to understand the directions in which data flows, because an integration is not one stream but several independent tracks – each with its own rules. Products and current stock levels usually flow from the ERP towards Baselinker and the store, because it is the accounting and warehouse core of the company that knows best how much of what is really sitting on the shelf. Orders go the other way – they are born in the store or on a marketplace, are aggregated in Baselinker, and from there reach the ERP as documents to be fulfilled. Invoices and sales documents, in turn, are created in the ERP, because it is responsible for numbering, regulatory compliance and accounting records. Their numbers or PDF files then come back to Baselinker and to the customer.
The way this data travels matters enormously for the quality of the whole solution. A modern integration is based on communication via REST-style APIs, on webhooks and on task queues. This approach replaces the old, heavy cyclical synchronizations that fired every quarter of an hour and ground through the entire product database regardless of whether anything had changed. A webhook works the other way round, and more intelligently: the system reports a specific event exactly when it happens. A new paid order has appeared – a notification goes out. A product’s stock level has changed – an update goes out. The data is fresher and the load on APIs and servers is many times lower.
In project practice we rarely rely on webhooks alone. We combine them with task queues that buffer events and process them at a controlled pace. Such a buffer saves the day when a wave of orders suddenly arrives during a promotional campaign, or when one of the systems temporarily stops responding. Events wait in the queue, the integration works through them one by one, retrying in case of an error. On top of that comes a periodic, lightweight control synchronization that every now and then compares stock levels and catches any drift. A safety belt in case a webhook goes missing.
The most important decision to make right at the start concerns the notion of a single source of truth. It is about unambiguously establishing which system owns a given type of data and has the right to change it. And this is not an invention of the e-commerce industry – it is a fundamental pattern of software architecture. The application architecture documentation describes it like this:
“When a new data type is defined in your app, assign a single source of truth (SSOT) to it. The SSOT is the owner of that data, and only the SSOT can modify or mutate it.”
Translated into our world, this means very concrete decisions. Who owns the stock level – the ERP or Baselinker? Who keeps the master prices and the price list? Where does the customer record and their invoicing data live? Without these decisions an integration turns into a battlefield on which two systems overwrite each other and a product’s stock level jumps back and forth. When we clearly assign an owner to each type of data, we eliminate a whole class of errors before they even arise. The source quoted above lists the benefits of this approach directly:
“Centralizes all changes to a particular type of data in one place. Protects the data so that other types cannot tamper with it. Makes changes to the data more traceable, so bugs are easier to spot.”
Those three sentences explain beautifully why a well-arranged integration is not only faster, but also easier to diagnose. When something goes wrong, you know where to look for the cause, because every change has one owner and one trace. That is the difference between a system you can maintain for years and one that after six months becomes a black box nobody wants to open.
What can be automated: sales, warehouse and invoices step by step
Let us move from architecture to specifics, because it is the specifics that determine the return on investment. The scope of automation is wide, but it is better to break it down into individual, tangible actions that a person used to perform. A well-designed flow covers the entire life cycle of an order – from the customer’s click all the way to the document in accounting. Here is the list of processes we genuinely take off the team’s shoulders:
- Importing orders – every order from the store and the marketplaces lands automatically in Baselinker and the ERP, with products correctly matched by SKU and with the customer’s data.
- Reserving stock – goods are blocked for a given order the moment it is created, so they cannot be sold a second time.
- Updating shipping statuses – the dispatch, the tracking number and the fulfilment status come back to the store and to the customer without any human involvement.
- Generating invoices – the sales document is created in the ERP on the basis of a paid order, preserving the continuity of numbering.
- Sending documents to the customer – the invoice as a PDF goes out by email automatically, right after it is issued.
What usually raises the most emotion is automatic invoicing, because it touches the sensitive area of accounting. The trick here is to tie the issuing of the document to a specific business event – most often to the order being paid. Until the payment arrives, no invoice is created. That way we do not produce documents for orders that will never be fulfilled. Numbering that complies with the company’s accounting policy matters just as much. Invoices have to preserve the continuity and the order required by the regulations, which is why we always leave their numbering to the ERP system – it was built for that. The integration only triggers the process and passes the data, but the owner of the number remains the ERP. That is another application of the single source of truth principle.
The second pillar is two-way synchronization of stock levels. It sounds simple. Except that this is exactly where most of the subtleties hide. Stock has to flow from the ERP to the sales channels so that a customer does not buy something that physically is not there. And at the same time information about a sale has to come back, to remove the goods from availability in all places at once. When this circuit runs smoothly, the phenomenon of phantom sales disappears – that is, taking orders for products that ran out a second earlier in another channel. This protects the seller rating and spares the team a round of explanations to customers.
Tip: if you sell the same products on several marketplaces at once, set a safety buffer on stock levels. Showing a level a few units lower than the real one in every channel gives you a margin for synchronization delays and drastically lowers the risk of a double sale during peak hours.
The area that almost always slips through at the quoting stage is the handling of unusual situations. Returns, invoice corrections and working with several warehouses are not a margin. They are the daily reality of a mature e-commerce business. A return requires reversing the stock level, issuing a correction and recording the whole thing in the accounts. An invoice correction has to preserve its link to the original document and the consistency of numbering. Several warehouses, in turn, mean you have to decide which location a shipment is fulfilled from and how to split stock between locations. If the contractor does not include these cases in the analysis, the client gets an integration that handles the happy path beautifully and falls over at the first return.
Our experience yields a simple truth: the value of an integration is measured not by how it handles a typical order, but by how it copes with exceptions. That is why, during the analysis stage, we always break business processes down into their elements and ask about edge cases before writing the first line of code. This lets us quote the project honestly and avoid a situation in which the budget grows during the rollout, because it suddenly turns out that returns have to be handled after all.
Architectural decisions and risks you cannot see at the start of a project
Every integration looks similar on paper: connect two systems, pass data, done. The devil, as usual, is in the details – and most of them only reveal themselves during the first real production traffic. The most serious and most often underestimated challenge is data mapping. The store, Baselinker and the ERP speak different languages, even when they describe the same things. A product SKU may have a different format in each system, units of measure do not always match, and VAT rates are sometimes recorded in several ways. Add to that order statuses that are named differently in one system than in another. Most implementation errors are born precisely at this stage of translating one dictionary into another.
Mapping is not a one-off table you fill in within an hour. It is a living part of the system that has to be designed with change in mind. A new VAT rate will appear, a new product category will be added, the way variants are encoded will change – and the mapping has to survive all of that without rewriting the code. That is why in our rollouts we keep mapping rules in configuration rather than hard-coded. Changing a tax rate or adding a warehouse is then a matter of editing settings, not of another development cycle.
The second risk, invisible to the buyer but fundamental to reliability, is idempotency and duplicate handling. In the world of webhooks and queues you have to assume that the same event may arrive twice. Networks can be unreliable, systems retry, and a notification about an order can come through in duplicate. If the integration reacts naively, two invoices for the same order will be created, or goods will be taken off stock twice. Idempotency means that no matter how many times the same event arrives, the effect is a single one. We achieve it by identifying events with a unique key and checking whether a given order has already been processed before we perform any operation.
Tip: whenever you receive an event, record its unique identifier together with its processing status. Before you create an invoice or update stock, check whether that identifier already exists. This one simple rule protects you against a whole family of errors caused by duplicate notifications.
The third area is working within the limits imposed by external systems. Both the Baselinker API and the interfaces of ERP systems have their own request limits. Exceed them and requests will be rejected, and as a result you will lose data if the integration is not prepared for it. A professional solution therefore assumes a retry mechanism with a sensible interval, queueing of requests at a pace consistent with the limits, and full event logging. Because logs are the first place we reach for when a client reports a problem. Without them, diagnosis turns into guesswork and fixing a failure takes hours instead of minutes.
The fourth pillar, which must not be treated as an afterthought, is security. An integration operates on API keys that give access to the heart of the company and on customers’ personal data. Keys must not sit in the code or in the repository – we store them in secure secret vaults, with access control and the option to rotate them. Personal data is subject to the GDPR, which means specific obligations: minimizing the information collected, controlling who has access to it, and making conscious decisions about where and for how long data is stored. Logs, which we praise so highly for their usefulness in diagnostics, also have to be designed sensibly, so that they do not record customers’ sensitive data in readable form. This is not an add-on to the project, but an integral part of it. Skipping these issues creates legal and reputational risk that many times exceeds the cost of designing the safeguards correctly from the start.
Typical implementation mistakes and the cost of maintaining an integration
After years of working on integrations we can see that companies make surprisingly repetitive mistakes. We have gathered the most common ones, because awareness of the traps is the cheapest way to avoid them. Here is a list of the typical sins we observe in rollouts done in a hurry or by contractors without e-commerce experience:
- No mapping of VAT rates – invoices go out with the wrong tax, which generates corrections and accounting problems.
- Ignoring returns and corrections – the integration handles sales only, and the entire returns process stays on people’s shoulders.
- No monitoring – nobody knows the integration has stopped working until an aggrieved customer calls.
- Hard-coded identifiers – warehouse, status or category IDs written rigidly into the code, which fall apart with every change.
- No test environment – every change lands straight in production, so errors hit real customers and real invoices.
Each of these points has a common denominator: it comes from thinking about an integration as a one-off project you do once and forget. And that is the biggest misunderstanding in this whole field. An integration is a living organism that has to keep up with a changing environment. The Baselinker API evolves, new versions and new methods appear. New sales channels show up that the company wants to connect. The ERP receives updates that sometimes change the way key functions behave. Each of these events can disturb a data flow that has worked until now. An integration that nobody looks after will sooner or later stop working – and it usually happens at the least convenient moment.
This brings us to the real breakdown of costs, which is worth discussing honestly already at the quoting stage. The cost of an integration has two components: implementation and maintenance. Implementation is one-off and visible, so it draws all the attention. Maintenance is spread over time and less spectacular, but it is what decides whether the integration will serve for years or become a source of constant crises. Maintenance covers monitoring, responding to changes in APIs, small corrections and, above all, a system of alerts. The difference between a mature and an immature integration comes down to one question: do you learn about a failure from an automatic alert, or from a customer’s phone call on Friday afternoon?
Monitoring and alerts turn a reactive situation into a proactive one. Instead of a message saying “the integration stopped working on Friday” that reaches the company on Monday together with a wave of complaints, the team gets a notification the moment something starts to go wrong. The number of processed orders has fallen below the expected threshold, the queue of failed attempts is growing, the API is starting to return errors – it is worth knowing about each of these signals immediately. An early warning lets you fix the problem before customers feel it. It is precisely this invisible layer that separates a professional integration from a makeshift one that works as long as the sun is shining.
I will close this section with three practical pointers for anyone commissioning an integration who does not want to be disappointed. Treat them as minimum requirements towards the contractor – regardless of who ends up delivering the project:
- Demand logs – without a full record of events, diagnosing a failure is guesswork. Logs are your insurance for the hard days.
- Demand a test environment – changes have to be verifiable without risk to real orders and real invoices. No sandbox means asking for trouble.
- Demand documentation of the data mapping – a list of how the fields of one system correspond to the fields of another is the map that lets the next contractor understand the rollout at all.
These three demands cost nothing at the agreement stage, and they can save enormous amounts of money and nerves in the future. A contractor who drags their feet over meeting them is signalling that they are either doing an integration for the first time or do not plan to stay with the client for long. Either one should switch on a warning light.
FAQ – the most common questions about Baselinker and ERP integration
We have gathered the two questions clients ask us most often before they decide on a project. We answer them the same way we would at a first meeting – without beating about the bush and without promising the impossible.
Does integrating Baselinker with an ERP fully eliminate manual handling of orders and invoices?
In the vast majority of cases yes, although an honest answer requires one caveat. A well-designed integration automates the entire happy path – that is, a typical order from placement, through stock reservation and shipping, all the way to issuing and sending the invoice. Here human involvement drops practically to zero, and the team supervises instead of retyping data. The human element remains where a business decision is needed: an unusual return, a complaint that requires negotiation, an order with incorrect customer details that has to be clarified. This is not manual handling in the old sense, though, but conscious control over exceptions. The goal of an integration is not to make people redundant, but to shift their attention from monotonous retyping to tasks that genuinely require human judgement. The company gains the ability to handle many times more orders without a proportional growth of the team.
How long does it take, and what determines the cost of integrating a store with Baselinker and an ERP?
There is no single honest answer in the form of a specific figure, because the cost and the time depend on several measurable factors. The most important of them is the ERP system on the client’s side and the quality of its API – some systems have modern, well-documented interfaces, others require workarounds and groundwork. The second factor is the complexity of the processes: the number of warehouses, sales channels and product variants, and whether returns and corrections have to be handled. The third is the state of the data – a mess in the product records can extend the project more than the programming part itself. A simple integration of one store with one warehouse and basic invoicing is a project of a few weeks. An extensive rollout with many channels, returns and full monitoring takes correspondingly longer. In a conversation we always start with an analysis of the processes, because only that allows us to give a reliable quote instead of a number plucked from thin air. And remember: a cheaper offer that skips the edge cases usually turns out to be more expensive to maintain.
Summary and when it is worth handing the integration to a contractor
Let us go back to the Monday morning from the beginning of this article. After a well-executed integration it looks completely different. The goods released from the warehouse are the ones the system really shows as available. The invoice is waiting in the customer’s inbox before they have a chance to ask about it. The accountant is doing analysis instead of retyping numbers. Automating sales, warehousing and invoicing pays for itself in two ways at once – through the time the team gets back, which it can spend on growth, and through a radical reduction in the number of costly errors. This is not a saving you have to imagine. You can see it in a shorter order handling time, in fewer complaints and in a more stable rating on the marketplaces.
Remember, though, what separates an integration done well from a slapdash one. The first is scalable, so it grows along with the business instead of holding it back at the moment of success. It is monitored, so you learn about problems from an alert rather than from a customer. It is resilient to API changes, because it was designed on the assumption that its environment will change. These three qualities do not come from chance or from the cheapest offer. They follow from conscious architectural decisions made right at the start, from experience with edge cases and from treating an integration as a living system rather than a one-off assignment.
At Web Systems we have been working on such projects since 2006. We are a software house from Łódź that designs and delivers web and mobile applications, B2B systems, API integrations, automations, e-commerce solutions and AI-based tools. We treat integrations of online stores with Baselinker and ERP systems not as copying data between windows, but as designing a reliable flow of information that is meant to work for years. We know the real technical, cost and maintenance problems, because we do not only build these systems but also maintain and develop them together with our clients. It is from that perspective that we write about data mapping, idempotency, API limits and security – not from a textbook, but from implementation practice.
If your store is growing faster than your support team, and the data between systems is still joined by a person using copy and paste, this is a good moment to talk. Whether you need a full Baselinker and ERP integration, a lightweight MVP to test the process, the automation of one specific bottleneck, or an AI solution to support customer service – we will gladly help you put the flow of data in order and automate sales, warehousing and invoicing without the chaos. Write to us – we will analyze your process and propose a solution tailored to real needs rather than to a ready-made template.