The future of ERP: software configured to the company

The future of ERP is software that is configured to each company instead of each company bending its processes to a standard package. AI makes business logic cheap to write and change, so the expensive part of an ERP shifts from customisation to the parts that must not change: the ledger, the controls, the audit trail and, in Germany, the rules of GoBD and HGB.

For 30 years, companies paid for ERP twice: once for the licence and again for adapting themselves to it. That second bill is what is about to shrink. Our view at Agent F is that most business software will be rewritten in the next two years or so, and that the winners will be the systems that stay strict where the law is strict and flexible everywhere else.

---

Why did companies end up adapting to their ERP?

Packaged ERP was a reasonable answer to an expensive problem. Writing software was slow and costly, so vendors built one system for thousands of customers and sold configuration as the way to fit it. Industry templates covered the common cases. Everything else became a customisation project, a workaround or a spreadsheet next to the system.

The result is familiar to anyone who has run finance in a growing company. Implementations of legacy ERP commonly take 12 to 18 months. Processes are redesigned to match the software rather than the business. Every change after go-live needs a consultant, so changes get postponed, and the system drifts further from how the company actually works. We describe how those workarounds pile up in ERP complexity debt.

Smaller companies avoided this by not buying an ERP at all. They combined basic accounting tools, point solutions and Excel. That works until the company reaches 30 or 50 people and the system change keeps getting deprioritised, because nobody wants a year-long project.

What changes when software becomes cheap to build?

Code generation changes the economics. When a working workflow, a report or a data model extension can be produced and tested in days instead of months, the logic of one package for everyone weakens. It becomes practical to build the system around the company: its entities, its cost centres, its approval rules, its way of invoicing.

That does not mean every company should write its own ERP. Generated software without structure is just a faster way to create complexity debt. The shift is subtler: the standard part of the system becomes smaller and more rigorous, and the company-specific part becomes larger, faster to change and owned by the business rather than a consultancy.

Three consequences follow:

• Implementation becomes configuration. Instead of mapping the company onto a template, the system is set up from the company's own data, documents and processes.
• Change becomes routine. A new entity, a new revenue model or a new approval rule is an adjustment, not a project.
• The interface becomes a conversation. People ask for a report or a change in plain language, and the system proposes it for review.

Regulation shows why this matters. German B2B e-invoicing becomes mandatory for sending in two steps, from 2027 for companies above 800,000 euros of prior-year turnover and from 2028 for everyone. In a packaged system, a change like that waits for the vendor's release and then for the consultant who adapts it to your setup. In a system built around the company, the new format becomes part of the existing invoice workflow, tested on the company's own data. The rules come from outside. How quickly they reach your process depends on the architecture.

The broader category is explained in what an AI-native ERP is, and how to tell a native architecture from AI added to an old one is covered in AI-native ERP vs AI added on.

What has to stay fixed when everything else becomes configurable?

This is the part the general debate about AI and software tends to skip, and it matters most in Germany. Finance software is where a company proves to its tax advisor, its auditor and the tax office that its books are complete and correct.

Some things should never be generated freshly per company:

• Double-entry logic and the integrity of the general ledger.
• GoBD (German digital bookkeeping rules), which require bookings to be traceable and unchangeable once recorded. Corrections are new entries, not edits.
• Retention: under § 147 of the German Fiscal Code (AO), books and annual financial statements must be kept for ten years, and booking vouchers for eight years since 2025.
• Period lock (Festschreibung), so that bookings in a closed month cannot be changed afterwards.
• The handover to the tax advisor (Steuerberater), in practice through DATEV, in a format they can work with.
• Human approval for anything that changes the books.

The more flexible the rest of the system becomes, the more these fixed points carry. A configurable ERP is only trustworthy if its core is stricter than the old one, not looser.

Why will the record of why matter as much as the record of what?

A classic ledger records what happened: an amount, an account, a date. The reasons sit elsewhere: the approval in an email, the contract in a shared drive, the explanation in someone's head. When that person leaves, the reasons leave with them.

As AI starts preparing more of the work, the reasons move into the system. An AI suggestion for an accrual comes with the documents it used and a confidence score. An approval is attached to the booking, with the person and the time. A change to a report definition is logged. GoBD has always asked for this in spirit, and an auditor will expect it when software prepared part of the bookkeeping. We look at how that trail works in audit trail in accounting.

What does this mean for the finance team?

The work changes direction. Less time goes into producing numbers: typing invoices, matching payments, rebuilding the same report. More time goes into reviewing and deciding: approving suggestions, explaining variances, setting the rules the system follows.

That makes the finance team's judgement more visible, not less necessary. Someone has to decide what counts as a one-off, which cost centre owns a contract and when a forecast assumption is wrong. AI agents can prepare that decision. They should not make it alone, which is the boundary we describe in agentic ERP.

For a CFO, the practical question is no longer which package fits best. It is how much of the system can be shaped around the company, and how strict the core stays while that happens.

How does Agent F approach the future of ERP?

Agent F is built on this thesis. Instead of industry templates, each company's system is configured through our AI-native ERP Factory: finance, operations and people on one data model, set up from the company's own structure and data. Implementation takes 4 to 10 weeks rather than the 12 to 18 months common for legacy ERP. The core follows HGB and GoBD, every AI action is a suggestion with a confidence score that a person approves, and everything sits in an immutable audit trail with a DATEV connection to the tax advisor.

If you are thinking about your next system, start with three questions. Which of your current processes exist only because your software forced them? Which parts of your finance must stay fixed by law, and does your current setup actually guarantee them? And how long does a simple change, such as a new entity or a new report, take today?

Learn how Agent F works, or see it on your own data at agent-f.ai/demo.