The project crosswalk reaches capitalisation. What survives it?

A chiller is bought, installed, commissioned and handed over. While the project ran, the money that bought it was tracked against a code, and that code was tied to the general ledger by a requirement somebody was answerable for. After handover it is an asset on a balance sheet, with a useful life, a depreciation charge and a maintenance history.

Both of those are true, and both are governed. The question this piece asks is narrower than it sounds: after capitalisation, is anybody required to preserve how the project item and the recorded asset are the same chiller?

Two records of one quantity, during the project

, read: The certified value and the booked value are two different recordsThe certified value and the booked value are two different records

What the project is required to keep joined

The joining requirement is real, it is specific, and it is stronger than the practitioner complaint about silos would suggest.

That is not a recommendation to align things where convenient. It is an exact correlation, at a stated depth, between a technical structure and an accounting structure, and the handbook is explicit that the structure carries the traffic between systems: the WBS "typically serves as the common relational reference point" between budgeting, scheduling, cost accounting, time keeping and performance analysis. The coding structure is settled by the project team in coordination with the financial organisation, so that it "consistently matches the coding structure used by the NASA financial community for cost accounting".

The direction of that requirement is worth noticing against the one another guide names. The GAO Cost Estimating and Assessment Guide's best-practice statement asks for an estimate "based on a WBS that is product-oriented, traceable to the statement of work, and at an appropriate level of detail to ensure that cost elements are neither omitted nor double-counted". Traceable towards the contract. The guide's own chapter on the estimating structure was not reachable in the copy read here, so nothing further is claimed from it.

Saudi Arabia's national projects manual builds the same joint from the other side. Its cost coding procedure composes a control account out of four parts: a project number, a work breakdown code, a locator for the physical area, and a cost code for the commodity.

The joint to the ledger is made one chapter away, and it is the part worth reading twice. The cost and commitment procedure says flatly that "actual costs are available from the accounting system" and that "payments are imported into the Project cost control system". It carries a reconciliation template of its own, EPM-KPC-TP-000010, whose form sets the corporate general ledger against the project's cost and commitment balance, prints an unreconciled items line, and is signed and dated by whoever prepared it. Its monthly review asks whether something "was cost-coded incorrectly", whether actuals were "posted to the wrong commodity", and requires a check with Accounting before a commitment is closed.

And it names an owner.

Five functions, one of them Accounting, with ultimate responsibility resting in a named place and a Division of Responsibilities to be settled after engineering release. Whatever else is true of the cost-to-ledger mapping during delivery, in these documents it is required, mechanised, reconciled on a cycle, evidenced on a form and owned.

Where the project-side requirement stops

Read the NASA sentence again for its scope rather than its strength. Each WBS element is assigned a unique code "to be used as a reference point for its technical and financial identification throughout the life of the project". The correlation is to the project's accounting structure, for cost accounting and earned value, for as long as there is a project.

The Saudi manual ends the project in a different volume, and that volume was searched for the joint.

Neither of the two functions that would have to carry the mapping forward appears in that list. There is no finance role and no asset management role among the eight, and no accounting or asset document among the twelve.

That absence was measured rather than assumed. Both Saudi national manuals, the one for projects management and the one for assets and facilities management, were extracted to text in full, 743 documents, and searched: the phrase "asset register" appears in the assets manual and does not appear in any Projects Management document in the collection held. The asset register is defined, in detail, in the other manual, which sets out asset classification, data collection, physical verification and the asset hierarchy, and shows financial systems and procurement among the register's interfaces. It is a complete instrument. It is reached from the projects manual by no reference at all.

Where the accounting side makes the join

The asset arrives on the accounting side through a different procedure, and in the Saudi case that procedure is published. The Ministry of Finance's comprehensive manual for the census and valuation of assets of government entities sets out, in its section on adding assets under construction to the non-current asset table, what finance does with a project's cost.

That is a join, and a required one. At capitalisation the project's cost is taken apart into assets and components by a named function, against documents the project supplies. The reading above, that the requirement to keep the mapping is written in project terms, has to be held against it: in this national procedure the mapping is exercised once more, by finance, on the way onto the balance sheet.

What the procedure does not say is what the resulting asset record keeps. The steps describe the transfer and name its outputs, the updated non-current asset list and the updated general ledger. They do not say that the project code, the work breakdown code, the cost code, the contract package or the allocation itself stays with the asset once it is on the list.

One asset through six structures

What follows is an analytical example built from published classification structures. It is not an observed project, it does not describe any organisation, and every code shape in it comes from a document cited above rather than from a real asset register.

Take the chiller. During delivery it is a work breakdown element inside a mechanical facility group, a locator pointing at the plant room, and a commodity code under the heating, ventilating and air conditioning division of a work-result classification. Those three, with the project number, compose one control account, and that control account is what the ledger reconciliation ties to the accounts.

At the same time the machine is a line in a purchase order or a mechanical subcontract package, priced in the units a trade estimate uses. It is a tag on a drawing. After commissioning it becomes a maintainable item with a functional parent, sitting in a room, in a floor, in a building.

