ERP Customization: A Brutal Cost-Benefit Analysis

Companies should expect to spend 10–30% of their total ERP budget just on customizations — and that's the conservative estimate. The actual cost of ERP customization compounds over time through upgrade costs, maintenance, and the complexity it introduces into an otherwise standard system. Yet customization is sometimes essential: a business with genuinely unique processes, industry-specific calculations, or regulatory requirements that no vendor anticipated will get more value from custom logic than from forcing their operation into a standard workflow. This post is a framework for making the customization decision correctly — before you've already committed.

Standard vs Custom: What the Numbers Say

Standardized ERP solutions can be rolled out in 6–12 months. Highly customized platforms take 12–18+ months. Custom code adds $10,000–$50,000 in annual maintenance per major customization tranche due to upgrade testing and compatibility work. Organizations that adapt their processes to the ERP's best practices consistently achieve faster implementations and lower TCO. The business case for customization must clear a high bar: the customization must deliver specific, quantifiable business value that exceeds its lifetime cost.

The Three Legitimate Reasons to Customize

After evaluating dozens of customization requests, I've found three legitimate justifications. First: regulatory compliance that the standard system doesn't support (Indonesian-specific tax calculations, BPK-compliant audit formatting, BPJS integration for HR). Second: core business logic that is genuinely unique and competitively differentiating (a pricing engine that accounts for variables no standard ERP handles, a production scheduling algorithm specific to your manufacturing process). Third: integration with hardware or external systems that have no standard connector (specific barcode scanner models, government data portals, industry-specific APIs).

The Seven Requests That Are Never Worth Customizing

These customization requests come up in almost every project and are almost never worth it: custom report layouts (use the built-in report builder or export to Excel), custom approval email templates (configure, don't code), minor UI changes ('can we move this field to the left?'), convenience features that duplicate existing functionality ('we want a shortcut for this 3-step process'), preferences that differ by individual user ('I like my invoices sorted differently'), cosmetic field label changes, and adding fields that will 'maybe be needed someday.' Every one of these requests increases upgrade cost and project timeline. Push back hard.

ERP Customization Decision Matrix

  REQUEST                         │ Config? │ Worth Customizing?
  ────────────────────────────────┼─────────┼──────────────────────
  Indonesian e-faktur integration │  NO     │  YES — regulatory req
  BPJS contribution calculation   │  NO     │  YES — regulatory req
  Custom approval hierarchy       │  MAYBE  │  YES if unique logic
  Product pricing engine          │  MAYBE  │  YES if core business
  Custom report layout            │  YES ✓  │  NO — use config
  Field label rename              │  YES ✓  │  NO — cosmetic only
  Email template styling          │  YES ✓  │  NO — use template
  "Shortcut" for 3-step process   │  NO     │  NO — train instead
  Sort order preference           │  YES ✓  │  NO — user setting
  Future "maybe needed" fields    │  YES ✓  │  NO — YAGNI

  ────────────────────────────────────────────────────────────────
  COST-BENEFIT GATE: Before approving any customization, require:
  1. What business outcome does this enable? (Specific, measurable)
  2. What is the annual value of that improvement? (In IDR)
  3. Can 80% of the value be achieved through configuration?
  ────────────────────────────────────────────────────────────────

  Lifetime cost formula:
  Total = Dev_Cost + (Annual_Maintenance × Years) + (Upgrade_Cost × Upgrades)

  Example: Custom approval module
  = Rp 25M dev + (Rp 5M × 5yr) + (Rp 8M × 2 upgrades) = Rp 66M
  Annual value needed: > Rp 13.2M/yr to justify at 5-year horizon

Configuration vs Customization: Know the Difference

Configuration is changing how the system behaves using built-in tools — workflow rules, field validation, approval hierarchies, report templates. It doesn't modify the codebase and doesn't break on upgrades. Customization is writing code that changes how the system works at a technical level. It does modify the codebase and does break on upgrades. Before any customization is approved, the implementation team must demonstrate that configuration cannot solve the problem. In my experience, 60–70% of early customization requests can be resolved through better use of configuration — the business just didn't know the capability existed.

# Configuration vs Customization: Odoo Examples

# ✅ CONFIGURATION — safe, upgrade-friendly
# Setting approval thresholds in Odoo Purchase Settings:
# No code changes. Uses built-in workflow engine.
PURCHASE_ORDER_APPROVAL = {
    "limit_1": 5_000_000,   # auto-approve under Rp 5M
    "limit_2": 25_000_000,  # manager approval Rp 5M–25M
    "limit_3": None,        # director approval above Rp 25M
}

# ✅ CONFIGURATION — custom fields via Odoo Studio
# Adding NPWP field to vendor form:
# Drag-drop in Studio interface. No Python code.

# ❌ CUSTOMIZATION — requires Python code, breaks on upgrade
# Custom module to change the AP aging calculation:
# /addons/custom_ap_aging/__manifest__.py
# This will need retesting and potential rewriting
# every time Odoo releases a major version (yearly).

# 🔶 LEGITIMATE CUSTOMIZATION — regulatory, justified
# Indonesian PPh 23 withholding tax calculation:
class IndonesianWithholdingTax(models.Model):
    _inherit = 'account.move'

    def compute_pph23(self):
        """Calculate PPh 23 per DJP regulations"""
        # This customization is justified:
        # 1. Regulatory requirement (no alternative)
        # 2. Annual value: avoid manual calculation errors
        # 3. Cannot be solved by configuration alone
        rate = 0.02  # 2% for services, per PMK-141/2015
        return self.amount_untaxed * rate

Customization in Custom ERP: A Different Game

When I build custom ERP at Commsult, the customization question doesn't disappear — it just changes shape. Every feature request is still a cost-benefit decision. But the comparison is different: there's no upgrade cost from vendor compatibility breaks, no licensing fee increase from adding users, and no constraint from a vendor's data model. The discipline required is scope control — every feature request must justify its development cost against business value, because the budget is finite even without licensing costs.

Building a Customization Register

Before any development starts, create a customization register: a living document that lists every custom item, its business justification, estimated development cost, estimated annual maintenance cost, and the owner who requested and approved it. Review this register quarterly. Items with no measurable business outcome after 12 months should be candidates for removal. This register also helps future teams understand why each customization exists — without documentation, custom code becomes unmaintainable because nobody remembers why it was written.

My Recommendation: The 80/20 Rule for ERP Customization

Aim for 80% standard configuration, 20% customization maximum — by cost, not by feature count. If you're approaching 40–50% customization by cost, you've crossed from 'adapted ERP' into 'custom system built on an ERP framework' — and at that point, a purpose-built custom ERP is often cheaper over a 5-year horizon. The businesses that get the most ERP value are the ones willing to adapt their processes to the platform's best practices for 80% of workflows, and make precise, high-value customizations for the 20% that genuinely need it.