ECLI:NL:CBB:2017:246

uitspraak COLLEGE VAN BEROEP VOOR HET BEDRIJFSLEVEN zaaknummers: 15/279 tot en met 15/286 27000 uitspraak van de meervoudige kamer van 16 juni 2017 in de zaken tussen Getronics Pinkroccade Overheidspersoneel B.V., te Den Haag, XS4ALL Internet B.V., te Amsterdam, KPN B.V., te Den Haag, KPN Corporate Market B.V., te Zoetermeer, Infrastructure Services & Projects B.V., te Houten, Ibasis EuropE Limited, te Den Haag en Call-2 B.V., te Zoetermeer, appellanten (gemachtigde: mr. V.H. Afourtit), en de minister van Economische Zaken, verweerder (gemachtigden: mr. C. Cromheecke en ir. drs. G.J. Bolks).

Bij besluiten van 20 december 2013 (de primaire besluiten) heeft verweerder de aanvragen van appellanten in het kader van de Wet vermindering afdracht loonbelasting en premie voor de volksverzekeringen 1995 (Wva) voor de periodes januari tot en met juni 2013 en juli tot en met december 2013 deels afgewezen. Bij besluiten van 27 februari 2015 (de bestreden besluiten) heeft verweerder de bezwaren van appellanten ongegrond verklaard. Appellanten hebben tegen de bestreden besluiten beroepen ingesteld. Verweerder heeft een verweerschrift ingediend. Het onderzoek ter zitting heeft plaatsgevonden op 17 oktober 2016. Appellanten hebben zich laten vertegenwoordigen door hun gemachtigde, bijgestaan door [naam 1] , [naam 2] en [naam 3] . Verweerder heeft zich laten vertegenwoordigen door zijn gemachtigden, bijgestaan door [naam 4] .

1.1 Appellanten hebben voor de eerste en tweede helft van 2013 verklaringen voor het verrichten van speur en ontwikkelingswerk in de zin van de Wva (S&O-verklaringen) aangevraagd voor een aantal projecten met betrekking tot de ontwikkeling van programmatuur. 1.2 Partijen hebben afgesproken dat project 015 (Fulfillment) model staat voor de overige projecten. Project 015 ziet op de ontwikkeling van programmatuur om bestellingen, voorraadbeheer en levering van klantorders volledig te integreren. Het is de bedoeling de meer dan 70 traditionele leverstraten te migreren naar één generieke leverstraat (Leverstraat 3.0). Daarvoor worden de bestaande processtraten geüniformeerd en zo veel mogelijk geautomatiseerd en de generieke productiestraat opgeschaald en geschikt gemaakt voor de migratie van de traditionele leverstraten. Appellanten ontwikkelen één nieuwe architectuur en faseren systemen met een overlappende functie uit. Leverstraat 3.0 moet real time kunnen opereren en ook aansluitingen kunnen realiseren bij netwerkcomponenten van derden. Ook leveringsprocessen van partijen buiten appellanten en porteringsprocessen moeten in deze architectuur geïntegreerd kunnen worden. Een deel van de werkzaamheden hebben appellanten uitbesteed aan een derde partij in India (de programmeur). Voor deze uitbestede werkzaamheden gebruiken appellanten de term ‘code kloppen’. Deze werkzaamheden hebben zij buiten de aanvragen gelaten. 1.3 Bij de primaire besluiten heeft verweerder de aanvragen deels toegewezen, maar afgewezen voor de projecten 015, 022 (XS4ALL04), 030, 041, 054, KCC-01, 043, 049, 052, 053 en IBA-01, omdat het geen speur- en ontwikkelingswerk betreft. Een deel van de projecten is afwezen, omdat appellanten daarbij hebben aangegeven dat er geen sprake is van programmatuurontwikkeling. Een ander deel van de projecten is afgewezen, omdat het niet gaat om een fysiek product, maar om het aanbieden van een dienst. 1.4 Appellanten hebben bezwaar gemaakt voor zover de aanvragen zijn afgewezen. In bezwaar hebben appellanten een rapport van TNO van 23 april 2014 overgelegd (TNO-rapport 2014), waarin conclusies zijn getrokken over technische nieuwheid voor appellanten en programmatuurontwikkeling door appellanten zelf. 1.5 Naar aanleiding van de uitspraak van het College van 10 juli 2014, ECLI:NL:CBB:2014:264 (NS-uitspraak) heeft verweerder aanleiding gezien de aanvragen opnieuw te beoordelen. Op basis van de door appellanten verstrekte, nadere, informatie en rekening houdend met de NS-uitspraak, heeft verweerder in de bestreden besluiten geconcludeerd dat bij de afgewezen projecten geen sprake is van door appellanten verricht speur- en ontwikkelingswerk. De activiteiten die door appellanten worden uitgevoerd zijn volgens verweerder aan te merken als het implementeren en aanpassen van aangekochte (bestaande) technologie en het specificeren van op te leveren systemen door derden. De rol van appellanten bestaat uit het (gedetailleerd) opstellen van specificaties en het testen van de opgeleverde software. Zij hebben niet aangetoond dat zij zelf technische knelpunten oplossen in de ontwikkeling van technisch nieuwe (onderdelen) van programmatuur in de fase voorafgaand aan het feitelijk programmeren. Verweerder heeft daarom de afwijzing van de aanvragen gehandhaafd. 1.6 Appellanten hebben hiertegen beroepen ingesteld. KPN Contact B.V., een van de aanvankelijke appellanten, is na het instellen van beroep door fusie opgegaan in KPN B.V. 1.7 In de loop van de beroepsprocedure heeft verweerder in reactie op het TNO-rapport 2014 een rapport ingebracht van [naam 4] van 19 mei 2016: “ICT-Technische Analyse van de behandeling van WBSO-aanvragen KPN” (rapport [naam 4] ), waarin is geconcludeerd dat appellanten zich primair richten op het specificeren van systemen en deze vervolgens extern laten programmeren. 1.8 In reactie daarop hebben appellanten een tweede rapport van TNO van 8 juli 2016 (TNO-rapport 2016) in de procedure gebracht. Daarin wordt vastgesteld door TNO dat na de bestudering van het rapport van [naam 4] de conclusies uit het TNO-rapport 2014 onverkort geldig blijven. Gronden 2.1 Appellanten voeren aan dat zij zich met het maken van een technisch ontwerp en het testen van programmatuur richten op de ontwikkeling van voor hen technisch nieuwe programmatuur en daarmee voldoen aan de volgens hen enige eis die de wet stelt aan programmatuurontwikkeling. Volgens appellanten is niet vereist dat technische knelpunten worden opgelost en dat het werkingsprincipe van de oplossing wordt onderzocht en aangetoond, omdat ook als een technisch knelpunt niet wordt opgelost de werkzaamheden gericht kunnen zijn op het voortbrengen van technische nieuwheid en er dus sprake kan zijn van speur- en ontwikkelingswerk. Volgens appellanten komt het standpunt van verweerder erop neer dat zij slechts programmatuur in de zin van de Wva zouden ontwikkelen als hun medewerkers zelf de ‘code kloppen’ in plaats van deze werkzaamheden uit te besteden aan een derde. Uit de NS-uitspraak volgt, aldus appellanten, dat dit standpunt niet juist is. Appellanten menen dat hun situatie vergelijkbaar is met die in de NS-uitspraak en de uitspraak van het College van 15 juli 2014, ECLI:NL:CBB:2014:337 (Prepare-uitspraak), gelet op de rol en inbreng van hun medewerkers in relatie tot de derde, de complexiteit van de projecten en het feit dat de technische knelpunten uitsluitend kunnen worden opgelost door personen die het geheel van de KPN-systemen en -applicatielandschappen en de daarin werkende programmatuur kennen en overzien. Alleen medewerkers van appellanten hebben de kennis en deskundigheid die vereist is voor de ontwikkeling van de programmatuur. 2.2 Voor de kwalificatie als programmatuurontwikkeling is het niet nodig dat appellanten het werkingsprincipe aantonen, laat staan dat zij dat voorafgaande aan de uitbesteding van de werkzaamheden zouden moeten doen. Het aantonen van het werkingsprincipe is volgens appellanten niet vereist bij programmatuurontwikkeling die het integreren en laten samenwerken van bestaande, zelf ontwikkelde programmatuur behelst, zoals bij project 015, omdat daarbij sprake is van, volgens appellanten, programmatuurontwikkeling in ruime zin. Appellanten stellen dat de wet onderscheid maakt tussen programmatuurontwikkeling in enge zin – door appellanten verstaan als de in artikel 1, eerste lid, aanhef en sub n, van de Wva bedoelde door een S&O-inhoudingsplichtige systematisch georganiseerde werkzaamheden direct en uitsluitend gericht op de ontwikkeling van voor de S&O-inhoudingsplichtige technische nieuwe (onderdelen van) programmatuur – en programmatuurontwikkeling in ruime zin, waaronder appellanten ook begrijpen het integreren of laten samenwerken van bestaande, zelf ontwikkelde programmatuur voor de eigen onderneming. Voor het laatste gelden volgens appellanten minder stringente eisen. Technologisch nieuwe principes zijn volgens appellanten niet vereist en het aantonen van het werkingsprincipe is niet aan de orde, omdat uit de toelichting bij de beleidswijziging in 2009 volgt dat het voldoende is dat de technische knelpunten en oplossingsrichtingen liggen op het niveau van het integreren of met elkaar laten samenwerken van bestaande programmatuurcomponenten. Appellanten stellen dat, als het werkingsprincipe wel aangetoond zou moeten worden, uit de Wva en de rechtspraak niet kan worden afgeleid dat dat voorafgaand aan het ‘code kloppen’ zou moeten. Daarnaast stellen appellanten dat zij werkingsprincipes wel degelijk vooraf aantonen, doordat zij virtuele ketentests uitvoeren en op basis van de uitkomsten daarvan de instructies bijstellen die aan de programmeur worden verstuurd. Als tijdens de virtuele ketentest een fout blijkt, dan wordt de technische-ontwerpfase voor het betrokken onderdeel overgedaan.

