Interfaces between store, ERP and line-of-business systems —
enter data once.
Shopware, Shopify, WooCommerce, Ecwid — connected to SAP, Odoo, Business Central, Abacus, Clarity or Avista. Through n8n, Alumio or an interface of our own.
In most companies several systems run side by side that ought to know about each other: a store, an inventory system, accounting, perhaps a point of sale or a line-of-business application. As long as the transfer happens by hand, it costs time and produces discrepancies. We build the connections in between — with ready-made tools where they fit, and with development of our own where they do not.
Every manual transfer is an error waiting for its date.
System landscapes that have grown over time were rarely planned. A shop was added, then a warehouse system, then industry applications — and in between are people typing data from one screen into the next. That costs time, produces errors and makes reporting unreliable, because nobody knows which figure is the right one.
Clean systems integration makes the systems talk, and solves three things at once: the effort drops, the data quality rises, and for the first time you see in real time how your business is actually running.
Interfaces between your systems
We make ERP, shop, warehouse, shipping and accounting talk to each other — bidirectional, logged and traceable. Articles, stock levels, prices, orders and documents flow automatically, in the direction and at the pace your business needs.
Processes without manual steps in between
Recurring routines run without intervention: triggering orders, filing documents, sending notifications, reconciling data. What three people handle on the side today runs in the background afterwards — and only talks back when something is wrong.
Data migration when a system is replaced
When a system is replaced, the data migration decides between success and standstill. We clean, transfer and verify — with test runs before anything is switched over in production.
Entries that arise by themselves
In many companies, accounting entries are keyed into the accounting system by hand: from the online shop, from the payment provider, from payroll. The same steps every month, the same sources of error every month.
The posting rules come from you or from your fiduciary — that is where they belong. We turn them into an automation that applies them reliably, and into a control that shows every entry has arrived. Anything that is not unambiguous is held back and reported, rather than posted wrongly.
We are IT, not a fiduciary. Professional responsibility for the bookkeeping stays where it is.
We choose the tool to suit the project.
Taking stock
Which systems are in use, which data goes where, and where is the gap bridged by hand today? The result is an overview of your landscape — often the first one that exists at all.
Target picture and priority
Not everything has to be connected. Together we determine which connection saves the most effort, and start there.
Delivery in stages
Each interface is built, tested and put into production on its own. You see the first benefit after a few weeks instead of waiting months for a single overall result.
Operation and monitoring
Failures are logged and reported, not silently passed over. You receive documentation another supplier could carry on with.
E-commerce middleware for BlueBioTech International —
orders without manual entry.
01 · Starting point
The online shop and the existing systems worked without automated synchronisation — articles, stock levels and orders had to be carried across by hand.
02 · Delivery
Implementation of e-commerce middleware connecting the online shop to the existing systems — with automated synchronisation of articles, stock levels and orders.
03 · Result
Orders reach order processing without manual entry — stock levels in the shop are current.
Software development: applications of your own where the standard falls short
Not every task can be solved with a finished product. Sometimes the function is missing, sometimes the fit is wrong, and sometimes going through three tools costs more than one application that does exactly one thing.
What we build here: line-of-business applications for processes that do not exist as a product. Tools that automate a calculation or a check. Interfaces between systems that have no ready-made connection. And reports that bring figures from several systems together.
The tools on this website are our own: the integration check, the project risk assessment, the accessibility check and visitor identification. They show the form we work in: as a web application, on our own infrastructure, with no service in between reading the data.
And if it should be an app? A great deal of what is conceived as an app can be built as a web application: it runs in the phone’s browser, can be added to the home screen and needs no store. Where an app in the store really is necessary, we say so — and we also say when it is not our job.
n8n self-hosted: setup and operation
n8n is an open tool for automating processes between systems — without writing a separate program for every connection. There is a hosted edition from the vendor, and the option of running it yourself.
We run n8n self-hosted, and we set it up that way for clients too. That makes sense when data flows through those processes that should not leave the house: customer records, prices, orders, personnel data.
What belongs to it: setup on your own infrastructure, securing access, backup and restore, updates, and building the processes themselves. Along with monitoring that reports when a process stops — because a silent failure is otherwise noticed only once data is missing.
On the location, without evasion: we run self-hosted on our own infrastructure with a European provider, without US hyperscalers. The data centres are in Germany and Finland, not in Switzerland. For most requirements under the revised Swiss data protection act, that is sufficient. If your own rules require a location in Switzerland, say so in the first conversation — then we plan for it from the start.
AI phone assistant
A phone assistant takes calls, understands what the caller wants and handles the simple part itself — making an appointment, giving information, taking a message for a call back. What it cannot resolve, it passes on.
Technically, three things belong together: a telephone connection, speech recognition and synthesis, and a connection to the system that holds the answer — usually a calendar or a customer database. For callers in Switzerland there is one more condition: spoken Swiss German has to be understood reliably. That is the demanding part, and it decides whether such an assistant is accepted in daily use.
We build applications of this kind on open components and on our own infrastructure, so that the content of conversations does not sit with a third party.
What integration projects settle first.
What an interface would roughly cost in your case, and from when it pays for itself, you can work out in a few minutes with the integration check.
What does an interface cost?
That depends above all on how well the systems involved come with documented interfaces. A standard connection between two modern systems is manageable; a legacy application without an API is effort. After taking stock you receive a dependable estimate. We give a first indication in conversation.
Do we have to replace our existing system?
As a rule, no. Integration means precisely that: connecting existing systems instead of replacing them. We recommend a replacement when it pays for itself.
Where does our data run?
On request entirely in Switzerland or in your own data centre. For public administration and regulated industries in particular this is often the decisive question — we settle it at the start, not at the end.
What happens if an interface fails?
Errors are detected, logged and reported; transfers are repeated rather than lost. You hear about a problem before your customer does.
Will we depend on you afterwards?
No, and that is deliberate. Everything is documented, the credentials are yours, and we use widely used tools rather than a special construction only we can maintain.
What is middleware — and when do we need it?
Middleware is an intermediate layer between two systems that translates data, holds it temporarily and monitors its transfer. It makes sure an order reaches the ERP even if the ERP was unreachable at the moment the order was placed.
It becomes necessary as soon as more than two systems are involved, as soon as the systems work to different rhythms — orders immediately, stock levels hourly — or as soon as it has to remain traceable which record was transferred when. With exactly two systems, documented interfaces and a manageable volume, a direct connection is enough; it is cheaper to build and to run.
What is missing without middleware is the retry. If a transfer fails, the record is lost, and nobody notices until a customer complains. We build this intermediate layer with Alumio, n8n or as a bespoke solution — most recently for BlueBioTech International, where orders have since been arriving in the ERP without manual entry.
How do you connect an online shop to SAP?
Through the interfaces SAP already brings with it: OData services on newer systems, IDocs and BAPIs on older ones. Which of them are available depends on the release and the modules — that is the first question in the project, not the last.
The shop does not address SAP directly. In between sits a middleware that translates formats, repeats failed transfers and records what was transferred when. Before the technology, though, comes data ownership: SAP usually holds articles, prices, stock levels and customer master data, while orders, baskets and shop accounts arise in the shop. Every departure from that belongs in writing, otherwise the systems overwrite one another.
From experience: the interface itself is rarely the problem. It becomes laborious with article variants, price tiers and VAT rules that are modelled differently in SAP than in the shop. Clarifying those three points early saves half the project time. We delivered this route for Held AG — from the choice of systems through to go-live.
Alumio, n8n or a bespoke interface — what is right when?
Alumio is an integration platform with ready-made connectors. It pays off when several systems stay connected permanently, when transfers are to be adjusted without programming, and when monitoring and retries have to come included. The price for that is ongoing licence costs.
n8n is an automation tool that can be run in-house. It fits when processes change often, when steps beyond the data transfer are involved — notifications, approvals, reports — and when the data is not to leave your own data centre. The price is operating effort instead of a licence. A bespoke interface, finally, is right when it stays with two systems, the data model is stable, and volume or response times argue against an intermediate layer — full control with full responsibility.
The most common wrong decision is the platform for the two-system case: licence and training then cost more than the interface would ever have cost. We work with all three routes and decide by the undertaking, not by the tool.
Are there Swiss providers that deliver ERP and online shop from a single source?
Yes, though few. The division of labour in the market usually runs differently: agencies build the shop, ERP partners look after the ERP, and the interface in between belongs to nobody. That is exactly where the delays arise, and exactly where each side points at the other when something goes wrong.
What to look for when choosing: does the provider take responsibility for both sides itself, or does it only broker? Do you get the interface handed over documented, together with access and source code? Can you carry the operation on later without them, or hand it to someone else? And are there references with the same ERP — not only with the same shop software? A provider that answers the third question evasively is building a dependency, not a solution.
om3 from Zurich works this way: ERP integration and shop from a single source, documented handover, no obligation to stay. Delivered for Juwelier Bockholt, Spyk Bänder and Held AG, among others.
What does an API interface cost?
The effort depends on how many data objects run in which direction, how well the systems involved are documented, and whether legacy data is migrated. After an initial review you receive a quotation for the specific project.
Which systems should come together at your organisation?
Describe your landscape briefly — we tell you what can be connected and where the effort lies.
Discuss an interface or an AI application→