ERP System Guide 2026: How Enterprise Resource Planning Works, What It Costs, How to Implement It

Updated: June 9, 2026

Most companies start looking for an ERP system when daily operations already hurt: inventory lives in three different spreadsheets, month-end close takes a week, and two departments give two different answers to the same question. This guide covers the topic from the ground up — what an ERP actually is, how it works, when you genuinely need one, what it costs in 2026, and where implementations go wrong.

The guide is vendor-neutral. Where we quote prices, they come from published vendor price lists and from project quotes we see in the Hungarian and Central European mid-market, where our agency builds custom business systems. If you are evaluating the build-vs-buy question specifically, jump to the decision framework at the end.

What is an ERP system?

An ERP (Enterprise Resource Planning) system is software that manages a company's core operating areas — finance, inventory, purchasing, manufacturing, sales and HR — in a single shared database. Every department reads and writes the same data, which eliminates duplicate data entry, manual reconciliation and parallel spreadsheet bookkeeping.

The shared database is the whole point. When a warehouse worker issues stock, the inventory value updates in accounting at the same moment; when a salesperson enters an order, production planning and purchasing see it instantly. Without an ERP, that data lives in separate programs and spreadsheets, and people carry it across by copy-paste. Every hand-off is slow, and every hand-off is a chance to introduce an error.

The category itself is old: Gartner analysts coined the term ERP in 1990 as a generalization of manufacturing resource planning (MRP II) systems (source: Gartner). What changed by 2026 is access. A system class that once required a server room and a multi-year corporate project is now available as a cloud subscription to a 10-person trading company — or can be built as a custom web application on a mid-market budget.

How an ERP works: modules on a shared database

An ERP is a set of modules running on one shared database. Each module covers an operating area — finance, inventory, manufacturing, sales, HR — but they all read and write the same records. You can roll them out one at a time: most companies start with finance plus inventory and switch on the rest later.

To see why the shared database matters, follow one order through the system. A customer places an order: the sales module records it, the inventory module reserves available stock immediately, and missing items generate demand in manufacturing or purchasing. At dispatch, the system produces the delivery note and the invoice; invoice data flows to the general ledger and the tax authority, and the receivable appears in finance. One piece of data was entered once, at the start — everything downstream was derived from it.

The same order without an ERP: it arrives by email, someone types it into the invoicing tool, someone else deducts it from the stock spreadsheet, production hears about it verbally, and the accountant gets a pile of documents at month-end. Five people, five systems, and data can be lost or distorted at every hand-off. The business value of an ERP is precisely the removal of those hand-offs.

When do you actually need an ERP?

You need an ERP when the company has outgrown spreadsheets and disconnected tools: the same data is maintained in several places, regulatory reporting involves manual steps, and management decisions run on numbers that are weeks old. Symptoms typically appear above 10–15 employees and 20–30 documents a day.

The most common warning signs we see in audits:

• The same data lives in three places.The item master sits in the invoicing tool, stock in one spreadsheet, prices in another — and they regularly disagree. Once weekly “reconciliation” is routine, manual data handling already costs more than a system would.
• Island systems. Separate invoicing, warehouse and CRM tools, none of them talking to each other, with people doing the integration by copy-paste. In our client audits this typically consumes 10–20 staff-hours a week at a 20–50 person company (source: AppForge ERP audits, 2024–2026).
• Month-end close takes 5+ working days. If accounting spends the first week of every month chasing documents, management is always deciding at least a month behind reality.
• Stock numbers don't add up.Stocktakes uncover large discrepancies, the webshop sells items that aren't on the shelf, or production stops for a material the system claimed was available.
• Onboarding a new hire takes weeks, because the knowledge lives in heads and unwritten spreadsheet habits. That is also a key-person risk: when the owner of the spreadsheets resigns, part of the operation leaves with them.

A practical rule of thumb: count the hours spent each month on copying, reconciling and fixing data, and multiply by fully loaded labor cost. If the result exceeds €2,500–5,000 a month — the typical range at a 20-person company — an ERP project is not a new cost. It replaces a loss you are already paying for.

