ERP for the Mittelstand: How Custom Software Extends Your ERP

The IT agenda for 2026 reads like a task you cannot solve.

On one side, the compliance list. In Germany, issuing electronic invoices becomes mandatory in B2B from 1 January 2027, a year later for smaller companies. The NIS2 implementation act has been in force since December 2025 and has expanded the circle of supervised companies from around 4,500 to roughly 29,500, industrial production explicitly included, with no transition period. The EU AI Act has been generally applicable since 2 August 2026. Anyone running SAP ECC has mainstream maintenance until the end of 2027 and a paid extension until 2030 after that.

On the other side, the budget. According to the Lünendonk study on the CIO agenda, only 55 percent of IT decision-makers expect a rising IT budget for 2026. A year earlier, 79 percent had expected one. At the same time, 91 percent want to invest more in security and 80 percent in IT modernisation to reduce technical debt.

And in between, usually unmentioned, the actual point: the process that sets your company apart from the competition still runs in an Excel file on a network drive. Not because nobody noticed, but because the ERP could not represent it and there was never room for a project of its own.

The answer rarely is a bigger ERP and almost never another island solution. It is a lean ERP core plus a few targeted applications of your own on clean interfaces. That is not an attack on your ERP vendor. It is precisely the architecture the vendors themselves recommend.

What ERP software is, and what it is not

Briefly, because the term is used so often that it has lost its edge.

An ERP system (Enterprise Resource Planning) is the central administration of your company's business resources on one shared data model. Customers, articles, orders, inventory, documents, costs and accounts sit in one place, and the modules for purchasing, sales, warehousing, production, finance and HR all work on that data. That is the real meaning of ERP software, and it is not in the feature list but in this one sentence: one truth, many views.

That also says what an ERP is not. It is not a toolbox in which every process in your organisation finds a home. It is a system of record for standard transactions: transactions that run roughly the same way everywhere, that are regulated, that must be documented and audit-proof, and that do not distinguish you from anyone.

This distinction is the axis the entire rest of this post turns on:

• Systems of record hold the binding data. Accounting, inventory, documents, master data. The standard wins here, always.
• Systems of differentiation represent how your business works. The order in which you schedule jobs. The way you inspect. The rule your purchasing department plans by. The standard loses here, because that standard does not exist.

An ERP system that tries to be both ends up bad at both.

The lean ERP as a foundation, not a compromise

There is a reading of "custom software" that I consider wrong: the one in which the ERP is the problem. It is not. For everything standardised and regulated, a well-implemented ERP system is the cheapest and most durable solution you can buy. Financial accounting, tax, payroll, inventory management, document flow, and from 2027 electronic invoicing: you want to neither build nor maintain that yourself.

The decisive word is lean. A lean ERP is one that runs as close to the standard as possible. In practice, that is exactly where the money is.

Because every modification in the core is a loan you repay at the next upgrade. And for many, the next upgrade is due. For SAP customers, mainstream maintenance for ECC 6.0 ends on 31 December 2027, extendable to 2030 against a surcharge of two percentage points on the maintenance fee. An honest move to S/4HANA takes eighteen to thirty months in a mid-sized company, and according to surveys around 60 percent of these migrations miss their budget, schedule or quality target. I name SAP here only as an example, because the deadline is so well dated. The mechanics are the same with every ERP: whatever you built into the core, you migrate with it, test again and pay for twice.

The vendors now say so themselves. SAP calls it Clean Core, Gartner calls it Composable ERP, as the successor to "Postmodern ERP" formulated in 2013. The core statement is identical in every variant: keep the core standard-near and extend it alongside, over interfaces, rather than inside it.

And customers are following. In the DSAG Investment Report 2026, the SAP Business Technology Platform is the most sought-after SaaS solution with 39 percent high and medium investment intent, up from 33 percent in 2024. What it is used for is remarkably clear: 45 percent name complex integration tasks, 38 percent data-driven analysis. The report concludes that investment decisions are guided not by visions but by feasibility, cost-effectiveness and integration capability.

Put differently: the market is currently spending a great deal of money to move extensions out of the ERP core and onto its interfaces.

Where the ERP hits its limits in the Mittelstand

