How financial performance evaluation is set up in finance and ERP systems

In most organisations this process sits on top of the general ledger, not inside it. The ledger carries the account and dimension structure. Allocation and costing logic usually lives in a controlling module or a separate profitability tool. The analysis itself often ends up in spreadsheets and dashboards.

The ledger and its dimensions

Everything starts with how the chart of accounts and its attributes are built. Performance analysis depends on transactions carrying the right tags when they post. Typical tags include cost centre, product, customer, channel, region and project. If a sales invoice posts without a product code, no later tool can reliably say which product earned that margin.

Most ERP systems let finance define these attributes once and make some of them mandatory on certain account ranges. This is where the quality of profitability reporting is decided. Teams that skip this design work end up rebuilding the missing detail by hand every period.

Manual journals matter here too. Accruals, reclasses and corrections are often posted without full dimensions because the person preparing them is under time pressure. Those entries quietly distort margin reports.

Where costs get assigned

Revenue usually arrives with good detail. Costs do not. Direct material and labour can often be traced to a product through the inventory and production modules. Overheads are another matter.

The common setup is a controlling or management accounting module that holds allocation cycles. These move costs from support cost centres to operating ones, then onward to products or customers, using drivers such as headcount, floor space, machine hours or order lines. Activity-based measures are built the same way, with the drivers chosen to reflect what actually consumes the resource.

Some organisations run this logic in the ERP. Others extract ledger data into a dedicated costing or planning tool because the ERP allocation engine is rigid or slow to change. Both approaches work. What breaks is when allocation rules exist in several places and nobody knows which version is current.

Profitability by customer and product

Customer and product profitability reports combine the tagged revenue, the traced direct costs and the allocated overheads. Many ERP suites offer a profitability analysis component that stores results in a separate cube or table. That design keeps the ledger clean but creates a second source of truth that must reconcile back to it.

The reconciliation step is often neglected. A sound setup shows, every period, that total profit across all customers or products equals operating profit in the ledger. When it does not, the gap usually points to unallocated costs or untagged postings.

Decisions about customer and product mix are rarely made in the ERP. They happen in models built from these reports, where finance tests scenarios such as dropping a product line or repricing a customer segment.

New products and life cycle costing

New product evaluation tends to live outside the core system. Business cases are built in spreadsheets or a planning tool, with assumptions about volume, price, cost and investment. Life cycle costing extends this view across design, launch, maturity and withdrawal.

The weak point is linking the business case to actual results later. A good setup creates a product or project code at approval, so that real costs and revenues post against it from the first transaction. Without that code, comparing promise to outcome becomes guesswork.

Tracking strategies after launch

Once a new product or customer strategy is live, tracking usually runs through the reporting layer. Actuals from the ledger are compared with the original case and with the current forecast. Program owners receive standard reports, and analysts build ad hoc views on request.

Every figure shown to a business owner should trace to ledger balances. When reports draw on extracts that have been adjusted offline, trust erodes quickly and meetings turn into arguments about the numbers.

Continuous cost improvement

Cost improvement work tends to be tracked as initiatives with owners, targets and expected savings. A few organisations hold these in a planning tool tied to cost centres. Many more keep them in a tracker that finance updates by hand. The hard part is proving that a saving actually reached the ledger, not just that a project closed.

Questions to ask the people who run it

The documented process and the real one often diverge. These questions tend to surface the gap:

• Which dimensions are mandatory on postings, and which are skipped in practice?
• Where do allocation rules live, and who last changed them?
• Does total customer or product profit reconcile to ledger operating profit each period? Who checks?
• Which reports are pulled straight from the system, and which are rebuilt in spreadsheets?
• How are manual journals tagged, and who reviews their dimensions?
• When a new product is approved, is a code created before the first cost is incurred?
• How are cost savings confirmed against actual spend?
• Which numbers do business owners dispute most often, and why?
• What workarounds would break if the allocation tool or reporting layer changed?

Where changes tend to go wrong

Most redesigns focus on the report and ignore the posting. A new dashboard cannot fix a missing product code on the original transaction. Changes to allocation drivers also shift reported profit between business units, which can affect bonuses and budgets. Agreeing those effects with business owners before go live saves a great deal of disruption afterwards.

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.