ERP systems and implementation

Enterprise resource planning systems run the finances of most medium and large organizations. An ERP integrates financial accounting, purchasing, sales, inventory, manufacturing, human resources and often customer relationship and analytics functions in one system with one database. The market is led by a few large vendors, including SAP (S/4HANA), Oracle (Fusion Cloud ERP and NetSuite), Microsoft (Dynamics 365), Infor and Workday, along with many mid-market and industry-specific products. This course is vendor-neutral: the concepts here apply to any of them. What matters for accountants is how an ERP is structured, how it is configured to reflect the organization's accounting, what can go wrong when one is implemented, and how to keep it under control afterwards.

Ridgeback moved from a small accounting package and separate spreadsheets to a mid-market cloud ERP three years ago. Before the change, the warehouse kept its own inventory system, the online store sent a daily spreadsheet of orders to accounting, and month-end close took 12 working days. After a 10-month implementation, the close takes five days, inventory is updated in real time and the online store posts orders directly. The project also ran over budget by about a third and caused a difficult first quarter, a common pattern that this lesson explains.

How an ERP is organized

An ERP is built from modules that share common master data and post to a common general ledger. A typical financial core includes general ledger, accounts payable, accounts receivable, fixed assets, cash management and consolidation. Operational modules include procurement, sales and distribution, inventory and warehouse management, manufacturing, project accounting and human capital management. Because the modules share data, a single business event, such as a goods receipt, can update inventory quantities, the open purchase order, the goods-received-not-invoiced liability and the general ledger at once, through account determination rules that map business events to ledger accounts.

Configuration, not programming, adapts most modern ERPs to an organization. During implementation the team defines the organizational structure (legal entities, business units, warehouses), the chart of accounts, fiscal calendars, currencies, tax codes, payment terms, approval workflows, account determination rules and many other settings. Cloud ERP vendors encourage customers to adopt standard processes and avoid custom code, because customizations make upgrades difficult and expensive. When a process genuinely differs, extensions are built through the vendor's approved tools rather than by changing the core software.

Designing the chart of accounts

The chart of accounts is the most important design decision in an ERP from the accountant's point of view, because every report depends on it and it is hard to change later. Modern ERPs use a segmented chart, in which each account string combines several segments: for example, company, natural account, department, product line and location. The natural account (such as 4000 sales or 6100 office expense) says what the amount is; the other segments say where and for what. This lets one natural account serve many reporting needs without creating hundreds of accounts like "sales of tents in the west region". Good design keeps the natural account list short, uses segments and dimensions for analysis, defines each account clearly, and controls who may create new accounts or segment values.

# Ridgeback: validating segmented account strings before posting (illustrative)
segments = {
    "company": {"10": "Ridgeback Outdoor Gear", "20": "Ridgeback Online"},
    "account": {"1100": "Accounts receivable", "4000": "Sales", "5000": "Cost of goods sold",
                "6100": "Office expense", "6200": "Freight out"},
    "dept": {"000": "None", "110": "Sales", "210": "Warehouse", "310": "Finance"},
    "product": {"00": "None", "TE": "Tents", "PA": "Paddling", "WI": "Winter"},
}
# cross-validation rules: balance sheet accounts must not carry a department or product
balance_sheet = {"1100"}
lines = ["10-4000-110-TE", "10-6100-310-00", "20-1100-110-PA", "10-6250-210-00", "30-5000-000-WI"]
for line in lines:
    co, acct, dept, prod = line.split("-")
    errors = []
    for name, val in (("company", co), ("account", acct), ("dept", dept), ("product", prod)):
        if val not in segments[name]:
            errors.append(f"invalid {name} {val}")
    if acct in balance_sheet and (dept != "000" or prod != "00"):
        errors.append("balance sheet account cannot carry department or product")
    print(f"{line:16s} " + ("OK" if not errors else "REJECTED: " + "; ".join(errors)))