A standard product presupposes a cleanly defined, idealised process. The Mittelstand lives on processes that have grown over years, that sit in people's heads instead of manuals, and that do exactly what makes this one company successful. More than 70 percent of mid-sized companies have not fully documented their end-to-end processes. That is not sloppiness, that is the nature of the thing.

We have covered this contradiction in detail elsewhere, so here just the pointer: Can an SME even build custom software for the Mittelstand?

More interesting is where the limit reliably runs in the Mittelstand. In our experience, almost always at the same four places:

Production and shop floor specifics. Detailed scheduling at the machine, setup sequences, special cases every foreman knows and no module anticipates.

Coordination across legal entities and sites. As soon as several units are simultaneously supplier and customer to each other, the ERP's notion of "one" order ends.

Inspection and QA workflows. Who inspects what, in which order, with which approval, with which evidence. Hardly any business does this the way the business next door does, and hardly any inspection result fits into a standard field.

Costing, configuration and planning. Everywhere a rule decides rather than a form. How much do we order, how do we price a custom build, which variant can even be manufactured.

How you notice you are standing at this limit, without an analysis project:

• A list is kept alongside the system, and the list is right.
• The same information is captured twice, in two places, by two people.
• There is one reporting figure everyone believes, and it is produced in a spreadsheet.
• A transaction regularly waits for a person, not for an approval.
• Asked why a result looks the way it does, someone answers with a rule of thumb, not with system logic.
• At the last ERP update, something broke that you had built in yourselves.

What such a point looks like in reality, we wrote up on a concrete project in which purchasing no longer believed its own order planning: Anatomy of a process optimisation.

Two ways out of the gap, and only one scales

Once the gap is recognised, there are two reactions. Both feel pragmatic, and they differ by an order of magnitude in follow-up costs.

Way one: the island solution. You buy a specialised tool for exactly this case. It handles the case really well. But it also brings along: its own customer list, its own article master, its own user management, its own notion of permissions, its own maintenance contract, its own update risk and, since NIS2, its own share of your security concept.

The expensive part is not the first tool. It is the third. Because costs do not grow with the number of systems, but with the number of connections between them, and that number grows considerably faster. Then there is the part that appears on no invoice: from two copies of a master data truth onwards, it is no longer settled which one applies. From then on your organisation does not discuss decisions, it discusses numbers.

The DIHK digitalisation survey 2026, in which 4,686 companies took part, describes exactly this pattern from the inside: as the biggest obstacles to digitalisation, businesses name time (58 percent) and complexity (56 percent), well ahead of a shortage of IT specialists (29 percent). It is not inability that slows things down, it is administering what has grown.

Way two: the extension. You build the missing domain logic as an application of your own, but without its own data household for things the ERP already owns. It reads customers, articles and orders from the ERP instead of keeping track of them. It uses the sign-in and the roles that already exist in the organisation. It writes its result back where it belongs.

So the difference between the two ways is not "buy or build". You can buy a tool that hangs cleanly off your ERP, and you can build an application of your own that still drags along its own customer master.

The difference is whether, afterwards, one single place in the organisation still says authoritatively who this customer is and what this article costs. Or two.

Data integration: duplicate or consolidate?

That brings us to the question on which such initiatives are technically decided. And because a lot of vocabulary gets muddled here, first two terms worth keeping apart:

• The system of record is the place where a data object originates and applies authoritatively. There is exactly one per object.
• The consolidation point is the place where data from several systems comes together for analysis. It is authoritative for analyses and never for transactions.

Whoever confuses the two builds a data warehouse that eventually gets written back into. That is the beginning of the end of traceability.

Building on that, there are four patterns, and the choice is a domain decision, not a matter of taste:

So copying has a legitimate place, but a narrow one: offline capability, read load, decoupling from maintenance windows, history and evidence, and migration phases. What copying never legitimises is convenience at the interface.

And so the decision does not evaporate inside the project, it belongs in a document a CIO can demand before a line of code exists. We call it the data ownership matrix. It is a table, it fits on one page, and it answers five questions per data object:

