How cost management is usually set up in finance and ERP systems

Most organisations run cost management inside the general ledger module of their ERP. Cost centers, projects and cost objects hang off the chart of accounts. Indirect costs are collected in pools and spread by allocation rules at period end. Driver data often arrives from other systems or spreadsheets.

The structure that holds costs

Everything starts with master data. A cost center represents a responsibility area, usually a team or a site. A project or internal order holds spend for something with a start and a finish. Cost objects are whatever the organisation wants to know the cost of. That might be a product, a service line, a customer group or a programme.

These elements usually sit in a hierarchy. Cost centers roll up to departments and then to divisions. That hierarchy drives reporting, approval routing and often security, so a change to it ripples further than people expect.

Spend limits tend to live here too. Many systems let a budget be attached to a cost center or project, with a warning or a hard block when commitments exceed it. Whether the block is switched on is a policy decision that is frequently forgotten after go live.

Closing out matters as much as setting up. Projects that finish should be settled and locked. Cost centers for teams that no longer exist should be blocked for posting. Where this is neglected, stray postings land in dead codes and quietly distort the numbers.

How costs get collected

Direct costs are captured at the point of posting. An invoice, a timesheet or a goods issue carries a cost center or project code, and the ledger records it there. The quality of cost data depends heavily on how those codes are defaulted. Some come from the employee record, others from the purchase order, and some are typed by hand.

Indirect costs follow a different path. Rent, IT, shared services and management overhead are posted first to pooling cost centers. They wait there until the allocation run moves them on.

Allocation runs

Allocations are configured as rules. Each rule names a sender, one or more receivers and a basis for splitting. The basis might be headcount, floor space, machine hours, transaction volumes or a fixed ratio agreed with the business.

The basis has to be captured somewhere. ERPs typically hold it as statistical figures that are loaded each period. The load is often manual, and it is the step most likely to go stale. A rule can run perfectly on a driver that nobody has refreshed in a long while.

Sequence also matters. Some pools feed other pools before costs reach products or services. If the cycles run in the wrong order, or a new pool is added without updating the chain, costs end up in the wrong place without any error message.

Drivers and critical activities

Identifying what really causes cost is analytical work, and it rarely happens inside the ERP. Finance teams usually study it in spreadsheets or a separate costing tool, then translate the result into allocation keys the ledger can use.

Measuring those drivers means pulling data from operational systems: warehouse transactions, service tickets, production logs, HR records. Interfaces for this are often thin. Where a driver depends on someone emailing a figure each month, that dependency deserves attention before any redesign.

Some organisations go further and model activities explicitly. They define the activities that consume resources, assign rates and charge activity costs to cost objects. This gives better insight into which activities are critical, at the price of more data upkeep.

Assets and capacity

Fixed assets connect to cost management through depreciation. Each asset is linked to a cost center, and depreciation posts there automatically. When equipment moves between sites or teams and the asset record is not updated, the cost stays behind.

Utilisation is harder. Most ledgers know what an asset costs but not how much it is used. Usage data, where it exists, sits in maintenance or production systems and has to be brought across before idle capacity can be priced or reported.

Reporting and downstream uses

Cost reports usually show actuals against budget by cost center, project and cost object. They should reconcile to general ledger balances. When they do not, the gap normally comes from postings made outside the cost structure or from allocations reversed and rerun late.

Cost information also feeds other processes. Budget formulation uses it as a baseline. Billing teams use it to set rates for internal recharges or for services charged to outside parties. A change to allocation logic can therefore alter invoices, which surprises people who think of costing as an internal matter.

Questions to ask the people who run it

• Which allocation keys are refreshed every period, and which have been carried forward unchanged?
• Where do the driver figures actually come from, and who sends them?
• Are there manual journals posted after the allocation run to fix results?
• Which cost centers or projects are still open but no longer used?
• Do spend limits stop transactions, or only produce warnings that get ignored?
• What does the team do when an asset moves but its record does not?
• Which reports do managers trust, and which do they rebuild themselves in spreadsheets?
• Who relies on the costing output for billing rates or budgets, and how would they learn of a change?
• What workarounds exist because the system cannot do something the business needs?

The answers usually reveal a second process running alongside the configured one. That shadow process is often where the real costing logic lives.

APQC's Process Classification Framework® (PCF) is an open standard developed by APQC, a nonprofit that promotes benchmarking and best practices worldwide. To download the full PCF or to view definitions and measures, please visit www.apqc.org/pcf.