Where evaluating and managing financial performance usually breaks

This process usually breaks at two points: where ledger data is reshaped into product and customer costs, and where an analytical finding is passed to someone expected to act on it. Between those points, spreadsheet workarounds absorb the exceptions and quietly create rework.

The ledger does not carry the attributes the analysis needs

Profitability work depends on transactions arriving tagged by customer, product, channel or activity. Ledger structures are usually built for statutory reporting. The performance attributes get added later, inconsistently, or not at all. Analysts then rebuild the missing detail by hand from subledgers, sales extracts and operational systems.

This gap is visible when the profitability model cannot be traced back to ledger balances without a reconciling plug. Watch for a line labelled "unallocated" or "other" that grows over time. Another giveaway is a team that runs the same mapping exercise every cycle because nobody fixed the source coding.

Manual journals and late accruals distort the cost base

Corrections posted as manual journals often land in a default cost centre with no product or customer tag. Accruals reversed in the following period swing margins in ways that have nothing to do with performance. The analyst sees a product that suddenly looks unprofitable, investigates, and finds an accounting entry.

A telling pattern is the analyst who keeps a private list of "known distortions" to strip out before presenting results. If margin commentary regularly opens with an explanation of a journal, the problem is upstream.

Allocation rules nobody agrees on

Activity-based measures stand or fall on the drivers chosen. Operations picks one basis, finance picks another, and sales disputes both when a key account looks weak. The model gets rerun with different assumptions until someone accepts the answer. That is rework dressed up as analysis.

Trouble here surfaces in meetings about the method, held at the moment results should be discussed. Version names on model files multiply. Driver data, such as order counts or machine hours, is pulled from operational teams by email each period and arrives in a slightly different shape each time.

New product cases that are never revisited

A new product or customer strategy is approved on a business case with assumed volumes, prices and lifetime costs. Once it launches, tracking falls to whoever has spare capacity. Life cycle costs such as support, warranty and eventual withdrawal are rarely captured against the original case. The product survives on momentum.

You can spot this by asking for the actual results set against the approved case. If that comparison has to be built from scratch, it was never part of the process. The same goes for business cases stored in a shared folder with no owner named.

Findings that stop at the handoff to the business

Finance identifies an unprofitable customer segment or a product that drains margin. The report goes to the commercial lead. Nothing changes, because pricing, terms and range decisions sit with people who were not involved in the analysis and do not trust it. Mix optimisation becomes a recurring slide.

One marker is the same underperforming items appearing in successive reviews with no recorded decision. Another is sales and operations teams producing their own competing margin figures.

Cost improvement savings that cannot be located

Continuous improvement initiatives report savings that never appear in the ledger. Sometimes the saving was real but was absorbed elsewhere. Sometimes it was avoided cost that was never budgeted. Without an agreed way to evidence a saving, claims and results drift apart.

The symptom is a savings tracker that totals well above the movement in actual costs, with nobody able to reconcile the two. Budget holders who have "delivered" savings yet still overspend are another clue.

Exceptions handled outside the system

Intercompany charges, shared service recharges, one-off rebates and returns rarely fit the standard allocation logic. They get handled in a side spreadsheet owned by one person. When that person is absent, the cycle stalls or the exceptions are skipped.

Look for reports that cannot be produced on time without a specific individual. Also check whether the side workbook feeds the model through pasted values with no audit trail.

Questions to ask the people who run it

Documented procedures describe the intended path. These questions reveal the real one.

• Which numbers do you adjust before anyone else sees them, and why?
• Where does your driver data come from, and what do you do when it arrives late or looks wrong?
• Which spreadsheets would stop the cycle if they disappeared tomorrow?
• When a result surprises the business, what is the first thing you check?
• Who decides what happens after a product or customer is shown to lose money, and how do you hear about that decision?
• How do you know whether a new product is meeting the case it was approved on?
• Which allocation rules have you changed informally, and who agreed to the change?
• When a saving is claimed, what evidence do you ask for before counting it?
• What do you rebuild every cycle that you wish were fixed at the source?
• Which report do people ask for that the system cannot produce?

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.