5.1 In de NS-zaak is het volgende overwogen: “6.1 Blijkens de bestreden besluiten heeft verweerder bij de beoordeling van de onderhavige projecten de maatstaf aangelegd dat er sprake is van technisch nieuwe programmatuur als er technische knelpunten moeten worden opgelost bij het omzetten van het ontwerp van een systeem naar de feitelijke programmatuur. Verweerder heeft daaraan de conclusie verbonden dat deze knelpunten dus worden opgelost bij het programmeren. Als binnen een onderneming gewerkt wordt aan functioneel en technisch ontwerp c.q. architectuur van een systeem, maar de omzetting van het ontwerp naar programmatuur wordt uitbesteed, is volgens verweerder geen sprake van het ontwikkelen van technisch nieuwe (onderdelen) van programmatuur en geeft verweerder geen S&O verklaring af. Het College is van oordeel dat deze maatstaf van verweerder, geplaatst tegen de achtergrond van de hier toepasselijke bepalingen, waaronder artikel 1, eerste lid, onder n, sub 2º en onder o, van de Wva, te beperkt is. Uit de stukken, waaronder het door appellanten in het geding gebrachte deskundigenbericht van [naam 5] en de uiteenzettingen van de deskundige ter zitting, is voor het College voldoende vast komen te staan dat ook in de fase voorafgaand aan het daadwerkelijke programmeren ofwel coderen sprake kan zijn van het oplossen van technische knelpunten met betrekking tot de ontwikkeling van technische nieuwe (onderdelen van) programmatuur en dat een programmeur op basis van een gedetailleerd ontwerp een stuk software kan bouwen, zonder zelf technische knelpunten te hoeven oplossen. Naar het oordeel van het College staat de definitie van ‘programmatuur’ in artikel 1, eerste lid, onder o, van de Wva als een niet-fysiek, logisch deelsysteem van een informatiesysteem dat de structuur van de gegevens en van de verwerkingsprocessen bepaalt, niet in de weg aan een ruimere uitleg dan door verweerder bepleit. Het College kan uit het woord ‘bepaalt’ in voornoemd artikel de door verweerder ter zitting bepleite beperking van het toepassingsbereik van het begrip ‘programmatuur’ niet afleiden. Dat het ontwikkelen van programmatuur noodzakelijk inhoudt dat ook daadwerkelijk wordt geprogrammeerd c.q. gecodeerd, betekent niet per definitie dat van programmatuurontwikkeling geen sprake kan zijn als technische knelpunten niet tijdens het feitelijk programmeren ofwel coderen worden opgelost, maar daaraan voorafgaand in het ontwikkelen van het (technisch) ontwerp. Het College acht bij het voorgaande van belang dat er, zoals aan de hand van de uiteenzetting van de deskundige voldoende aannemelijk is geworden, bij de softwareprogrammering in de loop van de tijd een ontwikkeling heeft plaatsgevonden van ‘ouderwets programmeren’ naar de ‘hedendaagse softwareontwikkeling’. Door de deskundige is uiteengezet dat bij de systeemontwikkeling door appellanten het zogenoemde V-model is toegepast waarbij het maken van het ontwerp en het gebruik ervan in de test- en acceptatiefase (de V-werking) het meest wezenlijke en meest technisch vernieuwende deel van het programmeren vormen. De deskundige heeft verklaard dat het schrijven van de programmeercode zelf (het programmeren door de programmeur) daarbij aanzienlijk minder van belang is, mede gegeven het feit dat het bouwen zelf steeds minder creatieve arbeid vereist nu daarvoor heden standaard ‘blokkendozen’ of ‘componenten’ voor de programmeur beschikbaar zijn. Het is dan ook dit deel dat is uitbesteed aan derden. Naar de mening van de deskundige was bij de aanlevering van de onderhavige producten van appellanten aan de programmeurs een zodanig gedetailleerde beschrijving gevoegd dat bij het programmeren door deze derden geen wezenlijk technische knelpunten behoefden te worden opgelost. De deskundige heeft toegelicht dat als zich in die fase onverhoopt toch wezenlijke technische knelpunten voordoen, die knelpunten dan “terug in het proces” moeten om in een van de stappen voorafgaande aan het bouwen van de programmatuur te worden opgelost. Het College heeft bij het vormen van zijn oordeel er niet aan voorbijgezien dat, zoals verweerder ter zitting in zijn pleitnota heeft verwoord, de ontwikkeling van programmatuur met behulp van technisch nieuwe hulpmiddelen niet per definitie hoeft te leiden tot speur- en ontwikkelingswerk in de zin van de wet en dat technisch nieuw betekent dat er sprake is van een onderzoekscomponent in het project en/of de aanwezigheid van technische onzekerheid omtrent het bereiken van het resultaat. Het College heeft tevens voor ogen gehouden dat, zoals verweerder heeft betoogd, er geen sprake is van speur- en ontwikkelingswerk indien geen onderzoeks- of ontwikkelcomponent in de programmatuurontwikkeling aanwezig is. Het College volgt verweerder evenwel niet, waar hij betoogt, dat dit laatste betekent dat er sprake moet zijn van “daadwerkelijk programmeren” binnen de entiteit van de aanvrager (S&O-inhoudingsplichtige) zelf, wil sprake kunnen zijn van speur- en ontwikkelingswerk. Naar uit het vorenoverwogene volgt, is het College van oordeel dat noch uit de toepasselijke wetsbepalingen noch uit de aard van de zaak (ontwikkeling van programmatuur) volgt dat het zoeken naar en bewijzen van een “nieuw informatietechnologisch principe” of het oplossen van “programmeertechnische knelpunten” in de programmatuur dient plaatsvinden bij het feitelijke programmeren ofwel coderen.” 5.2 Gelet op de NS-uitspraak heeft verweerder de juiste uitgangspunten gehanteerd bij de beoordeling of er sprake is van programmatuur als bedoeld in de Wva. Voor speur- en ontwikkelingswerk dient een onderzoeks- of ontwikkelcomponent in de programmatuurontwikkeling aanwezig te zijn en er dient sprake te zijn van “zoeken en bewijzen” en een “nieuw informatietechnologische principe” of het oplossen van “programmeertechnische knelpunten”. Ook als het gaat om ontwikkeling van programmatuur voor het integreren van bestaande programmatuur, zoals in project 015 het geval is, is er eerst sprake van speur- en ontwikkelingswerk als er technische knelpunten zijn die moeten worden opgelost. Verweerder heeft bij de beoordeling van de aanvragen van appellanten dan ook terecht getoetst of de werkzaamheden van appellanten de ontwikkeling van technisch nieuwe (onderdelen van) programmatuur inhouden, waarbij zij zelf technische problemen moeten oplossen en het technisch nieuwe werkingsprincipe aantonen. 5.3 Het door appellanten ingenomen standpunt dat in het geval van integreren van programmatuur technologisch nieuwe principes niet vereist zijn en het werkingsprincipe niet aangetoond behoeft te worden volgt het College niet. Ongeacht de in 2009 in de regelgeving doorgevoerde verruiming van het begrip programmatuur (zie 4.5 hiervoor), is op grond van artikel 1, aanhef en onder n, sub 2°, van de Wva voor speur- en ontwikkelingswerk immers nog steeds technische nieuwheid vereist. Het betoog van appellanten ertoe strekkende dat er een onderscheid bestaat tussen programmatuur in ruime zin en programmatuur in enge zin laat het voorstaande onverlet. Het College is dan ook van oordeel dat, anders dan appellanten stellen, verweerder met de door hem in de bestreden besluiten weergegeven beoordelingsuitgangspunten niet buiten het wettelijke kader is getreden. 5.4 Het College volgt appellanten ook niet in hun standpunt dat verweerder vereist dat het werkingsprincipe voorafgaand aan het uitbesteden van het werk aan derden moet zijn aangetoond. Verweerder heeft immers de ketentests, die appellanten hebben uitgevoerd na terugontvangst van de aan de derde uitbestede werkzaamheden en die weer uitgangspunt kunnen zijn voor aanpassing van het technisch ontwerp, betrokken bij de beoordeling van de aanvragen. 5.5 Voorts wijst niets er op dat verweerder ervan uit is gegaan dat reeds vanwege het gebruik van op de markt verkrijgbare software geen sprake is van programmatuurontwikkeling, zodat wat appellanten hierover aanvoeren feitelijke grondslag mist en buiten bespreking kan blijven.

Het College verklaart de beroepen ongegrond. Deze uitspraak is gedaan door mr. mr. R.R. Winter, mr. R. C. Stam en mr. H.A.B. van Dorst-Tatomir, in aanwezigheid van mr. M.B. van Zantvoort, griffier. De beslissing is in het openbaar uitgesproken op 16 juni 2017. w.g. R.R. Winter De griffier is buiten staat de uitspraak te ondertekenen

uitspraak COLLEGE VAN BEROEP VOOR HET BEDRIJFSLEVEN zaaknummers: 15/279 tot en met 15/286 27000 uitspraak van de meervoudige kamer van 16 juni 2017 in de zaken tussen Getronics Pinkroccade Overheidspersoneel B.V., te Den Haag, XS4ALL Internet B.V., te Amsterdam, KPN B.V., te Den Haag, KPN Corporate Market B.V., te Zoetermeer, Infrastructure Services & Projects B.V., te Houten, Ibasis EuropE Limited, te Den Haag en Call-2 B.V., te Zoetermeer, appellanten (gemachtigde: mr. V.H. Afourtit), en de minister van Economische Zaken, verweerder (gemachtigden: mr. C. Cromheecke en ir. drs. G.J. Bolks).

Bij besluiten van 20 december 2013 (de primaire besluiten) heeft verweerder de aanvragen van appellanten in het kader van de Wet vermindering afdracht loonbelasting en premie voor de volksverzekeringen 1995 (Wva) voor de periodes januari tot en met juni 2013 en juli tot en met december 2013 deels afgewezen. Bij besluiten van 27 februari 2015 (de bestreden besluiten) heeft verweerder de bezwaren van appellanten ongegrond verklaard. Appellanten hebben tegen de bestreden besluiten beroepen ingesteld. Verweerder heeft een verweerschrift ingediend. Het onderzoek ter zitting heeft plaatsgevonden op 17 oktober 2016. Appellanten hebben zich laten vertegenwoordigen door hun gemachtigde, bijgestaan door [naam 1] , [naam 2] en [naam 3] . Verweerder heeft zich laten vertegenwoordigen door zijn gemachtigden, bijgestaan door [naam 4] .

