Accountancyregels waardebepaling: Waarde van software wordt overschat

Jelle de Groot heeft onderzoek gedaan naar betere modellen voor de waardering van maatwerksoftware, waarmee CFO’s tot een accuratere inschatting kunnen komen van de reële waarde van software-assets in de organisatie.

De waardebepaling van maatwerksoftware volgt in de grootste economieën van de wereld de voorschriften van IFRS of die van US GAAP. In beide standaarden wordt maatwerksoftware beschouwd als immateriële activa, dus als ontastbare bezittingen. De activatiewaarde wordt bepaald door de gemaakte ontwikkelkosten, gemaximeerd door de verwachte toekomstige baten. Maar de ontwikkelkosten die in een softwareproject gemaakt worden, dragen lang niet altijd bij aan werkelijke waardevermeerdering.

Soms wordt functionaliteit ontwikkeld die bij nader inzien niet gebruikt gaat worden. Of er wordt geëxperimenteerd met nieuwe technologieën of ontwikkelmethoden, waardoor een gedeelte van de kosten als leergeld gezien moet worden. Ook de reis- en verblijfskosten van ingevlogen specialisten of te duur ingekochte arbeidsuren leiden tot projectkosten die niet wezenlijk bijdragen aan de waarde van het ontwikkelde product. Als activatiewaarde wordt gebaseerd op deze kosten, leidt inefficiënt ontwikkelen tot meer bezittingen op de balans!

REKEN JE RIJK
De maximering van de activatiewaarde tot de te verwachten toekomstige baten biedt geen hard plafond. Ter onderbouwing van de verwachting moet er een businesscase worden opgesteld. In een dergelijke projectie is het eenvoudig om zich rijk te rekenen door baten hoger en risico’s lager dan realistisch in te schatten. Optimisme is menselijk. En een positieve businesscase is een voorwaarde om een project doorgang te laten vinden.

Het is niet uitzonderlijk dat uitvoeringsproblemen leiden tot het realiseren van minder functionaliteit of het later in gebruik nemen daarvan. Hierdoor komen baten substantieel lager uit dan geprojecteerd, en balanswaarde verdampt. De speelruimte die de huidige regels bieden maakt het mogelijk dat bij beursgang of verkoop activatie aangegrepen wordt om de waarde van de organisatie en de winstgevendheid gunstiger af te spiegelen. Uitgaven die niet als investering bestempeld kunnen worden, gaan immers direct ten laste van het resultaat. Bijgevolg is het activeren van maatwerksoftware voor velen bij voorbaat verdacht en wordt er door veel organisaties simpelweg geen gebruik van gemaakt om verkeerde schijn te voorkomen.

INTRINSIEKE WAARDE VAN MAATWERKSOFTWARE
Voor het bepalen van de waarde van maatwerksoftware zou niet primair gekeken moeten worden naar de gemaakte ontwikkelkosten, maar naar intrinsieke eigenschappen van het ontwikkelde softwareproduct. Dit is gemakkelijker gezegd dan gedaan. Welke intrinsieke eigenschappen kunnen er gemeten worden aan software? En hoe kunnen deze metingen worden omgezet in een waardebepaling? Om deze vragen te beantwoorden hebben we meerdere meet- en waarderingsmodellen opgesteld en met elkaar vergeleken (zie ook onderstaande figuur).

– Reparatiekosten voor kwaliteitsgebreken
Wie een huis koopt met een lekkend dak zal de reparatiekosten voor dit gebrek aftrekken van de prijs. Hetzelfde principe kan worden toegepast op software. Als software kwaliteitsgebreken vertoont, zoals hoge complexiteit of veelvuldige duplicatie van codefragmenten, kan de waarde ervan verminderd worden met de kosten die gemoeid zouden zijn met het verhelpen van deze gebreken.

De Software Improvement Group (SIG) heeft een standaard kwaliteitsmodel ontwikkeld dat dergelijke kwaliteitsgebreken kwantificeert. In combinatie met het volume van de gebrekkige code en industriegemiddelde productiviteitscijfers kan het kwaliteitscijfer omgezet worden in een inspanningsbegroting en een raming van reparatiekosten. Het eerste alternatieve model voor waardebepaling van maatwerksoftware wordt daarmee: de ontwikkelkosten van de software, verminderd met de reparatiekosten voor kwaliteitsgebreken (Model A). In dit model wordt dus een kwaliteitscorrectie uitgevoerd, maar de basiswaarde wordt nog steeds bepaald door de gemaakte kosten.

– Vervangingswaarde van software
Wie een tweedehands auto koopt zal zich niet richten op de prijs die de vorige eigenaar ervoor heeft betaald, maar op de prijs van vergelijkbare auto’s. Ook dit principe kan, met enige moeite, op software worden toegepast. Er is geen markt waar vergelijkbare maatwerksoftware wordt verhandeld, dus vergelijkingsmateriaal moet elders vandaan komen. Software bestaat uit programmacode geschreven in bepaalde programmeertalen. Er kan dus vergeleken worden met systemen die even groot zijn qua hoeveelheid programmacode en die in dezelfde taal zijn ontwikkeld.

Aan de hand van industriegemiddelde productiviteitscijfers kunnen deze gegevens wederom omgezet worden in een inspanningsbegroting voor het vervangen (opnieuw programmeren) van de software en daarmee in een geschatte vervangingswaarde. Het tweede alternatieve waardebepalingsmodel wordt daarmee: de vervangingswaarde van software, verminderd met de reparatiekosten vanwege kwaliteitsgebreken (Model B). In dit model wordt dus niet meer uitgegaan van de kosten van een wellicht inefficiënt uitgevoerde ontwikkeling.