The most important effect of this table is the one you do not expect when filling it in for the first time: some of the rows are owned by the extension, not by the ERP. Inspection results, machine feedback and forecasts are data for which your ERP has no responsible field and should not have one. As soon as that is written down, the extension is no longer an appendage but a regular part of your landscape with clearly outlined responsibility.

The architecture as a CIO should see it

Let us start with the case in which you do not need an architecture yet.

The first application of your own may hang directly off the ERP. It uses the ERP's interfaces, fetches customers and articles, writes its result back, done. That is not a stopgap and not incurring debt, it is the right decision: building an integration layer for a single connection would be effort without return.

The point at which it tips over is the second extension. And for a reason that looks harmless on a slide and is not harmless in operation: it is not the number of applications that grows, but the number of connections between them. Three extensions that have to know one another are not three links, but six. On top of that, each of these links contains the same work over again: signing in to the ERP, field mapping, error handling, restart after a failure. At the next ERP update, each one is reworked and tested individually.

From here on, the layer in between pays for itself. Not because architecture is beautiful, but because it does this work once instead of six times. At board level this needs no component diagram. It needs three bands and five rules.

At the top your extensions, each for exactly one process that sets you apart. In the middle an integration layer made of contracts rather than cables. At the bottom the ERP core, standard-near and untouched. Beside it, deliberately set apart, a read-only data platform for reporting and AI.

The five rules that hold this architecture together:

1. One system of record per data object. Not per system, per object. It is in the data ownership matrix, otherwise it does not count.
2. No write access into ERP tables. Only through supported interfaces. Whoever writes directly into the database has just made their ERP vendor's maintenance contract worthless.
3. Domain logic belongs in the extension. Not in modifications of the core. That is the same thought your ERP vendor calls Clean Core.
4. Every interface has a contract. What arrives, in which version, what happens on an error, how it restarts after a failure. An interface without a restart is an outage with a schedule slip.
5. Replaceability is part of the design. An extension that talks exclusively through contracts survives a change of the ERP underneath it.

Rule five is the one that ends most of the discussion at CIO level. If a migration is coming anyway, that is no argument against an application of your own. It is the argument for moving it now, out of the core and behind a contract. What sits beside the ERP and speaks only through interfaces travels along with the migration. What sits in the core becomes part of the migration risk.

Two things lie across all three bands and are regularly forgotten: one identity instead of a user management per application, with permissions derived from the existing directory and from the ERP. And one operating concept with logging, monitoring, restart and named responsibility. Since the NIS2 implementation act, the latter is no longer merely good practice. Breaches of the new obligations carry fines of up to 10 million euros or two percent of annual turnover, and the reporting deadlines are 24 hours for the early warning and 72 hours for the notification.

Why this is a differentiation topic and not an IT topic

Nobody differentiates with the general ledger. That is not a provocation, it is the entire reason standard software exists and why it is good.

You differentiate with what your customer notices: that you cost a custom build in four days and not in two weeks. That your inspection evidence arrives complete with the delivery. That you plan an order sensibly even though four legal entities are involved. Those are processes, not features, and for processes there is no standard, because otherwise they would be no advantage.

Then there is a point that has migrated from HR into IT strategy. According to the DIHK skilled labour report 2025/26, 36 percent of companies cannot fill open positions, and it hits hardest exactly the size classes this post is about: 44 percent of businesses with 20 to 199 employees and 47 percent of those with 200 to 999.

When additional people are no longer an available option, the only remaining lever is that the work fits each person better. That is precisely the economic core of an extension: not more features, but less friction where your volume is created.

And the boundary stays the same one we always draw: custom exactly where your process sets you apart from the competition. Everything else you buy in. Whoever builds their own payroll is burning money, and we would advise against it.

The phases this takes shape in

The most common failure in these initiatives is not technical. It is that the hardest question gets asked too late. Hence this phase model, in which the interface question moves forward.

Phase 0: process and system survey

• Goal: understand what actually happens, not what the manual says.
• Result: the as-is process, an inventory of the systems and tables involved, and the first version of the data ownership matrix. Deliberately no requirements specification.
• Who must be there: the people who run the process every day, not just their management.
• Abort criterion: if it turns out here that the process can be standardised, stop and take the ERP module.

Phase 1: integration feasibility

