Fixed Asset Lifecycle Management

Asset-heavy organisations - plants, fleets, hospitals, utilities, contracting groups - tend to discover the same three gaps a year or two after going live on Dynamics 365 Finance & Operations.

The first is that the register in the ERP has quietly stopped matching what is physically on site. Nothing connects a tag on a machine to a row in AssetTable, so the annual verification is run on a spreadsheet exported from the register, reconciled by hand, and closed with a write-off journal that nobody can trace back to a specific asset. The second is that assets which are really assemblies get booked as a single line. When a compressor, an engine or a chiller is replaced, there is no clean way to retire the part - so the whole asset is disposed and re-acquired, and the depreciation history is lost. The third is the legal entity boundary. Moving an asset from one company to another in standard F&O means a disposal in company A and an acquisition in company B, which resets acquisition date, accumulated depreciation and every audit trail an external auditor will ask about.

None of this is a defect. Fixed assets in F&O is a competent ledger-side register: books, depreciation profiles, disposals, roll-forward. It was simply never designed to be the physical control system an asset-heavy business needs, and it stops where the legal entity stops.

What ECOSIRE builds

The app is written as an X++ extension in its own model. Nothing is overlayered, standard objects are extended through chain-of-command and extension classes, and the whole thing is delivered as a deployable package for your LCS pipeline.

Barcode tagging and physical verification

Every asset gets a tag number driven by its own number sequence, separate from the asset ID, so re-tagging never disturbs the register. Labels print from an SSRS report design, or as a ZPL layout through document routing if you already print to industrial printers. Verification is run as a session: a session header scopes the count by legal entity, location, asset group, custodian or ledger dimension, and the field scan populates the session lines. Scanning is done from a Power Apps canvas app on Dataverse fed by dual-write, or from the warehouse mobile app where assets sit inside warehouses you already scan. Unscanned assets, assets found in the wrong location and unregistered tags each land in their own variance bucket, and closing the session posts corrections - a location or custodian update, a dimension change, or a proposed write-off routed through the F&O workflow framework before any fixed asset journal is created.

Componentisation and asset hierarchies

Assets can carry parent and child relationships with a defined split of the acquisition value. A child component can be disposed, replaced or transferred on its own, with the parent value and accumulated depreciation adjusted proportionally through the fixed asset journal. Component records link to the standard Asset management module where you run maintenance, so the maintenance object and the financial component are the same physical thing rather than two disconnected records.

Transfers between legal entities

Inter-entity transfer is handled as a single guided process with an approval workflow. The app posts the disposal side in the source company, the acquisition side in the target company, and writes an inter-entity transfer record that carries original acquisition date, original acquisition value, accumulated depreciation to date and the source asset ID onto the new asset. Intercompany balancing accounts are configurable per company pair, and the transfer runs in the SysOperation batch framework so a fleet move of several hundred assets is one job rather than several hundred manual entries.

Parallel depreciation books

Standard F&O already supports multiple books, including books that do not post to the general ledger. What is missing is the operational layer around them: bulk creation of a tax or IFRS book across an asset group, a side-by-side variance view of net book value per book, and a proposal run that flags assets whose books have diverged beyond a threshold. Book setup, depreciation profiles and conventions stay standard - the app adds the mass-maintenance and comparison tooling on top.

From capital expenditure to capitalisation

Capital projects accumulate cost as work in progress. The app adds a capitalisation worksheet that pulls eligible project and purchase-order cost lines, lets you allocate them across one or many assets, and creates the asset records and acquisition postings in one step - with default financial dimensions inherited from the asset group and overridable per line. Purchase orders keep using the standard fixed asset acquisition flow; the worksheet exists for the multi-line, multi-asset cases the standard flow does not cover.

Data, security and reporting

Everything the app adds is exposed as data entities so it flows through the data management framework and OData: verification sessions, session lines, tag numbers, component links and inter-entity transfers. Security is delivered as privileges and duties assembled into roles you can merge with your existing role design, so an asset custodian can run a count without holding ledger posting rights. Batch jobs cover verification variance ageing, book divergence checks and label reprint queues.

Who it is for

Organisations running several thousand or more fixed assets across more than one legal entity, where a physical audit currently happens on spreadsheets, where component replacement is common, and where finance already lives in Dynamics 365 Finance & Operations. It is aimed at controllers, fixed asset accountants, internal audit and the maintenance function that has to agree with them.

How delivery works

Nothing here is pre-built or downloadable. The sequence is deliberate:

1. Scoping call. Sixty to ninety minutes on your current asset setup - books, groups, posting profiles, dimensions, legal entity structure, how you count today, what your auditor asks for. 2. Fixed quote. A written scope, a fixed price and a lead time. Typical lead time is one working week from acceptance. 3. Build. Development against a copy of your configuration, in a dedicated model with its own package. 4. Install in test. The deployable package goes into your sandbox through LCS. You run UAT with your own assets and your own tag data. 5. Production. Deployment through your normal LCS release path, in your change window, with a rollback plan agreed in advance. 6. Support. A defect-correction window after go-live, and a written handover so your partner or in-house team can take the code forward.

Scope boundaries

The app extends fixed assets - it does not replace it, and it does not change how depreciation is calculated by standard profiles. Barcode hardware, label printers and Azure or Power Platform licences are yours. If your organisation needs a full enterprise asset management rollout rather than financial asset control, that is a different conversation and we will say so on the scoping call.