And when should you not buy an ERP? Below roughly 5 people, while an invoicing tool plus one well-kept spreadsheet is still transparent; while your core process is being redesigned and the system would need reconfiguring in six months; or when nobody inside the company can dedicate a few hours a week to the project. Fix the process first — software only makes disorder run faster.

ERP types: on-premise, cloud and custom-built

There are three base types. On-premise ERP is licensed software running on your own servers. Cloud (SaaS) ERP is rented per user per month. Custom ERP is developed for your specific processes, and the code is yours. Company size, process uniqueness and 5-year total cost decide between them — the entry price alone misleads.

On-premise ERP

The classic model: buy licenses, run the system on your own or rented hardware, implement through a partner. SAP Business One on-premise is the textbook example. You get full control over data and environment, and the license is a one-time item. The trade-offs are a high entry cost — license plus implementation typically lands at €45,000–100,000 — an annual maintenance fee (18% of license value for SAP B1), and an operations burden that is yours to carry.

Cloud (SaaS) ERP

The system runs in the vendor's cloud and you pay per user per month. Microsoft Dynamics 365 Business Central is the best-known mid-market example at $70–100 per user per month (source: Microsoft price list). Start-up is fast, updates are automatic, and no servers are needed. The subscription never ends, though: at 30 users it adds up to €25,000–35,000 a year, which over five years rivals a full custom build. Customization extends exactly as far as the vendor allows.

Custom-built ERP

A system built on modern web technology around your actual processes, with no license fees and full ownership of the code. It makes sense when your operation doesn't fit packaged templates — industry-specific manufacturing, project-based billing, unusual logistics — or when the user count makes subscriptions explode. Custom ERP development starts around €20,000 (8M HUF); a typical mid-market project runs €40,000–200,000. At 50+ users its 5-year total cost can be 50–70% lower than licensed alternatives (source: AppForge project calculations, 2026).

Hybrids work well in practice: a packaged accounting core handling the regulated, compliance-heavy part, with a custom warehouse or manufacturing module connected over APIs. The differentiating process stays unconstrained, while statutory bookkeeping rides on proven software.

What does an ERP cost in 2026?

Realistic Central European bands: cloud ERP at €20–65 per user per month plus €3,000–13,000 setup. SAP Business One at €20,000–38,000 in licenses for 10 users plus €25,000–65,000 implementation. Dynamics 365 Business Central at $70–100 per user per month plus €20,000–75,000 implementation. Custom ERP from €20,000, typically €40,000–200,000. Compare on 5-year total cost, never on entry price.

The list price is only the visible part. The real budget includes data migration (cleaning and loading master data and open items from the old system), integrations (webshop, shop floor, banking, EDI), training, and the item nearly everyone underestimates: your own people's time. On a 6-month implementation, key users realistically spend internal effort worth 30–50% of the external implementation fee. Plan for it explicitly.

This is why a 5-year horizon is the honest comparison. A low-entry SaaS with 50 users and €40,000–100,000 in annual subscriptions can cost more over five years than building a custom system outright, while a cheaply licensed on-premise package claws back the difference through customization day rates. Our ERP TCO calculator gives you a first approximation in minutes, comparing the licensed and custom paths from your user count, modules and industry.

One myth worth killing: ERP cost does not scale linearly with headcount. A 15-person manufacturer with complex costing can be a more expensive project than a 60-person distributor with standard processes. Process complexity, integration count and data quality drive the price; headcount only moves the license line.

Implementation steps and the classic pitfalls

An ERP implementation has seven steps: process mapping, system selection, data migration, customization and integration, testing, training and go-live. Time-wise, a simple accounting package takes 4–8 weeks, a cloud ERP 3–6 months, SAP B1 or Dynamics BC 6–12 months and a custom build 5–12 months.

