Custom ERP for SMEs: when does it make sense?

What to look at first

ERP projects become risky when companies try to replace everything at once. A modular approach lowers risk.

• Map core operational flow.
• Choose one module first.
• Define master data.
• Integrate finance and reporting gradually.

What the result should be

The business gets one operational backbone without overcommitting to a large-suite implementation.

Make the decision from the operating process

Custom ERP fits a distinctive order, stock and delivery chain that standard suites handle poorly. Start with one core transaction flow and stable master data.

• Choose a source for customer, product, stock and price.
• Separate operational transactions from reporting.

A realistic operating example

Orders reserve stock, create warehouse work and send approved financial entries to accounting. Management sees current margin without rebuilding finance first.

A controlled implementation sequence

Deliver the smallest complete workflow first. Test exceptions with the people who perform the work before adding more features.

• Stabilise identifiers and master data.
• Build one audited flow.
• Run old and new in parallel.

Measure adoption and operating value

Set a baseline before launch and review both business results and manual recovery.

• Order time and stock variance.
• Manual hand-offs and finance reconciliation.

Important limits and safeguards

Core transactions require constraints, backups, monitoring and recovery. AI may predict or flag, but should not make untraceable stock or finance mutations.

Identify the operation that genuinely needs an owned backbone

Custom ERP is not a goal. It fits where orders, inventory, delivery and invoicing form a distinctive chain that standard suites support only through permanent workarounds. Trace one transaction from request to financial processing and mark every hand-off, exception and source. Keep commodity accounting or payroll with specialist products where practical; the owned layer should organise the operational difference.

• Core order, production, service or case journey.
• Steps affecting revenue, margin and lead time.
• Duplicate entry between departments.
• Exceptions managed through email and spreadsheets.
• Systems that remain authoritative.

Stabilise master data before transactions

Customers, products, suppliers, locations, prices and units need unambiguous ownership and identifiers. Preserve effective dates and change history so old transactions retain their meaning. Do not let every integration interpret names independently. Master-data clean-up and governance are often more important than the first dashboard.

• Unique product, customer, supplier and location codes.
• Explicit units, currency, tax and pricing rules.
• Version and effective period for changing agreements.
• Approval for critical master-data changes.
• Mappings to connected-system identifiers.

Build transactions for control and recovery

Orders and stock movements must be atomic, traceable and repeatable. Define states and permitted transitions rather than allowing a model to invent status. Use idempotency across APIs and queues so retries do not create duplicates. Preserve who changed what and why. Correct through reversals or controlled adjustment instead of overwriting history.

• Fixed state machine and business constraints.
• Transaction identifiers across system boundaries.
• Owned failure queue with recovery actions.
• Audit history for values, inventory and approvals.
• Backups, restoration tests and manual continuity.

Integrate finance without rebuilding accounting

The operational layer may calculate price, margin and billable delivery while accounting remains authoritative for invoices, payments and ledgers. Agree posting events, mappings and correction. Reconcile amounts and counts and treat unexplained differences as incidents. Reporting must distinguish operational, invoiced and paid values to avoid precise-looking but conflicting dashboards.

• Invoice proposal from accepted delivery.
• Controlled customer, tax and ledger mapping.
• Invoice and payment status returned.
• Reconciliation with explained variance.
• No generative AI posting financial mutations autonomously.

Deliver by module instead of a multi-year big bang

Choose a first module with complete value and manageable dependencies, such as order intake or stock reservation. Run old and new together under control and measure time, manual work, errors and reconciliation. Expand only after stable production and user acceptance. Operations, monitoring and data ownership must grow from the first release rather than being postponed to the end.

• A first phase with usable end-to-end value.
• Migration and fallback per module.
• Acceptance with peak volume and exceptions.
• Measured stop-or-go decision before expansion.
• Client ownership of code, accounts and documentation.