Implement ERP modules in the order their data depends on each other: chart of accounts and master data first, then core finance, then purchasing, inventory and sales. Payroll follows clean HR records and general ledger mapping; manufacturing follows accurate bills of materials and inventory. Go live with each phase at the start of an accounting period.
The question is not which module is most important. It is which module produces the records the next one consumes. A sales module cannot show reliable stock if receiving is not in the system, and stock cannot be valued correctly if purchase costs and costing rules are not set. This guide sets out that dependency logic, gives phased roadmaps for three types of business, and ends with a decision checklist. If you need the basics first, read what ERP software is and what its modules do.
Why does the order of ERP modules matter?
Each ERP module either posts transactions to another or reads records another creates. Going live out of order forces temporary workarounds, re-keying between systems and reconciliation that nobody planned for.
| Module | Depends on | Why | What happens if it goes first |
|---|---|---|---|
| General ledger | Chart of accounts, entities, tax codes, currencies | Every other module posts to it | Nothing to post to; reports built on a structure that will change |
| Accounts payable and receivable | General ledger, customer and supplier masters | Invoices and payments post to control accounts | Balances that never tie to the ledger |
| Purchasing | Supplier master, item master, approval rules | Creates purchase orders and goods receipts | Usually fine early, after the masters |
| Inventory | Item master, warehouses, units of measure, purchasing receipts, costing method | Stock quantity comes from receipts; value comes from purchase cost and costing rules | Quantities without reliable costs; valuation that does not match the ledger |
| Sales and invoicing | Customer master, price lists, inventory availability, receivables | Orders reserve stock; invoices post revenue and cost of sales | Promises on stock that is not there; cost of sales that is wrong |
| Payroll | HR records, pay elements, statutory rules, general ledger mapping | Pay is calculated from employee data and posts salary journals | Payslips correct but accounting entries missing or misposted |
| Manufacturing | Bills of materials, routings, work centres, accurate inventory | Production consumes components and creates finished goods | Material shortages and product costs nobody trusts |
What should you implement first in an ERP?
Start with the foundation, then core finance. The foundation is not a module users see, but every later phase rests on it.
The foundation
- Chart of accounts. Redesigned for the new system, not copied. Decide the accounts and the reporting dimensions (branch, department, cost centre, project) now, because changing them after transactions exist is painful.
- Legal entities, currencies and tax codes. For groups, decide how inter-company transactions will work before any module goes live. Our guide to multi-entity ERP governance covers this.
- Master data. Customers, suppliers, items, units of measure, warehouses and locations, employees, each with a named owner and agreed naming rules.
- Users, roles and approvals. Who can create, approve and post, and the segregation of duties your auditors will expect.
Core finance
General ledger, accounts payable, accounts receivable and bank. Finance first gives every later module a stable place to post, and gives you a reconciled baseline. Finance go-lives are cleanest at the start of a financial year, or at least a month start, with opening balances loaded and tied out. Our ERP data migration plan covers how to load and reconcile those balances.
Why does purchasing come before inventory and sales?
Because stock quantity and stock value both originate in purchasing. A goods receipt against a purchase order is what increases stock, and the purchase price, plus landed costs such as freight and duty if you capitalise them, is what sets its cost.
Inventory valuation then depends on the costing rule you choose. Under IAS 2, the international accounting standard for inventories, items that are ordinarily interchangeable are costed using first-in, first-out or weighted average cost, and items that are not interchangeable are costed by specific identification. Agree the method with your accountants before the first receipt is posted in the new system, because changing it later means revaluing stock.
Sales comes after inventory for a similar reason. A sales order should reserve available stock, and the invoice should post revenue and cost of sales. If inventory is not live, the sales module either guesses availability or ignores it.
Where do payroll and manufacturing fit in the roadmap?
Payroll
Payroll depends on clean HR records (employees, contracts, pay elements, leave balances, bank details), on the statutory rules of each country, and on mapping each pay element to general ledger accounts. It touches the operational modules very little, so it can run as a separate track alongside purchasing and inventory once finance is live. Go live at the start of a pay period, ideally the start of a tax year so year-to-date figures do not have to be migrated. A short parallel run of payroll calculations is one of the few places where running old and new side by side is usually worth the effort.
Manufacturing
Manufacturing is normally last. It needs accurate bills of materials and routings, defined work centres and, above all, inventory you trust, because every production order consumes components and creates finished goods. Running manufacturing on top of unreliable stock produces shortages on the shop floor and product costs that finance cannot defend.
What does an ERP roadmap look like for different businesses?
The tables below are illustrative patterns, not fixed plans. Your phases depend on where the pain is, what the old system can still do and how much change your team can absorb at once.
Trading or distribution business
| Phase | Modules | Why now | Go-live gate |
|---|---|---|---|
| 0 | Chart of accounts, master data, roles | Everything else depends on it | Masters cleansed and signed off by owners |
| 1 | General ledger, payables, receivables, bank | Stable posting target and reconciled baseline | Opening trial balance tied out |
| 2 | Purchasing and inventory | Stock quantity and cost originate here | Physical count agrees with loaded stock |
| 3 | Sales orders, invoicing, pricing, credit control | Needs live stock and receivables | Orders reserve stock; invoices post correctly |
| 4 | Warehouse scanning, customer portal, reporting | Builds on reliable transactions | Users trained; reports agree with the ledger |
| 5 | HR and payroll | Separate track, minimal operational dependency | Parallel payroll run agrees |
Manufacturer
| Phase | Modules | Why now | Go-live gate |
|---|---|---|---|
| 0 | Chart of accounts, master data, item and BOM structure design | Items and BOMs are the backbone | BOM owners named; item coding agreed |
| 1 | Finance core | Posting target for everything | Opening balances tied out |
| 2 | Purchasing and inventory, including raw materials and work in progress | Production consumes what purchasing brings in | Stock and valuation reconciled |
| 3 | Sales orders and invoicing | Drives demand for production | Order-to-cash tested end to end |
| 4 | Manufacturing: BOMs, routings, work orders, production costing | Needs reliable stock and costs | Test production orders cost correctly |
| 5 | Planning, quality, maintenance; HR and payroll as a parallel track | Depends on stable production data | Plans match real capacity |
Service or project-based business
| Phase | Modules | Why now | Go-live gate |
|---|---|---|---|
| 0 | Chart of accounts with project and department dimensions, client and employee masters | Projects are the reporting unit | Project coding agreed |
| 1 | Finance core | Billing and costs post here | Opening balances tied out |
| 2 | Projects, timesheets and expenses | The main source of cost and billable work | Timesheets approved and costed |
| 3 | Billing: milestones, time and materials, retainers | Needs approved time and project rules | Invoices match contracts |
| 4 | Procurement for project costs; CRM and pipeline | Links purchases and sales to projects | Purchases land on the right project |
| 5 | HR and payroll; resource planning | Uses employee and timesheet data | Utilisation reports agree with timesheets |
Which ERP modules can be piloted on their own?
Modules with few upstream dependencies can be piloted alone, often connected to the existing system through an integration. Good candidates include purchase requisitions and approvals, HR records and leave, timesheets, CRM and sales pipeline, document management, field service jobs, warehouse scanning that feeds the current stock system, and management dashboards.
Modules that do not pilot well alone are those whose results depend on another module's data: inventory valuation without purchasing, sales invoicing without receivables and the ledger, and manufacturing without inventory. Piloting these in isolation proves the screens but not the numbers.
When should each ERP phase go live?
Cut over at the start of an accounting period. A month start is the minimum; a financial year start is cleanest for finance because opening balances become the closing balances of the old year and period reports start clean. Beyond that:
- Avoid year-end close and peak season. Finance and operations staff are needed for testing and training, and they are least available then.
- Count stock just before inventory goes live, so loaded quantities reflect what is on the shelves.
- Start payroll at a pay period start, ideally a tax year start.
- Leave a full close between phases, so each phase completes a month-end before the next one adds load.
Big-bang or phased ERP rollout: which is safer?
Neither is automatically safer. Big-bang concentrates risk into one date; phasing spreads it over time but adds temporary interfaces and a longer period of running two systems.
| Approach | How it works | Advantages | Risks | Usually suits |
|---|---|---|---|---|
| Big-bang | All modules and sites go live on one date | No temporary interfaces; one cut-over; one training wave | A single failure point; heavy load on users at once; rollback is hard | Smaller, tightly integrated businesses with simple processes |
| Phased by module | Modules go live in dependency order | Each phase is smaller and proven before the next | Temporary interfaces to the old system; longer overall timeline | Most mid-size businesses |
| Phased by site or entity | One branch or company goes live first, then the rest | Lessons from the first site improve the others | Two systems run in parallel across the group for a while | Multi-site and multi-entity groups |
| Pilot, then scale | A small set of modules proves the approach before the full plan is fixed | Real evidence before full commitment | The pilot must be chosen to test the riskiest assumptions | Buyers unsure of fit, scope or vendor |
When is a phased roadmap the wrong approach?
Phasing is the default for good reason, but it is not always right.
- Small, tightly coupled operations. A business whose sales, stock and invoicing happen in one counter transaction gains little from phasing; the temporary interfaces can cost more than the risk they remove.
- A hard deadline on the old system. If the current system loses vendor support or its hosting ends on a fixed date, the roadmap must fit that date, which can force a larger first phase.
- Inseparable modules. For many retailers, sales and inventory are effectively one module. Split them and you build an interface only to throw it away.
- Group consolidation as the main goal. If the reason for the ERP is consolidated group reporting, finance for all entities may need to move together even if operations phase later.
ERP roadmap decision checklist
- Chart of accounts and reporting dimensions redesigned and approved
- Every master data set has a named owner
- Costing method agreed with your accountants before the first receipt
- Dependencies mapped for every module in scope
- Each phase has a measurable go-live gate
- Go-live dates set at period starts, away from year-end and peak season
- Temporary interfaces to the old system listed, with an end date for each
- Stock count planned before inventory goes live
- Payroll start aligned to a pay period or tax year
- A full month-end close planned between phases
- The pilot tests the riskiest assumption, not the easiest module
Planning your roadmap with Timeline Digital
We plan the module order before building anything, because it shapes migration, integration and training. For a custom ERP, Timeline Digital starts with a free pilot of 2 to 3 key modules before the full project, chosen to prove the dependencies that matter most to your business. See how we approach ERP development and ERP implementation.