WIP Transactions

During the life of a project, things don’t always go to plan. Timelines can slip, and projects may need to be carried over to the next financial period (or, the project just might be massive in nature, and it is unavoidable that it will span multiple periods). In these cases, it is important to be able to track the costs associated with a project, and see those costs reflected in the financial statements of the organisation when periods roll over. This is where WIP (Work in Progress) transactions come into play.

What are WIP Transactions

A WIP transaction is a special type of transaction that allows you to capitalise costs associated with a project against the underlying Bucket Component Items, without having to consider any other capitalisation impacts such as disposal, impairment, or the effect on accumulated depreciation.

The Transaction Type for WIP Transactions is called ‘WIP Transfers’.

WIP transactions behave just like a regular transaction in that they are protected by the rules of the Capital Transactions Ledger, they exist within a single reporting period, are ascribed to a Finance Category, and will impact the Fair Value of the underlying Component. The one exception to the ’normal’ suite of rules is that WIP transactions can be posted against Components that have a status of ‘Proposed’. That is, a Component that is not yet commissioned, may receive WIP transactions to carry value prior to final commissioning.

The above compliance with the rules of the Capital Transaction Ledger rules is why you will still be required to provide a valid Posting Data and Finance Category when generating WIP transactions. Note; the Finance Category is only required for Components that do not currently have any entries in the Capital Transactions Ledger.

What happens to WIP Transactions after Final Capitalisation

When a project is completed, and the final capitalisation occurs, the WIP transactions that have been posted against each Component (by the current Budget Bucket) are summed up and the total value is ‘rolled back’ against each item. The following table outlines how this process may look from the perspective of a single Component Item:

As shown above, the WIP transactions that were posted against the Component Item over several years are rolled back at the time that the Final Capitalisation occurs. The same value that is rolled back, is then added to the Component Item using the Capitalisation methodology defined for the Budget Bucket. In this case, it was ‘Installation’, reflecting 100% New Capitalisation shares.