From Network Build to Fixed Asset
Last updated 12 Oct 2026
At a glance
Network build spend becomes assets that are depreciated over years, and ERP is where that happens: project, asset under construction, fixed asset, depreciation. It is the one place ERP and the network meet directly, and the asset register has to be reconciled with resource inventory.
The picture
Two registers of the same network, built by different teams at different granularity
ERP: the capital path
- 1Investment projectCollects equipment, contractor and labour cost
- 2Purchase and goods receiptInto stock or straight onto the project
- 3Asset under constructionWork in progress while the site is built
- 4CapitalisationAt commissioning: useful life, depreciation method
- 5Depreciation, impairment, disposalEach period, until decommissioned
Resource inventory (TMF639)
- Cabinet
- OLT chassis
- Line cards × 4
- PON ports × 64
- Uplink ports
- Logical resources
Elements, ports and topology, updated continuously by engineering and OSS
- Card swapped: no finance event
- Asset written off: element still carries traffic
How it works
From purchase to depreciation
Investment project
A rollout or build is set up as a project that collects costs: equipment, contractors, internal labour.
Purchase and goods receipt
Equipment is bought through procurement and received into stock or straight onto the project.
Asset under construction
Costs accumulate as work in progress while the site or route is being built.
Capitalisation
At commissioning the costs move to one or more fixed assets, with a useful life and a depreciation method.
Depreciation and disposal
The asset is depreciated each period, written down if impaired, and retired when it is decommissioned.
Two registers of the same network
| ERP fixed assets | Resource inventory (TMF639) | |
|---|---|---|
| What it records | Cost, book value, useful life, depreciation | The element itself: type, location, ports, capacity, topology, state |
| Granularity | Often a site, a route or a batch of equipment | Individual devices, cards, ports and logical resources |
| Who updates it | Finance, at capitalisation and disposal | Engineering and OSS, continuously |
| What it is used for | The balance sheet, depreciation, impairment | Fulfilment, assurance, capacity planning |
Why they drift
The two are built at different granularity by different teams on different clocks. Equipment is swapped without a finance event; an asset is written off while the element still carries traffic; a site is capitalised as one asset that inventory knows as hundreds of elements. Reconciling them needs a shared key, an asset or project reference held on inventory records, and a regular comparison.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Fixed asset (cost, book value, depreciation) | ERP | — | Resource Inventory | The financial view of the network. |
| Network element, port, logical resource | Resource Inventory | — | ERP (asset reference) | TMF639. The working element, with topology and capacity. |
| Investment project and asset under construction | ERP | Engineering, field service | — | — |
| Purchase order and goods receipt | ERP (procurement) | — | — | — |
| Asset-to-element link | Resource Inventory (asset or project reference on the record) | — | ERP | Only exists if someone designs it; without it, reconciliation is manual. |
In practice
Finance capitalises at whatever granularity suits the balance sheet, and engineering models at whatever suits fulfilment. Neither is wrong. The problem appears when a question needs both: which elements make up this asset, or which asset does this element belong to.
The trade-off
What it solves
Separate registers let finance account for the network at the granularity the balance sheet needs while OSS models it at the granularity fulfilment needs.
What it does not solve
- Drift between the two registers.
- Equipment changed in the network without a finance event.
- The missing link for assets capitalised before a shared reference existed.
What it adds
- A shared asset or project reference to maintain on inventory records.
- A regular reconciliation process owned jointly by finance and engineering.
Architecture decision
At what granularity should the network be capitalised?
Coarse: one asset per site, route or batch
Choose when the main need is depreciation and the balance sheet, and inventory holds the element detail.
Finer: assets that map to major equipment
Choose when impairment, network sales or carve-outs are likely and need assets traceable to elements.
Breaks if no shared reference is held on inventory records. At any granularity the registers then drift with nothing to reconcile them by.
Takeaways
Key Takeaways
- Network build flows through ERP as project, asset under construction, fixed asset and depreciation
- ERP owns the financial asset; resource inventory owns the element; neither replaces the other
- The registers differ in granularity, owner and update cycle, so they drift
- A shared asset reference and regular reconciliation keep them aligned
Check yourself
A card is swapped in a live OLT. Inventory is updated; ERP is not. Is that a problem?Show answerHide
Not immediately, because ERP may hold the site as one asset. It becomes one when someone needs to trace assets to equipment, for an impairment test or a sale, and finds the registers no longer match.
The board is planning a tower carve-out. What do you need from the two registers?Show answerHide
A mapping from each financial asset to the towers and equipment in resource inventory. Without a shared asset reference, that mapping has to be rebuilt by hand, which can take months.