1.1 Appellanten hebben voor de eerste en tweede helft van 2013 verklaringen voor het verrichten van speur en ontwikkelingswerk in de zin van de Wva (S&O-verklaringen) aangevraagd voor een aantal projecten met betrekking tot de ontwikkeling van programmatuur. 1.2 Partijen hebben afgesproken dat project 015 (Fulfillment) model staat voor de overige projecten. Project 015 ziet op de ontwikkeling van programmatuur om bestellingen, voorraadbeheer en levering van klantorders volledig te integreren. Het is de bedoeling de meer dan 70 traditionele leverstraten te migreren naar één generieke leverstraat (Leverstraat 3.0). Daarvoor worden de bestaande processtraten geüniformeerd en zo veel mogelijk geautomatiseerd en de generieke productiestraat opgeschaald en geschikt gemaakt voor de migratie van de traditionele leverstraten. Appellanten ontwikkelen één nieuwe architectuur en faseren systemen met een overlappende functie uit. Leverstraat 3.0 moet real time kunnen opereren en ook aansluitingen kunnen realiseren bij netwerkcomponenten van derden. Ook leveringsprocessen van partijen buiten appellanten en porteringsprocessen moeten in deze architectuur geïntegreerd kunnen worden. Een deel van de werkzaamheden hebben appellanten uitbesteed aan een derde partij in India (de programmeur). Voor deze uitbestede werkzaamheden gebruiken appellanten de term ‘code kloppen’. Deze werkzaamheden hebben zij buiten de aanvragen gelaten. 1.3 Bij de primaire besluiten heeft verweerder de aanvragen deels toegewezen, maar afgewezen voor de projecten 015, 022 (XS4ALL04), 030, 041, 054, KCC-01, 043, 049, 052, 053 en IBA-01, omdat het geen speur- en ontwikkelingswerk betreft. Een deel van de projecten is afwezen, omdat appellanten daarbij hebben aangegeven dat er geen sprake is van programmatuurontwikkeling. Een ander deel van de projecten is afgewezen, omdat het niet gaat om een fysiek product, maar om het aanbieden van een dienst. 1.4 Appellanten hebben bezwaar gemaakt voor zover de aanvragen zijn afgewezen. In bezwaar hebben appellanten een rapport van TNO van 23 april 2014 overgelegd (TNO-rapport 2014), waarin conclusies zijn getrokken over technische nieuwheid voor appellanten en programmatuurontwikkeling door appellanten zelf. 1.5 Naar aanleiding van de uitspraak van het College van 10 juli 2014, ECLI:NL:CBB:2014:264 (NS-uitspraak) heeft verweerder aanleiding gezien de aanvragen opnieuw te beoordelen. Op basis van de door appellanten verstrekte, nadere, informatie en rekening houdend met de NS-uitspraak, heeft verweerder in de bestreden besluiten geconcludeerd dat bij de afgewezen projecten geen sprake is van door appellanten verricht speur- en ontwikkelingswerk. De activiteiten die door appellanten worden uitgevoerd zijn volgens verweerder aan te merken als het implementeren en aanpassen van aangekochte (bestaande) technologie en het specificeren van op te leveren systemen door derden. De rol van appellanten bestaat uit het (gedetailleerd) opstellen van specificaties en het testen van de opgeleverde software. Zij hebben niet aangetoond dat zij zelf technische knelpunten oplossen in de ontwikkeling van technisch nieuwe (onderdelen) van programmatuur in de fase voorafgaand aan het feitelijk programmeren. Verweerder heeft daarom de afwijzing van de aanvragen gehandhaafd. 1.6 Appellanten hebben hiertegen beroepen ingesteld. KPN Contact B.V., een van de aanvankelijke appellanten, is na het instellen van beroep door fusie opgegaan in KPN B.V. 1.7 In de loop van de beroepsprocedure heeft verweerder in reactie op het TNO-rapport 2014 een rapport ingebracht van [naam 4] van 19 mei 2016: “ICT-Technische Analyse van de behandeling van WBSO-aanvragen KPN” (rapport [naam 4] ), waarin is geconcludeerd dat appellanten zich primair richten op het specificeren van systemen en deze vervolgens extern laten programmeren. 1.8 In reactie daarop hebben appellanten een tweede rapport van TNO van 8 juli 2016 (TNO-rapport 2016) in de procedure gebracht. Daarin wordt vastgesteld door TNO dat na de bestudering van het rapport van [naam 4] de conclusies uit het TNO-rapport 2014 onverkort geldig blijven. Gronden 2.1 Appellanten voeren aan dat zij zich met het maken van een technisch ontwerp en het testen van programmatuur richten op de ontwikkeling van voor hen technisch nieuwe programmatuur en daarmee voldoen aan de volgens hen enige eis die de wet stelt aan programmatuurontwikkeling. Volgens appellanten is niet vereist dat technische knelpunten worden opgelost en dat het werkingsprincipe van de oplossing wordt onderzocht en aangetoond, omdat ook als een technisch knelpunt niet wordt opgelost de werkzaamheden gericht kunnen zijn op het voortbrengen van technische nieuwheid en er dus sprake kan zijn van speur- en ontwikkelingswerk. Volgens appellanten komt het standpunt van verweerder erop neer dat zij slechts programmatuur in de zin van de Wva zouden ontwikkelen als hun medewerkers zelf de ‘code kloppen’ in plaats van deze werkzaamheden uit te besteden aan een derde. Uit de NS-uitspraak volgt, aldus appellanten, dat dit standpunt niet juist is. Appellanten menen dat hun situatie vergelijkbaar is met die in de NS-uitspraak en de uitspraak van het College van 15 juli 2014, ECLI:NL:CBB:2014:337 (Prepare-uitspraak), gelet op de rol en inbreng van hun medewerkers in relatie tot de derde, de complexiteit van de projecten en het feit dat de technische knelpunten uitsluitend kunnen worden opgelost door personen die het geheel van de KPN-systemen en -applicatielandschappen en de daarin werkende programmatuur kennen en overzien. Alleen medewerkers van appellanten hebben de kennis en deskundigheid die vereist is voor de ontwikkeling van de programmatuur. 2.2 Voor de kwalificatie als programmatuurontwikkeling is het niet nodig dat appellanten het werkingsprincipe aantonen, laat staan dat zij dat voorafgaande aan de uitbesteding van de werkzaamheden zouden moeten doen. Het aantonen van het werkingsprincipe is volgens appellanten niet vereist bij programmatuurontwikkeling die het integreren en laten samenwerken van bestaande, zelf ontwikkelde programmatuur behelst, zoals bij project 015, omdat daarbij sprake is van, volgens appellanten, programmatuurontwikkeling in ruime zin. Appellanten stellen dat de wet onderscheid maakt tussen programmatuurontwikkeling in enge zin – door appellanten verstaan als de in artikel 1, eerste lid, aanhef en sub n, van de Wva bedoelde door een S&O-inhoudingsplichtige systematisch georganiseerde werkzaamheden direct en uitsluitend gericht op de ontwikkeling van voor de S&O-inhoudingsplichtige technische nieuwe (onderdelen van) programmatuur – en programmatuurontwikkeling in ruime zin, waaronder appellanten ook begrijpen het integreren of laten samenwerken van bestaande, zelf ontwikkelde programmatuur voor de eigen onderneming. Voor het laatste gelden volgens appellanten minder stringente eisen. Technologisch nieuwe principes zijn volgens appellanten niet vereist en het aantonen van het werkingsprincipe is niet aan de orde, omdat uit de toelichting bij de beleidswijziging in 2009 volgt dat het voldoende is dat de technische knelpunten en oplossingsrichtingen liggen op het niveau van het integreren of met elkaar laten samenwerken van bestaande programmatuurcomponenten. Appellanten stellen dat, als het werkingsprincipe wel aangetoond zou moeten worden, uit de Wva en de rechtspraak niet kan worden afgeleid dat dat voorafgaand aan het ‘code kloppen’ zou moeten. Daarnaast stellen appellanten dat zij werkingsprincipes wel degelijk vooraf aantonen, doordat zij virtuele ketentests uitvoeren en op basis van de uitkomsten daarvan de instructies bijstellen die aan de programmeur worden verstuurd. Als tijdens de virtuele ketentest een fout blijkt, dan wordt de technische-ontwerpfase voor het betrokken onderdeel overgedaan.

5.1 In de NS-zaak is het volgende overwogen: “6.1 Blijkens de bestreden besluiten heeft verweerder bij de beoordeling van de onderhavige projecten de maatstaf aangelegd dat er sprake is van technisch nieuwe programmatuur als er technische knelpunten moeten worden opgelost bij het omzetten van het ontwerp van een systeem naar de feitelijke programmatuur. Verweerder heeft daaraan de conclusie verbonden dat deze knelpunten dus worden opgelost bij het programmeren. Als binnen een onderneming gewerkt wordt aan functioneel en technisch ontwerp c.q. architectuur van een systeem, maar de omzetting van het ontwerp naar programmatuur wordt uitbesteed, is volgens verweerder geen sprake van het ontwikkelen van technisch nieuwe (onderdelen) van programmatuur en geeft verweerder geen S&O verklaring af. Het College is van oordeel dat deze maatstaf van verweerder, geplaatst tegen de achtergrond van de hier toepasselijke bepalingen, waaronder artikel 1, eerste lid, onder n, sub 2º en onder o, van de Wva, te beperkt is. Uit de stukken, waaronder het door appellanten in het geding gebrachte deskundigenbericht van [naam 5] en de uiteenzettingen van de deskundige ter zitting, is voor het College voldoende vast komen te staan dat ook in de fase voorafgaand aan het daadwerkelijke programmeren ofwel coderen sprake kan zijn van het oplossen van technische knelpunten met betrekking tot de ontwikkeling van technische nieuwe (onderdelen van) programmatuur en dat een programmeur op basis van een gedetailleerd ontwerp een stuk software kan bouwen, zonder zelf technische knelpunten te hoeven oplossen. Naar het oordeel van het College staat de definitie van ‘programmatuur’ in artikel 1, eerste lid, onder o, van de Wva als een niet-fysiek, logisch deelsysteem van een informatiesysteem dat de structuur van de gegevens en van de verwerkingsprocessen bepaalt, niet in de weg aan een ruimere uitleg dan door verweerder bepleit. Het College kan uit het woord ‘bepaalt’ in voornoemd artikel de door verweerder ter zitting bepleite beperking van het toepassingsbereik van het begrip ‘programmatuur’ niet afleiden. Dat het ontwikkelen van programmatuur noodzakelijk inhoudt dat ook daadwerkelijk wordt geprogrammeerd c.q. gecodeerd, betekent niet per definitie dat van programmatuurontwikkeling geen sprake kan zijn als technische knelpunten niet tijdens het feitelijk programmeren ofwel coderen worden opgelost, maar daaraan voorafgaand in het ontwikkelen van het (technisch) ontwerp. Het College acht bij het voorgaande van belang dat er, zoals aan de hand van de uiteenzetting van de deskundige voldoende aannemelijk is geworden, bij de softwareprogrammering in de loop van de tijd een ontwikkeling heeft plaatsgevonden van ‘ouderwets programmeren’ naar de ‘hedendaagse softwareontwikkeling’. Door de deskundige is uiteengezet dat bij de systeemontwikkeling door appellanten het zogenoemde V-model is toegepast waarbij het maken van het ontwerp en het gebruik ervan in de test- en acceptatiefase (de V-werking) het meest wezenlijke en meest technisch vernieuwende deel van het programmeren vormen. De deskundige heeft verklaard dat het schrijven van de programmeercode zelf (het programmeren door de programmeur) daarbij aanzienlijk minder van belang is, mede gegeven het feit dat het bouwen zelf steeds minder creatieve arbeid vereist nu daarvoor heden standaard ‘blokkendozen’ of ‘componenten’ voor de programmeur beschikbaar zijn. Het is dan ook dit deel dat is uitbesteed aan derden. Naar de mening van de deskundige was bij de aanlevering van de onderhavige producten van appellanten aan de programmeurs een zodanig gedetailleerde beschrijving gevoegd dat bij het programmeren door deze derden geen wezenlijk technische knelpunten behoefden te worden opgelost. De deskundige heeft toegelicht dat als zich in die fase onverhoopt toch wezenlijke technische knelpunten voordoen, die knelpunten dan “terug in het proces” moeten om in een van de stappen voorafgaande aan het bouwen van de programmatuur te worden opgelost. Het College heeft bij het vormen van zijn oordeel er niet aan voorbijgezien dat, zoals verweerder ter zitting in zijn pleitnota heeft verwoord, de ontwikkeling van programmatuur met behulp van technisch nieuwe hulpmiddelen niet per definitie hoeft te leiden tot speur- en ontwikkelingswerk in de zin van de wet en dat technisch nieuw betekent dat er sprake is van een onderzoekscomponent in het project en/of de aanwezigheid van technische onzekerheid omtrent het bereiken van het resultaat. Het College heeft tevens voor ogen gehouden dat, zoals verweerder heeft betoogd, er geen sprake is van speur- en ontwikkelingswerk indien geen onderzoeks- of ontwikkelcomponent in de programmatuurontwikkeling aanwezig is. Het College volgt verweerder evenwel niet, waar hij betoogt, dat dit laatste betekent dat er sprake moet zijn van “daadwerkelijk programmeren” binnen de entiteit van de aanvrager (S&O-inhoudingsplichtige) zelf, wil sprake kunnen zijn van speur- en ontwikkelingswerk. Naar uit het vorenoverwogene volgt, is het College van oordeel dat noch uit de toepasselijke wetsbepalingen noch uit de aard van de zaak (ontwikkeling van programmatuur) volgt dat het zoeken naar en bewijzen van een “nieuw informatietechnologisch principe” of het oplossen van “programmeertechnische knelpunten” in de programmatuur dient plaatsvinden bij het feitelijke programmeren ofwel coderen.” 5.2 Gelet op de NS-uitspraak heeft verweerder de juiste uitgangspunten gehanteerd bij de beoordeling of er sprake is van programmatuur als bedoeld in de Wva. Voor speur- en ontwikkelingswerk dient een onderzoeks- of ontwikkelcomponent in de programmatuurontwikkeling aanwezig te zijn en er dient sprake te zijn van “zoeken en bewijzen” en een “nieuw informatietechnologische principe” of het oplossen van “programmeertechnische knelpunten”. Ook als het gaat om ontwikkeling van programmatuur voor het integreren van bestaande programmatuur, zoals in project 015 het geval is, is er eerst sprake van speur- en ontwikkelingswerk als er technische knelpunten zijn die moeten worden opgelost. Verweerder heeft bij de beoordeling van de aanvragen van appellanten dan ook terecht getoetst of de werkzaamheden van appellanten de ontwikkeling van technisch nieuwe (onderdelen van) programmatuur inhouden, waarbij zij zelf technische problemen moeten oplossen en het technisch nieuwe werkingsprincipe aantonen. 5.3 Het door appellanten ingenomen standpunt dat in het geval van integreren van programmatuur technologisch nieuwe principes niet vereist zijn en het werkingsprincipe niet aangetoond behoeft te worden volgt het College niet. Ongeacht de in 2009 in de regelgeving doorgevoerde verruiming van het begrip programmatuur (zie 4.5 hiervoor), is op grond van artikel 1, aanhef en onder n, sub 2°, van de Wva voor speur- en ontwikkelingswerk immers nog steeds technische nieuwheid vereist. Het betoog van appellanten ertoe strekkende dat er een onderscheid bestaat tussen programmatuur in ruime zin en programmatuur in enge zin laat het voorstaande onverlet. Het College is dan ook van oordeel dat, anders dan appellanten stellen, verweerder met de door hem in de bestreden besluiten weergegeven beoordelingsuitgangspunten niet buiten het wettelijke kader is getreden. 5.4 Het College volgt appellanten ook niet in hun standpunt dat verweerder vereist dat het werkingsprincipe voorafgaand aan het uitbesteden van het werk aan derden moet zijn aangetoond. Verweerder heeft immers de ketentests, die appellanten hebben uitgevoerd na terugontvangst van de aan de derde uitbestede werkzaamheden en die weer uitgangspunt kunnen zijn voor aanpassing van het technisch ontwerp, betrokken bij de beoordeling van de aanvragen. 5.5 Voorts wijst niets er op dat verweerder ervan uit is gegaan dat reeds vanwege het gebruik van op de markt verkrijgbare software geen sprake is van programmatuurontwikkeling, zodat wat appellanten hierover aanvoeren feitelijke grondslag mist en buiten bespreking kan blijven.

