ERP customization governance is the set of rules that decides what may be customised, who approves each change, how it is documented, how upgrades are protected and how a change is rolled back. A workable framework has five parts: a standard-first policy, tiered decision rights, a customization register, an upgrade impact test and a tested rollback.
Our guide to ERP customization vs configuration explains what the two terms mean and which changes break upgrades. This guide goes one level deeper. It is the operating model for an ERP implementation program: who holds decision rights, what a change board does, how an upgrade impact test works and how a customization is withdrawn when it goes wrong. It is written for the CIO, COO, CFO or program sponsor who wants the rules agreed before the first request arrives, not after fifty have piled up.
Key takeaways
- Governance exists to keep the system upgradable and auditable, not to say no. Most requests should be met by configuration or a process change.
- Classify every request into a tier. The higher the tier, the more senior the approver and the more evidence required.
- Decision rights belong to named roles, not committees in general: a business owner, a process owner, a design authority and, for control-relevant changes, finance.
- Every customization needs a register entry, an automated or scripted test and a rollback path before it reaches live users.
- Run an upgrade impact test against the register before each vendor release, in a copy of production.
- On cloud ERP, stay inside the vendor's documented extension points. That is what keeps upgrade paths intact.
What is an ERP customization governance framework?
It is a short, written policy plus a standing decision process. The policy says what kinds of change are allowed. The process says who decides, what evidence is needed and how the result is recorded. Together they stop customization from accumulating one reasonable request at a time.
| Component | What it answers | Typical artifact |
|---|
| Standard-first principle | Must we try configuration or a process change before building? | One-page policy signed by the sponsor |
| Tier model | How risky is this change to upgrades and controls? | Tier definitions with examples |
| Decision rights | Who may approve each tier? | RACI table |
| Register | What exists today, who owns it, how is it tested? | Customization register |
| Upgrade impact test | Will this survive the next release? | Test routine and sign-off record |
| Rollback | How is it withdrawn safely? | Rollback note per change |
What may be customised, and what may not?
Allow changes in proportion to how little they touch the vendor's standard code. A four-tier model works for most programs: configuration, personalisation, extension and core modification. The last is refused by default. The table shows a common split, and you should adjust the examples to your platform.
| Tier | What it is | Example | Who may approve | Evidence required |
|---|
| 1. Configuration | Settings the vendor provides | Approval limits, numbering, tax codes | Process owner | Configuration workbook entry |
| 2. Personalisation | Screen, report or field changes by role | Extra field, saved view, report layout | Process owner plus design authority | Register entry |
| 3. Extension | Separate code using supported hooks and APIs | Credit-hold override with approval log | Design authority; finance if it touches controls | Register entry, automated test, rollback note |
| 4. Core modification | Changing vendor or base code | Altering a costing calculation | Steering group only | Proof that tiers 1 to 3 cannot meet the need, quantified upgrade cost, rollback plan |
Two rules do most of the work. First, a request cannot skip tiers: the requester must show that the lower tier was tried or is impossible. Second, anything that changes posting, tax, approvals or access rights is reviewed by finance or internal audit whatever its tier, because it changes a control.
Who approves an ERP customization?
Give each decision to one accountable role and use the change board to review, not to vote. Committees dilute accountability, so every request needs a named person who says yes or no, a named person who is consulted, and a record of both decisions in the register.
| Role | Decides | Consulted on |
|---|
| Business owner of the process | Whether the problem is real and worth solving | Workarounds, volume, benefit |
| Process owner | Whether configuration or a process change can meet it | Training and procedure impact |
| Design authority (architect or lead consultant) | Tier, technical approach, upgrade impact | Integrations, performance |
| Finance or controller | Any change touching posting, tax, approvals or audit trail | Segregation of duties |
| Security or IT owner | Access, data exposure, hosting impact | Identity, logging |
| Steering group | Tier 4 changes and budget over a threshold | Program risk |
The change board meets on a fixed rhythm, weekly during build and fortnightly afterwards, with a rule that urgent changes may skip the meeting but not the register.
How should leaders prioritize requirements for customization governance?
Score every request on the same few criteria and send only the high scorers to design. Prioritisation should reward control impact, volume and the cost of living without the change, and penalise upgrade risk and effort. A fixed weighted scale gives a defensible order and prevents the loudest requester from winning.
Illustrative worked example. The weights are control impact x3, transaction volume x2, workaround cost x2, upgrade safety x2 (5 means low upgrade risk) and low effort x1. Maximum score is 50. All numbers are illustrative.
| Request | Control | Volume | Workaround | Upgrade safety | Effort | Score | Decision |
|---|
| Credit-hold override with approval log | 5 | 4 | 4 | 4 | 4 | 43 | Build as tier 3 extension |
| Customer-segment pricing rule | 3 | 5 | 4 | 3 | 3 | 36 | Check pricing configuration first, then extend |
| Change to standard costing calculation | 5 | 5 | 3 | 1 | 2 | 35 | Tier 4: steering group, with proof configuration cannot do it |
| Extra delivery-note field on sales order | 1 | 3 | 2 | 5 | 5 | 28 | Tier 2 personalisation |
| Custom dashboard layout | 1 | 2 | 1 | 5 | 4 | 23 | Backlog |
Note the third row. It scores 35, ahead of the extra-field request, but because it changes the vendor's costing calculation it is tier 4 whatever its score. The score orders the queue; the tier model decides who signs.
What should stakeholders include in a discovery workshop about customization governance?
Invite the people who own processes, controls, integrations and budgets, and bring a draft policy so they react to something concrete. The workshop should leave with agreed tiers, named approvers, a list of known gaps and an initial register. It fails when only IT attends.
Who attends. Sponsor, a business owner from each major process (order to cash, procure to pay, record to report, plus production or projects if relevant), finance or controller, internal audit if you have it, the security owner, the integration owner, the implementation partner's lead and a representative of the people who will use the system daily.
What to bring. The process list, the fit-gap results, any existing customizations on the old system, the list of integrations, audit findings that touched the old system and the vendor's extension and upgrade policy.
What to decide in the room.
- The standard-first policy and who may grant exceptions.
- Tier definitions with at least three local examples each.
- Named design authority, change board members and meeting rhythm.
- The upgrade policy: how many releases behind you may be, and who tests.
- The documentation standard and where the register lives.
- Which gaps already known will be handled by process change, configuration or extension.
Which integration points commonly affect the design of customization governance?
Any point where the ERP exchanges data with another system can turn a harmless change into an outage. Customizations that add or rename fields, change status values or alter posting logic can break the other side without any error in the ERP.
| Integration point | Why it matters to governance |
|---|
| Identity and single sign-on | Role changes can open or close access in other tools |
| Banking and payment files | Format and reference changes cause rejected payments |
| E-commerce and marketplaces | Item, price and stock fields drive the storefront |
| CRM | Customer and order status mappings must stay in step |
| Payroll and HR | Cost centre and employee codes feed posting |
| Reporting and BI | Renamed or repurposed fields silently change dashboards |
| EDI and customer portals | Partners expect fixed formats and codes |
| Tax and e-invoicing | Regulatory formats are not yours to alter |
Any change touching these needs the integration owner in the review, and a test of the other side.
What data dependencies must be mapped before changing integration architecture?
Map what each interface reads, writes and relies on before you move, replace or reshape it. If a dependency is invisible, the change will find it for you in production. A one-page dependency sheet per interface is enough, and the integration owner should sign it before design starts.
- Records and owners: which object (customer, item, order) and which system is the master.
- Keys: the identifiers that match records across systems, and what happens when they change.
- Direction and timing: one-way or two-way, real time or batch, and the batch window.
- Transformations: code mappings, unit conversions, currency and rounding rules.
- Volumes and peaks: records per day and at month end.
- Error handling: what happens on rejection, who sees it and how it is retried.
- Downstream consumers: reports, dashboards and other interfaces that depend on the same fields.
- History: whether past records must be re-sent or remain in the old format.
Our enterprise integration patterns guide compares point-to-point, middleware and event-driven designs once the map exists.
How should a customization be documented?
Document it in a register that a stranger could use: if a new partner cannot understand an extension from its entry, the entry is incomplete. Keep one row per customization, update it in the same change that alters the code, and review the whole register at every upgrade.
| Field | Content |
|---|
| ID and tier | Unique reference and tier 1 to 4 |
| Business reason | The problem in business terms, with the requester |
| Owner | Named business owner and technical owner |
| Objects touched | Tables, forms, APIs, workflows, interfaces |
| Dependencies | Other customizations, integrations, reports |
| Tests | Location of automated tests and scripted scenarios |
| Upgrade notes | Last release tested and result |
| Rollback note | How to switch it off and what that does to data |
| Approval | Who approved, when and under which tier |
How do you protect upgrades?
Run an upgrade impact test before every release reaches live users. Read the release notes against the register, refresh a copy of production, apply the release there, rerun the extension tests and the business scenarios, and have owners sign. The cost of this routine is the real running cost of customization.
- Compare release notes with the register and mark affected entries.
- Refresh a sandbox from production data and apply the release.
- Recompile or reinstall extensions and fix reported errors.
- Run automated tests, then scripted scenarios such as order to cash and period close.
- Test integrations end to end with real file formats.
- Obtain owner sign-off and schedule the live release with a rollback plan.
Our guidance on testing for ERP programs covers the scenarios in more detail.
What level of customization is possible with cloud-based ERP without breaking upgrade paths?
On cloud ERP, you can go as far as the vendor's documented, supported extension points allow, and no further. Configuration, personalisation, side-by-side extensions that call published APIs and well-defined event hooks are designed to survive releases. Changing vendor code is generally not available.
Treat this as a vendor-specific question and confirm it in writing: which extension methods the vendor supports, whether they are covered by the upgrade commitment, how much notice you get of changes to APIs, and what the release schedule is. Ask for the vendor's current documentation rather than a salesperson's summary. Remember that in a cloud product you often cannot delay an upgrade, so the impact test above becomes a regular calendar item. Our guide to cloud ERP vs on-premise ERP explains how the deployment model limits customisation.
What rollback plans are appropriate for customization changes?
Match the rollback to what the change touches. A configuration change can be reversed by restoring the previous setting. An extension can be switched off or its previous version redeployed. A change that wrote or reshaped data needs a data plan as well, and some changes cannot be undone at all.
| Change type | Rollback method | Watch for |
|---|
| Configuration | Restore previous setting from the configuration log | Records created under the new setting |
| Personalisation | Remove the view or field | Reports that already use it |
| Extension (code) | Feature switch off, or redeploy previous version | Records the extension has already changed |
| Integration mapping | Revert mapping, replay queued messages | Messages sent in the new format |
| Data model or posting change | Restore from backup plus re-entry of later transactions | Point after which rollback is impractical |
Every change record should name the person who may order the rollback, the trigger that forces it and the time after which it is no longer practical. Governance rules themselves need a rollback too: if a new approval threshold stalls work, the change board can revert to the previous threshold at its next meeting, with the decision recorded.
When is this approach the wrong one?
A full framework is too heavy for a small system with no customization or integrations, or a simple SaaS tool the vendor controls. A ten-user company needs a one-page policy and a spreadsheet, not a change board. It also fails as a veto: if requests wait weeks for a meeting, people build spreadsheet workarounds, which is worse.
Glossary: design authority, the person or group that decides technical approach and upgrade impact; core modification, changing vendor or base code; customization register, the list of every extension, integration and notable configuration, with owner and tests.
How Timeline Digital approaches this
Governance rules only help if the people building the changes work to them. Timeline Digital, founded in Islamabad in 2013 and delivering remotely, discusses with you in the Plan step what may be built, who approves it and how it is documented, and we build a free pilot of two to three key modules that your team tests before the final agreement. Schedules are set from your requirements, and the code and documentation transfer to you on full payment. See our custom ERP software service.