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.
Example
During a reporting period, an asset component may have six (6) renewal transactions, two (2)
depreciation transactions, and one (1) upgrade transaction posted against it. The end of period
report (the Temporal Finance Report) will sum the six (6) renewal postings, the two (2)
depreciation postings, and the one (1) upgrade postings as the summary of movements for that
component during the reporting period.
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.

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).