Het College verklaart de beroepen ongegrond. Deze uitspraak is gedaan door mr. mr. R.R. Winter, mr. R. C. Stam en mr. H.A.B. van Dorst-Tatomir, in aanwezigheid van mr. M.B. van Zantvoort, griffier. De beslissing is in het openbaar uitgesproken op 16 juni 2017. w.g. R.R. Winter De griffier is buiten staat de uitspraak te ondertekenen

Door deze inrichting en uitvoering van de virtuele ketentests wordt het werkingsprincipe van de door appelanten ontwikkelde programmatuur aangetoond. 2.3 Appellanten menen nieuwe techniek in de programmatuur te ontwikkelen in de fase van het technische ontwerp die volgt op de laatste stap in het functioneel ontwerp: het opstellen van Business Requests (BR’s). De IT-afdeling geeft dan reacties op de BR’s in de vorm van Business Request Responses (BRR’s), die aangegeven welke systemen geraakt gaan worden. Er worden verschillende versies van een BRR opgesteld, waarin telkens de nieuwe technische belemmeringen worden uitgeschreven met de redenen waarom de vereisten nog niet kunnen worden ontwikkeld. Bij iedere aanpassing in een BRR moet worden doordacht wat de implicaties daarvan zijn voor de andere BRR’s. Telkens moet daarbij worden gekozen uit een groot aantal variabelen. Het resultaat van het technisch ontwerp is neergelegd in Use Case Modules (UCM’s), waarin wordt aangegeven wat herontwikkeld moet worden. De UCM’s vormen de instructies voor de programmeur en zijn zodanig uitgewerkt dat die derde nog slechts uitvoerwerkzaamheden hoeft te verrichten. Voor het technisch ontwerp zijn de S&O-verklaringen aangevraagd. 2.4 De vier in 2013 voor het project 015 geschreven UCM’s, tonen, samen met het TNO-rapport 2014, aan dat appellanten zelf interfases hebben ontwikkeld waarmee automatisch advies kan worden gegenereerd voor de klant over de haalbare bandbreedte en de leverbare pakketten en diensten op een adres van een klant of waarmee de klant zelfstandig een monteur kan inplannen en alle orders kunnen worden afgerond. Deze mogelijkheden bestonden daarvoor nog niet. Voor de ontwikkeling ervan is specifieke deskundigheid van de KPN-systemen- en -landschappen vereist. Medewerkers van appellanten hebben hiervoor zelf algoritmes en de bijbehorende programmatuur geschreven. Sommige UCM’s bevatten zelfs pseudocode, waardoor volgens appellanten in elk geval sprake is van programmatuurontwikkeling. In de UCM’s staat de technische oplossing van de technische problemen. Bij het schrijven van de UCM’s ontwikkelen appellanten programmatuur en brengen zij een nieuwe techniek voort. 2.5 Na terug-ontvangst van het programmeerwerk uit India voeren appellanten ketentests uit. Een fout blijkt vaak niet te liggen op het niveau van de individuele UCM, maar op het niveau van de leverstraat. Het gaat vaak pas fout als alle onderdelen bij elkaar worden gevoegd en de leverstaat integraal operationeel moet worden. Een fout in het technisch ontwerp leidt ertoe dat de in India gemaakte programmatuur niet werkt of niet voldoet aan de gestelde eisen, zodat de fase van het technisch ontwerp overgedaan moet worden. Dit kan zich verschillende keren herhalen (het zogenoemde V-model). Appellanten dragen volledig het risico van fouten in de ontwikkelde programmatuur. De technische knelpunten worden opgelost in de fase van het technische ontwerp bij het uitwerken van de BRR’s en UCM’s in IT Quick Scans en het technisch ontwerp vormt tezamen met de ketentests speur- en ontwikkelingswerk. 2.6 De Wva eist volgens appellanten niet dat bij het ontwikkelen van programmatuur geen gebruik gemaakt mag worden van op de markt verkrijgbare software of dat met de programmatuurontwikkeling niet tevens functionele problemen opgelost mogen worden. Volgens appellanten is voor de kwalificatie bepalend of zij een voor hen nieuwe techniek ontwikkelen, of bestaande, zelf ontwikkelde programmatuur integreren of laten samenwerken. In project 015 is daarvan sprake, omdat de gebruikte softwarepakketten niet met enkele eenvoudige aanpassingen te gebruiken zijn en zonder programmatuurontwikkeling niet ingezet kunnen worden en de pakketten slechts voor een aantal applicaties in het project 015 worden gebruikt. Appellanten beperken zich niet tot het invoeren en aanpassen van op de markt verkrijgbare softwarepakketten, of het oplossen van louter functionele problemen. Zij zijn gericht op het zoeken naar een oplossing voor een technisch probleem. Daarnaast spreekt het volgens appellanten vanzelf dat er tevens functionele problemen worden opgelost, omdat de programmatuur wordt ontwikkeld ter ondersteuning van de eigen bedrijfsvoering. In de Wva staat niet dat zodra functionele problemen worden opgelost per definitie van technisch nieuwe programmatuur geen sprake kan zijn. 2.7 Voorts stellen appellanten dat verweerder het begrip technisch knelpunt of nieuwe techniek niet heeft gedefinieerd en stelselmatig weigert om te verduidelijken wat hij onder technisch knelpunt verstaat. Standpunt verweerder 3.1 Verweerder schaart onder het begrip programmatuur ook programmatuur die bestaande programmatuur op voor de S&O-inhoudingsplichtige technisch nieuwe wijze integreert of laat samenwerken. Er is sprake van speur- en ontwikkelingswerk als de technische knelpunten liggen op het niveau van het integreren of met elkaar laten samenwerken van bestaande programmatuurcomponenten, mits deze bestaande programmatuur hoofdzakelijk in de eigen onderneming is ontwikkeld en wordt toegepast. In de bestreden besluiten heeft verweerder aangegeven dat hij bij de beoordeling of er sprake is van programmatuur als bedoeld in de Wva de volgende uitgangspunten hanteert: “Technisch nieuw betekent dat er sprake is van een onderzoekscomponent in het project en/of de aanwezigheid van technische onzekerheid omtrent het bereiken van het resultaat. Centraal hierin staat de aanwezigheid en de aard van de technische knelpunten, evenals de wijze waarop die technische knelpunten kunnen worden opgelost door de aanvrager. De werkzaamheden moeten bovendien een oorspronkelijk en niet routinematig karakter hebben, met een hoge graad van technische onzekerheid met betrekking tot de uiteindelijke resultaten. Maatstaf hierbij vormt het eigen technische kunnen en de eigen technische kennis van de aanvrager. Het karakter van ontwikkelingswerk heeft te maken met ‘zoeken’ en ‘bewijzen’. ‘Zoeken’ is het vanuit een bekend technisch probleem trachten een voor de aanvrager technisch nieuwe oplossing te vinden. ‘Bewijzen’ is het aantonen of een oplossing van het technisch probleem realiseerbaar is. Met andere woorden, men heeft een idee van de oplossing, maar weet niet of die ook technisch realiseerbaar en werkbaar is. Het doel is om het werkingsprincipe van de oplossing aan te tonen. Het maken van een prototype zonder gebruikswaarde kan daar een onderdeel van zijn.” 3.2 Verweerder meent dat bij de afgewezen projecten geen sprake is van speur- en ontwikkelingswerk, omdat hij geen technische knelpunten kan ontdekken in de door appellanten verstrekt informatie. Appellanten hebben geen inzicht verschaft in de specifieke aard van de werkzaamheden en het technische risico, de manier waarop het zoeken en bewijzen wordt uitgevoerd en hoe het werkingsprincipe wordt aangetoond. Het TNO-rapport 2014 geeft aan dat appellanten specificaties van de modules in detail opstellen in de vorm van IT Quick Scans en tijdens het programmeertraject strak sturing geven aan het werk door derden. TNO beschrijft dat appellanten de systeemarchitectuur uitwerken, het systeem uitsplitsen in losse modules, technische specificaties opstellen en systeemintegratietesten uitvoeren. Dat appellanten de problemen analyseren en meesturen met het oplossen ervan toont echter niet aan dat zij daadwerkelijk zelf technische knelpunten oplossen. De rol van appellanten wordt beschreven, maar een analyse van de daadwerkelijke projectuitvoering ontbreekt.