Then it becomes an accounting entity: an asset class with its accounting code, the natural accounts its cost and its depreciation are posted to, an acquisition cost, a useful life and a capitalisation threshold it either cleared or did not. The Ministry's manual lists the forms that carry these on page 225.

Six identities. The mappings on the project side are required while the project exists. The accounting identities are set out in the Ministry's manual. Between the two, the Saudi procedure requires the join to be made once, at capitalisation. What none of the public documents read here establishes is that the join is kept afterwards.

Two functions, separate hierarchies, no shared vocabulary

, read: The competence you need is not in the asset management functionThe competence you need is not in the asset management function

What the accounting standard does when the mapping is not there

IPSAS 45 makes the unit of account finer than the machine.

Then it requires an event that happens years later, in a different system, to reach back into the original cost.

Read the second sentence carefully, because it is easy to over-read. The provision is a measurement expedient. It tells an entity what to do when a carrying amount cannot practicably be determined, and there are several reasons that might be so: the part was never separately recorded, the original cost was not split that finely, the records are old, or the allocation would cost more than it is worth. It is not evidence that a mapping existed and was lost, and this piece does not use it that way.

What it does establish is what the standard requires, which is the point: an approximation is permitted at the step where the maintenance system and the capitalised cost have to meet. The standard's own implementation guidance then works an example around exactly that condition.

A standard-setter writing an example around records that cannot be reconstructed is describing a situation it expects to be met. That is the board's own account of the terrain, and it is a stronger basis than any assertion this publication could make about how common the condition is.

Where componentisation stops, and what stops it

, read: A lighting pole in the desert is not an assetA lighting pole in the desert is not an asset

The classifications that say they are the thread

The argument so far has to survive the fact that the classification bodies say they have solved this.

The claim and the scope limit sit in one document. A thread declared to run from planning to disposal is declared, on the same page, unsuitable for the trade estimate a contract package is priced in, and inapplicable to civil works. ASTM marks that revision Historical and lists E1557-09(2024) as active; the quotations are from the 2020e1 revision and are attributed to it.

The Construction Specifications Institute makes the broader claim on its own account. Its standards page describes MasterFormat, UniFormat and OmniClass as "construction's shared language: a connected system that keeps meaning intact as a project moves from concept to design, documentation, bidding, construction, handover, and operations", and describes MasterFormat as organising specifications "into work results that contractors can price, procure, and build". That is the publisher describing its own standards rather than the standards themselves, and it is quoted here as such.

A shared vocabulary is worth having and it is a different thing from a maintained mapping between six populated systems. The vocabulary is also not static: CSI states that MasterFormat 2026 introduces "2,185 new and 617 reorganized listings". Reorganised listings are a mapping event for anybody whose cost codes are built on them, which is the subject of this piece arriving from an unexpected direction.

The asset management standards have addressed the seam directly, and the shape of what they produced is informative.

ISO gives two alternative grounds for issuing a Technical Specification and its catalogue does not say which applies here, so no conclusion about the state of agreement is drawn from the deliverable type. What can be said is what ISO says: the aim for a document of this kind is transformation into an International Standard, and this one is on its second edition six years after the first without having been transformed.

What it costs where somebody is looking

The consequence of a property record that cannot be reconciled is documented, in one jurisdiction, by its own auditor.

That is nine years between the finding and the department's own estimate of when it will be closed, and the estimate is what it is: a date the department has given, not a repair that has happened.

The boundary on this evidence matters. It documents reconciliation failure between real property records and financial reporting systems, in a single department, under a statutory audit regime most owners do not face. It is used here for what it documents and for nothing wider. It says what a reconciliation failure costs where an auditor is looking. It does not establish how often the six structures diverge anywhere else, and no such figure is offered.

Why a register can be current, approved and wrong

, read: Nothing tells you when a record stopped being trueNothing tells you when a record stopped being true

What to ask

The test is a trace and three counts, and a reader can run it on one asset in an afternoon. Pick a maintainable item with a capital cost and follow it through ten stops: requirement, design tag, work breakdown code, cost code, purchase order or package, installed location, commissioning record, asset register identifier, capitalised cost, and maintenance record.

At each of the nine transitions, ask three things.

Is the identifier carried, derived, or created again? Carried means the same string appears on both sides. Derived means a rule turns one into the other and the rule is written down. Created again means somebody read one system and typed into another.

Where does the mapping live, and can it be opened by a second person? A mapping held in one person's working file is a different control from a mapping held in a system, and the difference shows up when that person is not there.

Who is answerable for it after capitalisation? The project answer is usually available, because the documents above require one, and the Saudi manual names finance for the transfer itself. The question is what the answer becomes once the cost has been transferred and the project has closed.

Three counts come out: manual re-entries, identifiers that could mean more than one physical thing, and mappings with no named owner after capitalisation. The counts are the finding. There is no score attached to them here, and none is needed: an owner who knows that the number is four rather than zero knows what to do next, and an owner who cannot produce the number has already learned something.