The Measurement of Databases in the National Accounts (Update)
Nadim Ahmad
Introduction
1.At the last Canberra (II) meeting held in Paris in October 2003 four proposals were presented concerning the capitalisation of databases. These are repeated, for convenience, below:
- To capitalise all databases, including those produced on own-account, with an expected service life of more than year;
- To capitalise, only, databases maintained by businesses in data-providing industries
- Not to record the own-account production of databases as capital formation but to record the transfer of databases (only when exclusive proprietary rights are sold) in the revaluation account.
- To capitalise only databases that are capitalised by businesses
2. The OECD/Eurostat Software Task Force had considered this issue, and the consensus agreed with proposal (I), that all databases in principle should be capitalised, but recognised the practical difficulties involved in estimation and so acknowledged the practical solution provided by proposal (III). The Task Force did not consider option (IV) explicitly but the evidence (presented below) suggests that this approach will not be a panacea vis-à-vis estimation.
3.The earlier paper presented on this issue took a stronger line on the Task Force deliberations, which remained inconclusive, and recommended that proposal (III) be adopted by the Group. The Group were however not convinced that the practical issues regarding measurement should override the substantive issue (relating to the widely-held view) that all databases (satisfying the SNA asset requirements) should, in principle be capitalised. As such the Group could not agree to the recommendation made in the earlier paper on this subject.
4.In fact, the consensus was that a statement of principle should form the recommendation but recognising the practical difficulties involved in estimation. As such, one might interpret the recommendation from the Group to be: proposal (I) in theory but proposal (III) in practice.
Macro-Based Estimation
5.To a large extent, this thinking reflects the fact that the measurement of own-account production of all databases is very difficult; if we accept that databases exist in literally every business and that databases can be produced by manual typing or by assimilation of other electronic data. However, that said, the method used to estimate own-account software originals may provide a way forward here.
6.In this way the value of own-account construction could be estimated if companies were asked to report estimates of employees working on the construction and updating of databases, or if some other source of employee numbers in this field could be determined, including any additional costs of production such as payments for data and consumption of fixed capital from any hardware used in production.
7.In summary therefore one could estimate own-account production of databases as:
Total number of employees working on database construction/updating *
Average remuneration *
Proportion of time spent on own-account development of databases +
Other intermediate costs used in own-account production of databases(including data costs) +
Notional operating surplus related to own-account production of databases.
8.The main problem with this approach is that no international definition of individuals working on database management or construction exists. In the International Standard Classification of Occupations (ISCO 88) the closest categories are ISCO 213 (computing professionals) and ISCO 312 (computer associate professionals). However the Software Task Force recommended that ICSO 213 be used as the basis for calculating own-account software; where better estimates were not available. It is possible that some employees classified to this activity may in fact be database producers and so there is a danger that separate recommendations for databases may lead to double-counting.
9.This is even more likely if one further considers the delineation between software and databases; since the latter nearly always embody some of the former. In fact we should be clear that the Software Task Force recommendations already make provision for the capitalisation of own-account software created for databases.
10.As such, the equation above describing how estimates of own-account production can be derived should be re-written as follows:
Total number of employees working on database construction/updating not in ISCO 213 *
Average remuneration *
Proportion of time spent on own-account development of databases+
Other intermediate costs used in own-account production of databases (including data costs) +
Notional operating surplus related to own-account production of databases
+
Total number of employees working in ISCO 213 *
Average remuneration *
Proportion of time spent on own-account development of databases (not including software development)+
Other intermediate costs used in own-account production of databases (including data costs) +
Notional operating surplus related to own-account production of databases
11.Some caveats are needed here however regarding the suitability of ISCO estimates for this purpose. Earlier work in the OECD evaluating the applicability of ISCO in the context of estimating own-account software suggested that considerable comparability problems exist across countries. For example in Italy hardly any employees are recorded in ISCO 213 but significant numbers are in 312, whereas in the UK the opposite holds.
Business Statistics
12.Business accounts form another possible route for estimation; however, even here the scope is limited. There are no separate provisions for databases in international accounting standards; and so databases would be treated in line with general principles of IAS 38 (Intangible assets). (See John Verrinder’s note on this topic for the last Canberra II Group meeting)
12.IAS38 specifically mentions “customer lists”, but does not mention “databases” or “content of databases”. Nevertheless it seems to be widely accepted in the business accounting world that valuable databases can and should be identified as separate intangible assets.
13.International accounting authorities did discuss the treatment of database content in business accounting back in February 2002 (in the “International Financial Reporting Interpretations Committee”) but decided not to pursue the subject, and since then no further development work has taken place.
14.Looking at selected company accounts, it appears that the capitalisation of databases varies significantly:
Reed Elsevier (Publisher): Includes databases as intangible assets, valued at “fair value” on acquisition.
Emap plc (Publisher/Audio Visual): Includes acquired databases as intangible assets.
Reuters (Information company): Do not separately capitalise databases.
Dun and Bradstreet (Business information): Capitalise certain “database enhancements” as intangible assets. No further information available from the accounts.
British Telecom: Do not separately capitalise databases.
Dow Jones: Do not separately capitalise databases
15.This of course makes the use of business accounts difficult but it does not invalidate them. In fact it would be fair to say that businesses largely follow proposal (III) above.
Recommendation
16. In concluding, the proposal of this paper is as follows:
All databases, including those produced on own-account, with an expected service life of more than year should be capitalised. Macro based estimates based on the schematic below can be used:
Total number of employees working on database construction/updating not in ISCO 213 *
Average remuneration *
Proportion of time spent on own-account development of databases+
Other intermediate costs used in own-account production of databases (including data costs) +
Notional operating surplus related to own-account production of databases
+
Total number of employees working in ISCO 213 *
Average remuneration *
Proportion of time spent on own-account development of databases (not including software development) +
Other intermediate costs used in own-account production of databases (including data costs) +
Notional operating surplus related to own-account production of databases
In practice these figures may not be economically significant if a significant proportion of own-account database construction is recorded as own-account software in the accounts.
All transfers of databases where full proprietary rights are sold should be recorded in the revaluation accounts.
1