Finance Categories

The finance category is the principle categorisation field for the Financial Movement Report - the key input tool for an organisations ‘Infrastructure, Property, Plant, and Equipment’ statement. Typically, organisations will configure one finance category within Metrix for each desired reporting row within this end of period statement.

In practice, an asset components finance category is assigned via the first financial transaction ledger entry made against it. Each subsequent transaction, posted against that component, will inherit that finance category. To change a components finance category, a ‘Reclassification’ process must occur which will write-off the gross and accumulated depreciation value from the component under the ‘old’ category, and then write both back on against the ’new’ category (no value is created or lost, but the finance category will be changed).

Finance Category ID

The finance category ID is the only way to make a valid reference to a finance category from external locations such as API calls or CSV Data Imports. Once a finance category has been created, the ID value (which will remain constant regardless of alterations) can be found in the ‘Code’ column of the finance category preview table.

Transaction Types

The transaction type is designed to inform the financial transaction ledger on the type of financial movement that the entry represents. Built-in transaction types include ‘Recognition’, ‘Renewal’, ‘Addition’, etc.

Transaction Type Effects

Each transaction type is assigned to a transaction type effect of ‘Gross’ and/or ‘Accumulated Depreciation’. When the Temporal Finance Report is generated, the movement results are summed into these transaction type allotments.

Restrictions can be applied to transaction type posting values such as ‘Positive Values’ only, or, ‘Negative Values’ only. This can assist with controlling end user input around expected movement behaviour in terms of capital value. For example, the built-in depreciation transaction type has a restriction of ‘Negative Values’ only because depreciation is always and only ever a decrement to an asset components carrying value.

Transaction Type ID

The transaction type ID is the only way to make a valid reference to a transaction type from external locations such as API calls or CSV Data Imports. Once a transaction type has been created, the ID value (which will remain constant regardless of alterations) can be found in the ‘Code’ column of the transaction type preview table.

Information about System Transaction Types

The important thing to note about transaction types is that they are performing two roles. Firstly, they are “grouping” the transaction for EOY reporting. That is, the renewal, depreciation, addition, parts of the transaction type are simply grouping the spend into a category. Additionally, they are “allocating” the transaction to have an effect on either the gross value or the amount of accumulated depreciation carried by the component. That is, the gross versus accumulated depreciation parts.

Sites can also add their own transaction types to cover financial cases not considered by the system’s built-in types.

The following are some generic definitions for the system pre-configured transaction types (grouped into like categories):

Financial Management Transaction Types

Depreciation: Economically recognising the year-on-year (or quarter, etc.) degradation of infrastructure. This transaciton type has accumulated depreciation effect targets only. Indexation: Economically recognising the impact of CPI on the valuation register. When a component is indexed, the “percentage” effect is applied equally to gross and accumulated depreciation. Revaluation: These transaction types balance a component’s capital value to the desired level for revaluation. They are adjustments to the gross and/or accumulated_depreciation so that the new value matches that of the valuer’s.
WIP: These are for recognising works in progress. WIP transactions can be posted to carry gross project value over financial periods when project timeframes span more than one financial period. At the “end” of the project, any WIP transactions would be “reversed”, and the value would be reposted with its actual transaction type (i.e. addition, installation, etc.).

Infrastructure Modification Transaction Types

Additions: For upgrading existing infrastructure (road widening, building additions, etc). Typically, these transactions only target gross value. Installation: For new infrastructure. Again, these transactions typically only target gross value. Recognition: Used for onboarding value into the system - that is, Metrix recognising existing value on components. This could also be used for recognising value for “found” assets and the like. Renewal: Used for tracking spends that are focused on the replacement of existing service capacity of infrastructure (reseals, pipe replacements, etc.) Note, the use of the term “service capacity” is aimed at extending to cases where a component may be in a new location, but its purpose is to usurp that of an existing component (i.e. pipe replacement on the other side of the road).

Disposal/Impairment Transaction Types

Disposal: Accelerated depreciation of infrastructure to allow removal from the ledger. Typically, the system will only target accumulated depreciation with disposal transactions. Impairment: Same as disposal but recognises the loss of value is due to a specific event (e.g. storm damage). Like disposal, the system will typically only target accumulated depreciation with impairment transactions. Write-Off: This transaction type is easily/often confused with disposal/impairments. The actual intention of the write-off transaction type is to fully remove any trace of value AFTER a disposal (or after the component reaches $0 written down value). See the worked example below for context of its intention:

• Component with gross value of $1000, accumulated depreciation of -$900, would be carrying a written down value of $100.
• To dispose (or impair) the component, one would post a disposal-accumulated_depreciation transaction of -$100.
• Its new value state is now: gross value is $1000, accumulated depreciation is -$1000, written down value of $0.
• The actual gross value (and accumulated depreciation) is still sitting on the capital valuation register at this point. True, they do cancel each other out in terms of written down value, but they are still inflating gross/accumulated_depreciation figures.
• To fully remove the value, the Write-Off transactions are used. The gross value is written off with -$1000, and the accumulated depreciation is written off with +$1000.

System Operation Transaction Types

Adjustment: System transaction type for splitting/merging. These transactions balance-off value from a parent to children records (or vice-versa for merge). Migration Adjustment: Legacy system transaction type used in onboarding clients that have historical movements that do not fit into the above.

It is NOT recomended that end-users of the Metrix Asset Management system utilise these system operation transaction types directly. Rather, leave them for tool-call usages (such as split and merge).