The board of a mid-sized manufacturer has sat through three pitches. The first vendor demonstrates a well-known ERP suite and promises that “everything is configurable”. The second, a software development firm, argues that a business with such an unusual production process deserves a custom ERP: built to fit, no licences, no compromises. The third proposes “extending” the current system by adding the missing features to software the company already owns. Each pitch sounds reasonable, each carries a different price, and each assumes that the decision covers the whole system at once.
The CFO asks the question none of the vendors answers directly: what part of this will still work in seven years, when the regulations, the versions and the people who built it have all changed?
This article is for CEOs and CFOs of mid-sized companies facing that decision. It defends a position that neither some ERP vendors nor some providers of ERP development services will like: buy the accounting and tax core and adopt its standard process, even if that means changing some of your habits; build only where a process creates a real advantage, and build it beside the ERP, not inside it. The most expensive option is neither building nor buying. It is modifying the inside of a packaged system, which looks like the cheapest line in most proposals.
Why does “build or buy ERP” lead to the wrong decision?
Because it assumes an ERP is one thing and the decision is made once. In reality, an ERP in a mid-sized company covers a dozen or more processes of very different character: general ledger, receivables and payables, VAT and e-invoicing, payroll, fixed assets, purchasing, inventory, production planning, sales, pricing and logistics. Some of these are identical in every company in the country and change only when the law changes. Some are what sets the company apart from its competitors. A single “build” or “buy” decision for the whole system guarantees a mistake in one of those groups.
The scale of the risk is well documented. In a 2024 prediction, Gartner forecast that by 2027 more than 70% of recently implemented ERP initiatives would fail to fully meet their original business goals, with as many as one in four failing outright. These are not amateur projects. They are projects in which the architecture was too often decided for the system as a whole, before anyone broke it down into processes.
The build-or-buy question also hides a third answer that vendors call “extending”. It sounds like a safe compromise: buy the standard product, add what is missing. In practice “extend” covers four very different things, from changing settings to rewriting the vendor’s code, and the difference in cost and risk between them is larger than the difference between building and buying. So instead of one question, ask three: which processes to buy and run on the standard, which to extend and how, and which to build yourself.
We applied similar logic to sales systems in our piece on when custom CRM development pays off. ERP differs from CRM in one crucial respect, though: it is the system in which the company’s books and tax filings are produced. That changes the calculation more than it first appears.
Which parts of an ERP are commodities and which can be an advantage?
A useful starting point is a distinction enterprise architects have used for years: processes where the company must be correct, and processes where it can be better than others. In the first group, what matters is compliance, completeness and auditability. In the second, what matters is speed, flexibility and whatever the customer experiences as a difference.
The first group almost always includes the general ledger and chart of accounts, receivables and payables, VAT and e-invoicing, payroll and HR administration, fixed assets, consolidation, and reporting for tax authorities and auditors. No customer chooses a supplier because it posts supplier invoices with unusual elegance. These processes are commodities: they must work, they must comply with the law and they should cost no more than necessary.
The second group contains whatever is specific to the business model. In a manufacturer, that might be planning for short make-to-order runs. In distribution, pricing driven by many variables and dynamic discounts. In logistics, route and loading-window optimisation. In services, the way a customer orders, tracks and changes a job. This is where an unusual process can be the very reason customers choose the company.
Between the two lies a middle band: purchasing, warehousing, standard order management, project accounting. In most companies these are commodities too, but in some they become the advantage. A wholesaler that promises delivery within four hours may have something in its warehouse operations that competitors do not. A company that sells the same products as everyone else, but cheaper thanks to purchasing discipline, may have its edge in procurement.
The most common mistake is to treat everything the company does differently as an advantage. “We do it our own way” does not mean “we do it better”. Many process differences are simply habits that formed around the previous system and survived because nobody questioned them. An honest process review usually shows a handful of genuinely differentiating processes, not dozens.
Why shouldn’t you build your own general ledger and tax engine?
Because the cost of a custom accounting core does not end on go-live day. The real cost is keeping it compliant with regulations that change every year, sometimes several times a year, and for which the company, not the developer, is accountable.
Europe’s e-invoicing wave is the clearest illustration. Since 1 January 2025 every business established in Germany must be able to receive structured e-invoices, with issuing obligations phasing in from 2027. Poland’s national e-invoicing system, KSeF, became mandatory on 1 February 2026 for taxpayers whose 2024 sales exceeded PLN 200 million, with all other taxpayers following on 1 April 2026. France requires every business to be able to receive e-invoices from 1 September 2026, with large and mid-sized companies issuing them from the same date and smaller ones a year later. And the EU’s VAT in the Digital Age package, adopted by the Council in March 2025, introduces mandatory e-invoicing and near-real-time reporting for intra-EU transactions from 1 July 2030.
A company running a packaged ERP receives each of these changes in a vendor update; it still has to deploy, test and train, but it does not have to design the integration. A company with a custom-built core has to design and build each integration itself, handle every schema, fallback mode and permission model, and then maintain it through every change. For a group operating in three or four EU countries, that is a permanent compliance backlog that a vendor spreads across thousands of customers and a single company pays for alone, every time.
There is an audit argument too. An external auditor reviewing a company that runs a widely used ERP already knows its controls, logs and standard reports. With a home-grown system, the auditor has to learn them from scratch, and the company has to demonstrate that the system posts correctly, prevents unauthorised changes and keeps a full audit trail. It can be done, but it is more work that creates no value for any customer.
Finally, there is a people argument. Finance teams want to work in tools they know from the market and for which they can hire. A new financial controller joining from another company will find their way around a popular ERP within days. In a custom system, they need training, and their knowledge does not transfer anywhere else.
The thesis of this section is a strong one: even a company with every reason to build its own operational system should buy its accounting and tax core. Exceptions exist, but they apply to companies for which financial software is the product, not a tool.
What does “extend” actually mean, and why is it four different decisions?
“Extension” appears in almost every implementation proposal and is almost never defined. Yet it covers four levels of intervention that differ in cost, in risk and in what happens when the system is upgraded.
Level one: configuration. Changing settings the vendor anticipated: chart of accounts, approval paths, document types, permissions, form layouts. No programming, and it survives upgrades because the vendor designed it to. This is the primary way to fit an ERP to a company and it should cover most needs in commodity processes.
Level two: extensions at vendor-provided points. Additional fields, custom reports, business rules and scripts running in places the vendor has exposed and committed to maintain. It requires development, but within a limited, documented scope. It survives upgrades as long as it uses only public interfaces.
Level three: core modifications. Changes to the system’s own code or data structures, direct table access, rewritten standard procedures. This gives the greatest freedom and is the fastest route to “doing it our way”. In return, every vendor upgrade requires re-analysis and retesting, and often rewriting. After a few years, the company has a system it cannot upgrade without a major project.
Level four: applications beside the ERP. Separate software that runs a differentiating process with its own code and its own database, exchanging data with the ERP through published APIs or message queues. The core stays untouched and the application evolves at its own pace. This is effectively building, but within boundaries that never touch the books.
The large vendors have arrived at a similar classification themselves. SAP has promoted a “clean core” principle for several years, and its guidance published in August 2025 grades extensions from level A to level D: from those using only publicly released, stable interfaces, which are the safest at upgrade time, to those relying on non-recommended objects and techniques, which carry the highest risk and create significant technical debt. You do not need to run that vendor’s software to adopt the same logic: classify every extension before you commission it.
The practical consequence for the board is simple. Instead of asking a vendor “can this be extended?”, ask “at which level will this extension be built, and what happens to it at the next upgrade?”. An answer like “it’s a modification, but a small one” should set off an alarm.
Why is modifying the core the most expensive option, even though it looks the cheapest?
Because its cost appears later, in a different budget and often after the people who ordered it have left. In an implementation proposal, a modification looks like a few days or a couple of weeks of consultant time. In the run budget, it comes back with every upgrade, every regulatory change and every migration to a new version.
The best-known example is Lidl’s eLWIS programme. According to Consultancy.uk’s report from August 2018, the retailer spent seven years implementing a merchandise management system and then stopped. Trade press estimated the spend at around EUR 500 million, although neither Lidl nor the vendor confirmed the figure. The root problem was a mismatch between the company’s process and the system’s standard: Lidl valued inventory at purchase prices, while the vendor’s standard retail software was built around retail prices. Lidl declined to change its process, so the software was adapted to the company instead, which hurt performance and drove up costs. Lidl’s CEO wrote to staff that the original strategic goals could not be achieved at acceptable expense.
The second example is more recent. Birmingham City Council, the largest local authority in Europe, planned to implement a cloud ERP largely out of the box, with a budget of GBP 19 million plus GBP 1 million contingency. During the project, however, it built customisations, including a bank reconciliation mechanism that did not work properly, leaving the council unable to see its own cash position for a long period. According to The Register in January 2026, the programme is now forecast to cost GBP 144.4 million up to the 2027/28 financial year, and the council is reimplementing the system from scratch, this time on the standard, with a third-party product for bank reconciliation.
Both organisations are far larger than a mid-sized company, but the mechanism is the same at any scale. A core modification turns a one-off decision, “let’s fit the system to us”, into a recurring cost that grows with every version. There is also a compounding effect: the first modification makes the second easier to justify, because “we already have our own version anyway”. A few years later, the company is paying licence fees for a standard product whose standard it no longer uses.
The problem is most visible when support for an old version ends. Vendors set dates after which they stop delivering fixes and legal updates. For one of the most widely used ERP systems in the world, SAP ERP 6.0, the vendor announced in February 2020 that mainstream maintenance would end in 2027, with optional extended maintenance to the end of 2030. Companies that modified the core for years are now discovering that migrating means inventorying and rewriting hundreds of changes. Companies that stayed close to the standard face a much simpler project.
There is one more, less visible cost of modifications: knowledge. Usually only a few people at the implementation partner understand the core changes. When they leave, the company is left with code nobody understands, in a system the vendor does not support in that form. That is a fast track to technical debt of the most expensive kind, accumulated within a few years of go-live rather than over decades.
When does building your own system make sense, and what shouldn’t you build even then?
Custom ERP development makes sense when three conditions hold at the same time. First, the process genuinely creates advantage, which can be demonstrated rather than merely claimed: customers choose the company for reasons that depend on that process. Second, packaged systems do not support it, even after configuration and extensions at vendor-provided points, and the gap is not a matter of habit. Third, the company is prepared to maintain the software for years, with a team, a budget and an owner on the business side.
Typical situations in which those conditions can be met:
- an unusual production model, for example engineer-to-order manufacturing with customer-driven product configuration, where standard planning assumes batches and fixed routings;
- pricing as the advantage: hundreds of variables, contracts with individual formulas, prices linked to commodity indices, where the speed and accuracy of a quote decide the sale;
- customer service integrated with operations, where customers place, track and change orders themselves and that data immediately feeds planning;
- high transaction volumes with a simple structure, where per-user or per-transaction licensing stops making economic sense and the logic is simple enough that a custom solution is cheaper to run.
Even then, you do not build the whole ERP. You build the company’s operational system: planning, pricing, a customer portal, warehouse management with unusual rules. The books, taxes and payroll stay in the purchased product, and the custom system passes documents and data to it through systems integration based on clear data contracts. This architecture keeps the most valuable part of building, control over the differentiating process, and the most valuable part of buying, handing regulatory compliance to the vendor.
It is also worth being honest about when building does not make sense, even if a provider of ERP software development argues otherwise. When the main argument is licence cost, compare it with the cost of a team maintaining your own system for years; for commodity processes, the licence almost always wins. When the argument is “our process is unique”, and nobody can say what effect that uniqueness has on customers, it is usually a habit. When the argument is independence from vendors, remember that a custom system creates dependence on your own team or on the firm that built it. We covered general build-versus-buy criteria for any software in our strategic guide to buy-or-build decisions; for ERP, the key distinction is between processes that must be correct and processes that can be better.
How do you map processes so that each one gets its own decision?
An ERP decision map does not require a months-long analysis project. It requires a few workshops with process owners and the discipline to ask each of them the same questions.
Start with a list of processes at the level at which the board can discuss them: a dozen, at most twenty items, from order-to-cash to procure-to-pay and month-end close. For each process, ask five questions.
- Does the customer notice if we do this better than competitors? If not, the process is a commodity.
- How often does regulation change this process? The more often, the stronger the case for a purchased standard.
- How does our way differ from market-standard practice, and why? If the answer is “we’ve always done it this way”, the difference is a habit.
- What happens if we adopt the standard? Quantify it: lost sales, slower service, extra headcount. Often the effect turns out to be small or zero.
- Who will own this for the next seven years? A process without an owner should not have its own software.
Sort the results into three categories. Adopt the standard: the process runs in the purchased system, changes only through configuration, and the company adapts its way of working. Extend at vendor-provided points: the purchased system plus extensions built on published interfaces, with no core modifications. Build beside: a separate application, own code, integration through APIs. A fourth category, “modify the core”, should not appear on the list by default; if it does, it needs a separate, documented board approval with an assessment of its maintenance cost.
In a typical mid-sized company, this review produces a distribution that surprises the participants. Most processes land in the first category, a few in the second, one to three in the third. That is a very different picture from the vendor pitches, in which either “everything is configurable” or “everything has to be built”.
Good practice is to produce this map before issuing an RFP, not after. An RFP that states which processes the company will run on the standard and which it intends to build beside the ERP produces comparable proposals. An RFP that just says “we are looking for an ERP” produces proposals that each draw the boundary in a different place.
Which decision criteria should the board check?
The table below brings together the criteria worth checking for each process or group of processes. It does not replace the map, but it shows quickly which option is the natural one in a given place.
| Criterion | Buy and adopt the standard | Extend at vendor-provided points | Build beside the ERP | Modify the core |
|---|---|---|---|---|
| Does the process create advantage? | No | Partly | Yes, and it can be shown | Rarely the real reason |
| How often does regulation change it? | Often (VAT, e-invoicing, payroll) | Often or moderately | Rarely | Often, which multiplies the cost |
| Departure from market practice | Small, or a matter of habit | Moderate, in data or rules | Large, in the process logic | Any, but expensive |
| What happens at upgrade | Vendor handles it | Usually works, needs testing | Independent, depends on the API contract | Needs analysis, often rewriting |
| Time to go-live | Shortest | Short | Longer, but in stages | Short at first, long later |
| Who maintains it for years | Vendor and implementation partner | Internal team or provider, small scope | Own team or a long-term provider | A narrow group of specialists |
| Ownership of code and data | Data in vendor’s system, terms in contract | Own the extension code | Full, if written into the contract | Modification code often not portable |
| Exit risk | Depends on contract and data format | Moderate | Low for the process, depends on integration | High |
The most important column is the last one. Modifying the core wins on no row except the short time to a first delivery. That is why it should be treated as an exception requiring justification, not as one of several equal options in a proposal.
A second observation concerns the row “who maintains it for years”. Boards often judge options by implementation cost and leave the maintenance decision for later. Yet maintenance decides the outcome. A solution nobody will maintain is a bad solution, however cheaply it was built.
How do you compare the costs of the options before there is an implementation estimate?
At the architecture stage, there is no implementation estimate yet, and that is right, because an estimate made before the system boundaries are decided is guesswork. What you can compare is the structure of costs and how each behaves over time. That is enough to eliminate options that cannot be defended.
Run the comparison over seven to ten years, because that is how long an ERP typically lives in a mid-sized company. Over a shorter horizon, building and modifying look better than they are, because their maintenance costs have not yet accumulated. We described the general method for calculating the total cost of ownership of software separately; here we focus on what is specific to ERP.
The purchased standard has a predictable, spread-out cost: licences or subscription, implementation, training, periodic upgrades. The main risks are licence price increases in later years and the cost of changing ways of working, which the organisation bears rather than the IT budget.
Extensions at vendor-provided points add the cost of building each extension and retesting it at every upgrade. That cost stays moderate as long as there are a dozen extensions rather than hundreds, and they use public interfaces.
An application beside the ERP costs what any custom software project costs: a team, time and maintenance. For orientation, ARDURA’s software development page puts a typical three-person team (two developers and a QA engineer) at about EUR 14,500–28,700 per month, depending on seniority, with individual developer rates of roughly EUR 165–650 per day. The key difference from core modifications is that this cost grows with the scope of the application, not with the number of ERP upgrades.
Core modifications have the smallest cost in the proposal and the fastest-growing cost over time. Every upgrade and every regulatory change requires a review of all changes. In a migration to a new version, the cost can be many times what it took to build them in the first place.
A detailed ERP implementation budget, broken down by line item and estimated before tendering, is a topic for a separate article. At the option-selection stage, one exercise is enough: for each process in the “build beside” category, write down how many people, for how long, will be needed to maintain it after go-live. If those headcounts add up to more than the company can sustain, the boundary has been drawn too wide.
How do you protect data, code ownership and the ability to exit?
An ERP decision is a decision for years, so plan the exit from the start. Not because you intend to switch, but because a credible exit is the best protection of the commercial terms. We discussed this mechanism at length in our piece on avoiding vendor lock-in.
For a purchased system, data comes first. The contract should specify in what format and within what time the company can extract all of its data, including history and attachments, and at what cost. EU law helps here: since 12 September 2025, the Data Act has required providers of data processing services, SaaS included, to facilitate switching, and from 12 January 2027 it generally prohibits charging for the switch itself. The European Commission’s Digital Omnibus proposal would soften some of these rules for custom-made services, so check the final position before signing. The law is no substitute for a well-drafted exit clause, though.
For extensions and applications built beside the ERP, code comes first. The contract with the developer should assign intellectual property in the code to the company, with an obligation to hand over source code and documentation continuously, not only at the end of the engagement. The code should live in the company’s repository, not the provider’s.
For integrations, data contracts come first: documented interfaces, message formats and versioning rules. They decide whether, a few years from now, you can replace one part of the architecture, such as the purchased accounting system, without rewriting everything that talks to it. An integration built on direct access to ERP tables is a core modification in practice, just approached from the other side.
If the company already runs a heavily modified system and does not know its condition, start with an independent review. Before the board decides whether to extend the current system or replace it, a technical due diligence or code audit will show how much technical debt it carries and which changes are risky. At ARDURA, the Code Health Audit has a fixed scope, takes one to two weeks and starts from EUR 4,500.
How do the options differ in the accounts and the budget?
For the CFO, choosing an option is also a decision about how ERP costs will show up in reported results. These differences are worth understanding before the board meeting, because they can reverse a ranking of options compared on cash alone.
Custom software developed for the company, where the company controls the result, can in many cases be recognised as an intangible asset and amortised. Under IFRS, IAS 38 separates the research phase, which is expensed, from the development phase, which can be capitalised when its criteria are met. SaaS subscription fees are generally operating expenses.
The biggest surprises concern configuration and customisation costs for cloud ERP, and here the two major frameworks diverge. Under IFRS, the Interpretations Committee’s 2021 agenda decision concluded that configuration and customisation costs in a SaaS arrangement usually do not create an intangible asset, because the customer does not control the software being configured. For IFRS reporters, much of a cloud ERP implementation therefore hits the income statement immediately. Under US GAAP, ASU 2018-15 brought implementation costs of cloud service contracts into the internal-use software guidance, so qualifying costs are capitalised and amortised over the term of the arrangement. The same project can look quite different in a European subsidiary’s IFRS accounts and in a US parent’s GAAP accounts.
The takeaway for the board is not that one option is “better for accounting”. It is that the comparison of options should show both cash flows and the profit impact in each year, agreed with the finance team. An option that is cheaper in cash may look worse in the first year’s results, and vice versa.
How can you reach a decision in a few weeks, before signing anything?
Deciding the boundaries of an ERP does not take a year of analysis. It takes a few weeks of well-structured work that turns intuitions into checked facts. A workable sequence looks like this.
Weeks 1–2: process map. Workshops with process owners, the five questions above for each process, an initial split into three categories. The output is one page the board can approve or challenge.
Weeks 3–4: testing the standard. For processes in the “adopt” and “extend” categories, run demonstrations on the company’s real data, not the vendor’s demo data. The aim is to establish whether the standard really is enough and which extensions are genuinely necessary. Every extension gets a level: configuration, extension point, modification or application beside the ERP.
Weeks 5–6: validating the differentiating process. For the single most important process in the “build beside” category, run a short discovery phase: requirements, architecture, the integration contract with the ERP and a prototype of the key screen or algorithm. At ARDURA, discovery for software development projects usually takes one to two weeks and ends with a defined scope and architecture from which the next steps can be planned.
Weeks 7–8: board decision. On the table: the process map with categories, the list of extensions with levels, the result of the differentiating-process validation, the cost structure over seven to ten years and a list of assumptions. The board decides on the system boundaries and the first stage, not on everything at once.
This sequence has one important feature: the choice of a specific ERP product and a specific implementation partner comes after the boundary decision, not before it. Reversing the order, picking a product first and then fitting the company to it, is the most common path to core modifications.
If your current system is old and you are weighing whether to extend or replace it, also compare the options described in our article on modernising legacy systems. The ERP boundary decision and the fate of the old system are related, but they are not the same decision.
What are the key takeaways before an ERP decision?
“Build or buy ERP” is the wrong question, because an ERP is a dozen processes of very different character. A good decision is made for each of them separately, and its most important output is a boundary: where the purchased standard ends and your own code begins.
Remember six things. First, buy the accounting and tax core and adopt its standard; e-invoicing mandates across Europe change it more often than any single company should want to pay for alone. Second, distinguish the four levels of “extending” and ask vendors at which level each change will be built. Third, treat core modification as an exception that needs separate board approval, because its cost grows with every upgrade. Fourth, build only where a process creates an advantage you can demonstrate, and build it beside the ERP, integrated through published interfaces. Fifth, compare options over seven to ten years and from the perspective of reported profit, not just cash. Sixth, secure data, extension code and the ability to exit in your contracts before you sign anything.
If you need to validate a process that will be built beside your ERP, or design its integration with a packaged system, see how we work in custom software development, or book a call. We start with a short discovery phase that ends with a scope, an architecture and an integration contract you can take back to the board.