####

– Toekomstige onderhoudslast
In Model A en B worden reparatiekosten in mindering gebracht op een basiswaarde. Maar men kan ervoor kiezen de kwaliteitsproblemen niet te verhelpen. De consequentie hiervan is dat de kosten voor het onderhouden en verder ontwikkelen van de software hoger zullen zijn dan bij afwezigheid van kwaliteitsproblemen. Ook deze verhoging van de onderhoudslast kan in financiële termen worden uitgedrukt. Hierbij moeten aannamen worden gemaakt ten aanzien van de verwachte levensduur van de software en de hoeveelheid programmacode die per jaar aanpassing zal behoeven. Bij hoge kwaliteit zal de aanpassing van deze hoeveelheid code minder inspanning vragen dan bij lage kwaliteit.

SIG heeft bijvoorbeeld geconstateerd dat het productiviteitsverschil tussen lage kwaliteit (2 sterren op een schaal van 5) en hoge kwaliteit (4 sterren) een factor 2 kan bedragen. Vermenigvuldiging van levensjaren, te onderhouden codevolume en productiviteitsverschil levert een becijfering op van de verhoogde onderhoudslast. Het derde alternatieve waarderingsmodel wordt hiermee: de vervangingswaarde van de software, verminderd met de kosten van de verhoogde onderhoudslast (Model C). In dit model wordt dus niet uitgegaan van de daadwerkelijke reparatie van kwaliteitsgebreken, maar van terugkerende kosten als gevolg van blijvende kwaliteitsgebreken.

TOEPASSING VAN DE MODELLEN
Met bovenstaande modellen voor softwarewaardering hebben we de mogelijkheden onderzocht voor een verbeterde waarderingsmethodiek. Om de toepasbaarheid van de verschillende modellen te evalueren hebben we 8 casestudies uitgevoerd. In deze casestudies zijn de modellen toegepast op softwaresystemen van een aantal organisaties en zijn de resultaten vervolgens voorgelegd aan CFO’s en CIO’s. De jaarlijkse investering in maatwerksoftware van deze organisaties ligt tussen de 1 en 68 miljoen euro.

Uit de casestudies kwam naar voren dat de overwegingen die in elk van de modellen zijn verwerkt, als valide worden beschouwd, maar ook dat elke respondent een voorkeursmodel kiest, afhankelijk van zijn of haar situatie. In het algemeen werd voor waardecorrectie de voorkeur gegeven aan reparatiekosten (Model A en Model B) boven verhoogde onderhoudslast (Model C). De vervangingswaarde (Model B en C) werd gezien als een objectievere basiswaarde dan de gemaakte kosten (Model A).

IMPACT VAN DE MODELLEN
We hebben ook een puur numerieke analyse uitgevoerd op een set van 170 softwaresystemen, waarbij voor elk systeem vervangingswaarde, reparatiekosten en verhoogde onderhoudslast zijn uitgerekend. Hieruit bleek dat meer dan 85 procent van de software onder de huidige waarderingsregels overgewaardeerd zou worden. Voor systemen van lage kwaliteit (2 sterren of minder volgens het SIG-model), kan de waardevermindering oplopen tot 60 (Model A) of 80 procent (Model C).

WAT NU?
Op korte termijn zullen de inzichten uit ons onderzoek niet leiden tot nieuwe accountancyregels voor het activeren van software. Hiervoor is meer ervaring met de voorgestelde modellen nodig en een lange adem voor het doorlopen van de benodigde standaardisatieprocedures.

Maar CFO’s kunnen er al wel hun voordeel mee doen. Meerdere deelnemers aan onze casestudies zien de modellen als een belangrijk instrument voor de waardebepaling tijdens due diligence. De aankopende partij kan snel en op basis van betrekkelijk beperkte informatie een goede inschatting maken van de waarde van de software-assets. Bij het samengaan van organisaties zijn de intrinsieke eigenschappen van de software een belangrijke factor voor een snelle en succesvolle integratie.

Softwarewaardering op basis van vervangingswaarde en reparatiekosten maakt een objectieve weging mogelijk tussen verschillende integratiescenario’s. Bij het rationaliseren van een landschap van softwaresystemen kan waardering van software leidend zijn bij het stellen van prioriteiten en het nemen van investeringsbeslissingen. In plaats van te kijken naar de gemaakte ontwikkelkosten kunnen systemen verkozen worden op basis van de benodigde reparatiekosten en de toekomstige onderhoudslast.

De voorgestelde waarderingsmodellen lenen zich uitstekend voor het vergelijken van softwareportfolio’s van verschillende organisaties. Dit geeft CFO’s de mogelijkheid om hun organisatie te laten benchmarken op intrinsieke waarde in plaats van op historische kosten. CFO’s kunnen waardebepaling op basis van reparatiekosten, onderhoudslast en vervangingswaarde dus nu al gebruiken om investeringsbeslissingen te ondersteunen en om financiële rapportages over softwareportfolio’s accurater te maken.

JELLE DE GROOT is master student aan de Universiteit Leiden en heeft bij de Software Improvement Group onderzoek gedaan naar waardering van software. Zijn onderzoek wordt beschreven in Incorporating Software Quality in the Capitalization of Software as an Asset, M.Sc. Thesis, August 2011, Leiden. JOOST VISSER is hoofd research bij de Software Improvement Group, waar hij het onderzoek leidt naar methoden voor het bepalen van softwarekwaliteit en de impact daarvan op bedrijfsvoering.