5.6 Verder merkt het College op dat de wet inderdaad, zoals appellanten stellen, niet verbiedt dat tevens functionele problemen mogen worden opgelost, maar dat neemt niet weg dat de werkzaamheden waar appellanten S&O-verklaringen voor hebben aangevraagd moeten voldoen aan de eis van technische nieuwheid om als speur en ontwikkelingswerk aangemerkt te worden. 5.7 Aangaande de beroepsgrond dat verweerder de begrippen technisch knelpunt en nieuwe techniek vooraf had moeten verduidelijken volgt het College verweerders standpunt dat het voor verweerder niet mogelijk is om in het geval van appellanten aan te geven wat een technisch knelpunt is en dat het aan appellanten is om hierover voldoende gegevens te verschaffen. 5.8 De door appellanten over het toetsingskader aangevoerde gronden slagen niet. 6.1 Wat betreft de gang van zaken in de bezwaarprocedure stelt het College vast dat het bij de behandeling van het bezwaar aanvankelijk ging om de vraag of appellanten ook zelf programmeerden of dat het programmeren uitsluitend gebeurde door een derde in India, in welk geval verweerder er aanvankelijk van uitging dat door appellanten zelf geen speur- en ontwikkelingswerk werd gedaan. In de NS-uitspraak heeft verweerder vervolgens aanleiding gezien om de aanvragen van appellanten in bezwaar opnieuw te beoordelen. 6.2.1 Omdat verweerder uit de op dat moment beschikbare informatie niet kon afleiden welke technische problemen (knelpunten) door appellanten concreet werden opgelost, hoe die opgelost werden, hoe het werkingsprincipe werd aangetoond en hoeveel uren aan het oplossen van concrete problemen zijn toe te rekenen heeft verweerder in de bezwaarfase hierover aan appellanten nadere vragen gesteld bij brief van 31 juli 2014, te weten: “In de primaire fase is reeds veel informatie verstrekt met betrekking tot project 015. De informatie over project 015 bestaat echter vooral uit beschrijvingen van deelprojecten, waarbij tot op redelijk detailniveau is gespecificeerd welke functionaliteit nodig is. De informatie is vooral gemaakt vanuit de systeembouwinvalshoek. Op grond van de beschikbare informatie is echter niet af te leiden welke technische problemen (knelpunten) concreet worden opgelost, hoe KPN (lees: welke entiteit) die gaat oplossen en hoe het werkingsprincipe wordt aangetoond.” 6.2.2 Vervolgens heeft verweerder in die brief verzocht om een opsomming te geven van de technische knelpunten die appellanten verwachten bij de ontwikkeling en per technisch knelpunt aan te geven: “a. Wat is concreet het technische knelpunt? b. Waarom is het technische knelpunt niet op te lossen met bestaande technologie? c. Wat is de door u gekozen oplossingsrichting (beschreven vanuit een technische invalshoek? d. Welke technische onzekerheden/risico’s spelen een rol bij het oplossen van technische knelpunten? e. Waaruit bestaat de onderzoekscomponent (hoe wordt het ‘zoeken’ uitgevoerd)? f. Hoe wordt aangetoond dat de oplossing(srichting) voldoet (hoe vindt het ‘bewijzen’ plaats)? g. Waaruit bestaat de uitbreiding van uw eigen technische kunnen en/of de eigen technische kennis? h. Hoeveel uren zijn (‘direct en uitsluitend’) toe te rekenen aan het oplossen van het technische knelpunt? i. Met welke andere partijen wordt samengewerkt? j. Wat wordt er concreet door u opgeleverd (of overgedragen aan een samenwerkende partij)? k. Waaruit bestaan de activiteiten van uw eigen medewerkers? l. In hoeverre wordt door andere betrokken partijen technische (deel)problemen opgelost (wie zijn die partijen en wat zijn de problemen en activiteiten)?” 6.3 Op 21 augustus 2014 heeft een bespreking tussen partijen plaatsgevonden, waarbij afspraken zijn gemaakt over de aan te leveren informatie. 6.4 Op 28 augustus 2014 hebben appellanten een tiental pagina’s overgelegd van het project 015 en een printscreen van eerdere e-mails en daarbij aangegeven dat deze informatie reeds volledig in het dossier aanwezig is en dat daaruit het speur- en ontwikkelingswerk blijkt. Appellanten hebben verder meegedeeld dat zij beogen een leeswijzer te geven bij die reeds aanwezige informatie en uiteengezet dat project 015 een aantal releases omvat, die elk bestaan uit een aantal BR’s, waarvan drie BR’s zijn meegenomen voor de aanvragen. Verder hebben appellanten toegelicht dat de BR’s onderverdeeld worden in UCM’s en daarbij aangegeven welke daarvan zijn geselecteerd voor de aanvragen: “Deze UCM’s bevatten de technische knelpunten, technische oplossingen en daarmee het eigen technische werk van KPN.” (…) “De drie geselecteerde BR’s zijn in Word – met alle verschillende UCM’s- door KPN volledig uitgewerkt en op 2 december 2013 aan RVO toegezonden. Alle UCM’s zijn daarin inhoudelijk toegelicht/uitgeschreven, inclusief de onderlinge relatie en afhankelijkheid. Per UCM zijn in de Word-documenten de technische knelpunten aangegeven, de oplossingsrichtingen en het daadwerkelijke uitschrijven van de oplossingsrichting. De systematiek van de UCM’s (…) is tijdens de bijeenkomst op 20 november 2013 toegelicht door KPN en door RVO akkoord bevonden. Als gezegd, heeft RVO deze informatie op 2 december 2013 ontvangen van KPN. KPN benadrukt dat de antwoorden op de door RVO in de brief van 31 juli 2014 gestelde vragen volgen uit de UCM’s die op 20 november 2013 zijn toegelicht en op 2 december 2013 zijn toegezonden. Ter onderbouwing daarvan worden hieronder een aantal UCM’s zoals uitgevoerd door KPN weergegeven. De geel gemarkeerde passages waren al geelgemarkeerd in de originele IT QuickScans die op 2 december 2013 zijn verstrekt aan RVO. De groen gemarkeerde stukken zijn ten behoeve van de op 21 augustus 2014 gevraagde nadere toelichting aangebracht om nog duidelijker de onderdelen te duiden waaruit RVO de technische knelpunten en oplossingsrichtingen kan opmaken. Nota bene deze passages waren al opgenomen in de op 2 december 2013 toegezonden informatie, met dien verstande dat zij daarin nog niet waren gemarkeerd. Oftewel, deze informatie is reeds voor de besluitvorming in december 2013 aan RVO verstrekt en TNO heeft deze informatie betrokken in haar rapportage.” 6.5 Verweerder heeft op 5 september 2014 om nadere informatie verzocht: “In het bijgevoegde document over project 015 wordt aangegeven dat de informatie ook reeds bij ons aanwezig was. Dat is juist. In de brief van 31 juli 2014 hebben we een aantal vragen gesteld met de bedoeling aanvullende informatie te krijgen om het S&O-karakter van de werkzaamheden te kunnen beoordelen. In het gesprek van 21 augustus 2014 is aan de orde geweest dat het voor ons de vraag blijft in hoeverre er sprake is van - technische knelpunten - technische onzekerheid en - het zoeken naar een oplossingsrichting - het bewijzen van het werkingsprincipe van de oplossing door eigen personeel van de aanvrager. (…) De UCM’s, die als voorbeeld aanwezig zijn, geven ons daarover nog geen of onvoldoende duidelijkheid, ondanks de aanvullende markering en de beperkte notities van 28 augustus. Dit licht ik als volgt toe. De in de UCM’s vermelde ‘problems’ geven niet een technisch knelpunt aan, maar veeleer een beschrijving vanuit een requirements-invalshoek. Ons is zonder nadere toelichting niet duidelijk waarom de uitwerking ervan technische knelpunten oplevert en technisch onzeker is. In het verlengde daarvan is het evenmin, zonder nader toelichting, duidelijk dat de description of the solution het resultaat is van S&O, c.q. het zoeken naar een oplossingsrichting en het bewijzen van het werkingsprincipe daarvan. De description zou gebaseerd kunnen zijn op aanwezige kennis van systeem en programmeertechniek.

Door deze inrichting en uitvoering van de virtuele ketentests wordt het werkingsprincipe van de door appelanten ontwikkelde programmatuur aangetoond. 2.3 Appellanten menen nieuwe techniek in de programmatuur te ontwikkelen in de fase van het technische ontwerp die volgt op de laatste stap in het functioneel ontwerp: het opstellen van Business Requests (BR’s). De IT-afdeling geeft dan reacties op de BR’s in de vorm van Business Request Responses (BRR’s), die aangegeven welke systemen geraakt gaan worden. Er worden verschillende versies van een BRR opgesteld, waarin telkens de nieuwe technische belemmeringen worden uitgeschreven met de redenen waarom de vereisten nog niet kunnen worden ontwikkeld. Bij iedere aanpassing in een BRR moet worden doordacht wat de implicaties daarvan zijn voor de andere BRR’s. Telkens moet daarbij worden gekozen uit een groot aantal variabelen. Het resultaat van het technisch ontwerp is neergelegd in Use Case Modules (UCM’s), waarin wordt aangegeven wat herontwikkeld moet worden. De UCM’s vormen de instructies voor de programmeur en zijn zodanig uitgewerkt dat die derde nog slechts uitvoerwerkzaamheden hoeft te verrichten. Voor het technisch ontwerp zijn de S&O-verklaringen aangevraagd. 2.4 De vier in 2013 voor het project 015 geschreven UCM’s, tonen, samen met het TNO-rapport 2014, aan dat appellanten zelf interfases hebben ontwikkeld waarmee automatisch advies kan worden gegenereerd voor de klant over de haalbare bandbreedte en de leverbare pakketten en diensten op een adres van een klant of waarmee de klant zelfstandig een monteur kan inplannen en alle orders kunnen worden afgerond. Deze mogelijkheden bestonden daarvoor nog niet. Voor de ontwikkeling ervan is specifieke deskundigheid van de KPN-systemen- en -landschappen vereist. Medewerkers van appellanten hebben hiervoor zelf algoritmes en de bijbehorende programmatuur geschreven. Sommige UCM’s bevatten zelfs pseudocode, waardoor volgens appellanten in elk geval sprake is van programmatuurontwikkeling. In de UCM’s staat de technische oplossing van de technische problemen. Bij het schrijven van de UCM’s ontwikkelen appellanten programmatuur en brengen zij een nieuwe techniek voort. 2.5 Na terug-ontvangst van het programmeerwerk uit India voeren appellanten ketentests uit. Een fout blijkt vaak niet te liggen op het niveau van de individuele UCM, maar op het niveau van de leverstraat. Het gaat vaak pas fout als alle onderdelen bij elkaar worden gevoegd en de leverstaat integraal operationeel moet worden. Een fout in het technisch ontwerp leidt ertoe dat de in India gemaakte programmatuur niet werkt of niet voldoet aan de gestelde eisen, zodat de fase van het technisch ontwerp overgedaan moet worden. Dit kan zich verschillende keren herhalen (het zogenoemde V-model). Appellanten dragen volledig het risico van fouten in de ontwikkelde programmatuur. De technische knelpunten worden opgelost in de fase van het technische ontwerp bij het uitwerken van de BRR’s en UCM’s in IT Quick Scans en het technisch ontwerp vormt tezamen met de ketentests speur- en ontwikkelingswerk. 2.6 De Wva eist volgens appellanten niet dat bij het ontwikkelen van programmatuur geen gebruik gemaakt mag worden van op de markt verkrijgbare software of dat met de programmatuurontwikkeling niet tevens functionele problemen opgelost mogen worden. Volgens appellanten is voor de kwalificatie bepalend of zij een voor hen nieuwe techniek ontwikkelen, of bestaande, zelf ontwikkelde programmatuur integreren of laten samenwerken. In project 015 is daarvan sprake, omdat de gebruikte softwarepakketten niet met enkele eenvoudige aanpassingen te gebruiken zijn en zonder programmatuurontwikkeling niet ingezet kunnen worden en de pakketten slechts voor een aantal applicaties in het project 015 worden gebruikt. Appellanten beperken zich niet tot het invoeren en aanpassen van op de markt verkrijgbare softwarepakketten, of het oplossen van louter functionele problemen. Zij zijn gericht op het zoeken naar een oplossing voor een technisch probleem. Daarnaast spreekt het volgens appellanten vanzelf dat er tevens functionele problemen worden opgelost, omdat de programmatuur wordt ontwikkeld ter ondersteuning van de eigen bedrijfsvoering. In de Wva staat niet dat zodra functionele problemen worden opgelost per definitie van technisch nieuwe programmatuur geen sprake kan zijn. 2.7 Voorts stellen appellanten dat verweerder het begrip technisch knelpunt of nieuwe techniek niet heeft gedefinieerd en stelselmatig weigert om te verduidelijken wat hij onder technisch knelpunt verstaat. Standpunt verweerder 3.1 Verweerder schaart onder het begrip programmatuur ook programmatuur die bestaande programmatuur op voor de S&O-inhoudingsplichtige technisch nieuwe wijze integreert of laat samenwerken. Er is sprake van speur- en ontwikkelingswerk als de technische knelpunten liggen op het niveau van het integreren of met elkaar laten samenwerken van bestaande programmatuurcomponenten, mits deze bestaande programmatuur hoofdzakelijk in de eigen onderneming is ontwikkeld en wordt toegepast. In de bestreden besluiten heeft verweerder aangegeven dat hij bij de beoordeling of er sprake is van programmatuur als bedoeld in de Wva de volgende uitgangspunten hanteert: “Technisch nieuw betekent dat er sprake is van een onderzoekscomponent in het project en/of de aanwezigheid van technische onzekerheid omtrent het bereiken van het resultaat. Centraal hierin staat de aanwezigheid en de aard van de technische knelpunten, evenals de wijze waarop die technische knelpunten kunnen worden opgelost door de aanvrager. De werkzaamheden moeten bovendien een oorspronkelijk en niet routinematig karakter hebben, met een hoge graad van technische onzekerheid met betrekking tot de uiteindelijke resultaten. Maatstaf hierbij vormt het eigen technische kunnen en de eigen technische kennis van de aanvrager. Het karakter van ontwikkelingswerk heeft te maken met ‘zoeken’ en ‘bewijzen’. ‘Zoeken’ is het vanuit een bekend technisch probleem trachten een voor de aanvrager technisch nieuwe oplossing te vinden. ‘Bewijzen’ is het aantonen of een oplossing van het technisch probleem realiseerbaar is. Met andere woorden, men heeft een idee van de oplossing, maar weet niet of die ook technisch realiseerbaar en werkbaar is. Het doel is om het werkingsprincipe van de oplossing aan te tonen. Het maken van een prototype zonder gebruikswaarde kan daar een onderdeel van zijn.” 3.2 Verweerder meent dat bij de afgewezen projecten geen sprake is van speur- en ontwikkelingswerk, omdat hij geen technische knelpunten kan ontdekken in de door appellanten verstrekt informatie. Appellanten hebben geen inzicht verschaft in de specifieke aard van de werkzaamheden en het technische risico, de manier waarop het zoeken en bewijzen wordt uitgevoerd en hoe het werkingsprincipe wordt aangetoond. Het TNO-rapport 2014 geeft aan dat appellanten specificaties van de modules in detail opstellen in de vorm van IT Quick Scans en tijdens het programmeertraject strak sturing geven aan het werk door derden. TNO beschrijft dat appellanten de systeemarchitectuur uitwerken, het systeem uitsplitsen in losse modules, technische specificaties opstellen en systeemintegratietesten uitvoeren. Dat appellanten de problemen analyseren en meesturen met het oplossen ervan toont echter niet aan dat zij daadwerkelijk zelf technische knelpunten oplossen. De rol van appellanten wordt beschreven, maar een analyse van de daadwerkelijke projectuitvoering ontbreekt.

5.6 Verder merkt het College op dat de wet inderdaad, zoals appellanten stellen, niet verbiedt dat tevens functionele problemen mogen worden opgelost, maar dat neemt niet weg dat de werkzaamheden waar appellanten S&O-verklaringen voor hebben aangevraagd moeten voldoen aan de eis van technische nieuwheid om als speur en ontwikkelingswerk aangemerkt te worden. 5.7 Aangaande de beroepsgrond dat verweerder de begrippen technisch knelpunt en nieuwe techniek vooraf had moeten verduidelijken volgt het College verweerders standpunt dat het voor verweerder niet mogelijk is om in het geval van appellanten aan te geven wat een technisch knelpunt is en dat het aan appellanten is om hierover voldoende gegevens te verschaffen. 5.8 De door appellanten over het toetsingskader aangevoerde gronden slagen niet. 6.1 Wat betreft de gang van zaken in de bezwaarprocedure stelt het College vast dat het bij de behandeling van het bezwaar aanvankelijk ging om de vraag of appellanten ook zelf programmeerden of dat het programmeren uitsluitend gebeurde door een derde in India, in welk geval verweerder er aanvankelijk van uitging dat door appellanten zelf geen speur- en ontwikkelingswerk werd gedaan. In de NS-uitspraak heeft verweerder vervolgens aanleiding gezien om de aanvragen van appellanten in bezwaar opnieuw te beoordelen. 6.2.1 Omdat verweerder uit de op dat moment beschikbare informatie niet kon afleiden welke technische problemen (knelpunten) door appellanten concreet werden opgelost, hoe die opgelost werden, hoe het werkingsprincipe werd aangetoond en hoeveel uren aan het oplossen van concrete problemen zijn toe te rekenen heeft verweerder in de bezwaarfase hierover aan appellanten nadere vragen gesteld bij brief van 31 juli 2014, te weten: “In de primaire fase is reeds veel informatie verstrekt met betrekking tot project 015. De informatie over project 015 bestaat echter vooral uit beschrijvingen van deelprojecten, waarbij tot op redelijk detailniveau is gespecificeerd welke functionaliteit nodig is. De informatie is vooral gemaakt vanuit de systeembouwinvalshoek. Op grond van de beschikbare informatie is echter niet af te leiden welke technische problemen (knelpunten) concreet worden opgelost, hoe KPN (lees: welke entiteit) die gaat oplossen en hoe het werkingsprincipe wordt aangetoond.” 6.2.2 Vervolgens heeft verweerder in die brief verzocht om een opsomming te geven van de technische knelpunten die appellanten verwachten bij de ontwikkeling en per technisch knelpunt aan te geven: “a. Wat is concreet het technische knelpunt? b. Waarom is het technische knelpunt niet op te lossen met bestaande technologie? c. Wat is de door u gekozen oplossingsrichting (beschreven vanuit een technische invalshoek? d. Welke technische onzekerheden/risico’s spelen een rol bij het oplossen van technische knelpunten? e. Waaruit bestaat de onderzoekscomponent (hoe wordt het ‘zoeken’ uitgevoerd)? f. Hoe wordt aangetoond dat de oplossing(srichting) voldoet (hoe vindt het ‘bewijzen’ plaats)? g. Waaruit bestaat de uitbreiding van uw eigen technische kunnen en/of de eigen technische kennis? h. Hoeveel uren zijn (‘direct en uitsluitend’) toe te rekenen aan het oplossen van het technische knelpunt? i. Met welke andere partijen wordt samengewerkt? j. Wat wordt er concreet door u opgeleverd (of overgedragen aan een samenwerkende partij)? k. Waaruit bestaan de activiteiten van uw eigen medewerkers? l. In hoeverre wordt door andere betrokken partijen technische (deel)problemen opgelost (wie zijn die partijen en wat zijn de problemen en activiteiten)?” 6.3 Op 21 augustus 2014 heeft een bespreking tussen partijen plaatsgevonden, waarbij afspraken zijn gemaakt over de aan te leveren informatie. 6.4 Op 28 augustus 2014 hebben appellanten een tiental pagina’s overgelegd van het project 015 en een printscreen van eerdere e-mails en daarbij aangegeven dat deze informatie reeds volledig in het dossier aanwezig is en dat daaruit het speur- en ontwikkelingswerk blijkt. Appellanten hebben verder meegedeeld dat zij beogen een leeswijzer te geven bij die reeds aanwezige informatie en uiteengezet dat project 015 een aantal releases omvat, die elk bestaan uit een aantal BR’s, waarvan drie BR’s zijn meegenomen voor de aanvragen. Verder hebben appellanten toegelicht dat de BR’s onderverdeeld worden in UCM’s en daarbij aangegeven welke daarvan zijn geselecteerd voor de aanvragen: “Deze UCM’s bevatten de technische knelpunten, technische oplossingen en daarmee het eigen technische werk van KPN.” (…) “De drie geselecteerde BR’s zijn in Word – met alle verschillende UCM’s- door KPN volledig uitgewerkt en op 2 december 2013 aan RVO toegezonden. Alle UCM’s zijn daarin inhoudelijk toegelicht/uitgeschreven, inclusief de onderlinge relatie en afhankelijkheid. Per UCM zijn in de Word-documenten de technische knelpunten aangegeven, de oplossingsrichtingen en het daadwerkelijke uitschrijven van de oplossingsrichting. De systematiek van de UCM’s (…) is tijdens de bijeenkomst op 20 november 2013 toegelicht door KPN en door RVO akkoord bevonden. Als gezegd, heeft RVO deze informatie op 2 december 2013 ontvangen van KPN. KPN benadrukt dat de antwoorden op de door RVO in de brief van 31 juli 2014 gestelde vragen volgen uit de UCM’s die op 20 november 2013 zijn toegelicht en op 2 december 2013 zijn toegezonden. Ter onderbouwing daarvan worden hieronder een aantal UCM’s zoals uitgevoerd door KPN weergegeven. De geel gemarkeerde passages waren al geelgemarkeerd in de originele IT QuickScans die op 2 december 2013 zijn verstrekt aan RVO. De groen gemarkeerde stukken zijn ten behoeve van de op 21 augustus 2014 gevraagde nadere toelichting aangebracht om nog duidelijker de onderdelen te duiden waaruit RVO de technische knelpunten en oplossingsrichtingen kan opmaken. Nota bene deze passages waren al opgenomen in de op 2 december 2013 toegezonden informatie, met dien verstande dat zij daarin nog niet waren gemarkeerd. Oftewel, deze informatie is reeds voor de besluitvorming in december 2013 aan RVO verstrekt en TNO heeft deze informatie betrokken in haar rapportage.” 6.5 Verweerder heeft op 5 september 2014 om nadere informatie verzocht: “In het bijgevoegde document over project 015 wordt aangegeven dat de informatie ook reeds bij ons aanwezig was. Dat is juist. In de brief van 31 juli 2014 hebben we een aantal vragen gesteld met de bedoeling aanvullende informatie te krijgen om het S&O-karakter van de werkzaamheden te kunnen beoordelen. In het gesprek van 21 augustus 2014 is aan de orde geweest dat het voor ons de vraag blijft in hoeverre er sprake is van - technische knelpunten - technische onzekerheid en - het zoeken naar een oplossingsrichting - het bewijzen van het werkingsprincipe van de oplossing door eigen personeel van de aanvrager. (…) De UCM’s, die als voorbeeld aanwezig zijn, geven ons daarover nog geen of onvoldoende duidelijkheid, ondanks de aanvullende markering en de beperkte notities van 28 augustus. Dit licht ik als volgt toe. De in de UCM’s vermelde ‘problems’ geven niet een technisch knelpunt aan, maar veeleer een beschrijving vanuit een requirements-invalshoek. Ons is zonder nadere toelichting niet duidelijk waarom de uitwerking ervan technische knelpunten oplevert en technisch onzeker is. In het verlengde daarvan is het evenmin, zonder nader toelichting, duidelijk dat de description of the solution het resultaat is van S&O, c.q. het zoeken naar een oplossingsrichting en het bewijzen van het werkingsprincipe daarvan. De description zou gebaseerd kunnen zijn op aanwezige kennis van systeem en programmeertechniek.

3.3 Verweerder concludeert dat de werkzaamheden van appellanten bestaan uit het opstellen van specificaties, het bedenken en specifiek beschrijven van het systeem, het signaleren van de noodzaak van nieuwe programmatuur, het beschrijven van de vereisten daarvoor door middel van UCM’s en pseudocode en het testen van het systeem en de nieuwe programmatuur aan de vereisten door middel van onder meer virtuele ketentests. Het gaat daarbij primair om het maken van keuzes, wat volgens verweerder wat anders is dan het feitelijk oplossen van de technologische problemen en het aantonen van het werkingsprincipe. Er is slechts op onderdelen sprake van het zoeken naar functionele oplossingen, maar niet van bewijzen van een mogelijke technische oplossing die door eigen medewerkers van appellanten is gerealiseerd. 3.4 Volgens TNO-rapport 2014 valt het aantonen van het werkingsprincipe samen met de ketentest, die als doel heeft vast te stellen of het systeem als geheel voldoet aan de specificaties. Maar het gaat bij het aantonen van het werkingsprincipe niet om het toetsen of een ontwerp aan de functionele specificaties voldoet, maar om het toetsen van de gevonden oplossing voor het informatietechnologische probleem. Van zoeken en bewijzen is daarom geen sprake. 3.5 Het gebruik van bestaande businesssoftwarepakketten betekent niet dat er geen sprake van programmatuurontwikkeling kan zijn. Het gebruik van deze pakketten heeft alleen een rol gespeeld bij de beoordeling of de activiteiten vallen onder de verruiming uit 2009. Dat is niet zo, omdat de standaard businesssoftwarepakketten die appellanten integreren of laten samenwerken niet door appellanten zelf zijn ontwikkeld, zodat op grond van artikel 1, onderdeel b, sub 3°, van de Afbakeningsregeling geen sprake is van speur- en ontwikkelingswerk. Juridisch kader 4.1 Voor de beoordeling van het geschil is het volgende juridische kader van belang. 4.2 Op grond van artikel 23, eerste lid, van de Wva, zoals dat luidde ten tijde hier van belang, verstrekt verweerder een S&O-verklaring aan een S&O-inhoudingsplichtige die hiertoe voorafgaand een aanvraag heeft ingediend en die voornemens is in een periode van een kalenderjaar speur- en ontwikkelingswerk te verrichteng. 4.3 Onder speur- en ontwikkelingswerk wordt in artikel 1, aanhef en onder n, sub 2°, van de Wva, zoals dat ten tijde van belang luidde en voor zover hier relevant, verstaan door een S&O-inhoudingsplichtige of S&O-belastingplichtige systematisch georganiseerde en in een lidstaat van de Europese Unie verrichte werkzaamheden, direct en uitsluitend gericht op de ontwikkeling van voor de S&O-inhoudingsplichtige technisch nieuwe (onderdelen) van programmatuur. Onder programmatuur wordt in artikel 1, aanhef en onder o, van de Wva, zoals dit artikel destijds luidde, verstaan het niet-fysieke, logische deelsysteem van een informatiesysteem dat de structuur van de gegevens en van de verwerkingsprocessen bepaalt. 4.4 Artikel 1, onderdeel b, onder 3° van de Afbakeningsregeling speur- en ontwikkelingswerk 1997, zoals deze ten tijde hier van belang luidde (Afbakeningsregeling), sluit van het begrip speur- en ontwikkelingswerk uit het ontwikkelen van programmatuur die bestaande programmatuur op een voor de S&O-inhoudingsplichtige of S&O-belastingplichtige technisch nieuwe wijze integreert of laat samenwerken, tenzij de bestaande programmatuur hoofdzakelijk binnen de onderneming van de S&O-inhoudingsplichtige, binnen de fiscale eenheid waarvan de S&O-inhoudingsplichtige deel uitmaakt, of binnen de onderneming van de S&O-belastingplichtige, is ontwikkeld en wordt toegepast. 4.5 Met de Regeling van de Minister van Economische Zaken van 8 december 2008, nr. WJZ/8171682, tot wijziging van de afbakeningsregeling 1997 (Regeling wijziging Afbakeningsregeling) wordt het begrip programmatuur per 2009 ruimer uitgelegd. Voor zover hier van belang is in de toelichting bij deze wijziging gesteld: “Tot nu toe moest er (…) sprake zijn van technische knelpunten op het niveau van de ontwikkeling van nieuwe informatietechnologische principes. Vanaf 1 januari 2009 mag het ook gaan om technische knelpunten en oplossingsrichtingen die liggen op het niveau van het integreren of met elkaar laten samenwerken van bestaande programmatuurcomponenten. (…) Om bovenbedoelde intensivering gestalte te geven, wordt tegelijk met deze regeling een beleidsregel tot stand gebracht die aangeeft dat het begrip ‘voor de S&O-inhoudingsplichtige of S&O-belastingplichtige technisch nieuwe (onderdelen van) programmatuur vanaf 1 januari 2009 ruimer zal worden uitgelegd.” 4.5 In artikel 1 van de Regeling van de Minister van Economische Zaken van 8 december 2008, nr. WJZ/8179284, houdende beleidregels inzake de uitleg technisch nieuwe programmatuur (beleidsregel uitleg technisch nieuwe programmatuur), wordt het begrip programmatuur zo uitgelegd dat daaronder ook kan worden verstaan programmatuur die bestaande programmatuur op een voor de S&O-inhoudingsplichtige of S&O-belastingplichtige technisch nieuwe wijze integreert of laat samenwerken.

In dat geval is er wel sprake van werkzaamheden ten behoeve van nieuwe programmatuur, maar niet van technisch nieuwe programmatuur. In dit kader is in de brief van 31 juli een aantal vragen gesteld, waarin juist om een toelichting gevraagd wordt. (…) De hier gevraagde informatie ontbreekt in de door u verstrekte reactie. Zonder die informatie kan ik vooralsnog niet tot de conclusie komen dat KPN binnen de beschreven UCM’s S&O-werkzaamheden verricht. Ik wil u daarom wijzen op het belang van de beantwoording van die vragen ten aanzien van de betreffenden UCM’s.” Verweerder heeft vervolgens verzocht om de in de brief van 31 juli 2014 gestelde vragen expliciet te beantwoorden. 6.6 Op 26 september 2014 hebben appellanten hierop gereageerd en de gestelde vragen per UCM beantwoord. Zo is bij UCM866 vermeld: “Doel van UCM866 was het ontwikkelen van een Dynamisch configurabele beslisomgeving op basis waarvan iTV aangeboden kon worden aan klanten van KPN. Achtergrond: KPN moet vraag en aanbod goed kunnen afstemmen. KPN wil weten welke carrier technologie bij klanten beschikbaar is om een gericht producten aan te kunnen bieden die op een bepaalde locatie ook daadwerkelijk geleverd kunnen worden waarbij KPN ook de kwaliteit kan garanderen waar zij voor staat en de klant voor betaalt. (…) De technische interafhankelijkheid van keuzes maakt dat dit niet slechts het netjes en gedegen uitschrijven van processen is, maar technische nieuwe programmatuur vereist. Bestaande en beschikbare programmatuur volstaat op geen enkel punt voor deze technische werkzaamheden en KPN moest dan ook aanvullende programmatuur schrijven om de gewenste activiteit technisch mogelijk te maken. (…) Ten aanzien van iTV, is er een groot aantal technische variabelen die bepalen hoeveel SD/HD of een combinatie hiervan een klant kan ontvangen op basis van de snelheid/dragertechnologie die bij de klant aanwezig is. (…) De carrier technologie type bepaalt wat wel/niet beschikbaar is voor een klant. Met dit als achtergrond wil KPN heel klantspecifiek producten aanbieden. (…) KPN heeft daarom een Dynamisch configurabele omgeving ontwikkeld waarin de gehele beslisboom van producten die wel/niet aangeboden kunnen worden volledig geautomatiseerd is. Het gaat daarbij dus niet om het uitschrijven van de verschillende keuzes, maar om de interafhankelijkheid van de technische systemen bij verschillende keuzes. Dit is technisch speurwerk (…)” Als concreet technisch knelpunt noemen appellanten: “(…) een omgeving te bouwen die dynamisch is. Het gaat om een omgeving die niet alleen geschreven is met de huidige bestaande technologie als uitgangspunt maar ook eventuele toekomstige technologieën (…). Dit vraag om een zeer flexibele omgeving. Hierdoor zal KPN toekomstige upgrades eenvoudig kunnen doorvoeren en zullen in de toekomst software aanpassingen niet meer nodig zijn. Technische complexiteit hierbij was dat er geen bestaande programma’s voorhanden waren waarin dit te realiseren was. KPN moest dus zelf technisch onderzoeken welke programmatuur als basis kon fungeren en hier vervolgens de interfaces en de benodigde algoritmen zelf op stellen. (…) Nu wordt er binnen KPN één leverstraat ontwikkeld voor alle carrier types. Hierbij heeft KPN besloten om de leverstraat zodanig te ontwikkelen dat er dynamische omgevingen/systemen ontstaan waardoor toekomstige technische vernieuwingen/ontwikkelen geen problemen zullen opleveren.” Appellanten hebben in hun reactie verder aangegeven dat zij de vragen onder protest hebben beantwoord, omdat zij vinden dat verweerder te veel op detailniveau vraagt en het niet mogelijk is om deze informatie voorafgaande aan een project te verstrekken. Verder vragen appellanten aan verweerder om aan te geven onder welke concrete omstandigheden programmatuurontwikkeling binnen hun bedrijfsvoering nog wel als S&O worden aangemerkt en voorbeelden daarvan te geven. 6.7 Op 10 oktober 2014 heeft verweerder appellanten gevraagd een aantal opmerkingen in de e-mail van 26 september 2014 nader te concretiseren en er daarnaast op gewezen dat een aantal opmerkingen vragen oproept, waardoor het hem onduidelijk blijft of appellanten activiteiten uitvoeren die als speur- en ontwikkelingswerk aangemerkt kunnen worden. 6.8 Hierop hebben appellanten in een brief van 2 december 2014 uiteengezet waarom zij menen dat hun werkzaamheden in de fase van het technische ontwerp van project 015 speur- en ontwikkelingswerk inhoudt en dat uitsluitend zij in die fase verantwoordelijk zijn voor het oplossen van de technische knelpunten en voorts dat: “het voor de beantwoording van de vragen (uit de brief van 31 juli 2014) voldoende zou moeten zijn dat KPN wijst op de technische knelpunten die op voorhand, voorafgaand aan de S&O, bekend konden zijn.” 6.9 In december 2014 hebben partijen contact met elkaar gehad en heeft er op 9 december 2014 een gesprek plaatsgevonden, waarbij appellanten een PowerPoint-presentatie hebben gegeven. 6.10 Verweerder heeft vervolgens in de bestreden besluiten geconcludeerd dat appellanten niet aannemelijk hebben gemaakt dat de werkzaamheden direct en uitsluitend gericht zijn op de ontwikkeling van voor hen technisch nieuwe (onderdelen van) programmatuur, zodat geen sprake is van speur- en ontwikkelingswerk. Op basis van de over project 015 verstrekt informatie stelt verweerder dat appellanten slechts specificaties van de modules in detail opstellen in de vorm van IT Quick Scans. Zoals verweerder heeft gesteld gaat het daarbij primair om het maken van keuzes, wat iets anders is dan het feitelijk oplossen van de technische problemen en het aantonen van het werkingsprinsprincipe. Met de ketentest wordt getoetst of aan de functionele specificaties wordt voldaan, maar niet of de te realiseren oplossing technisch zal voldoen. 6.11 Zoals het College eerder heeft overwogen (zie onder meer de uitspraken van 16 juni 2015, ECLI:NL:CBB:2015:213, en 22 april 2013, ECLI:NL:CBB:2013:CA2133) is het voor verweerder noodzakelijk om van de aanvrager voldoende gegevens te verkrijgen om te kunnen beoordelen of de werkzaamheden waarvoor een verklaring wordt aangevraagd al dan niet onder de werkingssfeer van de Wva ressorteren. De vraag of dat het geval is, moet worden beantwoord aan de hand van de van toepassing zijnde wet- en regelgeving en de concrete feiten en omstandigheden van het geval. Het is in beginsel aan de aanvrager om daarover duidelijkheid te verschaffen. 6.12 Verweerder heeft bij herhaling en door gerichte vraagstelling appellanten gelegenheid geboden duidelijkheid te geven in hoeverre er sprake is van technische knelpunten, technische onzekerheid en het zoeken naar een oplossing en het bewijzen van het werkingsprincipe van de oplossing door eigen personeel. In hun reactie hierop hebben appellanten zich beperkt tot het vermelden van de met project 015 beoogde ambities en de gewenste functionaliteiten. Bij de beantwoording van door verweerder gestelde vragen naar de technische knelpunten bleven appellanten verwijzen naar de eerder door hen verschafte gegevens en bleven zij steken in vaagheden zonder concreet technische knelpunten te noemen. Exemplarisch voor dit laatste is de reactie van appellanten van 26 september 2016 bij de vraag van verweerder wat concreet het technisch knelpunt is bij een van de UCM’s: “Technisch knelpunt is een omgeving te bouwen die dynamisch is. Het gaat dan om een omgeving die niet alleen geschreven is met de huidige bestaande technologie als uitgangspunt maar ook eventuele toekomstige technologieën (die dus nog onbekend zijn ). Dit vraagt om een zeer flexibele omgeving. Hierdoor zal KPN toekomstige upgrades eenvoudig kunnen doorvoeren en zullen in de toekomst software aanpassingen niet meer nodig zijn. Technische complexiteit hierbij was dat er geen bestaande programma’s voorhanden waren waarin dit te realiseren was.

3.3 Verweerder concludeert dat de werkzaamheden van appellanten bestaan uit het opstellen van specificaties, het bedenken en specifiek beschrijven van het systeem, het signaleren van de noodzaak van nieuwe programmatuur, het beschrijven van de vereisten daarvoor door middel van UCM’s en pseudocode en het testen van het systeem en de nieuwe programmatuur aan de vereisten door middel van onder meer virtuele ketentests. Het gaat daarbij primair om het maken van keuzes, wat volgens verweerder wat anders is dan het feitelijk oplossen van de technologische problemen en het aantonen van het werkingsprincipe. Er is slechts op onderdelen sprake van het zoeken naar functionele oplossingen, maar niet van bewijzen van een mogelijke technische oplossing die door eigen medewerkers van appellanten is gerealiseerd. 3.4 Volgens TNO-rapport 2014 valt het aantonen van het werkingsprincipe samen met de ketentest, die als doel heeft vast te stellen of het systeem als geheel voldoet aan de specificaties. Maar het gaat bij het aantonen van het werkingsprincipe niet om het toetsen of een ontwerp aan de functionele specificaties voldoet, maar om het toetsen van de gevonden oplossing voor het informatietechnologische probleem. Van zoeken en bewijzen is daarom geen sprake. 3.5 Het gebruik van bestaande businesssoftwarepakketten betekent niet dat er geen sprake van programmatuurontwikkeling kan zijn. Het gebruik van deze pakketten heeft alleen een rol gespeeld bij de beoordeling of de activiteiten vallen onder de verruiming uit 2009. Dat is niet zo, omdat de standaard businesssoftwarepakketten die appellanten integreren of laten samenwerken niet door appellanten zelf zijn ontwikkeld, zodat op grond van artikel 1, onderdeel b, sub 3°, van de Afbakeningsregeling geen sprake is van speur- en ontwikkelingswerk. Juridisch kader 4.1 Voor de beoordeling van het geschil is het volgende juridische kader van belang. 4.2 Op grond van artikel 23, eerste lid, van de Wva, zoals dat luidde ten tijde hier van belang, verstrekt verweerder een S&O-verklaring aan een S&O-inhoudingsplichtige die hiertoe voorafgaand een aanvraag heeft ingediend en die voornemens is in een periode van een kalenderjaar speur- en ontwikkelingswerk te verrichteng. 4.3 Onder speur- en ontwikkelingswerk wordt in artikel 1, aanhef en onder n, sub 2°, van de Wva, zoals dat ten tijde van belang luidde en voor zover hier relevant, verstaan door een S&O-inhoudingsplichtige of S&O-belastingplichtige systematisch georganiseerde en in een lidstaat van de Europese Unie verrichte werkzaamheden, direct en uitsluitend gericht op de ontwikkeling van voor de S&O-inhoudingsplichtige technisch nieuwe (onderdelen) van programmatuur. Onder programmatuur wordt in artikel 1, aanhef en onder o, van de Wva, zoals dit artikel destijds luidde, verstaan het niet-fysieke, logische deelsysteem van een informatiesysteem dat de structuur van de gegevens en van de verwerkingsprocessen bepaalt. 4.4 Artikel 1, onderdeel b, onder 3° van de Afbakeningsregeling speur- en ontwikkelingswerk 1997, zoals deze ten tijde hier van belang luidde (Afbakeningsregeling), sluit van het begrip speur- en ontwikkelingswerk uit het ontwikkelen van programmatuur die bestaande programmatuur op een voor de S&O-inhoudingsplichtige of S&O-belastingplichtige technisch nieuwe wijze integreert of laat samenwerken, tenzij de bestaande programmatuur hoofdzakelijk binnen de onderneming van de S&O-inhoudingsplichtige, binnen de fiscale eenheid waarvan de S&O-inhoudingsplichtige deel uitmaakt, of binnen de onderneming van de S&O-belastingplichtige, is ontwikkeld en wordt toegepast. 4.5 Met de Regeling van de Minister van Economische Zaken van 8 december 2008, nr. WJZ/8171682, tot wijziging van de afbakeningsregeling 1997 (Regeling wijziging Afbakeningsregeling) wordt het begrip programmatuur per 2009 ruimer uitgelegd. Voor zover hier van belang is in de toelichting bij deze wijziging gesteld: “Tot nu toe moest er (…) sprake zijn van technische knelpunten op het niveau van de ontwikkeling van nieuwe informatietechnologische principes. Vanaf 1 januari 2009 mag het ook gaan om technische knelpunten en oplossingsrichtingen die liggen op het niveau van het integreren of met elkaar laten samenwerken van bestaande programmatuurcomponenten. (…) Om bovenbedoelde intensivering gestalte te geven, wordt tegelijk met deze regeling een beleidsregel tot stand gebracht die aangeeft dat het begrip ‘voor de S&O-inhoudingsplichtige of S&O-belastingplichtige technisch nieuwe (onderdelen van) programmatuur vanaf 1 januari 2009 ruimer zal worden uitgelegd.” 4.5 In artikel 1 van de Regeling van de Minister van Economische Zaken van 8 december 2008, nr. WJZ/8179284, houdende beleidregels inzake de uitleg technisch nieuwe programmatuur (beleidsregel uitleg technisch nieuwe programmatuur), wordt het begrip programmatuur zo uitgelegd dat daaronder ook kan worden verstaan programmatuur die bestaande programmatuur op een voor de S&O-inhoudingsplichtige of S&O-belastingplichtige technisch nieuwe wijze integreert of laat samenwerken.

In dat geval is er wel sprake van werkzaamheden ten behoeve van nieuwe programmatuur, maar niet van technisch nieuwe programmatuur. In dit kader is in de brief van 31 juli een aantal vragen gesteld, waarin juist om een toelichting gevraagd wordt. (…) De hier gevraagde informatie ontbreekt in de door u verstrekte reactie. Zonder die informatie kan ik vooralsnog niet tot de conclusie komen dat KPN binnen de beschreven UCM’s S&O-werkzaamheden verricht. Ik wil u daarom wijzen op het belang van de beantwoording van die vragen ten aanzien van de betreffenden UCM’s.” Verweerder heeft vervolgens verzocht om de in de brief van 31 juli 2014 gestelde vragen expliciet te beantwoorden. 6.6 Op 26 september 2014 hebben appellanten hierop gereageerd en de gestelde vragen per UCM beantwoord. Zo is bij UCM866 vermeld: “Doel van UCM866 was het ontwikkelen van een Dynamisch configurabele beslisomgeving op basis waarvan iTV aangeboden kon worden aan klanten van KPN. Achtergrond: KPN moet vraag en aanbod goed kunnen afstemmen. KPN wil weten welke carrier technologie bij klanten beschikbaar is om een gericht producten aan te kunnen bieden die op een bepaalde locatie ook daadwerkelijk geleverd kunnen worden waarbij KPN ook de kwaliteit kan garanderen waar zij voor staat en de klant voor betaalt. (…) De technische interafhankelijkheid van keuzes maakt dat dit niet slechts het netjes en gedegen uitschrijven van processen is, maar technische nieuwe programmatuur vereist. Bestaande en beschikbare programmatuur volstaat op geen enkel punt voor deze technische werkzaamheden en KPN moest dan ook aanvullende programmatuur schrijven om de gewenste activiteit technisch mogelijk te maken. (…) Ten aanzien van iTV, is er een groot aantal technische variabelen die bepalen hoeveel SD/HD of een combinatie hiervan een klant kan ontvangen op basis van de snelheid/dragertechnologie die bij de klant aanwezig is. (…) De carrier technologie type bepaalt wat wel/niet beschikbaar is voor een klant. Met dit als achtergrond wil KPN heel klantspecifiek producten aanbieden. (…) KPN heeft daarom een Dynamisch configurabele omgeving ontwikkeld waarin de gehele beslisboom van producten die wel/niet aangeboden kunnen worden volledig geautomatiseerd is. Het gaat daarbij dus niet om het uitschrijven van de verschillende keuzes, maar om de interafhankelijkheid van de technische systemen bij verschillende keuzes. Dit is technisch speurwerk (…)” Als concreet technisch knelpunt noemen appellanten: “(…) een omgeving te bouwen die dynamisch is. Het gaat om een omgeving die niet alleen geschreven is met de huidige bestaande technologie als uitgangspunt maar ook eventuele toekomstige technologieën (…). Dit vraag om een zeer flexibele omgeving. Hierdoor zal KPN toekomstige upgrades eenvoudig kunnen doorvoeren en zullen in de toekomst software aanpassingen niet meer nodig zijn. Technische complexiteit hierbij was dat er geen bestaande programma’s voorhanden waren waarin dit te realiseren was. KPN moest dus zelf technisch onderzoeken welke programmatuur als basis kon fungeren en hier vervolgens de interfaces en de benodigde algoritmen zelf op stellen. (…) Nu wordt er binnen KPN één leverstraat ontwikkeld voor alle carrier types. Hierbij heeft KPN besloten om de leverstraat zodanig te ontwikkelen dat er dynamische omgevingen/systemen ontstaan waardoor toekomstige technische vernieuwingen/ontwikkelen geen problemen zullen opleveren.” Appellanten hebben in hun reactie verder aangegeven dat zij de vragen onder protest hebben beantwoord, omdat zij vinden dat verweerder te veel op detailniveau vraagt en het niet mogelijk is om deze informatie voorafgaande aan een project te verstrekken. Verder vragen appellanten aan verweerder om aan te geven onder welke concrete omstandigheden programmatuurontwikkeling binnen hun bedrijfsvoering nog wel als S&O worden aangemerkt en voorbeelden daarvan te geven. 6.7 Op 10 oktober 2014 heeft verweerder appellanten gevraagd een aantal opmerkingen in de e-mail van 26 september 2014 nader te concretiseren en er daarnaast op gewezen dat een aantal opmerkingen vragen oproept, waardoor het hem onduidelijk blijft of appellanten activiteiten uitvoeren die als speur- en ontwikkelingswerk aangemerkt kunnen worden. 6.8 Hierop hebben appellanten in een brief van 2 december 2014 uiteengezet waarom zij menen dat hun werkzaamheden in de fase van het technische ontwerp van project 015 speur- en ontwikkelingswerk inhoudt en dat uitsluitend zij in die fase verantwoordelijk zijn voor het oplossen van de technische knelpunten en voorts dat: “het voor de beantwoording van de vragen (uit de brief van 31 juli 2014) voldoende zou moeten zijn dat KPN wijst op de technische knelpunten die op voorhand, voorafgaand aan de S&O, bekend konden zijn.” 6.9 In december 2014 hebben partijen contact met elkaar gehad en heeft er op 9 december 2014 een gesprek plaatsgevonden, waarbij appellanten een PowerPoint-presentatie hebben gegeven. 6.10 Verweerder heeft vervolgens in de bestreden besluiten geconcludeerd dat appellanten niet aannemelijk hebben gemaakt dat de werkzaamheden direct en uitsluitend gericht zijn op de ontwikkeling van voor hen technisch nieuwe (onderdelen van) programmatuur, zodat geen sprake is van speur- en ontwikkelingswerk. Op basis van de over project 015 verstrekt informatie stelt verweerder dat appellanten slechts specificaties van de modules in detail opstellen in de vorm van IT Quick Scans. Zoals verweerder heeft gesteld gaat het daarbij primair om het maken van keuzes, wat iets anders is dan het feitelijk oplossen van de technische problemen en het aantonen van het werkingsprinsprincipe. Met de ketentest wordt getoetst of aan de functionele specificaties wordt voldaan, maar niet of de te realiseren oplossing technisch zal voldoen. 6.11 Zoals het College eerder heeft overwogen (zie onder meer de uitspraken van 16 juni 2015, ECLI:NL:CBB:2015:213, en 22 april 2013, ECLI:NL:CBB:2013:CA2133) is het voor verweerder noodzakelijk om van de aanvrager voldoende gegevens te verkrijgen om te kunnen beoordelen of de werkzaamheden waarvoor een verklaring wordt aangevraagd al dan niet onder de werkingssfeer van de Wva ressorteren. De vraag of dat het geval is, moet worden beantwoord aan de hand van de van toepassing zijnde wet- en regelgeving en de concrete feiten en omstandigheden van het geval. Het is in beginsel aan de aanvrager om daarover duidelijkheid te verschaffen. 6.12 Verweerder heeft bij herhaling en door gerichte vraagstelling appellanten gelegenheid geboden duidelijkheid te geven in hoeverre er sprake is van technische knelpunten, technische onzekerheid en het zoeken naar een oplossing en het bewijzen van het werkingsprincipe van de oplossing door eigen personeel. In hun reactie hierop hebben appellanten zich beperkt tot het vermelden van de met project 015 beoogde ambities en de gewenste functionaliteiten. Bij de beantwoording van door verweerder gestelde vragen naar de technische knelpunten bleven appellanten verwijzen naar de eerder door hen verschafte gegevens en bleven zij steken in vaagheden zonder concreet technische knelpunten te noemen. Exemplarisch voor dit laatste is de reactie van appellanten van 26 september 2016 bij de vraag van verweerder wat concreet het technisch knelpunt is bij een van de UCM’s: “Technisch knelpunt is een omgeving te bouwen die dynamisch is. Het gaat dan om een omgeving die niet alleen geschreven is met de huidige bestaande technologie als uitgangspunt maar ook eventuele toekomstige technologieën (die dus nog onbekend zijn ). Dit vraagt om een zeer flexibele omgeving. Hierdoor zal KPN toekomstige upgrades eenvoudig kunnen doorvoeren en zullen in de toekomst software aanpassingen niet meer nodig zijn. Technische complexiteit hierbij was dat er geen bestaande programma’s voorhanden waren waarin dit te realiseren was.