After the order of the organization that the product has been put into operation, it is necessary to prepare an order for placing the software on the balance sheet, determine its initial cost, useful life, etc. How to do it? It is necessary to create an expert council, which, as part of the discussion of the functionality of the software, will give recommendations and estimates related to the cost of the software. It is better to formulate expert recommendations in the form of a protocol, which should then be submitted to the accounting department. The initial cost is determined independently by the developer company and most often includes direct costs directly. It is not necessary to overstate the cost of the software, because after accounting, the company will have to pay taxes, which will depend on the initial cost. The detailed rules for the formation of information on intangible assets of organizations in accounting and accounting statements are established by PBU 14/2007 (Accounting Regulations “Accounting of Intangible Assets”, appendix to the Order of the Ministry of Finance of the Russian Federation No. 153n dated December 27, 2007).
So, in order for internal development to be fully formalized, it must be protected by the following documents:
1. Service assignment
2. Report on the completion of the task
3. The act of acceptance of the software product for operation in the company
4. The order on setting the software on the balance sheet
An intelligently and correctly conducted formalization process turns internal development into a software asset. Speaking in legal and accounting terms, this way an intangible asset is obtained that increases the capitalization of the company. Despite its intangible status, a software asset has a lot in common with ordinary assets, but, first of all, it is its value. A company can earn, for example, by transferring non-exclusive rights to a software product to other companies/users or using it in an organization, optimizing costs for tasks that were not previously automated, reducing labor costs for their implementation. If this development is an expensive product, it will significantly increase the capitalization of the company.
What can an ordinary developer expect?
This is a very frequent question from programmers: “What benefit do I, as a creator, get from the formalization of the application I wrote?” If the employer for whom the developer created the application has formalized this application legally correctly, the programmer is left with the so-called personal non-property right of the author. It most likely does not carry any monetary benefits with it, since the creator has already received remuneration for the work done, and he no longer has any property rights to the software written by him. Non-property rights allow you to amuse your own ego and add a project to your portfolio. For example, the author of the development has the right to propose the name of the software himself, to allow you to specify your name in the context of the application. But keep in mind that the right to indicate the author’s name, or not to indicate it, is also regulated by the aforementioned employment contract. I will also note that non-property rights also apply to several people, that is, a product may have several authors.
Please note that if at the development stage, or within three years after, the employer announced that the software product is a trade secret, then it is prohibited to disclose any information about the software.
Why is paperwork important?
My colleagues and I often have to face a situation when the owner or top managers of customer companies do not even know what software and for what purposes the development team has created. We receive information about such software at the very first stage of the Software Asset Management procedure, when special tools scan servers and PCs in the customer company. Having discovered such “artifacts”, we, together with the responsible employees, raise the necessary documentation and at least understand that we are facing an internal development.
Imagine a situation where a check comes to the company, which discovers an incomprehensible “left” software, for which there is no documentation confirming its licensing. The excuse “our programmers developed it” does not work in this case, supporting documents are needed. Without them, the company may face the withdrawal of hardware and software until the circumstances are clarified. Probably, sooner or later the company will prove that this software is their own development, but the effort and time spent on this is not comparable to the risks to business continuity that the company may incur. Such a horror story instead of a conclusion.