Waardering software moet anders

donderdag 24 november 2011 | 4 reacties

De huidige verslaggevingsregels geven geen reëel inzicht in de waarde van software. Dit maakt de in jaarverslagen gerapporteerde waarden onbetrouwbaar en lastig vergelijkbaar.

Software wordt momenteel geactiveerd als immateriële vaste activa, door vast te stellen wat de verwachte toekomstige financiële baten zijn. Tot aan dat punt mogen gemaakte ontwikkelkosten worden geactiveerd. Wie een miljoen uitgeeft aan het ontwikkelen van een softwaresysteem waarmee hij de komende jaren twee miljoen denkt te kunnen verdienen, mag dit systeem op een miljoen waarderen.

Maar bij veel van softwareontwikkelingstrajecten is sprake van inefficiëntie en verloren kosten. Wellicht had de investering drie ton lager kunnen liggen als vooraf de juiste functionele eisen waren opgesteld, of als er minder dure externe consultants waren ingehuurd. Zou een waardering van zeven ton dan niet reëler zijn?

Uit onderzoek blijkt dat deze speelruimte kan worden misbruikt. Bij een beursgang of verkoop kan een organisatie bijvoorbeeld bezittingen op de balans fraaier doen lijken en de organisatie winstgevender.

Desalniettemin is het toelaten van softwareactivering de eerste goede stap in de accountancyregelgeving. Software is voor organisaties immers van waarde. De wijze van waarderen is vooralsnog echter onbetrouwbaar en ontoereikend. De regelgeving schiet te kort door de huidige staat van de software niet bij de waardering te betrekken.

Dit probleem kan worden opgelost door de ‘intrinsieke waarde' van software als factor voor waardering te gebruiken. Dit blijkt uit onderzoek van de Software Improvement Group en Universiteit Leiden. Uit interviews met executives komt naar voren dat een objectievere kwaliteitsmeting van software welkom is.

Allereerst wordt de basiswaarde vastgesteld op basis van daadwerkelijk gemaakte kosten of een benchmark. Daarna kan deze basiswaarde worden aangepast door het meten van de intrinsieke software-eigenschappen. Dit gebeurt door kwantificering van software-kwaliteitsgebreken en bijbehorend risico.

Als volgens de benchmark een softwaresysteem een basiswaarde heeft van een miljoen en de kosten voor het verhelpen van kwaliteitsproblemen worden bepaald op twee ton, dan is de software dus acht ton.

Deze objectievere waardebepaling geeft een beter inzicht in de reële softwarewaarde, gebaseerd op kosten en kwaliteit. Bij due diligence kan de acquirerende partij dan een objectievere inschatting maken van de softwarewaarde. Bij het fuseren van organisaties zijn de intrinsieke eigenschappen van de software een belangrijke factor voor snelle en succesvolle integratie. En last but not least wordt het mogelijk om jaarrekeningen van organisaties objectiever te vergelijken.

Jelle de Groot

Reacties

Geplaatst door Arnout van Kempen - 25-11-2011 15:48:39

Embeded software, operating systems e.d. zou je inderdaad logischerwijs rekenen tot het device dat ze besturen. Maar dat is bepaald iets anders dan software tot de materiële activa rekenen, vanwege de drager. Bij embeded software doe je dat dan ook niet, daar reken je de software tot het device, omdat het er een integraal onderdeel van uit maakt.

En zelfs dan: ja, de software van mijn auto reken ik tot mijn auto. Maar was ik de ontwikkelaar van die software, de leverancier van de autofabrikant dus, dan is die software voor mij een immaterieel actief.

De opinie van Jelle de Groot heeft, zo lees ik in zijn tekst, betrekking op zelf ontwikkelde software. Tot pakweg de jaren tachtig was het vrij normaal dat je je eigen operating system ontwikkelde, maar die tijd ligt van pc tot mainframe toch wel achter ons. Maar zelfs als je aangeschafte software gaat meerekenen, dan nog lijkt mij dat het het inzicht niet bepaald dient als je software als materieel actief gaat aanduiden, enkel omdat het op een fysieke drager vast ligt. En dat was wel de genoemde 'escape'.

Geplaatst door Bertusje - 25-11-2011 15:17:55

Arnout, het karakter van software is soms een glijdende schaal. Een bekend voorbeeld is het onderscheid tussen operating / systeemsoftware en applicatiesoftware. De gedachte is dan dat operating / systeem software noodzakelijk is op het fysieke apparaat te laten werken. Dan wordt het opgenomen in de boekwaarde van het materiele vaste actief (de computer). Voor applicatiesoftware gaat die redenering minder goed op vind ik, maar wordt wel verdedigd.
Trek het bijvoorbeeld door naar je auto: zou je in de balans de embedded software van het motormanagementsysteem afzonderlijk als immaterieel actief opnemen? Daarvan zou je nog kunnen zeggen dat het operating software is. Maar dat geldt niet voor bijv. de software in je Tomtom. Je auto rijdt ook wel zonder.

Geplaatst door Arnout van Kempen - 25-11-2011 11:03:17

Zonder de minste pretenties te koesteren op het gebied van verslaggeving, maar het idee dat je software als materieel actief kan zien omdat het vastligt op een fysiek medium vind ik echt geweldig. Maar dan ook waarderen tegen de waarde van dat medium, dus dat praten we tegenwoordig over pakweg een paar euro voor een USB-stickje?

En als we, zoals Apple nu al doet, software volledig via "the cloud" gaan distribueren, dan verandert dezelfde software ineens in een immaterieel actief?

Rechten die op een papieren contract zijn vastgelegd, zijn dat dan ook materiële activa?

Geplaatst door Bertusje - 25-11-2011 9:42:33

Hier lijken verschillende waardebegrippen door elkaar te lopen. "Reele waarde gebaseerd op kosten" is tegenstrijdig. De reele waarde lijkt mij hier beter te bepalen als de verwachte opbrengsten (zoals hier in het voorbeeeld 2 miljoen) contant gemaakt met een disconteringsfactor waarin de onzekerheid van deze opbrengsten is verwerkt. Wat een actief ooit daadwerkelijk gekost heeft, is in principe niet relevant voor de reele waarde.

Of het waarderen van activa tegen reele waarde beter is dan tegen kostprijs (met afschrijving) is een bekende discussie. Het waarderen van immateriele activa tegen reele (of actuele) waarde is wettelijk nauwelijks toegestaan; voor software is het feitelijk wettelijk niet mogelijk. Maar daar is misschien aan te ontkomen door te stellen dat software een materieel actief is omdat het vastligt of een fysiek medium. Hierover bestaan in de praktijk verschillende visies. Materiele activa mogen wel tegen actuele waarde worden gewaardeerd.
Maar sowieso is bij het waarderen van een heel bedrijf de balans niet voldoende om de totale waarde te bepalen.

Als het punt meer is om inefficiencies uit de kostprijs te halen, is mij niet duidelijk wat de toegevoegde waarde van deze methode is. Het lijkt mij inherent onmogelijk om in een ontwikkelingstraject inefficiency te definieren. Immers, inefficiency is een onderprestatie ten opzichte van een norm. Deze norm is voor innovatieve projecten inherent heel erg zacht. Kennis achteraf ("achteraf hadden we dat onderdeel anders moeten aanpakken") lijkt mij geen eerlijke beoordeling bij een ontwikelingstraject.

Het lijkt mij ook erg bewerkelijk om deze methode jaarlijks te gebruiken, immers ieder jaar heb je weer een nieuw boekwaarde nodig.