Why AI Fails on a Badly Designed Cost Model

The first three posts in this series looked at what AI does inside Oracle EPCM: the PCM Agent writes rules, IPM Insights flags movements and generative AI summarizes them. Every one of those features assumes the model underneath is right. This post is about what happens when it isn't.

The short version: AI reads the structure and the numbers of a cost model. It doesn't judge whether the logic is economically sound. A wrong driver produces a precise wrong answer, and AI delivers that answer faster, more often and in more confident language.

Same cost, two answers

Take a simple case. A bank spends $1.0 million a year on IT support for three product lines. The model allocates it by headcount, because headcount was easy to get. The work, though, is driven by support tickets.

Figure 1. Illustrative numbers. Cards consumes 55% of the tickets but receives 20% of the cost, so its margin looks better than it is.

Both versions calculate without errors. Both reconcile to the ledger. Only one describes how the cost is caused. Now add AI on top of the wrong one:

• The PCM Agent copies the headcount rule from actuals into the plan model in one request, so next year's budget inherits the error.
• IPM Insights flags a jump in IT cost for Loans when that team hires five people, even though their ticket volume didn't change.
• The generative summary explains the jump in a clear paragraph. The paragraph is accurate about the model and wrong about the business.

None of these features did anything wrong. They worked as designed on a model that wasn't.

Five design flaws AI makes worse

These are the flaws I'd look for first, because each one gets amplified by a specific AI feature.

Figure 2. Each flaw is tolerable while people work slowly through the model. AI removes the slowness that used to catch it.

1. A driver without a cause. The driver correlates with the cost, or was simply available, but doesn't cause it. Headcount for IT, revenue for marketing, square meters for a shared service where half the staff works remotely. AI can't detect this, because nothing in the model says what the driver is supposed to represent.

2. Idle capacity inside the rates. If the cost rate of an activity is total cost divided by actual volume, every drop in volume raises the rate and pushes unused capacity onto the products that remain. Time-driven ABC, as Kaplan and Anderson described it, uses practical capacity instead and reports unused capacity on its own line. Without that separation, Insights will flag product margins falling when the real event is a half-empty operation.

3. Stages mixed in one rule set. Resource-to-activity and activity-to-product rules sitting together make the waterfall hard to trace and every agent request ambiguous. The model still calculates. Nobody can explain it quickly, and AI won't either.

4. Names that only the builder understands. "Rule 14b" and member codes without aliases block the PCM Agent, which works by name, and turn generative summaries into lists of codes. This one is cheap to fix and expensive to ignore.

5. A balancing bucket nobody owns. "Other", "Unassigned" or a plug account that absorbs whatever doesn't fit. It moves every month, so Insights will keep flagging it, and the summary will keep describing it as if it meant something.

A design check before you switch on AI

You don't need a full rebuild to find these. Five questions, asked rule by rule, catch most of them:

1. Can you state the cause behind each driver in one sentence? "IT support work is driven by tickets" passes. "We had the headcount file" doesn't.
2. Are activity rates built on practical capacity, with unused capacity reported separately?
3. Does each rule set hold one allocation stage, in the order the cost actually flows?
4. Could someone outside the project read every rule name and member alias?
5. Do you know what sits in unassigned or balancing accounts, and who owns it?

If the answers are mostly yes, AI will make the model faster to work with. If they're mostly no, fix the design first. The AI features will still be there next quarter, and they'll be worth more on a model that deserves them.

Next in the series

Part 5 covers the piece Oracle's program doesn't include yet: a conversational layer that lets a CFO ask why a margin moved and get an answer traced to the drivers. It only works on a model that passes the check above.

If you want a second opinion on whether your cost model is ready for AI, write to me at psanmartin@asher.company.

---

Pedro San Martín is Founder & Principal of Asher & Company, a strategic finance and profitability analytics firm specializing in Enterprise Performance Management, profitability architecture and cost management. He chairs the IMA Profitability & Cost Management SIG.

Sources: Robert S. Kaplan and Steven R. Anderson, "Time-Driven Activity-Based Costing," Harvard Business Review, November 2004; Oracle EPCM documentation on the PCM Agent and IPM Insights, cited in Parts 2 and 3 of this series.