Customizing
Customizing refers to adapting a standard ERP system to a company's individual processes and requirements – mainly through settings and parameterization within the existing feature set, without changing the program code.
Customizing refers to adapting a standard ERP system to a company's individual workflows, structures and requirements – predominantly by configuring and parameterizing existing functions rather than programming new ones. Instead of developing software from scratch, a company buys a finished system and uses configuration options to set it up so that it reflects its own processes: which number ranges apply, how an order becomes an invoice, which documents trigger which postings, which fields are mandatory and who has which permissions.
The term originally comes from the SAP world but is now used vendor-neutrally for the setup and adaptation phase of any ERP system. The key idea is "configuration instead of programming": the system stays on the standard and is adapted to the company through the levers it provides. This makes customizing the core of every ERP implementation – it determines how well the system supports real-world work, and at the same time how maintainable and update-capable it remains in the long run.
At a glance
- Adapting a standard ERP to your own processes – without changing code
- "Configuration instead of programming": settings and parameters instead of custom development
- Covers number ranges, document flows, fields, roles and permissions, workflows
- Draw the line to development (extension/modification) carefully – for update capability
- A central part of every ERP implementation; the basis in requirements and functional specs
What does customizing include?
Customizing covers all the settings with which an ERP can be adapted to a company within its intended framework. This includes basic organizational structures such as clients, legal entities, sites and warehouses, as well as defining number ranges for documents, customers and items. On the process level, it defines how a transaction runs through the system: which document types exist, how a quotation becomes an order, a delivery note and finally an invoice (order-to-cash), and which status and approval steps are passed through along the way.
On top of this come settings for tax rates and account determination, pricing and discount logic, fields and mandatory entries in screens, print forms and document templates, as well as roles, user permissions and approval workflows. Many systems also let you set up additional fields, simple automations or rule-based flows without programming. All of this belongs to customizing in the narrower sense, because it uses the standard functions and merely parameterizes them.
Customizing vs. parameterization
The terms customizing and parameterization are often used synonymously, but they refer to different levels. Parameterization is purely setting values and switches in the fields provided – for example entering a tax rate or a default currency. Customizing is the broader term: it includes parameterization, but goes further and also covers setting up document flows, role models, forms and rule-based processes. Simplified: every parameterization is customizing, but not every customizing is limited to setting individual parameters.
Customizing in the ERP implementation project
In an ERP project, customizing is the central implementation phase between conception and go-live. The basis is the company's requirements captured in the requirements specification and their answers in the functional specification. On this basis, consultants and key users set up the system, usually in a separate configuration or test client, before the settings are transferred to the production environment. This typically happens iteratively: configure, check with realistic test data, readjust.
Customizing and data migration are intertwined here, because many settings – such as chart of accounts, number ranges or field structures – have to be in place before master and transactional data can be sensibly imported. In the end there should be a documented, tested system state that reflects the agreed processes. Clean documentation of the customizing is important, because later adjustments, updates and error analyses can only be traced if it is clear why the system was set up the way it was.
Who does the customizing?
Customizing is typically teamwork between the implementation partner and the business departments. Consultants bring system knowledge and best practices, while key users from the departments know the real processes and judge whether a setting is practical. Part of the ongoing customizing – such as new number ranges, form adjustments or permission changes – is often handled by trained administrators within the company after go-live. Especially with cloud and SaaS ERP, this is deliberately kept low-threshold so that user companies can make adjustments without deep development knowledge.
Why customizing matters – and where its limits lie
Good customizing determines whether an ERP makes daily work easier or harder. If processes are mapped cleanly, users work faster, make fewer mistakes and are more likely to accept the system. If too little or the wrong things are configured, workarounds, duplicate entries and frustration arise. The big advantage of customizing over true custom development: because the program core stays untouched, the system remains update-capable – vendor releases can be applied without having to reprogram adjustments every time.
But this is exactly where the limit lies. Not every requirement can be covered by settings; for some special processes the standard is not enough. Then you have to decide whether to adapt the process to the standard ("as little as possible, as much as necessary") or extend the system through programming. Excessive, unplanned customizing leads to an overly complex, hard-to-maintain system and can result in de facto vendor lock-in. As a rule of thumb, therefore, stay close to the standard and make individual adjustments deliberately and with justification.
Distinction: customizing vs. extension and modification
Customizing must be distinguished from true software development. With customizing, nothing is programmed – only the configuration options provided by the vendor are used. If that is not enough, an extension comes into play: additional functions via defined extension points, add-ons, plug-ins or custom developments that run alongside the standard without changing it. Such extensions are more effort than customizing, but usually remain update-capable because they do not touch the core.
The third level is modification: directly intervening in the vendor's standard program code. It solves almost any requirement, but is considered critical because every modification has to be checked and often adjusted again with each update – which drives up maintenance costs and risk. Connecting other systems via API, interface or middleware is also strictly speaking not customizing but integration. In practice the order applies: first adapt the process to the standard, then customize, then extend – and modify only in exceptional cases.
DACH specifics and compliance
In the DACH region, a significant part of customizing is driven by legal and tax requirements. Chart of accounts (such as SKR 03/04), tax keys and account determination must be set up so that postings run cleanly into financial accounting and for handover to DATEV or BMD. Document templates and invoice layouts must be adapted to the mandatory details under VAT law and to the e-invoicing formats (XRechnung, ZUGFeRD). Number ranges for invoices must also be configured so that every invoice number is assigned sequentially and uniquely (Section 14 UStG).
On top of this come the requirements of the GoBD: document flows, change logs and permissions must be set up so that records remain unchangeable, traceable and audit-proof. How a system was actually set up therefore belongs in the procedural documentation, which may have to be presented during a tax audit. In the DACH context, customizing is thus not only a question of optimizing process convenience, but also of compliance – incorrectly set options can have tangible tax consequences.
Example
Practical example: an e-commerce retailer sets up its new ERP
An online retailer with 25 employees introduces a new ERP that is meant to bring together shop, marketplaces and accounting. During customizing, the basic structures are set up first: two warehouses, separate number ranges for shop and marketplace orders, the document flow from the incoming order via delivery note to the invoice, and automatic status changes as soon as the shipping provider picks up a parcel. Tax keys and account determination are aligned with SKR 04 so that the postings are handed over cleanly to DATEV.
For one special case – a customer-specific bundle logic for sets – the standard is not quite enough. Instead of modifying the code, the company deliberately decides to adapt the process slightly to the standard and add only a small, update-capable extension. This keeps the system lean and easy to update going forward. The entire configuration is documented and feeds into the procedural documentation.
Frequently asked questions
Matching ERP systems
Related services
Questions about Customizing in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.