• Goal: prove that your ERP can deliver and accept the required data at all, at sufficient speed and without licence surprises.
• Result: a small working link against the real system, plus a statement on volumes and response times.
• Who must be there: your ERP partner, and here, not later.
• Abort criterion: if the required data is only reachable through direct table access, the design is wrong, not the ERP.

This phase costs a few days and saves projects. The classic mistake is to build half a year of domain logic and then discover that the interface does not provide what was assumed.

Phase 2: one complete process in production

• Goal: a single transaction, but from beginning to end, with real data and a small group of users. Not a prototype, not three half cases.
• Result: the first process that genuinely runs in the new tool.
• Who must be there: the future users, as users in live operation, not as a test group.
• Abort criterion: if the users are still keeping their list after two weeks, the scope is wrong, and more features will not help.

How to scope this first vertical slice onto the core use case, we wrote up here: The requirements cycle: why a one-time specification does not work.

Phase 3: roll out and switch off

• Goal: take the old solution away. That is the actual content of this phase, and the part most often left undone.
• Result: the Excel file is archived and out of circulation, the replaced tool is cancelled.
• Who must be there: whoever owns and maintains the old solution today, otherwise it lives on.
• Abort criterion: if nothing disappears here, the project has made the landscape more complicated.
• Rule of thumb: An island you do not switch off is not a replacement, it is an additional island.

Phase 4: operation and further development

• Goal: that the extension becomes a normal system of your organisation.
• Result: monitoring of the interfaces with alerting, a rehearsed restart, a named business and technical responsibility.
• Who must be there: the named owners, from now on permanently and not per project.
• Standing rule: a regression test that runs against the interface contracts before every ERP update.

This last rule decides whether the solution is still loved in three years or merely tolerated.

Compliance lies across all of it, and from the start: take permissions from the ERP instead of reinventing them, log who changed what, and carry the extension in the organisation's security concept.

AI as a tool in the project, not as a product promise

This is explicitly not about AI features in the finished software, but about AI as a tool during the integration. That is the part rarely discussed in board presentations and the one that changes project duration most noticeably.

Where it genuinely helps us:

Process survey. Interviews and shop floor conversations as transcripts, and from them a first structured process description with the open questions. That replaces no conversation, but it replaces the note-taking and makes visible where two participants describe the same step differently.

Excel archaeology. The process sits in a spreadsheet that has grown for eleven years. Formulas, macros, special cases in hidden columns. A model can extract these rules and turn them into a readable list you can walk through with the business. That is the work nobody wanted to do before, and it is the actual treasure of requirements.

Interface mapping. Generating mapping proposals from the ERP's field catalogues and interface descriptions instead of typing them out.

Test cases and reconciliation. Generating test data for interfaces, and during the switchover comparing the results of old and new to find deviations rather than hoping for none.

Documentation and handover. The part that, without tooling, always happens last and too briefly.

Plus three guardrails we do not negotiate. AI proposes, people decide. No extracted rule goes into production without a domain review, because a plausibly worded wrong rule is more expensive than a missing one. And: the saving is real, but it is not free. In the Bitkom study report 2026, 33 percent of companies say AI turned out more expensive than expected, and as the biggest obstacles they name a lack of AI competence in the team (53 percent), uncertainty about data protection (41 percent) and unclear costs (37 percent). Whoever uses AI in a project has to be able to use it, not merely license it.

How AI fits safely into the landscape

Up to here, AI was a tool. It helped in the project and then left the room again. From now on we are talking about something else, and this shift is bigger than it sounds.

An AI feature in your finished extension is not temporary help, it is a system component. It runs in operation, it processes real data permanently, and it needs a named responsibility, logging and a rehearsed restart like every other system from Phase 4. With that, it sits in your security concept.

This difference shifts the question. With the tool you ask: may I send this data through this model once? With the system component you ask: may this model process this data permanently and unsupervised, and who answers for the result? You need the classification that follows for both, because the tool in the project also sees real data. For the system component it is simply not negotiable.

Where this component belongs has already been decided by the architecture above. Because the ERP core stays standard-near, the extension is the natural place for AI features. There you may experiment, there you can roll back, and there a failed attempt does not endanger your accounting. Gartner expects that by the end of 2026 around 40 percent of enterprise applications will ship task-specific AI agents, up from less than 5 percent in 2025. So the question is less whether AI enters your landscape than at which point it does.

