Value-from-cost-source
It is tempting to let an AI "value" an asset from its attributes — a transformer of this rating, this age, in this region, is "worth" X. Do that and you have built a plausible-looking machine for generating audit findings. The principle that keeps a capitalisation engine defensible is narrow and unglamorous: value always comes from a cost source. Attributes only ever choose where it lands.
Two jobs that must never be confused
A TAR→FAR engine does two different things, and the entire credibility of the output depends on keeping them separate:
- Determination (attributes decide). Given a technical asset's attributes — class, functional location, componentisation, condition — decide which fixed asset(s) it maps to, in which asset class, split into which components, on which useful lives. This is a classification problem, and rules + ML are good at it.
- Valuation (a cost source decides). Given that mapping, attach a number. That number must come from an actual recorded cost: the AUC balance being settled, a purchase order, a manufacturer's estimated cost (MEA), a replacement-cost index, or an explicit manual entry. Never from the attributes.
Attributes pick the bucket. The cost source fills it. An engine that lets attributes invent the amount has crossed from accounting into fiction.
Why this matters to an auditor
An auditor's question is always the same: "Show me the asset behind this dollar — and show me where the dollar came from." If your answer is "the model estimated it from the asset's characteristics," you have failed the question. If your answer is "this $4.82M AUC was apportioned across these three components by this documented rule, and here is the immutable trail of who approved it, and the evidence is attached to the asset in SAP," you have passed.
That is why the two dimensions in the engine are configured separately:
amountSource— where the money comes from:AUC | PO | MEA | Index | Manual.apportionmentBasis— how a multi-line cost is split:Percentage | Equivalence | Quantity | ReplacementValue | Condition.
The basis decides the weights; the source decides the total. They are never the same knob.
The apportionment has to tie to the cent
When a single AUC produces several assets, the apportioned amounts must sum back to the original cost exactly — not approximately. Floating-point splits that lose a cent are not a rounding nuisance; they are a reconciliation break that an auditor will find. A correct engine uses a largest-remainder method so the parts reconstitute the whole to the cent, every time. On a $4,820,000 AUC split three ways, the three lines sum to $4,820,000 — full stop.
The compounding benefit
Keeping determination and valuation separate has a second payoff: every approved mapping becomes a reusable rule. "This techClass, this pattern → this class, this split, these lives" accrues, within your own instance, into a template library that gets more accurate with every approval — without ever letting the model touch the money. That's how you get a system that improves over time and stays defensible the whole way.
See it on your own AUC
A paid concierge on one completed project: map, apportion to the cent, approve, and hand SAP the asset masters and a settlement rule with the evidence pack.
Request a fit call →