1. Process mapping. Write down how an order, a purchase and a month-end close run today — and how they should run. This document becomes the yardstick for every later decision. Without it, the vendor implements their template instead of your business.
2. System selection.Shortlist 2–3 candidates and test them in live demos with your own data. Ask about local compliance support, references in your industry, and who will actually do the implementation — with the big brands, the local partner's quality matters more than the software.
3. Data migration. Cleaning and loading item masters, partner records, open items and stock. In our experience this is the most underestimated phase; it can absorb a third of the project because legacy data is never as clean as you believe.
4. Customization and integration.Document layouts, permissions, webshop, banking and shop-floor connections. This is where it's decided whether the system serves your processes or you bend to the system's.
5. Testing. Key users run real scenarios — a full order-to-invoice-to-ledger cycle — on a copy of live data.
6. Training.By role, on your own processes, instead of a generic feature tour. Untrained users retreat to Excel, and the system's data quality decays from that point on.
7. Go-live and stabilization. Usually tied to a year or quarter boundary, with intensive support until the first close. The 2–3 months of post-go-live tuning belong in the project scope, not in a dispute after the final invoice.

Where projects go wrong

• Copying the old process 1:1.Configure today's broken process into the new system and you get the same chaos at a higher price. The implementation is your one cheap chance to clean up workflows — use it.
• No internal owner. The vendor implements, but only you can decide what the correct item-numbering logic is or who may see prices. The project needs an internal lead with a genuine 4–8 hours a week to give.
• Big-bang cutover with no safety net. Switching off the old system on Friday and going live on Monday only works for small scopes. For anything serious, run parallel until the first month-end close, or cut over module by module.
• Skipping training and change management.A system is not live because it is installed. If the warehouse doesn't book movements immediately, real-time inventory is an illusion and the investment loses its point.
• Unbounded scope.Mid-project “can it also do this?” requests add months and tens of thousands of euros. Phase one delivers the mapped processes; extensions get their own phase and budget.

A note on Hungarian compliance

If you operate a Hungarian entity, the ERP must support the tax authority's real-time invoice reporting natively: since January 2021, every domestic B2B invoice must be reported to NAV in real time using the Online Számla 3.0 XML schema (source: NAV Online Számla documentation). Hungarian VAT handling — reverse charge, cash accounting, FX invoice rates — must match what local accountants expect. International systems cover this through localization packs of varying quality, so ask for live Hungarian references before signing. For custom systems the NAV API is well documented and the integration is built in from day one. We cover the full topic in the Hungarian edition of this guide.

Off-the-shelf or custom? A decision framework

The rule of thumb: with standard processes and under 30 users, buy a packaged system — start-up is faster and cheaper. With industry-specific processes, 50+ users, or a dead legacy system to replace, custom development typically wins on 5-year cost and fits the way you actually work.

Packaged software wins when

• Your processes are standard. Distribution, services, simpler manufacturing — exactly what the templates were built for. You get proven practice, live in weeks or months.
• User count is small.Under 30 users the annual subscription stays manageable, while a custom build's entry cost is the same as for a larger company.
• You need instant regulatory tracking without internal capacity. Established vendors ship tax-rule changes as part of the product.

Custom development wins when

• Industry-specific processesthe templates don't cover: unique production line configurations, construction project ERP, energy billing, MES integration. Forcing these into a boxed product means expensive compromises forever.
• 50+ users.At €40,000–100,000 a year in subscriptions, a custom system's 5-year total cost can come in 50–70% lower, with no vendor lock-in.
• A vendor-dead legacy system.When the original developer is gone, the “upgrade” is a rewrite anyway — so rewrite it around your current processes.
• Compliance pressure. Under NIS2 or strict data residency requirements, control over your own system is a stronger guarantee than an annex in a SaaS contract.

If you are weighing the custom path, our custom ERP development page walks through the process from audit to go-live, and the ERP TCO calculator shows the 5-year math on your numbers. For a concrete project, request a quoteand you'll have a tailored estimate within 48 hours — or book a free 30-minute consultation and we'll tell you which path is realistic, even when the honest answer is a packaged system.