That leaves the question of where the model itself runs. The answer given is usually too technical. The order is a different one: first the classification of the use case, then the choice of operating model.

Because the risk class under the AI Act attaches to the purpose of use, not to the data centre. A model in your own building does not turn a high-risk use case into a harmless one. Since 2 August 2026 the regulation has been generally applicable, with transparency obligations and national supervision, and with fines of up to 15 million euros or three percent of worldwide annual turnover. The obligations for high-risk systems have, however, been postponed, by way of the so-called Digital Omnibus. That is what the EU calls an omnibus act that amends several existing regulations at once instead of touching each one separately. There is a dedicated edition of it for the AI Act, in force since 27 July 2026: it moves the high-risk obligations to 2 December 2027 for standalone systems under Annex III and to 2 August 2028 for systems embedded in regulated products. The reason is sober: the harmonised technical standards and the assessment bodies were not ready in time. So the requirements have not become softer, they merely arrive later. That is time to prepare and no reason to defer the topic. And important for you as a deployer: even if the provider supplies the technical evidence, you remain responsible for how the system is used and monitored in your processes.

From this follow three operating models, and all three are legitimate, for different cases:

On-premise or at the edge of production. The model runs on your own hardware, no data leaves the building. Fitting if you process design, production or costing data whose leakage would touch your business, if you run consistently high volumes, or if a use case falls into the high-risk class and you want logging and traceability entirely in your own hands. The price is model choice and operating effort. Whether it pays off is a question of volumes and not of attitude, and we have worked through it here: Is a local AI setup really worth it for a company?

Sovereign hosting in the EU. Operation in a European region with a data processing agreement, without using your data for training, with dependable statements on data retention. Fitting for the majority of personal and business-critical cases, including high-risk ones, if the documentation and logging obligations are covered contractually and technically. The field of providers in Germany is now concrete, and digital sovereignty is not by accident one of the top investment priorities for 2026 and 2027 in the Lünendonk survey.

Any cloud. For non-critical data and tasks without personal data and without trade secrets. Translations of public texts, help with phrasing, research in open sources. Insisting on sovereign hosting here costs money without return.

Two architectural decisions keep this choice open instead of casting it in concrete once:

The model sits behind an access point of your own. Your applications talk to one place in your landscape, not directly to a provider. Then the operating model is selectable per use case and changeable later, and you log in one place what was asked and what was answered. You need that both for the transparency obligations and for traceability towards your own people. On choosing such access points and on data residency we wrote here: OpenRouter explained, and what it means for EU teams.

The AI never talks directly to the ERP. It accesses the same interfaces as the extension itself, with the same permissions. That keeps your ERP roles effective, and nobody can see data through an assistant that they would not be allowed to see in the business system. That is the rule most often skipped in pilot projects, and the only one that prevents your permission concept from being quietly circumvented.

That this caution is not a brake but a precondition is shown by the adoption gap: according to the DIHK survey 2026, 41 percent of companies actively use AI, but in the Mittelstand only 20 percent, and the obstacles named around data and AI are legal uncertainty (59 percent) and technical hurdles (50 percent). Whoever settles the classification and the operating model beforehand belongs to the 20 percent instead of waiting for clarity. How to build trust step by step rather than risking everything at once is here: Explainable AI for SMEs.

Five questions for your next IT meeting

If you want to take only one thing away from this post, take these questions:

1. Which of our processes genuinely sets us apart from the competition? If the answer is longer than three processes, it is not finished yet.
2. Which modification in our ERP will we pay for a second time at the next upgrade? And which of that could sit alongside instead?
3. Which system is the system of record for our ten most important data objects? If there is no document on that, it is the first task and it costs an afternoon.
4. Which of our island solutions could we switch off? And why did that not happen in the last project?
5. Which AI use case would we be allowed to run in production with today's operating model? If the answer is "none", the problem is not the AI but the missing classification.

The decision at stake here is not ERP or custom software. That juxtaposition has never helped anyone, because both sides are right, just in different places.

The decision is whether your ERP may stay lean so that your difference can grow somewhere else.