A fixed asset conversion looks like a technical exercise and behaves like an accounting one. Records move from one structure to another, and in the process every ambiguity in the source data has to be resolved into a specific value. Whoever writes the mapping is making accounting decisions, whether or not that is what anyone called it.
It is also close to a one-way door. Once a converted register is reconciled, signed off and used to produce a depreciation run, unwinding a bad mapping means unwinding everything built on top of it. The cheapest moment to get this right is before the first record moves.
Decide what the fields mean before you decide where they go
Mapping is usually approached as a matching problem: source field to target field. The harder question is what the source field actually contains, which is often not what its name suggests. Description fields that accumulated location codes. Acquisition dates that are sometimes invoice dates. A class field that three different eras of staff used three different ways.
Before mapping anything, work through the fields that carry accounting consequence and write down, for each one: what it is supposed to mean, what it actually contains, and what the rule will be going forward. Fields worth this treatment usually include asset class, acquisition date, in-service date, cost, useful life, depreciation method, location, entity, and whatever links a record back to its originating project.
Settle the accounting questions
These are the decisions that determine whether the converted register is defensible.
- Depreciation history: carry or recalculate? Carrying history preserves the audit trail and the errors. Recalculating produces internal consistency and a variance to explain. Both are legitimate; the choice has to be deliberate and documented.
- Which books come across? Financial, tax, state, alternative minimum — and whether they currently agree. Conversions frequently reveal that tax and GAAP diverged years ago for reasons nobody recorded.
- Fully depreciated and disposed assets. Whether they convert at all, and if so with what flag. Bringing everything increases fidelity and clutter; leaving it behind loses history you may need.
- Componentization. Assets recorded as lumps cannot be componentized later without effectively re-creating them. If the future state needs component-level detail, conversion is the natural moment.
- Lives and methods. If the target environment enforces a class-based standard and the source data does not follow one, conversion will surface every exception at once. Decide in advance which exceptions are intentional.
- In-service dates. Dates set for convenience rather than readiness are common, and conversion is the last easy chance to correct them.
Fix the reconciliation first, not after
If the sub-ledger does not tie to the general ledger today, it will not tie after conversion, and the conversion will be blamed. Establish the reconciliation before the move so there is a known starting position. A documented, explained variance is a workable baseline. An unexplained one becomes a permanent argument about whether the conversion caused it.
The same applies to population completeness. Confirm what the register is supposed to contain — against the project system, against capital spend, against the physical estate if that is practical — before deciding that the source is the source of truth.
Decide who owns the decisions
Every conversion generates a stream of small judgement calls: this record has no in-service date, this class does not exist in the target, this cost includes something that should not be capitalized. Under deadline pressure those get resolved by whoever is closest to the file, which is often a technical resource with no mandate to make accounting decisions.
Name the person who owns those calls before the work starts, and keep a log of every one that is made. The log is not bureaucracy — it is the document that explains the converted register to an auditor, and to whoever holds this role in three years.
Plan validation before you plan the cutover
Validation is where conversions are actually won, and it needs to be specified in advance rather than improvised at go-live.
- Control totals. Cost, accumulated depreciation and net book value by class and by entity, source versus target, before and after.
- Record counts with reasons. Any difference between source and target counts should be explained by a documented decision, not discovered afterwards.
- A parallel depreciation run. Run one period in both environments and reconcile the difference. Unexplained variances here are the cheapest ones you will ever find.
- Targeted sample testing. Pick the hard cases deliberately — the oldest assets, the componentized ones, the ones with mid-life adjustments, transfers, partial disposals and impairments.
- Report parity. Reproduce the reports leadership and audit actually use, and confirm they answer the same way.
What "clean data" really means
Clean data is not data without blanks. It is data whose every field has an agreed meaning, a documented rule, an owner, and a lineage you can explain. A register with gaps you understand is in better shape than a complete one whose values nobody can account for.
Conversion is worth treating as the accounting event it is. The technical part — extract, transform, load — is the straightforward half. The half that determines whether the new environment is trusted is everything decided before the first record moves.