Custom ERP or a customised off-the-shelf ERP?

According to Mesterséges Intelligencia Központ Kft., a software development company based in Budapest, Hungary, an off-the-shelf ERP works when processes can follow its standard; a custom ERP when operations differ or customisation would put upgrades at risk.

In short: There are three routes: an off-the-shelf ERP as it is; an off-the-shelf ERP configured and extended through the vendor's extension points; and a custom ERP. The deeper you would have to reach into the core of the off-the-shelf system, the more it pays to put the unique part into a separate module or to build your own system. Whichever route you take, a phased switchover with data cleansing up front carries less risk than one big, one-off change.

What is an ERP?

An ERP (enterprise resource planning) system brings a company's core processes together in one system. According to Microsoft's definition, ERP is business management software that helps organisations integrate their core processes, such as finance, supply chain, manufacturing, human resources, procurement and project management (Microsoft: What is ERP?).

In practice, the value of an ERP is that the same data is created only once: an incoming order becomes a goods issue, the goods issue becomes an invoice, and the invoice becomes an accounting entry and a receivable. If these steps live in separate programs and spreadsheets, data travels by hand, and errors travel with it. Tracking customers and sales is a related area but a separate decision; we cover it in the article When is it worth developing a custom CRM?.

Three routes to an ERP

The “custom or off-the-shelf” question is really a choice between three options. The line between them is not sharp, but the difference in cost, upgrades and dependency is significant.

An off-the-shelf ERP as it is

The company implements a ready-made product and adapts its own processes to the product's standard way of working. This works well when processes are common and the company is ready to change familiar ways of working. The advantages are a faster start and upgrades delivered by the vendor; the drawback is that whatever the product leaves out carries on in spreadsheets or manual work.

An off-the-shelf ERP, configured and extended

Most implementations end up somewhere here. It is worth distinguishing three things, because they mean very different things for upgradability:

Configuration: using the options the vendor provides, without programming: workflows, approval levels, fields, document templates, user roles.
Extension: new functionality through extension points and interfaces that the vendor supports and documents, without changing the product's own code.
Modification (customising the core): rewriting the vendor's own code or objects, or copying and rewriting them. This gives the most freedom, but according to the vendors' own documentation it also carries the most risk at upgrades (see below).

A custom ERP

The system is built on the company's own processes and data model, and only what is really needed gets built. There is no vendor core to upgrade, and the client decides on further development. In return, development, operation and maintenance have to be organised, either with an in-house team or a contracted developer. The general trade-off between custom and off-the-shelf software is covered in the article Custom software or an off-the-shelf solution (SaaS)?.

Why does heavy customisation make upgrades hard?

The vendor of an off-the-shelf ERP regularly releases fixes and new versions. If the company has modified the vendor's code, every upgrade means checking whether the modification still works, and often rewriting it. The large vendors' own documentation reaches the same conclusion:

SAP: under the “clean core” approach, extensions must be kept strictly separate from the SAP application and use well-defined, upgrade-stable interfaces; the vendor considers directly modifying or copying its objects more problematic, because every patch or upgrade may require thorough retesting (SAP Learning: Introducing the Clean Core Approach).
Microsoft Dynamics 365: for Finance, Supply Chain and Commerce, the vendor explains its extension-based model by saying that the cloud and frequent updates require a less intrusive customisation model, so that updates are less likely to affect custom solutions; in these products extensibility is the only way to customise, and overlayering of the application code is not supported (Microsoft Learn: Extensibility home page).
Odoo: according to its documentation, a database with custom modules cannot be upgraded until a version of those custom modules is available for the target version, and the maintainer of the custom module is responsible for making it compatible (Odoo: Upgrade).

The lesson is the same at SAP and Microsoft: leave the core untouched, and let whatever is unique to the company live in a separable extension or a separate module that talks to the off-the-shelf system through a documented interface; at Odoo, the maintenance of the custom modules determines when the system can be upgraded. If the uniqueness you need is so large that this can no longer be done cleanly, that is a strong signal for a custom ERP or a custom module.

Hungarian specifics: NAV Online Számla, invoicing, banks, webshops

An ERP for a Hungarian company also has to work with Hungarian systems. The most important is NAV Online Számla, the Hungarian tax authority's online invoice data reporting system: according to NAV, since 4 January 2021 data must be reported on every invoice, modifying invoice and cancelling invoice to which the invoicing rules of the Hungarian VAT Act apply (NAV: Online Számla).

The supported version of the system-to-system (machine) interface is 3.0 (checked on 17 October 2026). According to the interface specification, the invoicing software must report automatically, without separate human intervention within the process; NAV processes the submitted data asynchronously, and the reporting cannot be considered complete until the software has confirmed that processing succeeded and has received the receipt message for the invoice (NAV Online Számla: Documentation). NAV amends the specification from time to time (it published an amended version in August 2026 as well), so the connection needs maintenance.

What an ERP in Hungary typically needs to do, and what we connect:

NAV Online Számla: submitting invoice data through the machine interface, querying the processing result and handling errors.
Invoicing services: if invoicing stays in an external invoicing service, the connection goes through its interface.
Banks: importing bank statements and transactions, and matching incoming payments to invoices.
Webshop: synchronising orders, stock and prices between the webshop and the ERP.
Couriers and other systems: parcel shipping, the existing CRM, email and calendar.

When choosing an off-the-shelf ERP, it is worth asking whether the product has a Hungarian localisation, who maintains the NAV connection when the specification changes, and how it connects to Hungarian banks and invoicing services. With a custom ERP, the same connections are part of the development. We write about connecting systems in more detail on the Process automation page.

Decision table

