Parameterization
Parameterization means adapting an ERP system to your own business processes solely through its intended settings and parameters – without changing the program code. The standard stays intact but behaves according to the chosen values, such as number ranges, posting rules or document workflows.
Parameterization is the practice of adapting an ERP system to a company’s individual requirements purely by setting the intended parameters and options – that is, without touching the program code. Instead of programming new functions, you choose from the options the vendor provides: How are the number ranges for documents structured? Which method is used to value inventory? Which payment terms, dunning levels or rounding rules apply? The result is a system that behaves in a company-specific way while technically remaining the standard as delivered.
The term is often used synonymously with, or closely alongside, “configuration” and “customizing,” but in the narrow sense it refers precisely to control via parameter values. This makes parameterization the gentlest way to adapt an ERP to your own organization: it preserves the system’s update capability and maintainability because no individual programming has to be carried along. In almost every ERP implementation project, parameterization is therefore one of the central and most time-consuming steps before the system goes live.
At a glance
- Adapting an ERP via settings and parameter values – without programming
- The standard as delivered stays intact and thus remains update-capable
- Typical parameters: number ranges, posting rules, document workflows, permissions
- Gentler than customizing through code – lower risk, fewer follow-up costs
- A core task of every ERP implementation, often set down in the requirements spec
What is set during parameterization?
A modern ERP ships with thousands of adjustment options through which its behavior can be controlled. During parameterization, these values are set so that the system reflects the company’s real-world processes. The settings range from simple defaults – such as the home currency, the standard tax rate or the format of invoice numbers – to complex rule sets that govern entire process chains.
Typical areas of parameterization are document workflows (which document types exist and how an order becomes a delivery note and then an invoice), posting logic (which general ledger accounts are posted to automatically), inventory management (valuation method such as FIFO, handling of minimum stock levels), pricing and discount rules, and the permission and role concept. Number ranges, chart of accounts, cost centers and the assignment of process steps to responsible staff also belong here.
Client- and role-dependent parameters
Many ERP systems are multi-client capable: parameters can be set differently per client, company or location, so that several firms operate on one installation with their own number ranges, charts of accounts and tax rules. In addition, many settings are role- or user-dependent – for example, which modules an employee sees, which documents they may approve, or which default values appear in their input mask. These layers make parameterization powerful, but also maintenance-intensive.
Parameterization vs. customizing and custom development
Parameterization needs to be distinguished from deeper adaptations, even though the terms blur in practice. Parameterization uses only the adjustment options the vendor has provided – you stay fully within the standard. Customizing is often used as an umbrella term, but partly already refers to extending via form designers, workflows, custom fields or scripts that go beyond pure parameters. Custom development, finally, programs new functions into the source code or through extension points.
The rule of thumb is: parameterize first, then configure, and only develop as a last resort. Each stage increases effort, cost and risk and can jeopardize update capability, because customer-specific code has to be checked and adjusted with every new version. Pure parameterization, by contrast, is update-safe because it only uses documented settings. Whoever solves as much as possible via parameters lowers operating costs in the long run and reduces dependence on developers.
Why “as much standard as possible” applies
Every piece of individual programming is a special case that has to be maintained, tested and carried along during migrations over the long term. Experienced project teams therefore try to meet requirements through parameterization first and to adapt their own processes to the proven standard wherever it makes sense. This reduces not only costs but also the risk of vendor lock-in through hard-to-replace in-house developments.
Parameterization during ERP implementation
In an ERP implementation project, parameterization is the step in which a generic standard system becomes a system usable by the company. The basis is the requirements captured in the requirements and functional specifications: these are translated into concrete parameter values and usually set up first in a test or configuration client. Key users then check, based on real processes, whether the system behaves as desired before the settings are released for production operation.
Because many parameters depend on one another and are hard to change after go-live – a number range that has already been used, or an inventory valuation method, can barely be switched cleanly after the fact – parameterization needs to be carefully planned and documented. Changes to sensitive settings ideally run through a governed change management process, so it remains traceable who set which value when and for what reason.
Benefits and limits of parameterization
The great advantage of parameterization is the ratio between depth of adaptation and effort: a company gets a largely tailored system without bearing the costs and risks of software development. The system stays update-capable, vendor-supported and easier to migrate. Cloud ERP and SaaS systems in particular deliberately rely heavily on parameterization, because they are operated centrally and individual code in the client is often not possible there at all, or only through controlled extension mechanisms.
The limit of parameterization lies where the standard simply does not provide a required function. Then the only options are to adapt the process to the system, to configure an extension or – as a last stage – to develop individually. Another limit is complexity: an over-parameterized system with countless special rules can become hard to maintain and opaque to users. Good parameterization therefore does not mean setting every conceivable option, but choosing the right values deliberately and with documentation.
DACH specifics in parameterization
In the DACH region, a considerable part of parameterization concerns tax and commercial-law correctness. Charts of accounts such as SKR03 or SKR04, VAT rates and keys, the assignment of postings to the correct general ledger accounts, and the export formats for DATEV or BMD must be set up cleanly so that financial accounting and the advance VAT return are correct. Audit-proof, GoBD-compliant document management with gap-free number ranges is also controlled via parameters.
On top of this come the requirements of electronic invoicing: formats such as ZUGFeRD and XRechnung, as well as transmission channels like Peppol, are activated through parameterization and assigned to the appropriate customer and document processes. Because legal requirements change, parameterization in the DACH environment is not a one-off task but must be continuously adapted to new rules – such as the e-invoicing obligation. A well-kept process documentation records which settings are in place for which legal reason.
Example
Practical example: online retailer parameterizes its new ERP
An e-commerce retailer with around 40 employees is introducing a new cloud ERP. Instead of having functions programmed, the project team implements the requirements through parameters: it sets up separate number ranges for quotes, orders, delivery notes and invoices, chooses FIFO as the inventory valuation, stores the SKR04 chart of accounts and defines payment terms, dunning levels and discount tiers for B2B sales.
In addition, roles and permissions are parameterized so that the warehouse team sees only picking and shipping steps, while accounting has access to payments and dunning. For electronic invoicing, the team activates ZUGFeRD and assigns it to business customers. All settings are first checked and documented in a test client before they go live – this keeps the system fully within the standard and thus update-capable.
Frequently asked questions
Matching ERP systems
Related services
Questions about Parameterization in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.