What an ERP system is, when a small business needs one, what it costs beyond the price list, how bexio fits in, and where implementations go wrong.

An ERP system is usually bought like a program: you compare modules, prices and screenshots. Yet ERP is first and foremost an organisational decision. The decision that sales, the warehouse, purchasing and finance stop keeping their own lists and start writing to a single database, which from then on is the source of truth. The order, the stock level and the invoice become one record seen from three sides, not three copies that somebody reconciles every week.
If that decision makes sense for your company, the software will be found. If it doesn't, the best system in the world won't fix anything.
We write this from a specific position: we don't sell ERP and we don't implement it. We integrate with it — the online shops, forms and applications our clients already have. So we see ERP from a side that isn't in the vendors' brochures: from the side of the data that has to go into it and come out of it. Below: what an ERP system is, when a small business needs one and when it doesn't, and what the things you won't find in the price list cost.
An ERP system (enterprise resource planning) is software in which sales, stock, purchasing, production and finance work from one shared database. When a salesperson takes an order, the warehouse immediately sees the goods reserved, and accounting sees the invoice to come. Nobody copies anything, because everyone is looking at the same record.
That is the core of the answer to "what is ERP", and to the ERP meaning people search for. The rest is the list of modules that typical ERP software is made of:
Not every company needs all of them. A wholesaler can live without production, and a service company without a warehouse. That is why ERP solutions are usually sold by module, and you pay for the ones you use. "ERP program", "ERP software" and "ERP system" mean the same thing in practice — the difference is one of scale, not of idea: a small program for a wholesaler and a system for a group of companies rest on the same principle of one database.
What is an ERP system, then, as a class of software? Calling something "an ERP system" means exactly that: software that connects several areas of the company in one database. Accounting software isn't in that class, because it deals with one area — recording what has already happened, meaning invoices, costs and taxes. ERP starts earlier: with the order, the reservation of goods and the purchasing plan, and accounting receives finished documents from it.
MRP (material requirements planning) means working out what materials are needed: how much raw material to buy, and when, to produce the goods that have been ordered. Historically, ERP grew out of systems like this, and today MRP is usually one of the production modules in a larger system.
A CRM handles the relationship with the customer before and after they buy: enquiries, conversations, quotes, reminders. An ERP handles what happens once the order is placed. We go into the difference in more detail in our article on ERP vs CRM and how to choose a CRM for a small business.
Articles about ERP like to open with an adoption figure. We don't give one for Switzerland, for a simple reason. The survey we would otherwise quote — Eurostat's annual survey of how enterprises use ICT, which measures ERP use by company size and sector — covers the EU member states and a handful of other European countries, but not Switzerland. We found no current official Swiss figure measured the same way, and a number borrowed from another market would sound more precise than it is.
What the surveys that do exist show consistently is a mechanism, and the mechanism travels across borders. ERP is a tool that grows with the company. Among large companies it is close to universal; among small ones, working without an ERP is common, often for good reason. The reason is not that small companies are behind. It is that in a company of eight people, the same person often takes the order, packs the parcel and issues the invoice, so there is nothing to synchronise — the "single database" is one person's head and one program.
The second part of the mechanism: ERP is above all a tool for companies that sell from stock or manufacture. Where every order touches a stock level, a reservation and an invoice, the pressure to have one database appears early. In a service business, where sales and accounting meet once a month over an invoice, it may never appear at all.
What follows from this? Not that a small company "should catch up" with anyone. What follows is a question worth answering honestly: have we reached the point where separate lists cost more than one system would? That is what the next part is about.
A small business needs an ERP when the same information — about an order, goods or a payment — has to be up to date in several places at once, and today somebody keeps it that way by hand. Headcount matters less here than people think. What counts is how many times a day you copy data from one program into another.
These are the signals that show it:
You hold stock, and the numbers don't match. A customer orders goods you no longer have, because sales in the shop, on the phone and through a sales rep don't see the same stock levels. Every quarterly stocktake uncovers differences nobody can explain.
You manufacture. Even simple production needs to know how much material was used, how much is on its way and what has to be bought before the next job. A spreadsheet copes with a few products; with several dozen it starts to lie.
You sell through several channels. An online shop, a marketplace, wholesale, a physical outlet. Each channel has its own orders, but the goods are the same. Without a shared database, somebody copies orders from one system to another or reconciles stock at the end of the day.
Somebody retypes data by hand. The order from an email into the sales program, the invoice from the sales program into accounting, stock levels from a spreadsheet into the shop. Every retyping costs time and is a chance for a mistake, and when that person is on holiday, the process stops.
When accounting software is enough. If you run a service business, hold no stock, and your sales come to a dozen or a few dozen invoices a month, an ERP would be an expensive superstructure over a problem you don't have. Good invoicing and accounting software is enough — ideally one that creates and reads QR-bills and connects to your bank through e-banking. The QR-bill has fully replaced the old Swiss payment slips since 1 October 2022, and its QR code carries all the payment information in digital form. For a small company that is the first structured document in everyday use: software that reads it can record a supplier's invoice and match the payment without anyone retyping the reference, and part of the work disappears by itself. How to make use of that is covered in our article on business process automation. For customer conversations add a CRM, and for the rest, individual tools.
Between accounting software and a full ERP there is an intermediate step that is easy to forget: trading and inventory software. It handles sales, stock and invoices, while the bookkeeping is done by an external accountant in their own program, which the documents reach by export. For many small shops and wholesalers, that is enough for years. It is worth moving to a full system only once production, several warehouses or several sales channels are in play, all needing to see the same stock at the same moment.
If you recognise one signal, it is usually enough to sort out that one area. If you recognise two or three — and they concern goods that pass through sales, the warehouse and accounting — this is exactly the moment when ERP for small business stops being overkill.
Does a small business need an ERP — a decision tree
Digital Vantage
Anyone looking for an ERP faces a choice that vendors rarely spell out. You can buy one system with modules — sales, stock, accounting and HR from one vendor, on one database. Or you can put together a set of separate programs — accounting, a CRM, an inventory program, an online shop — each the best at its own job, joined by integrations.
On the market, three groups of products are easy to tell apart. We don't rank them, because the choice is decided by your process, not by the brand:
One system gives the most where the areas are tightly interwoven: an order reserves goods, a dispatch from the warehouse creates an invoice, the invoice goes straight into receivables. Nothing needs synchronising, because there is nothing to synchronise — the data sits in one place. The price is a compromise: the CRM module in an ERP is rarely as convenient as a separate CRM, and an online shop from an ERP vendor is rarely as flexible as a dedicated e-commerce platform.
Connected modules give freedom: each department works in a tool suited to it, and replacing one doesn't mean replacing everything. The price is integrations. Every connection has to be built, tested and maintained, and when one program changes the way it exchanges data, the connection has to be fixed. We know this side of the bill from our own work: in our online shop calculator, ERP integration is flagged as "often the biggest hidden cost — budget separately".
A simple rule follows. The more data passes between areas every day, the more one database pays off. A wholesaler where every order touches stock, a reservation and an invoice will benefit from one system. A company where sales and accounting meet once a month over an invoice will manage with two programs and one connection. In practice, many small companies choose the middle way: trading and inventory software as the core, with the online shop and the CRM connected to it by integration. In what order to build such connections, and how to decide which system owns which data, is a question we work through with every client who connects a shop to an ERP.
We aren't a partner of any ERP vendor, and we don't implement these systems. We build what has to talk to the ERP: the online shop, the form, the application, the customer portal — and the connections that let orders and stock flow between them without retyping. That is why this article doesn't recommend a particular system; it shows how to think about one.
"How much does an ERP system cost?" has two answers. The first is in the vendor's price list. The second — usually bigger — is in the items the price list doesn't contain. The total cost has five parts.
1. Licence or subscription. This is the only item some vendors publish. An example from the bexio price list, as of 22 September 2026, excluding VAT: bexio charges per package, not per seat. The Optima package, for up to five users and with stock management, costs CHF 69 a month billed annually, or CHF 79 billed monthly; the smallest package, Basic, for one user, costs CHF 35 a month annually. A team of three fits into Optima, which comes to CHF 828 a year. We leave out the time-limited discount the page was showing that week. Bear in mind that this is the price of ERP-lite. For fuller systems such as Abacus or SAP Business One we quote no price here: we quote only prices we could read in a published price list, so for those, ask the vendor or a partner for a quote covering the modules and users you need.
2. Implementation. Configuring the system to your processes: warehouses, document types, price lists, permissions, print templates. In small trading and inventory software this is sometimes a few days' work; in a modular ERP, it is a project run by the vendor's partner. Vendors don't publish these rates in their price lists.
3. Data migration. Product and customer records, opening stock, open receivables and payables. The data has to be extracted from old programs and spreadsheets, cleaned and loaded. The formats involved — CSV, XML or an API — and the order of work are something to settle with whoever does the migration before the first file is exported.
4. Training. The time of people learning the new program, who in the first weeks work more slowly than in the old one. It is a cost that doesn't appear on an invoice, but it is in every implementation.
5. Integrations. This is the item we know best, because it is our work. In our [online store cost calculator](pages:69b1d28de5961b9519f27fbc), integrating an online shop with an ERP costs CHF 6,000. Maintaining it, in our [website maintenance cost calculator](pages:69bfe4f90d5d51379c34259c), is CHF 60 a month excluding VAT. Why that much? We wrote it into the calculator configuration: synchronisation needs two-way data mapping — orders go to the ERP, stock levels come back to the shop — and each ERP vendor uses a different API or file protocol, so a connection like this is rarely reusable from one project to the next. Maintenance is a separate item because the connection has to be watched whenever one side changes the way it exchanges data.
Put those numbers side by side. A one-off integration costs more than seven years of the Optima package from the example above — and maintaining the integration costs CHF 720 a year, almost as much as the subscription itself. The comparison flatters the subscription, because bexio is ERP-lite and a fuller system costs more; but the direction holds for any ERP. It doesn't mean the integration is a waste or that the ERP is cheap. It means that an ERP budget worked out from the price list alone is understated whenever the ERP has to talk to an online shop, a marketplace or an application.
What the total cost of an ERP system is made of
bexio.com — packages and prices (read on 22 September 2026); our rates: Digital Vantage calculators (online store cost, website maintenance cost)
Plenty of failure statistics circulate about ERP implementations. We don't quote any, because none of them can be reliably checked. What our integration work does show is where an ERP implementation starts to fall apart. It is almost always the same three places.
Messy master data. An ERP is only as good as the data that goes into it. The same product recorded three times under different names, a customer with two VAT numbers or two UIDs, units of measure sometimes in pieces and sometimes in packs, stock levels nobody has confirmed with a stocktake. A new system doesn't tidy this up by itself — it moves the mess to the place where it becomes official. In an integration we see it immediately: the shop and the ERP have to agree on one identifier for each product, and if the product records contain duplicates, the connection either stops or sends out wrong stock levels. Cleaning the data has to be planned before the implementation, not after.
Blurred ownership of the process. Every process in an ERP — taking an order, dispatching goods, closing the month — needs one person who decides how it should run and is responsible for making sure its data is right. When there is no such person, decisions are made by the implementation consultant, or by nobody. The system then reflects somebody's idea of the company, not the company. The simplest test: for each module, ask who in your company will say "yes, this is how it should work" and who will notice when it stops working. If the answer is "the team" or "everyone", it means nobody.
Tailoring everything from day one. It is tempting to rework the system straight away so that it behaves exactly like the current way of working, exceptions and habits included. That is usually a mistake. The standard process in a mature ERP has been tested in many companies and often turns out better than a local workaround that survived only because nobody questioned it. A more sensible order: first run the standard, work with it for a few weeks, and only then change what really gets in the way. Every change made in advance is a cost at implementation and at every update after it.
Integrations belong in that plan from the start, not at the bottom of the list. If the ERP is to take orders from an online shop, the format of those orders and the product identifiers have to be agreed together with the product records — otherwise the connection is built on data that will change in a month.
An ERP can run on a server in the company or as a service in the browser. The choice comes down to three things.
Access. A cloud ERP works wherever there is an internet connection: from the office, the warehouse, home, or a sales rep on the road. A system on your own server needs remote access, which somebody has to set up and secure.
Updates. In the cloud, the provider updates the system — a change in VAT rates or in the payment standards reaches you without any work on your side. On your own server, updates are installed by someone in-house or by a service company, and every customisation of the system makes the next one harder.
Backups. In the cloud, the provider makes the backups, and you check in the contract how often and for how long they are kept. On your own server, backups are your responsibility — and your risk, if nobody checks that the data can actually be restored from them.
There is a fourth matter too: leaving the provider. With a cloud ERP, the data sits with them — and in Switzerland, your right to take it with you is whatever the contract says. You may have read that EU law now protects cloud customers from lock-in. The Data Act (Regulation 2023/2854) does require providers to allow switching — a notice period of no more than two months, a transition period of up to 30 days, a complete specification of the data that can be exported (Article 25(2)) and, from 12 January 2027, no switching fees (Article 29) — but only for providers "providing such services to customers in the Union" (Article 1(3)(f)). A Swiss company is not one of them, and Swiss law has no equivalent for business customers: the right to data portability in the revised Data Protection Act (Article 28) belongs to individuals, for the personal data they have disclosed themselves, not to a company for its business data. Use those points as a checklist when you read the contract. With an ERP this matters, because it holds the whole history of sales, purchasing, receivables and payables. Before you sign, check in what format you will get the data and whether that includes documents, not just master records. This is a description of the rules, not legal advice — go through the exit terms in the specific contract with a lawyer.
Not with choosing a program. Start with a sheet of paper on which you write down two things.
Processes. How an order runs in your company from being taken to being paid: who takes it, where they record it, who dispatches the goods, who issues the invoice, who chases the payment. At each step, mark where data is retyped by hand.
Data. What master records you have — products, customers, price lists, stock — in which programs and spreadsheets they live, and which version is the true one when they differ.
That sheet often answers the question of whether you need an ERP by itself. If the manual retyping happens in one place, one connection is enough. If it happens in five, it is worth talking to ERP vendors and handing them the sheet as a starting point. If your process is unusual enough that no off-the-shelf system will handle it, work out whether a tool of your own would pay off — we cover that in our article on off-the-shelf versus custom software, and the cheaper middle way in our article on low code and no code.
If you already have an ERP, or are choosing one right now, and need it to talk to an online shop, a form or an application — that is our part of the job. See how we approach it: custom software development and ERP integrations. For the wider picture, which business software solves which problem, see our guide to business software.
An ERP system (enterprise resource planning) is software in which sales, stock, purchasing, production and finance work from one shared database. The order, the stock level and the invoice are one record, so nobody retypes data between programs.
Accounting software records what has already happened: invoices, costs and taxes. An ERP also covers what happens earlier — orders, reservations of goods, stock and purchasing — and hands finished documents to accounting. Many ERP systems have an accounting module, but accounting software on its own isn't an ERP system.
Not always. Working without an ERP is common in small companies, and there is no reason to adopt one because others have. An ERP pays off when you hold stock or manufacture, sell through several channels, and somebody copies data between programs every day. A service business without stock is usually fine with accounting software that handles QR-bills and e-banking, plus a CRM.
The price-list figure is only the subscription or licence — for example, bexio's Optima package for up to five users costs CHF 69 a month billed annually, excluding VAT, and bexio is ERP-lite rather than a full ERP. On top come implementation, data migration, training and integrations. With us, integrating an online shop with an ERP costs CHF 6,000 and maintaining it CHF 60 a month excluding VAT.
A cloud ERP gives you access from anywhere, with updates and backups on the provider's side. Your own server gives you full control, but updates, backups and remote access are your responsibility. With the cloud, check the contract for the data export and switching terms: the EU Data Act's switching rules protect customers in the Union, not companies in Switzerland.
Tell us which programs you have and where somebody retypes data by hand today.
We will help you judge whether one connection is enough or a bigger step is needed.
We don't sell ERP, so if you don't need any integration, we will say so.
Business software is chosen one function at a time: accounting, CRM, ERP, booking, your own tools. A map of situations, the order to go in and the costs.
Low code and no code explained: who a citizen developer is, what a low code platform suits, its price limits and what you can take with you when you leave.
When a free booking calendar is enough, what an online booking system must handle and when a custom module pays off. Vendor prices and our estimate.
What a CRM is, when a spreadsheet is enough, what the system must do, how the revFADP and the UWG shape a customer database, and how to choose one.
Off-the-shelf or custom software is decided one function at a time. Four questions, a five-year TCO with our own prices, and vendor lock-in both ways.
Business process automation: how it differs from RPA and AI, the QR-bill as a first step, our hands-off funnel, examples by department.
What a mobile application is and how it differs from a website and a PWA. The frequency test, loyalty apps, working offline and app store costs.
Your Partner in Business, Digital Vantage Team
Digital Vantage team is a group of experienced professionals combining expertise in web development, software engineering, DevOps, UX/UI design and digital marketing. Together we carry out projects from concept to implementation - websites, e-commerce stores, dedicated applications and digital strategies. Our team combines years of experience from technology corporations with the flexibility and immediacy of working in a smaller, close-knit structure. We work in agile methodologies, focus on transparent communication and treat each project as if it were our own business. The strength of the team is the diversity of perspectives - from systems architecture and infrastructure, frontend and design, to SEO and content marketing strategy. As a result, the client receives a cohesive solution where technology, aesthetics and business goals go hand in hand.
Rate this article
Back to the guide: Business software — which tools a company needs, function by function

Low code and no code explained: who a citizen developer is, what a low code platform suits, its price limits and what you can take with you when you leave.

When a free booking calendar is enough, what an online booking system must handle and when a custom module pays off. Vendor prices and our estimate.

What a CRM is, when a spreadsheet is enough, what the system must do, how the revFADP and the UWG shape a customer database, and how to choose one.

A practical guide for entrepreneurs: how to use QR Code and Short Link, specific uses, creation instructions, analytics and pitfalls to avoid.

Kiedy wejść na marketplace, jak synchronizować oferty, ceny i zamówienia bez chaosu.

Why nobody can give you a Swiss price for app development, what the one published rate reference actually covers, our own prices, and cost after launch.

How to make an app for your business with a contractor: brief, prototype, sprint development, UAT and go-live. How long each stage takes and where you decide.

Off-the-shelf or custom software is decided one function at a time. Four questions, a five-year TCO with our own prices, and vendor lock-in both ways.

Business process automation: how it differs from RPA and AI, the QR-bill as a first step, our hands-off funnel, examples by department.