Criterion	Off-the-shelf ERP as it is	Extended off-the-shelf ERP	Custom ERP
Fit with processes	the company adapts to standard processes	most of the standard fits, a few points are unique	operations differ substantially from the standard
Start-up	typically quick, if configuration is enough	longer, because of developing the extensions	takes development time, can go live in stages
Upgrades	delivered by the vendor, with little risk	extensions must be checked at every upgrade	scheduled by the client, carried out by the developer
Unique processes	through settings only	through extension points or in a separate module	any business logic
Integrations	with connectors from the vendor and its partners	connectors and custom integrations	with anything whose interface or data is accessible
Cost structure	licence or subscription fee on the vendor's terms	licence, plus developing and maintaining the extensions	development, operation and further development
Dependency	on the vendor and the product's future	on the vendor and the partner developing the extensions	with the source code, can be taken further by another developer
Who is it for?	companies with common operations that need a quick start	those for whom the standard is a good base but differs at a few points	those whose operations or integrations are unique

A mixed solution is also common: the off-the-shelf ERP stays for finance and accounting, while the company's distinctive processes, for example custom production scheduling or pricing, run in a separate custom module that talks to the off-the-shelf system through an interface.

Moving from the old system

An ERP project rarely starts from a blank page: there is an old program, an off-the-shelf system or a set of spreadsheets holding years of data. The steps of the switchover:

Assessment: what data, processes and connections exist, and what runs today in spreadsheets, outside the system.
Data inventory and cleansing: sorting out duplicate customers, an incomplete item master and obsolete records before the migration.
Data mapping: where each old field goes in the new system, and what happens to old, closed records.
Trial migration: the old data goes into a test environment, where the key users check it against real cases.
Phased go-live: module by module or site by site, possibly with the old and the new system running side by side for a short time, so that daily work does not stop.
Follow-up: bug fixing, additional training and operation after go-live.

Not everything has to be replaced at once. Often the workable path is to place the new module next to the old system first and let the two exchange data through an interface until the old part can be retired.

Risks and how to reduce them

A first phase that is too big: if everything goes live at once, one error can stop the whole company. It is worth starting with a well-defined module.
Messy data: wrong data stays wrong in the new system. Data cleansing is part of the project, not an afterthought.
Hidden processes: many important steps live in spreadsheets or in one colleague's head. The assessment has to bring these to light too.
Missing key users: if the people doing the daily work are not involved in design and testing, the spreadsheet lives on next to the system.
Integration errors: the NAV, bank and webshop connections need logging and error alerts, so that a stalled synchronisation does not go unnoticed.
One-sided dependency: handing over the complete source code and documentation ensures that the system can later be taken further by another developer.

Where does artificial intelligence help in an ERP?

Large language models (OpenAI's ChatGPT, Anthropic's Claude and Google's Gemini) are useful wherever a person used to read, copy or write:

Documents: reading the data from incoming invoices, delivery notes and orders, and recording it ready for review.
Email: processing incoming order emails and preparing a draft reply.
Questions about the data: asking the system in plain language, for example which customers have overdue invoices.
Flagging anomalies: highlighting unusual items for review, for example an order that differs greatly from the customer's previous orders.

Where a mistake costs money, the AI proposes and a person approves. We explain how we connect the models and how we handle data protection on the AI integration page.

Our experience

We are currently developing a large ERP and CRM system; we do not disclose the client or the product name. The screens are rarely the hard part of an ERP: the data model, the user roles, the integrations and the takeover of old data decide whether people will use the system or keep their spreadsheet running next to it.

Frequently asked questions

When does it pay to develop a custom ERP?

When the company's operations differ substantially from what off-the-shelf ERPs are built for and it wants to keep that difference; when many systems must be connected and there are no ready-made connectors; or when the customisation needed would require modifying the vendor's core. If an off-the-shelf ERP covers most processes through configuration, that is usually the faster route. We will tell you so in the first consultation.

How far can an off-the-shelf ERP be customised?

In many ways, but how you do it matters. Configuration and the extension points supported by the vendor affect upgrades little; modifying the vendor's code, however, can cause new work at every upgrade. The documentation of large vendors such as SAP and Microsoft recommends leaving the core untouched and keeping extensions separate; according to Odoo's documentation, maintaining the custom modules is a precondition for upgrading.

What is the risk of heavy customisation?

Mainly that upgrades become expensive and risky: the modifications have to be checked and often rewritten at every new version, and with some vendors the upgrade cannot even be carried out until the custom parts are ready for the new version. The company also becomes dependent on the partner developing the extensions. If the extent of customisation calls for it, it is worth comparing it with the cost of a custom module or a custom ERP.

How does the switchover from the old system work?

It starts with an assessment, data cleansing and data mapping, followed by a trial migration in a test environment and then a phased go-live: module by module, or with the old and the new system running side by side for a short time. Go-live is followed by bug fixing and operation. The old system can keep running next to the new one for a while, connected through an interface.

Do you connect NAV Online Számla?

Yes. We submit the invoice data through NAV's machine interface, query the processing result and handle errors as NAV's interface specification requires. In the same way we connect external invoicing services, banks and the webshop.

How we can help

Mesterséges Intelligencia Központ Kft. develops custom ERP, CRM and back-office systems, builds custom modules and integrations for off-the-shelf systems, and connects them with artificial intelligence. The first consultation is free, and if an off-the-shelf ERP is enough, we will tell you so. We measure the functional size of the development in COSMIC function points (ISO/IEC 19761) and derive the offer and the schedule from it; the method is described on the Pricing page. We sign a non-disclosure agreement (NDA) on request, and after handover we also provide operation and maintenance. The contract governs source code and usage rights.

Details are on the Business software page. If you would like to talk to us about your own system, write to us using the details on the Contact page.