10-4000-110-TE   OK
10-6100-310-00   OK
20-1100-110-PA   REJECTED: balance sheet account cannot carry department or product
10-6250-210-00   REJECTED: invalid account 6250
30-5000-000-WI   REJECTED: invalid company 30

Cross-validation rules like the one in the example stop combinations that make no sense, such as a receivable coded to a sales department and product line. Without them, reports by department or product fill with balance sheet noise and someone eventually spends days reclassifying entries. The code also rejects an unknown natural account (6250) and an unknown company (30), which is exactly what an ERP's segment validation does at entry.

Selecting an ERP

Choosing an ERP is a major investment decision, usually made every ten to twenty years. A selection project typically starts with a business case and a statement of requirements, covering functional needs (multi-currency, inventory costing method, project accounting), technical needs (cloud or on-premises hosting, integration with the online store and banks), control needs (workflow approvals, segregation of duties tools, audit trails, change logs) and reporting needs. Shortlisted vendors give scripted demonstrations using the organization's own scenarios, not the vendor's polished examples, and references from similar customers are checked. Total cost of ownership over several years, including subscriptions, implementation partner fees, internal staff time, training, data conversion and future upgrades, matters more than the first-year license price.

Accountants should insist that control requirements are part of the selection, because retrofitting them later is expensive. Useful questions include: can the system enforce segregation of duties rules and report conflicts? Does it keep an unalterable log of master data and configuration changes? Can approval limits vary by amount, entity and account? Does the vendor provide independent controls reports for its hosting and operations? Can data be exported in full if the organization ever leaves?

Why ERP implementations fail

ERP implementations are large, risky projects. They change software, processes, roles and data at the same time, often across the whole organization. Well-known failures illustrate the risks. Hershey's 1999 go-live of new ERP, supply chain and CRM systems, timed just before its busiest season, left it unable to ship about $100 million of orders. The US Air Force canceled its Expeditionary Combat Support System in 2012 after spending about $1 billion without usable capability. Lidl abandoned a seven-year SAP project in 2018 after reportedly spending around €500 million, in part because it wanted to keep valuing inventory at purchase prices rather than adopt the system's standard approach. Canada's Phoenix pay system for federal employees, launched in 2016, produced years of incorrect pay and billions of dollars in remediation costs (CMPUT-301 discusses it as a software engineering case).

Accountants play several roles in an implementation. The finance team defines requirements for the chart of accounts, reporting, closing and controls. Internal audit or an external adviser reviews the project's governance and the design of controls, ideally before go-live, when changes are cheap. The external auditor will want evidence that data was converted completely and accurately, because the opening balances in the new system become the basis of the next audit. And finance staff must be trained early, since they often discover configuration problems only when they try to close the first month.

Living with an ERP

Go-live is the start, not the end. Cloud ERPs receive vendor updates several times a year, and each one can change screens, processes and sometimes controls. Organizations need a regression testing approach for key controls and reports, a process for reviewing vendor release notes, and governance for the configuration changes that users will continue to request. Master data governance (lesson 3) becomes a permanent function. Access must be reviewed as people join, move and leave (lesson 9). Many organizations set up a center of excellence, a small team of business and IT staff who own the ERP's processes and configuration after the implementation consultants have gone.

Cloud ERP shifts some responsibilities to the vendor. The vendor runs the data center, the database, the core software and the security of the infrastructure, and provides SOC 1 and SOC 2 type reports (in Canada, CSAE 3416 for the financial reporting controls) describing its controls. The customer remains responsible for its own configuration, users, data and the complementary user entity controls in those reports. Contracts should address data ownership, where data is stored, how it can be exported if the organization leaves, and what happens in an outage. For Canadian organizations with public-sector or health data, data residency can be a specific requirement.

US organizations with operations in several states must configure the ERP for state-level sales tax, payroll tax and reporting differences, often through tax engines that integrate with the ERP. Public companies also need the ERP to support SEC reporting, including the data needed for inline XBRL tagging of financial statements (lesson 12).