Omzetbelastingwetgeving en ERP-systemen

Transcriptie

1 TECHNISCHE UNIVERSITEIT EINDHOVEN Faculteit Wiskunde en Informatica Omzetbelastingwetgeving en ERP-systemen Een overbrugbare kloof? door A.T.M. Zegers Begeleiders: Dr. J.B.M. Goossenaerts (TM-IS) Prof. mr. dr. J.M. Smits (TM-T&B) Dr. M. Voorhoeve (W&I-AIS) Drs. S. Janssen RE (KPMG IRM) Eindhoven, Januari 2007

2

3 Afstudeerverslag Omzetbelastingwetgeving en ERP-systemen Een overbrugbare kloof? door Alexander Zegers 3 januari 2007 KPMG EDP Auditors N.V. Technische Universiteit Eindhoven (TU/e) Information Risk Management Faculteit Wiskunde & Informatica Beemdstraat 1 Den Dolech MA EINDHOVEN 5612 AZ EINDHOVEN 1e begeleider TU/e: 2e begeleider TU/e: 3e begeleider TU/e: Bedrijfsbegeleider KPMG: Dr. J.B.M. Goossenaerts Prof. mr. dr. J.M. Smits Dr. M. Voorhoeve Drs. S. Janssen RE

4

5 Abstract This master thesis describes the results of a project performed at KPMG Information Risk Management. The assignment was to model the current situation of VAT-legislation and ERPsystems and design the link between those models to close an identified gap in this context. To systematically model the current VAT-ERP situation, an architecural framework is built up filled in by repository elements using a system development methodology. This VAT-ERP model can be a basis for companies to reduce VAT-risks caused in their ERPsystems. ii

6

7 Management Samenvatting Projectcontext Dit afstudeerverslag in verband met de afstemming tussen BTW en ERP richt zich op oplossingen voor bedrijven die problemen hebben om BTW-wetgeving toe te passen in hun ERP-systemen. ERP-systemen ondersteunen de wisselwerkingen tussen marktspelers en moeten ingericht zijn op beperkingen die op worden gelegd door instituties belichaamd in BTW-wetgeving. De projectcontext kan worden voorgesteld als een driehoek met een vraag-aanbod zijde (bedrijven) en overstaande hoek instituties (BTW-wetgeving). Technologie (ERP-systemen) ondersteunen de interacties. Opdrachtomschrijving KPMG Information Risk Management (IRM) heeft bij een aantal ERP-systeem audits geobserveerd dat BTW-inrichting onvoldoende prioriteit krijgt waardoor BTW-bepaling niet altijd correct verloopt. Er is onvoldoende inzicht in de manier waarop BTW-bepaling worden toegepast door het ERP-systeem bij ingewikkelde vraag- en aanbod interacties (inkoop en verkoop). Er is een kloof geïdentificeerd tussen enerzijds ERP-systemen die vraag- en aanbod interacties ondersteunen en anderzijds instituties belichaamd in BTW-wetgeving die regels opleggen aan het gedrag van ERP-systemen. De opdrachtomschrijving voor dit afstudeeronderzoek die deze problematiek aan moet pakken is tweeledig: 1. Geef een modelsgewijze beschrijving van de huidige situatie met betrekking tot de vraagen aanbod interacties ondersteund door ERP-systemen en de beperkingen die hieraan op worden gelegd door BTW-wetgeving. Breng vervolgens de bestaande kloof in kaart. 2. Breng de door het ERP-systeem ondersteunde vraag- en aanbod interacties in overeenstemming met de door BTW-wetgeving opgelegde beperkingen middels het ontwerp van een Computation Independent BTW-ERP model (CIM) en implementeer het BTW-ERP model voor een specifiek ERP-systeem. Hiermee wordt de kloof gedicht. Aan deze opdrachtomschrijving zijn de volgende onderzoeksdoelstellingen gekoppeld: Verkrijging van inzicht in de aspecten van BTW-wetgeving en de huidige BTWbepalingsregels binnen ERP systemen. Vinden van een geschikte methodologie voor het beschrijven van de huidige situatie met betrekking tot de BTW-ERP context en het modelsgewijs beschrijven van de huidige situatie met behulp van de gekozen methodologie waarmee de aanwezige kloof in kaart wordt gebracht. iv

8 MANAGEMENT SAMENVATTING v Ontwerpen van een Computation Independent BTW-ERP model dat de brug vormt tussen de BTW-bepaling binnen ERP-systemen en BTW-wetgeving waarmee de huidige kloof wordt overbrugd. Vertaling van het Computation Independent Model (CIM) naar een Platform Specific Model (PSM) dat de implementatie voor een specifiek ERP-systeem vastlegt. Geven van aanbevelingen over de toepasbaarheid van het ontwerp met betrekking tot serviceproducten van KPMG Als onderzoeksmethodologie is gekozen voor de regulatieve cyclus [Strien van, 1975] waarin achtereenvolgens de volgende fasen worden doorlopen: oriëntatie, analyse, ontwerp, implementatie en evaluatie. Omdat de projectcontext is ingevuld op verschillende niveaus, is gekozen voor een onderscheid in schalen op basis waarvan de cyclus wordt doorlopen. Op macro-schaal wordt de markt beschreven waarvoor BTW-wetgeving de regels voorschrijft en de Belastingdienst als uitvoerend orgaan optreedt. Op meso-schaal bevinden zich de bedrijven die moeten voldoen aan regels die hen worden opgelegd. De micro-schaal wordt ingevuld door personen die BTW-regels implementeren in ERP-systemen. Analyse Tijdens de analyse is de huidige situatie van BTW-wetgeving en de toepassing ervan in ERPsystemen beschreven en is de BTW-ERP context geanalyseerd om gefundeerde ontwerpeisen op te stellen. De huidige situatie is modelsgewijs beschreven. Voor de macro- en meso-schaal is het 3-V model [Goossenaerts, 2006b] ingevuld voor wat betreft strategie (waarde- en risico model) (1-V) en operationele processen (2-V). Hierbij is een markt- en bedrijfsrepository is ingevuld op basis van de COMETrepositorystructuur [Berre et al., 2004]. De opbouw van de Wet op de Omzetbelasting [WetOB, 1968] is stap voor stap beschreven en gekoppeld aan een marktdomeinmodel (MDM) dat opgesteld is voor de BTW-ERP situatie. Hierbij zijn stapsgewijs BTW-determinanten afgeleid die volgen uit de regels die de Wet OB voorschrijft. BTW-determinanten zijn variabelen met een vaste semantiek binnen BTW-wetgeving die ingevuld worden door specifieke bedrijfsprocessen en een vaste invulling geven aan de configuratie van ERP-systemen. De BTW-determinanten vormen een koppeling tussen BTW-wetgeving en de ERP-configuratie, zie bovenstaande figuur. In totaal zijn achttien BTW-determinanten gedefinieerd die invloed v

9 vi MANAGEMENT SAMENVATTING hebben op de wijze waarop BTW moet worden bepaald. Vanuit een bedrijfsdomeinmodel (BDM) is het omzetgenererend bedrijfsproces beschreven dat BTW-verplichting veroorzaakt en mede de invulling van de BTW-determinanten bepaalt. Voor het ERP-systeem SAP R/3 is de BTW-bepaling beschreven. Het standaard BTWbepalingsproces binnen SAP maakt gebruik van drie BTW-determinanten. Eenvoudige veelvoorkomende BTW-stromen worden hiermee afgedekt, maar ingewikkelde grensoverschrijdende BTW-transacties verlopen niet correct met deze standaard bepalingsregels. Hiermee is een kloof tussen BTW-wetgeving en BTW-bepalingsregels geïdentificeerd. De analyse van de BTW-ERP context beschrijft de gevolgen van de kloof voor de stakeholders in de BTW-ERP context. Het ontwerp dat de kloof moet dichten moet voldoen aan een aantal ontwerpeisen: Het ontwerp moet implementatie-onafhankelijk zijn. Het ontwerp moet gepositioneerd zijn tussen BTW-wetgeving en ERP-systemen. Het ontwerp moet flexibel zijn. Het ontwerp moet correct zijn. Het ontwerp moet waarde toevoegen voor alle stakeholders. Ontwerp Het BTW-ERP model dat BTW-wetgeving uitvoerbaar maakt voor ERP-systemen bevat een beslissingsmodel dat gestuurd wordt door de geïdentificeerde BTW-determinanten. Voor een BTW-transactie beslist dit model welk BTW-patroon van toepassing is. Een BTW-patroon is een gezamenlijke groep van invullingen van BTW-determinanten waarbinnen BTW-transacties vallen die dezelfde eigenschappen met betrekking tot de BTW hebben. Voor elk BTW-patroon is een nieuw beslissingsmodel ontworpen dat leidt tot de BTW-eisen voor de transactie binnen dat BTW-patroon. De BTW-eisen voor de transactie bepalen het gedrag van het ERP-systeem doordat ze gestuurd worden vanuit BTW-determinanten waarmee in het ERP-systeem BTW-bepalingsregels kunnen worden opgesteld. Flexibiliteit is een belangrijke eis aan het BTW-ERP model. De kennisvastlegging in het BTW- ERP model stelt de eindgebruikers in staat om het model bij omgevingsveranderingen zodanig aan te passen dat het voldoet aan de eisen van de nieuwe omstandigheden. Bij wijziging (performance alert) in de BTW-ERP context worden projecten opgestart door de stakeholders die vastgelegd zijn in project charters. In een project charter worden stakeholderspecifieke doelen van elk project vastgesteld. Voor een BTW-verandering als performance alert is vastgesteld welke project charters worden opgestart om het BTW-ERP model aan te passen aan de ontstane situatie. Implementatie De implementatie bestaat uit een tweetal realisaties. Enerzijds de vertaling van het Computation Independent BTW-ERP model (CIM) naar een Platform Specific BTW-ERP model (PSM). Anderzijds de ontwikkeling van een BTW-ERP service voor KPMG met de opgedane kennis en verkregen inzichten. vi

10 MANAGEMENT SAMENVATTING vii De stappen voor de vertaling van het CIM naar het PSM zijn beschreven in een implementatieplan dat uitgaat van drie fasen: training, conversie en acceptatie [Whitten et al., 2004]. De invulling voor de BTW-ERP context is beschreven voor elk van deze drie fasen. Dit is geïllustreerd aan de hand van een voorbeelduitwerking voor een BTW-patroon. Aan de hand van een waarde- en risicoanalyse voor het BTW-ERP model is geconcludeerd dat het ontwerp waardetoevoeging voor alle stakeholders oplevert als er onderlinge kennissamenwerkingen worden aangegaan. De ontwikkeling van een BTW-ERP service voor KPMG is voorgesteld als een nuttig vervolgonderzoek. Conclusies en Aanbevelingen Het eindresultaat is getoetst aan de onderzoeksdoelstellingen die vooraf zijn opgesteld en er is geconcludeerd dat aan deze doelstellingen is voldaan met de kanttekening dat geen daadwerkelijke implementatie is uitgevoerd maar afgesloten is met een implementatieplan. De eindconclusies zijn opgesteld voor de macro- en meso-schaal in de BTW-ERP context. De aanbevelingen zijn gericht aan KPMG. Macro-schaal Bedrijven zijn in toenemende mate afhankelijk van ERP-systemen voor het leveren van concurrentiële prestaties. Het configureren van ERP-systemen op basis van het raamwerk van voorwaarden opgesteld door BTW-wetgeving en Belastingdienst gebeurt niet feilloos, met name voor ingewikkelde grensoverschrijdende BTW-transacties. Het invullen van een markt- en een bedrijfsrepository met deliverables vanuit COMETmodellen is een geschikte methodiek voor het beschrijven van de BTW-ERP situatie. Meso-schaal Het BTW-ERP CIM verhoogt het inzicht in mogelijkheden om het risico op boetes van uitvoerende instanties en het betalen van dubbele belastingen te verlagen. Bij ERP-implementatietrajecten moet BTW-inrichting hogere prioriteit krijgen en niet als standaard worden beschouwd. Het BTW-ERP CIM kan door bedrijven (in de toekomst) worden ingezet als proof of VAT-compliance richting uitvoerende instanties van wetgeving. Aanbevelingen KPMG Implementatie van het BTW-ERP CIM als kennisvermogen ter ondersteuning van een BTW-ERP kloof overbruggende adviesdienst (serviceblauwdruk) op basis van de resultaten van dit onderzoek. Opzetten van een BTW-ERP groep die het BTW-ERP CIM als adviesdienst in kan zetten bij klanten. Aangaan van samenwerkingen met andere partijen als ERP-vendors en de Belastingdienst. vii

11 Voorwoord Voor u ligt het eindrapport van mijn afstudeeronderzoek ter afsluiting van de studie Technische Informatie aan de Technische Universiteit Eindhoven (TU/e). Het afstudeeronderzoek is uitgevoerd binnen de faculteit Technologie Management, capaciteitsgroep Information Systems. In opdracht van KPMG Information Risk Management is de problematiek van omzetbelastingwetgeving binnen ERP-systemen in kaart gebracht en aangepakt. De interesse voor een afstudeeropdracht in een bedrijfskundige omgeving is gedurende mijn studententijd gegroeid. Het bestuursjaar bij UniPartners Eindhoven is zonder twijfel het meest leerzame en mooiste jaar van de afgelopen zes-en-een-half jaar geweest. Als financial manager bij UniPartners is tevens mijn interesse gewekt voor fiscale aspecten binnen bedrijven. De afstudeeropdracht bij KPMG was een perfecte mix tussen informatica-, bedrijfskundige- en fiscale aspecten. Deze kans heb ik dan ook met beide handen aangegrepen. De afgelopen 11 maanden zijn enorm uitdagend geweest en ik wil hierbij een aantal personen bedanken die mij gedurende deze periode hebben begeleid en ondersteund. Ik wil Jan Goossenaerts bedanken voor zijn constructieve commentaar tijdens onze besprekingen en goede begeleiding. Hoewel ik na onze besprekingen vaak meer vragen had dan ervoor, heeft dit ertoe geleid dat de resultaten van dit onderzoek in een veel breder perspectief kunnen worden geplaatst. Jan Smits en Marc Voorhoeve wil ik bedanken voor hun opbouwende commentaar en zitting in de examencommissie. Ik heb in een ontzettend leerzame en plezierige bedrijfsomgeving kunnen werken waarvoor ik mijn toekomstige collega s bij KPMG IRM wil bedanken. Peter Paul Brouwers en Stephen van den Biggelaar wil ik graag bedanken voor het beschikbaar stellen van de stageplaats bij KPMG. Daarnaast in het bijzonder Stephan Janssen voor de goede begeleiding en Anton Lissone en Leo van Loo voor hun inhoudelijke bijdrage op respectievelijk SAP- en BTW-gebied. Daarom verheug ik me erop om met de resultaten van dit onderzoek verder te werken aan de opbouw van een TAX-IT service binnen IRM Zuid. Tenslotte wil ik mijn ouders, broer en in het bijzonder Carina bedanken voor de onvoorwaardelijke steun die ik altijd heb gekregen, ook als de kloof tussen mijn perfectionisme en afstuderen onoverbrugbaar leek te worden. Alexander Zegers Eindhoven, december 2006 viii

12

13 Lijst van figuren 2.1 Projectfocus: Vraag-Aanbod-Instituties De regulatieve cyclus als onderzoeksmethodologie Het 3-V model COMET repositorystructuur voor macro- en meso-schaal Opbouw verslag Generiek domeinmodel marktcontext Koppeling tussen BTW en ERP Domeinmodel BTW-ERP context Voorbeeld van een driehoekstransactie Bedrijfsdomein BTW-ERP context BTW-plicht in de waardeketen Economic activity bij BTW-berekening Pricing in SAP Toepassing van condition technique bij een sales order Werking van condition type MWST Schematisch overzicht analyse BTW-ERP context Interrelationship Digraph - Probleemgerichte oorzaken Interrelationship Digraph - Deugdzame keten van oorzaken Systeemgrenzen van het BTW-ERP model Gedeelte uit het Pattern Determination Model Typologie 1 - BTW-patroon 1b Uitwerking BTW-patroon Gezamenlijke systeemlevenscycli BTW-ERP context Vraag- en aanbod interacties BTW-ERP BTW-ERP interacties instituties Projectcharters bij BTW-verandering Plaats van levering in het marktdomeinmodel Transformatie van CIM naar PSM Aangepast condition type MWST A.1 Organigram KPMG Holding N.V B.1 Vier perspectieven van de Balanced Scorecard x

14 LIJST VAN FIGUREN xi C.1 Bepaling categorie belastingplichtige D.1 3-laagse client-server architectuur D.2 Modules binnen SAP R/ D.3 Overzicht organisatie-eenheden binnen FI-CO E.1 FAST fasen bij systeemontwikkeling E.2 COMET repositorystructuur F.1 Opbouw en totstandkoming Wet OB F.2 Stakeholders bij implementatie ERP-systemen G.1 Market Value Exchange Model H.1 Principal Model - Civil and Public Agents H.2 Market Asset- & Resource Model H.3 Interaction Refinement Model J.1 Community Model J.2 Work Refinement Model: VAT-duty in value chain J.3 Work Refinement Model: Economic activity VAT-calculation K.1 Systeemgrenzen van het BTW-ERP model xi

15 Lijst van tabellen 4.1 Overzicht BTW-determinanten Kernoorzaken BTW-ERP Problemen (P) en Opportunities (O) Project charter Belastingdienst Project charter ERP-bedrijven (I) Project charter ERP-bedrijven (II) Project charter ERP-vendors Project charter KPMG Onderzoeksresultaten gekoppeld aan marktrepository (VARM en WOM) Onderzoeksresultaten gekoppeld aan bedrijfsrepository (VARM, WOM en CRM) Alignment onderdelen gekoppeld aan onderzoeksresultaten - Bijlage L Gezamenlijke invulling BTW-determinanten BTW-patroon 1b Specifieke invulling determinanten BTW-patroon 1b A.1 Kerncijfers KPMG C.1 Geheel meermalig, niet-cumulatief stelsel met voorbelasting C.2 Overzicht landen en gebieden EU C.3 BTW-eisen G.1 Balanced Scorecard Omzetbelastingwetgeving G.2 Balanced Scorecard De Belastingdienst G.3 Market Value Exchanges & Risks I.1 Balanced Scorecard Bedrijven (ERP-gebruikers) I.2 Balanced Scorecard ERP-Vendors K.1 Description Use Case 1: VAT change K.2 Description Use Case 2: Create sales order L.1 Overview VAT determinants

16

17 Lijst van gebruikte afkortingen ANT BDM BSC BTW CCM CIM COMET CRM EDP ERP EU FAST ICL ICTA ICV ID IRM MDM MRP-I MRP-II OB OCL PA PC PDM PPM PSM REA RRR TU/e UCD UML VARM VAT WOM Actor-Network Theory Business Domain Model Balanced Scorecard Belasting over de Toegevoegde Waarde Cumulative Component Model Computation Independent Model Component and Model-based development Methodology Cumulative Requirements Model Electronic Data Processing Enterprise Resource Planning Europese Unie Framework for the Application of System Techniques Intracommunautaire levering ICT Architectures Intracommunautaire verwerving Interrelationship Digraph Information Risk Management Market Domain Model Material Requirements Planning Manufacturing Resources Planning Omzetbelasting Object Constraint Language Performance Alert Project Charter Pattern Determination Model Product Portfolio Management Platform Specific Model Resources, Events, Agents Restrictions, Rights, Responsibilities Technische Universiteit Eindhoven Use Case Diagram Unified Modeling Language Value and Risk Model Value Added Tax Worksystem Operations Model xiv

18

19 Inhoudsopgave Abstract Management samenvatting Voorwoord Lijst van figuren Lijst van tabellen Lijst van gebruikte afkortingen Inhoudsopgave ii iv viii x xi xiii xv I Oriëntatie 2 1 Inleiding 4 2 Projectcontext Aanleiding Projectfocus Stakeholders Probleemstelling en opdrachtomschrijving Onderzoeksmethodologie Onderzoeksdoelstellingen Schalen in projectcontext Methodologie Onderzoeksfasering Opbouw verslag II Analyse 20 4 Beschrijving huidige BTW-ERP situatie Belasting over de Toegevoegde Waarde (BTW) BTW in Bedrijfsprocessen Enterprise Resource Planning Systemen Samenvatting xvi

20 INHOUDSOPGAVE xvii 5 Analyse BTW-ERP context Stakeholderanalyse Oorzaak- en gevolg analyse Ontwerpeisen III Ontwerp 54 6 Onderzoeksontwerp Ontwerp van het BTW-ERP model Flexibiliteit BTW-ERP model Waardetoevoeging BTW-ERP model Repository invulling IV Implementatie & Evaluatie 72 7 Realisatie Implementatieplan Training Conversie Acceptatie Samenvatting Conclusies en Aanbevelingen Beantwoording aan onderzoeksdoelstellingen Conclusies Aanbevelingen KPMG Suggesties voor vervolgonderzoek Bibliografie 90 V Bijlagen 92 A Bedrijfsbeschrijving KPMG 94 A.1 KPMG Nederland A.2 Kerncijfers A.3 Organigram A.4 Markten A.5 Service Lines B Methodieken Probleemanalyse 98 B.1 De Balanced Scorecard B.2 Actor-Network Theory C Wet op de Omzetbelasting 102 C.1 Opbouw Wet OB C.2 Heffingsstelsel C.3 Bepaling Belastingplichtige xvii

21 xviii INHOUDSOPGAVE C.4 Lidstaten Europese Unie C.5 Factuurvereisten BTW D SAP R/3 108 D.1 Architectuur D.2 Modules D.3 Organisatiestructuur E Systeemontwikkeling 112 E.1 FAST E.2 COMET F Resultaten Probleemanalyse 114 VI Repository invulling 120 G Marktrepository: Market Value and Risk Model (1-V) 122 G.1 Mission Statement G.2 Market Indicator Register G.3 Market Value & Risk Register H Marktrepository: Market Worksystem Operations Model (2-V) 128 H.1 Principal Model H.2 Market Asset- & Resource Model H.3 Interaction Refinement Model I Bedrijfsrepository: Business Value and Risk Model (1-V) 132 I.1 Business Mission Statement I.2 Business Indicator Register J Bedrijfsrepository: Business Worksystem Operations Model (2-V) 136 J.1 Community Model J.2 Work Refinement Model K Bedrijfsrepository: Business Cumulative Requirements Model (3-V) 140 K.1 Work Refinement Specification VII Repository alignment 142 L Alignment Marktrepository Bedrijfsrepository 144 L.1 VAT-determinants L.2 VAT-determinant filling-in L.3 VAT determinants ERP-system (SAP) L.4 Work Refinement Model Domain models L.5 Pattern Determination Model L.6 Pattern Elaboration L.7 VAT requirements elaboration xviii

22

23 Deel I Oriëntatie 2

24

25 Hoofdstuk 1 Inleiding Enterprise Resource Planning (ERP) systemen vormen een belangrijke familie van applicatiesoftware. In ERP-systemen zijn applicaties voor financiën, productie, planning, verkoop, inkoop en logistiek die voorheen gescheiden werden toegepast, geïntegreerd tot één integraal systeem. ERP-systemen bieden ondersteuning aan bedrijfsprocessen en worden via maatwerk gecustomized voor specifieke bedrijfsomgevingen. Deze ERP-implementatietrajecten zijn omvangrijk en duren maanden tot zelfs jaren. Een risico dat hierbij optreedt is dat de implementatie teveel vanuit de mogelijkheden van het ERP-pakket worden benadrukt en te weinig vanuit de bedrijfsdoelstellingen die organisaties ermee hebben en de processen die ze moeten ondersteunen. Hierdoor wordt de oorspronkelijke insteek van de inzet van het ERP-systeem uit het oog verloren waardoor bedrijfsdoelstellingen niet gehaald worden. Belasting over de Toegevoegde Waarde (BTW) is een vorm van belasting waar alle bedrijven mee te maken hebben. Bij het verrichten van belastbare prestaties moet een vast percentage van de vergoeding aan belasting worden betaald. BTW-wetgeving is vastgelegd in een Europese Richtlijn waaraan alle Lidstaten hun nationale wetgeving moeten conformeren. Deze Zesde Richtlijn [EEG, 1977] laat ruimte aan de Lidstaten om een aantal bepalingen zoals tarief en productclassificaties zelf in te vullen. BTW-bepaling zit verankerd in meerdere bedrijfsprocessen. BTW moet op de factuur worden vermeld door de afzender. Facturen worden automatisch gegenereerd door het ERPsysteem en BTW-bepaling vindt plaats op basis van gegevens die in het ERP-systeem aanwezig zijn. Met deze gegevens bepaalt het ERP-systeem de BTW die op de factuur wordt vermeld. Hierbij moet navolging worden gegeven aan de regels die door nationale wetgeving worden voorgeschreven. KPMG Information Risk Management heeft bij audits van grote ERP-omgevingen geobserveerd dat inrichting met betrekking tot BTW-bepaling lang niet altijd optimaal is. Bedrijven weten dit vaak niet omdat BTW slechts een klein onderdeel van de ERP-inrichting betreft. In dit afstudeeronderzoek wordt beschreven hoe ERP-systemen op dit moment omgaan met bepaling van BTW en wordt op een systematische manier een kloof tussen ERP-systemen en uitvoerbaarheid van BTW-wetgeving vastgesteld. Deze kloof wordt overbrugd door de ontwikkeling van een model dat het gedrag van BTW-wetgeving volgt en implementeerbaar is in ERP-systemen.

26

27 Hoofdstuk 2 Projectcontext 2.1 Aanleiding Wetten en regels leggen leefregels binnen onze samenleving vast. Een belangrijk aspect hierbij is het principe van eenduidigheid. Dubbelzinnigheden en onnauwkeurigheden zorgen voor verwarring en onduidelijkheid. Natuurlijke taal is gekozen als communicatiemiddel tussen zender en ontvanger, tussen wetgever en burger. Belastingwetgeving is een stelsel van regels en bepalingen dat betrekking heeft op de heffing van belastingen. Belasting over de Toegevoegde Waarde (BTW) is een indirecte belasting die bedrijven of particulieren moeten heffen bij het verrichten van leveringen of diensten. Grote ondernemingen zetten ERP-systemen in ter ondersteuning van bedrijfsprocessen als inkoop, verkoop, financiële rapportages en beheersing van voorraden. ERP-systemen moeten zodanig worden geconfigureerd dat ze ondersteuning bieden aan processen die specifiek voor dat bedrijf gelden. Bepaling van BTW is een activiteit die in meerdere bedrijfsprocessen terugkomt. Doordat ERP-systemen vaak worden geconfigureerd door technische specialisten die minder kennis hebben van fiscale aspecten, faciliteert de ERP-configuratie de BTW-bepaling niet altijd optimaal. De impact hiervan is aanzienlijk doordat het hoge tarief waar de meeste leveringen en diensten onder vallen meestal rond de 20% van de belastbare vergoeding ligt. Bij te weinig betalen ontstaan risico s op boetes van uitvoerende instellingen. Het correct configureren van het ERP-systeem met betrekking tot BTW-bepaling verhoogt de BTW-compliance van bedrijven zodat risico s op boetes en betalen van dubbele belastingen worden verlaagd. De initiële probleemstelling wordt als volgt geformuleerd: De configuratie van ERP-systemen faciliteert BTW-bepaling vaak niet optimaal waardoor risico s op dubbele belastingen en boetes van uitvoerende instellingen ontstaan. Risico s op dubbele belastingen en boetes kunnen vermeden worden door ERP-systemen zodanig te configureren dat BTW-bepaling correct wordt uitgevoerd. Door de huidige situatie van BTW-bepaling in ERP-systemen in kaart te brengen en te analyseren wat problemen oplevert, kunnen oplossingen worden ontworpen om de problematiek op te lossen. De initiële opdrachtomschrijving luidt als volgt: Het modelsgewijs beschrijven van de huidige situatie van BTW-bepaling in ERPsystemen, het genereren van een oplossingsrichting voor de gevonden problemen en het ontwerpen en implementeren van deze oplossingsrichting. 6

28 2.2. PROJECTFOCUS 7 Deze initiële opdrachtomschrijving is na afloop van de oriëntatiefase aangepast aan de nieuwe inzichten die uit de projectfocus verkregen zijn. 2.2 Projectfocus De probleemstelling is ontstaan uit het vermoeden van KPMG dat de configuratie van ERPsystemen met betrekking tot BTW-bepaling niet naadloos aansluit bij de regels die vanuit BTW-wetgeving worden voorgeschreven. In Figuur 2.1 is de projectfocus van dit onderzoek weergegeven. Hierbij worden drie foci onderscheiden: (1) vraag zijde, (2) aanbod zijde en (3) institutie zijde [Morioka et al., 2006]. Figuur 2.1: Projectfocus: Vraag-Aanbod-Instituties Uit: [Morioka et al., 2006] (vereenvoudigd) Tussen vraag- en aanbod zijde vinden interacties plaats die onder hierop ingerichte instituties zo optimaal mogelijk moeten plaatsvinden. Interacties bestaan uit in- en verkoopprocessen waarbij belastbare prestaties worden verricht waarop BTW van toepassing is. De rol van instituties wordt in de BTW-ERP context ingevuld door BTW-wetgeving en de Belastingdienst. Deze instituties leggen beperkingen op aan de wisselwerkingen tussen vraagen aanbod zijde. Technologie is een middel om de wisselwerkingen tussen vraag- en aanbod zijde efficiënter te laten verlopen. Bedrijven bevinden zich aan de vraag zijde. Deze bedrijven verrichten belastbare prestaties waarbij ERP-systemen ter ondersteuning worden gebruikt. ERP-systemen vervullen de rol van technologie in dit onderzoek. Het leveren van prestaties door ondernemingen is belast met BTW. BTW-wetgeving legt afdwingbare beperkingen op aan deze belastbare prestaties. Deze beperkingen moet op één lijn zijn met de BTW-bepalingsregels die in bedrijfsprocessen gehanteerd worden. Waar ERPsystemen gebruikt worden ter ondersteuning van de bedrijfsprocessen ontstaat een probleemveld (het rode vlak): zijn de BTW-bepalingsregels nauwkeurig vastgelegd in het systeem? Indien dit zo is, dan verschuiven de interacties tussen vraag- en aanbod zijde van het rode naar het groene vlak. In de huidige situatie liggen de beperkingen die BTW-wetgeving oplegt niet op één lijn met de BTW-bepalingsregels binnen ERP-systemen. Ingewikkelde goederenstromen waarbij belastbare prestaties worden verricht vereisen specifieke regels aan ERP-systemen opgelegd vanuit BTW- 7

29 STAKEHOLDERS wetgeving. In de beschrijving van de huidige situatie zal blijken dat de BTW-bepaling in een aantal veelvoorkomende gevallen niet correct verloopt. De ERP-ondersteunde wisselwerkingen tussen vraag- en aanbod zijde bevinden zich links in het rode vlak. Er is een kloof (zie Figuur 2.1) tussen deze wisselwerkingen en de beperkingen die BTW-wetgeving hieraan oplegt. Door BTW-bepalingsregels in ERP-systemen zo af te leiden dat deze in overeenstemming zijn met de beperkingen die vanuit BTW-wetgeving worden voorgeschreven wordt de kloof tussen ERP en BTW gedicht. 2.3 Stakeholders De stakeholders in deze projectcontext worden hieronder kort beschreven. In de probleemanalyse van de huidige situatie wordt uitvoeriger ingegaan op de stakeholders BTW-wetgeving Belasting over de Toegevoegde Waarde (BTW) is onderdeel van het Nederlandse belastingstelsel en wordt ook vaak als omzetbelasting aangeduid. Wetgeving omtrent BTW is vastgelegd in de Wet op de Omzetbelasting (Wet OB) [WetOB, 1968]. De BTW-inkomsten zijn na de inkomsten uit de inkomstenbelasting de grootste vorm van belastinginkomsten in Nederland [Belastingdienst, 2005b]. BTW kenmerkt zich door het feit dat het een algemene verbruiksbelasting is. BTW beoogt al het verbruik van particulieren en ondernemingen in de heffing te betrekken. Daarnaast is het een indirecte belasting. De heffing vindt niet direct bij de gebruiker plaats maar bij diens toeleverancier De Belastingdienst De Belastingdienst is de uitvoerende instantie van BTW-wetgeving. Zij is verantwoordelijk voor het innen en uitkeren van belastinggelden. De belastingdienst hecht er waarde aan dat ondernemingen gemakkelijk en accuraat hun belastingaangifte kunnen doen en dat de bereidheid van burgers en instellingen tot correcte aangifte wordt vergroot [Belastingdienst, 2005b]. Op deze manier worden belastingcontroles gemakkelijker uitvoerbaar en kan op termijn het aantal controles worden verminderd ERP-gebruikers Onder ERP-gebruikers worden bedrijven verstaan die ERP-systemen inzetten ter ondersteuning van de bedrijfsvoering en optimalisatie van de bedrijfsprocessen. Wanneer deze ondernemingen een ingewikkelde organisatiestructuur hebben en het ERP-systeem op meerdere plaatsen is geïnstalleerd wordt het optimaal uitvoeren van een BTW-strategie een ingewikkelde zaak. Naast de organisatiestructuur speelt de supply chain waarin de onderneming opereert een rol bij de impact die BTW heeft op de organisatie. Voor ingewikkelde goederenstromen verspreid over meerdere landen is geen standaardproces gedefinieerd binnen ERP-systemen waardoor maatwerk vereist is. 8

30 2.4. PROBLEEMSTELLING EN OPDRACHTOMSCHRIJVING BTW-ERP specialisten De samenwerking tussen KPMG Information Risk Management (IRM) en KPMG Meijburg & Co. leidt tot een specialisatie op het snijvlak van ERP en belastingen. ERP-kennis wordt geleverd door adviseurs van KPMG IRM en fiscale kennis is een specialisatie van KPMG Meijburg. KPMG Information Risk Management KPMG Information Risk Management (IRM) is onderdeel van Risk Advisory Services (RAS) van KPMG en voorziet in beoordelings- en adviesdiensten om klanten te helpen bij het identificeren van risico s en het bewerkstelligen van kennis bij het gebruik van informatiesystemen en informatietechnologie. Hierbij speelt het minimaliseren, beheersen en managen van risico s op het gebied van informatie een centrale rol. IRM adviseert klanten op het gebied van ICT zodat deze maximaal bijdraagt aan de bedrijfsvoering en het eindresultaat van de klant. Electronic Data Processing (EDP)-auditing speelt hierbij een centrale rol. EDP-auditing is het onafhankelijk en onpartijdig beoordelen van de betrouwbaarheid, beveiliging, effectiviteit en efficiency van geautomatiseerde informatiesystemen, de organisatie van de automatiseringsafdeling en de technisch/organisatorische infrastructuur van de geautomatiseerde gegevensverwerking [Praat van and Suerink, 2003]. KPMG Meijburg & Co. KPMG Meijburg & Co. is de belastingadviestak van KPMG Nederland. Sinds 1988 maakt zij onderdeel van uit van KPMG. In Nederland telt KPMG Meijburg ruim 450 professionals verdeeld over 15 vestigingen. Er wordt geopereerd in nagenoeg alle marktsegmenten, zoals automotive, energie, financial services en transport. Tot haar cliëntenkring kan KPMG Meijburg zowel nationale als multinationale klanten rekenen. ERP-specialisten Naast de specifieke BTW-ERP specialisten kunnen de ERP-ontwikkelaars die verantwoordelijk zijn voor de fiscale onderdelen van het ERP-systeem ook tot deze groep stakeholders worden gerekend. ERP-specialisten maken onderdeel uit van de grotere ERP-leveranciers als SAP en Oracle. 2.4 Probleemstelling en opdrachtomschrijving De rol van instituties binnen de maatschappij is in de beschrijving van de projectfocus uiteengezet: het opleggen van beperkingen op interacties tussen vraag- en aanbod zijde. In deze projectcontext moeten BTW-bepalingsregels binnen ERP-systemen op één lijn zijn met de beperkingen die BTW-wetgeving hieraan oplegt. In Figuur 2.1 is dit op één lijn brengen aangegeven met het groene oppervlak. Er heerst een gevoel dat dit in de huidige situatie niet plaatsvindt waardoor een kloof ontstaat tussen deze interacties en de beperkingen opgelegd door instituties. De uiteindelijke probleemstelling wordt als volgt geformuleerd: BTW-bepaling binnen ERP-systemen is niet op één lijn met de beperkingen opgelegd vanuit BTW-wetgeving waardoor een kloof ontstaat tussen enerzijds de ERP-systemen die vraag- en aanbod interacties ondersteunen en anderzijds instituties belichaamd in 9

31 PROBLEEMSTELLING EN OPDRACHTOMSCHRIJVING de BTW-wetgeving. Voor bedrijven ontstaan hierdoor risico s op boetes en betalen van teveel belasting. De kloof tussen vraag- en aanbod zijde en instituties moet worden gedicht. Een BTW-ERP model dicht deze kloof. Het BTW-ERP model moet toepasbaar zijn voor elk ERP-systeem en moet daarom Computation Independent zijn. De opdrachtomschrijving voor de aanpak van de probleemstelling is tweeledig: (I) Geef een modelsgewijze beschrijving van de huidige situatie met betrekking tot de vraag- en aanbod interacties ondersteund door ERP-systemen en de beperkingen die hieraan op worden gelegd door BTW-wetgeving. Breng vervolgens de bestaande kloof in kaart. (II) Breng de door het ERP-systeem ondersteunde vraag- en aanbod interacties in overeenstemming met de door BTW-wetgeving opgelegde beperkingen middels het ontwerp van een Computation Independent BTW-ERP model en implementeer het BTW-ERP model (CIM) voor een specifiek ERP-systeem. Hiermee wordt de kloof gedicht. In het volgende hoofdstuk worden aan deze probleemstelling onderzoeksdoelstellingen gekoppeld die deze probleemstelling aan moeten pakken. De onderzoeksdoelstellingen worden onderbouwd met het onderzoeksmodel dat de basis vormt voor de inrichting van dit afstudeeronderzoek. 10

32

33 Hoofdstuk 3 Onderzoeksmethodologie In het vorige hoofdstuk zijn de probleemstelling en opdrachtomschrijving voor dit afstudeeronderzoek beschreven. Er is aangegeven dat er een kloof is tussen BTW-bepalingsregels binnen ERP-systemen en de beperkingen die BTW-wetgeving oplegt aan vraag- en aanbod interacties. In dit hoofdstuk worden de onderzoeksdoelstellingen en onderzoeksopzet voor het ontwerponderzoek beschreven. 3.1 Onderzoeksdoelstellingen De onderzoeksdoelstellingen moeten een oplossing bieden voor de probleemstelling die gedefinieerd is in Hoofdstuk 2.4. De doelstelling van dit onderzoek is onder te verdelen in de volgende onderdelen: 1. Verkrijging van inzicht in de aspecten van BTW-wetgeving en de huidige BTWbepalingsregels binnen ERP systemen. 2. Vinden van een geschikte methodologie voor het beschrijven van de huidige situatie met betrekking tot de BTW-ERP context en het modelsgewijs beschrijven van de huidige situatie met behulp van de gekozen methodologie waarmee de aanwezige kloof in kaart wordt gebracht. 3. Ontwerpen van een Computation Independent BTW-ERP model dat de brug vormt tussen de BTW-bepaling binnen ERP-systemen en BTW-wetgeving waarmee de huidige kloof wordt overbrugd. 4. Vertaling van het Computation Independent Model (CIM) naar een Platform Specific Model (PSM) dat de implementatie voor een specifiek ERP-systeem vastlegt. 5. Geven van aanbevelingen over de toepasbaarheid van het ontwerp met betrekking tot serviceproducten van KPMG. De onderzoeksdoelstellingen worden uitgewerkt door een onderzoeksmethodologie te kiezen die de inrichting en het proces van het onderzoek vastlegt. Aangezien er meerdere stakeholders gedefinieerd zijn wordt een methodologie gekozen waarbij aandacht moet worden besteed aan alle stakeholders. Daarom worden de stakeholders eerst op schaal-niveau geordend en wordt vervolgens de gekozen onderzoeksmethodologie beschreven. 12

34 3.2. SCHALEN IN PROJECTCONTEXT Schalen in projectcontext De stakeholders binnen dit onderzoek kunnen worden geordend op schaal-niveau. Er wordt onderscheid gemaakt tussen drie schalen van social agents als onderdeel van de huidige kennismaatschappij [Goossenaerts, 2004]: Macro-schaal: Markt Meso-schaal: Bedrijven Micro-schaal: Personen In de projectcontext is een drietal foci beschreven waartussen interacties plaatsvinden. De vraagen aanbod zijde wordt ingevuld door de meso- en micro-schaal. De instituties gelden voor de markt en zijn onderdeel van de macro-schaal. Technologie wordt ingezet door bedrijven om processen efficiënt te laten verlopen. Technologie wordt in de context van dit onderzoek ingevuld door Enterprise Resource Planning (ERP) systemen. ERP-systemen helpen organisaties bij de ondersteuning van bedrijfsprocessen. ERP-systemen worden gedefinieerd als [Callaway, 2000]: Een verzameling applicaties die financiële en human resource departementen automatiseren en producenten kunnen helpen bij het omgaan met taken als orderverwerking en productieplanning. ERP-systemen zijn standaardpakketten die door middel van het instellen van bedrijfsspecifieke parameters worden geconfigureerd zodat ze optimaal binnen de desbetreffende bedrijfsomgeving opereren. Dit onderzoek richt zich op het bedrijfsspecifiek inrichten van de BTW-bepaling binnen ERPsystemen. In de volgende secties worden deze schalen toegelicht en specifiek ingevuld voor de stakeholders binnen dit onderzoek Macro-schaal: Markt De markt (samenleving) is het geheel van entiteiten uit de meso-schaal [Goossenaerts, 2004]. Instituties schrijven de leefregels binnen deze schaal voor. Deze leefregels zijn afdwingbare patronen waaraan bedrijven zich moeten houden. Bedrijven uit de meso-schaal moeten hun bedrijfsprocessen hiermee in overeenstemming brengen om optimale prestaties te leveren en risico s op non-compliancy te reduceren [North, 1990]. In de projectcontext wordt deze schaal ingevuld door BTW-wetgeving (regelgevend) en de Belastingdienst (uitvoerend) Meso-schaal: Bedrijven De meso-schaal bestaat uit samenwerkingen van entiteiten uit de micro-schaal [Goossenaerts, 2004]. Bedrijven zijn onderdeel van de meso-schaal. Zij moeten zich aanpassen aan de regels die hen op worden gelegd door instituties uit de macro-schaal. Bedrijven moeten zich ten doel stellen om zoveel mogelijk voordeel te behalen uit de mogelijkheden die worden gecreëerd door het institutionele raamwerk [North, 1990]. 13

35 METHODOLOGIE Bedrijven worden niet alleen ingericht als functie van de institutionele beperkingen die hen worden opgelegd maar ook als functie van beperkingen op technologisch gebied. De wisselwerkingen tussen deze twee vormen van beperkingen moeten op elkaar worden afgestemd om optimale prestaties te kunnen leveren. In dit onderzoek wordt deze schaal ingevuld door de bedrijven die ERP-systemen gebruiken Micro-schaal: Personen De micro-schaal bestaat uit personen, applicaties of andere resources [Goossenaerts, 2004]. Samenwerkingen tussen entiteiten in deze schaal leiden tot bedrijven in de meso-schaal. Personen passen de aanwezige technologie toe binnen bedrijven. Waar in de bedrijven-schaal de instituties een prikkelstructuur vast moeten stellen, moeten bedrijven uit de meso-schaal een prikkelstructuur voor personen bewerkstelligen om optimale prestaties te leveren. Persoonlijke ambities worden hiermee gestimuleerd. In dit onderzoek wordt deze schaal ingevuld door de BTW-ERP specialisten bij KPMG en ERP-vendors. 3.3 Methodologie Om de doelstellingen van het onderzoek te vervullen wordt een methodologie gekozen die het proces van het project definieert. De regulatieve cyclus [Strien van, 1975] is gekozen als onderzoeksmethodologie voor de fasering van dit onderzoek. Het karakteristieke van deze methodologie is dat deze uitgaat van het oplossen van een specifiek probleem in gegeven omstandigheden. Het ontwikkelde ontwerp is geldig voor een specifieke situatie. De regulatieve cyclus methodologie is daarom bruikbaar voor ontwerponderzoek. De regulatieve cyclus gaat uit van een probleemkluwen als basis voor het starten van een ontwerpopdracht. Van Aken (2002) definieert een probleemkluwen als [Aken van, 2002]: Een moeilijk grijpbaar en kenbaar samenspel van situaties en personen, persoonlijke opvattingen, motieven, macht en invloed. Aangezien het probleemgebied zich uitstrekt over meerdere stakeholders binnen de projectcontext is niet sprake van een eenheid van problemen maar van een probleemkluwen als basis voor dit onderzoek. In Figuur 3.1 is de regulatieve cyclus weergegeven. Achtereenvolgens worden de volgende vier fasen doorlopen: 1. Oriëntatie De probleemsituatie wordt in kaart gebracht. Er wordt inzicht verschaft in het kluwen van problemen en de oorzaken die daaraan ten grondslag liggen. Hieruit volgt een eerste definitie van het aan te pakken probleem. Deze probleemdefinitie wordt als basis genomen voor het ontwerponderzoek. Er worden onderzoeksdoelstellingen geformuleerd die uit worden gewerkt in een onderzoeksplan. 2. Analyse De oorzaken die ten grondslag liggen aan de probleemdefinitie worden verder onderzocht en grondig geanalyseerd. Er worden kernoorzaken vastgesteld die leiden tot een oplossingsrichting die wordt uitgewerkt tijdens de ontwerpfase. 14

36 3.4. ONDERZOEKSFASERING 15 Figuur 3.1: De regulatieve cyclus als onderzoeksmethodologie Uit: [Strien van, 1975] 3. Ontwerp Een diepte-analyse verschaft extra verdieping in technieken en concepten die benodigd zijn voor het daadwerkelijke ontwerp. De gekozen oplossingsrichting wordt uitgewerkt tot een ontwerp. 4. Implementatie & evaluatie Het ontwerp wordt geïmplementeerd en vervolgens geëvalueerd op basis van praktische toepasbaarheid. Hierna wordt de cyclus herhaald waarbij door evaluatie een nieuw probleemkluwen kan ontstaan. In dit afstudeeronderzoek wordt de cyclus eenmaal doorlopen. 3.4 Onderzoeksfasering De fasen uit de regulatieve cyclus zijn de basis voor de inrichting van dit onderzoek. Tijdens de vier fasen wordt aandacht besteed aan elk van de drie schalen die eerder beschreven zijn. In de volgende secties wordt de invulling van deze fasen beschreven evenals de gebruikte onderzoeks- en modelleertechnieken Oriëntatiefase De oriëntatiefase begint met een eerste verkenning van het probleemgebied. De belangrijkste aspecten van de BTW-wetgeving worden bestudeerd en basiskennis van ERP-systemen wordt opgedaan. Hiermee wordt inzicht verkregen in de aard van het probleemkluwen dat de directe aanleiding voor het onderzoek is. Er wordt een onderzoeksmethodologie gekozen die geschikt is voor het aanpakken van het specifieke probleem. Literatuuronderzoek verschaft inzicht in de specifieke methodieken die gebruikt gaan worden voor het aanpakken van de subproblemen. Aan de hand van de regulatieve cyclus methodologie is vervolgens een onderzoeksplan opgesteld waarin projectfasen met deliverables gebonden aan tijdsaspecten vastgesteld zijn. 15

37 ONDERZOEKSFASERING Analysefase Tijdens de analysefase wordt de huidige situatie van de BTW-ERP context modelsgewijs beschreven en worden kernoorzaken vastgesteld die ten grondslag liggen aan de aanwezige kloof tussen vraag-aanbod wisselwerkingen en BTW-regels. De BTW-ERP context heeft een sterk IT-aspect. De modelsgewijze beschrijving van deze context moet daarom worden bezien vanuit IT-perspectief. Om hierin systematisch te werk te gaan wordt de huidige situatie beschreven aan de hand van de invulling van een tweetal repositories. Op macro-schaal worden de BTW-beperkingen die door BTW-wetgeving worden opgelegd beschreven en wordt invulling gegeven aan een marktrepository. Vervolgens wordt de ERP-context beschreven en worden de relevante bedrijfsprocessen die betrekking hebben op BTW voor ERP-gebruikers beschreven. Hierbij wordt invulling gegeven aan een bedrijfsrepository. Figuur 3.2: Het 3-V model Het invullen van de repositories volgt het traject van de regulatieve cyclus. De fasen die hierin worden doorlopen zijn beschreven in het 3-V model (zie Figuur 3.2) dat een specifieke invulling aan deze cyclus geeft voor IT-gerelateerde projecten [Goossenaerts, 2006b], [Goossenaerts, 2006c]. De fasen in het 3-V model zijn gebaseerd op de FAST-methodologie [Whitten et al., 2004] waarin een gedetailleerde fasering voor de ontwikkeling van informatiesystemen is uitgewerkt. FAST staat voor Framework for the Application of Systems Techniques. In Bijlage E.1 wordt een gedetailleerde beschrijving van deze methodologie gegeven. In het 3-V model worden drie beslissingsniveaus onderscheiden waarin bij behoefte aan systeemontwikkeling besloten wordt welk type project wordt opgestart: Directe beslissing (1-V) Op basis van een geconstateerde veranderingsbehoefte wordt een directe beslissing tot installatie genomen. 16

38 3.4. ONDERZOEKSFASERING 17 Operationeel project (2-V) Alvorens tot installatie wordt overgegaan, wordt een probleemanalyse gehouden waarin een aantal mogelijke oplossingen wordt bekeken. De manier waarop deze oplossing wordt uitgevoerd wordt gekozen en uitgewerkt. ICTA project (3-V) Als wordt besloten dat de gekozen oplossing nieuwe IT-aspecten met zich meebrengt waarbij nieuwe eisen aan het informatiesysteem moeten worden opgesteld, wordt een ICTA project opgestart waarin op basis van deze eisen een logisch ontwerp wordt ontwikkeld dat uitgewerkt wordt tot een fysiek ontwerp en vervolgens wordt geïmplementeerd. ICTA staat voor ICT Architecture. De beschrijving van de huidige situatie vindt plaats op 1-V en 2-V niveau voor de markt- en bedrijfsschaal. De implementatie wordt dieper op 3-V niveau beschreven voor de bedrijfsschaal. De documentatie en deliverables die bij deze niveaus horen worden opgeslagen in de repository. De structuur van deze repository is naar eigen inzicht in te vullen. In dit onderzoek is gekozen voor een invulling op basis van de COMET-methodologie [Berre et al., 2004]. Hierin wordt een repositorystructuur met een aantal voorgeschreven deliverables beschreven. Figuur 3.3: COMET repositorystructuur voor macro- en meso-schaal De lagen van de COMET-repository corresponderen met de drie niveaus van het 3-V model. Het 3-V model wordt op macro- en de meso-schaal doorlopen door het invullen van de markten bedrijfsrepository als modelsgewijze beschrijving van de huidige situatie. Modellen die het domein van de markt- en bedrijfscontext beschrijven worden beschreven in UML (Unified Modeling Language) als class diagram [OMG, 2004]. Condities die voor deze domeinmodellen gelden maar niet expliciet uit de modellen volgen worden beschreven in de Object Constraint Language (OCL) [OMG, 2002]. 17

39 OPBOUW VERSLAG Procesmodellen die opgesteld worden vanuit de context van de domeinmodellen worden beschreven met Petri-netten [Hee van, 1994]. Er bestaat een formele koppeling tussen Petri-netten en UML-notatie [Wagner, 2002]. Bij het beschrijven van Petri-netten is gebruik gemaakt van een aantal vaste patroonsbeschrijvingen uit [Hruby, 2006] dat gebaseerd is op REA (Resources, Events, Agents)-concepten waarin patronen die vaak voorkomen in bedrijfssoftware applicaties zijn beschreven. De deliverables zijn voor de macro- en meso-schaal beschreven in Figuur 3.3 [Berre et al., 2004], [Goossenaerts, 2006a]. Na het beschrijven van de huidige situatie wordt een probleemanalyse gehouden waarin kernoorzaken worden geïdentificeerd die ten grondslag liggen aan de aanwezige kloof tussen vraag-aanbod interacties en BTW-wetgeving. Hieruit is een aantal ontwerpeisen voor het te ontwerpen model afgeleid. De probleemanalyse bestaat uit een stakeholderanalyse en een oorzaak- en gevolganalyse. Belangen en doelstellingen van de stakeholders worden in kaart gebracht met Balanced Scorecards [Kaplan and Norton, 1997] die ingevuld worden aan de hand van diepte-interviews, groepsbijeenkomsten en desk-research Ontwerpfase Tijdens de ontwerpfase wordt de gekozen oplossingsrichting ontworpen. De brug die de kloof moet dichten bestaat uit een aantal beslismodellen en beschrijvingen van relaties met de modellen die tijdens de analysefase opgesteld zijn als beschrijving van de huidige situatie. Deze modellen moeten op één lijn worden gebracht en pakken daarmee de kernoorzaken aan die geïdentificeerd zijn tijdens de probleemanalyse. Door middel van het identificeren van een veranderingsproces met betrekking tot BTW-wetgeving en het uitvoeren van een veranderingsscenario worden de koppelingen tussen de modellen gevalideerd Implementatie- en evaluatiefase In de implementatie- en evaluatiefase wordt onderscheid gemaakt tussen een tweetal realisaties. Eerst wordt de brug die ontworpen is vanuit markt- en bedrijfsperspectief vertaald van een Computation Independent Model (CIM) naar een Platform Specific Model (PSM). De bedrijfsrepository wordt (deels) tot op 3-V niveau uitgewerkt. Als ERP-systeem is hier gekozen voor SAP R/3. Vervolgens wordt met de verworven inzichten een eerste aanzet tot BTW-ERP serviceontwikkeling voor KPMG IRM beschreven. Het eindresultaat wordt geëvalueerd en de conclusies en aanbevelingen worden beschreven. Tenslotte worden suggesties voor vervolgonderzoek op dit gebied geformuleerd. 3.5 Opbouw verslag De opbouw van het verslag volgt uit de resultaten van de fasen van de regulatieve cyclus. De regulatieve cyclus is hierbij eenmaal doorlopen. Tijdens de evaluatie worden suggesties voor vervolgonderzoek beschreven die aanleiding geven tot mogelijke nieuwe regulatieve cycli. 18

40 3.5. OPBOUW VERSLAG 19 Figuur 3.4: Opbouw verslag Tijdens een aantal fasen zijn iteraties uitgevoerd om tot de gewenste resultaten te komen. De opbouw van het verslag volgt niet strikt de chronologische volgorde waarin de resultaten zijn bereikt maar zijn ter wille van de leesbaarheid daar in het verslag geplaatst waar zij logischerwijs thuishoren. Figuur 3.4 geeft de opbouw van het verslag schematisch weer. 19

41 Deel II Analyse 20

42

43 Hoofdstuk 4 Beschrijving huidige BTW-ERP situatie 4.1 Belasting over de Toegevoegde Waarde (BTW) Omzetbelasting wordt in Nederland sinds 1934 geheven. De termen omzetbelasting en Belasting over de Toegevoegde Waarde (BTW) zijn echter geen synoniemen. BTW zegt iets over de manier waarop omzetbelasting wordt geheven [Vervloed and Bod, 1999]. Hierop wordt verderop in dit hoofdstuk ingegaan. De manier van heffen van omzetbelasting zoals we die nu kennen dateert van Deze vorm van omzetbelasting staat bekend als Belasting over de Toegevoegde Waarde (BTW). In 2005 heeft het rijk in totaal e 38,1 miljard aan BTW ontvangen. Dit is ruim 36% van alle belastinginkomsten over 2005 [Belastingdienst, 2005b] Beschrijving marktcontext Voordat een uitgebreide beschrijving van BTW-wetgeving wordt gegeven, wordt een generieke marktcontext beschreven waarin BTW gepositioneerd is. Aan de hand van een generiek marktdomeinmodel (MDM) dat is weergegeven in Figuur 4.1, wordt een specifiek domeinmodel opgebouwd bij de beschrijving van BTW-wetgeving. Dit specifieke deel bouwt voort op concepten van dit generieke deel. De basis voor het generieke deel is een verfijning van het Society Domain Model dat is beschreven in [Goossenaerts, 2006b]. Dit model beschrijft het domein van een standaardmarktsituatie. Het model is aangevuld met een aantal concepten uit het Core Cadastral Domain Model [van Oosterom et al., 2006]. In Figuur 4.1 is een relatie aangegeven tussen de klassen RRR en Principal. BTWwetgeving legt restricties (Restriction) op aan bedrijven (nonnaturalperson) en particulieren (NaturalPerson) als specialisatieklassen van Principal. De Belastingdienst is een invulling van Agency als uitvoerend orgaan van BTW-wetgeving. Bedrijven die belastingplichtig zijn vallen onder de klasse Company. In een marktsituatie worden objecten uitgewisseld tussen marktactoren. In het generieke domeinmodel worden deze objecten gerepresenteerd door de klasse (InstitutionalObject). Deze uitwisselingen van objecten worden gereguleerd door regels (RRR) opgelegd door marktinstituties. De klasse (InstitutionalObject) heeft een aantal specialisatieklassen waarmee onderscheid kan worden gemaakt in het type product (algemeen/concreet/specifiek) dat wordt geconsumeerd in de markt. 22

44 4.1. BELASTING OVER DE TOEGEVOEGDE WAARDE (BTW) 23 Figuur 4.1: Generiek domeinmodel marktcontext Er is een marktcontext beschreven voor objectuitwisselingen tussen marktactoren waarop BTW van toepassing die voorgeschreven is door wetgeving. Deze marktcontext wordt voorzien van resources door dieper in te gaan op BTW-wetgeving. Eerst wordt de achtergrond van BTW beschreven en wordt ingegaan op een aantal karakteristieke eigenschappen van BTW. Vervolgens wordt een specifieke invulling van het MDM gegeven die aan de hand van de opbouw van BTW-wetgeving en de begrippen die hierin terugkomen wordt onderbouwd Karakteristieken van de BTW In deze sectie worden de belangrijkste karakteristieken van de BTW besproken. Achtereenvolgens wordt het rechtskarakter, het type belasting en de wijze van heffing besproken. Verbruiksbelasting Het rechtskarakter van omzetbelasting heeft altijd de vorm gehad van een algemene verbruiksbelasting. Dit wil zeggen dat de omzetbelasting de bedoeling heeft om op consumptieve bestedingen van particulieren en daarmee gelijkgestelden een heffing te laten drukken [Vervloed and Bod, 1999]. De belasting die daarmee betaald wordt is evenredig aan het betaalde bedrag van de besteding. Indirecte belasting Omzetbelasting is een vorm van indirecte belasting. Dit wil zeggen dat de belasting niet rechtstreeks wordt geheven bij de consument. De belastingplichtige en belastingverschuldigde zijn in dit geval niet een en dezelfde persoon. De consument is de belastingschuldige, terwijl bijvoorbeeld een winkelier de belastingplichtige is. De winkelier draagt de belasting af aan de Belastingdienst. In de Wet op de Omzetbelasting (Wet OB) [WetOB, 1968] wordt de belastingplichtige aangeduid als ondernemer. Deze ondernemer draagt de belasting die hij van zijn afnemers heeft ontvangen af aan de Belastingdienst. De bekendste vorm van een directe belasting is de inkomstenbelasting. 23

45 BELASTING OVER DE TOEGEVOEGDE WAARDE (BTW) Hiermee wordt de huidige vorm van omzetbelasting gekarakteriseerd als een indirecte algemene verbruiksbelasting. In het specifieke MDM dat later in dit verslag wordt beschreven wordt de indirecte wijze van heffing weergegeven door een driehoeksrelatie tussen Belastingdienst, klant en afnemer waarin een afnemer BTW op zijn factuur aan de klant in rekening brengt die de klant terug kan vragen bij de Belastingdienst. Wijze van heffing Nederland hanteert vanaf 1969 een geheel meermalig niet-cumulatief heffingsstelsel. In alle schakels van de bedrijfskolom wordt omzetbelasting geheven over de toegevoegde waarde die de desbetreffende schakel heeft toegevoegd. De werking van dit stelsel wordt toegelicht in Bijlage C.2. De omzetbelasting die wordt geheven in elke schakel kan door ondernemers worden teruggevraagd door de introductie van aftrek van voorbelasting. De leverancier brengt aan haar afnemer de verschuldigde BTW in rekening, terwijl de afnemers op zijn beurt dat bedrag in mindering brengt op de belasting die hij voor zijn belaste prestaties verschuldigd is. In Nederland hanteert men sinds 1968 het systeem van aftrek van voorbelasting. Deze keuze is in 1967 opgelegd door de Europese Richtlijn met betrekking tot het heffen van omzetbelasting. Deze richtlijn is gepubliceerd als de Eerste Richtlijn betreffende de harmonisatie van Omzetbelasting [EEG, 1967]. Tegelijkertijd is de Tweede Richtlijn vastgesteld die de nationale wetgevers voorschrijft om bepaalde regelingen in de wet op te nemen. Deze Tweede Richtlijn is in 1977 vervangen door de Zesde Richtlijn [EEG, 1977], waarin gedetailleerder dan in de Tweede Richtlijn wordt omschreven wat in nationale wetgeving opgenomen moet worden. Sinds 1 januari 1979 is de Nederlandse wetgeving in overeenstemming gebracht met de Zesde Richtlijn. Verder is er nog een aantal richtlijnen dat vrij specifiek ingaat op punten die voor specifieke Lidstaten meer in detail uitgewerkt dienen te worden BTW-determinanten De regels die BTW-wetgeving voorschrijft moeten door het ERP-systeem gefaciliteerd worden. Hierbij moet een koppeling vast worden gesteld tussen deze regels en de ERP-configuratie. BTW-determinanten geven invulling aan deze koppeling (zie Figuur 4.2). Figuur 4.2: Koppeling tussen BTW en ERP Bedrijven reageren met de inrichting van ERP-systemen op de regels die vanuit BTW-wetgeving worden voorgeschreven. 24

46 4.1. BELASTING OVER DE TOEGEVOEGDE WAARDE (BTW) 25 BTW-determinanten worden als volgt gedefinieerd: Variabelen met een vaste semantiek binnen BTW-regelgeving die ingevuld worden door specifieke bedrijfsprocessen en een vaste invulling geven aan de ERP-configuratie. De BTW-determinanten zijn weergegeven in Tabel 4.1. Bij de beschrijving van de Wet OB worden deze BTW-determinanten systematisch afgeleid en wordt gerefereerd naar deze tabel. Tabel 4.1: Overzicht BTW-determinanten Id BTW-determinant Waarden Beschrijving B.1 SupplierCountry Country Het land waar de afnemer is gevestigd en van waaruit de factuur wordt verzonden B.2 CustomerCountry Country Het land waar de afnemer gevestigd is B.3 TaxableTransaction TransactionType Het soort belastbare prestatie B.4 Installation-or-Assembly Boolean In geval van levering van goed, bepaalt deze determinant of er sprake is van installatie of montage B.5 Ship-from-Country Country Het land van waaruit de goederen worden verstuurd B.6 Ship-to-Country Country Het land waar het transport van de goederen eindigt B.7 PlaceOfSupply Country Het land waar de levering plaatsvindt B.8 PlaceOfService Country Het land waar de dienst plaatsvindt B.9 VATregistrationsSupplier SET of VATIDNumber Alle BTW-registratienummers van de leverancier in de verschillende EU-landen B.10 VATregistrationsCustomer SET of VATIDNumber Alle BTW-registratienummers van de afnemer in de verschillende EU-landen B.11 VATGroupSupplier Number De fiscale entiteit waarin de leverancier zich bevindt B.12 VATGroupCustomer Number De fiscale entiteit waarin de afnemer zich bevindt B.13 Triangulation Boolean Deze determinant geeft aan of er sprake is van een driehoekstransactie B.14 SimplifiedTriangulation Boolean Deze determinant geeft aan of de vereenvoudigde A-B-C regeling wordt toegepast B.15 TransportParty Boolean Deze determinant geeft aan of het vervoer in het kader van transactie van de leverancier plaatsvindt B.16 ItemClassification ItemType De BTW-tarief categorie waarin het product valt B.17 TaxablePerson TaxType De BTW-categorie waarin de afnemer valt B.18 FixedEstablishment Boolean Deze determinant geeft aan of de afnemer een vaste inrichting heeft in het land waar de belastbare prestatie plaatsvindt In de volgende sectie wordt een marktdomeinmodel beschreven waarin de BTW-determinanten worden gearticuleerd Opbouw Wet op de Omzetbelasting In Figuur 4.3 is het marktdomeinmodel (MDM) weergegeven aan de hand waarvan de opbouw van de Wet op de Omzetbelasting (Wet OB) wordt beschreven. 25

47 BELASTING OVER DE TOEGEVOEGDE WAARDE (BTW) Bij de bespreking van de Wet OB wordt naar de relevante delen van dit domeinmodel gerefereerd. De BTW-determinanten zijn met rood gemarkeerd in het domeinmodel en worden in de loop van de bespreking van de Wet OB geïntroduceerd. Figuur 4.3: Domeinmodel BTW-ERP context Centraal in het domeinmodel staat de klasse Order die leidt tot belastingplichtigheid. Wanneer een factuur (Invoice) vooraf wordt gegaan door een order is meestal niet sprake van een directe 26

48 4.1. BELASTING OVER DE TOEGEVOEGDE WAARDE (BTW) 27 uitwisseling van producten zoals dit het geval is bij consumenten die aan de kassa afrekenen en de factuur (in de vorm van een kassabon) direct betalen. Ook hier wordt BTW berekend, maar deze valt buiten de problematiek van deze context. Problemen ontstaan bij facturen die vooraf worden gegaan door orders die het ERP-systeem verwerkt en waarbij het tijdstip van productuitwisseling niet gelijk is aan het tijdstip van factuuruitwisseling. De Wet OB is opgebouwd uit 55 artikelen, verdeeld over negen hoofdstukken, aangevuld met twee tabellen. De volledige hoofdstukindeling van de integrale wettekst is te vinden in Bijlage C.1. De wettekst start met een hoofdstuk waarin een aantal inleidende bepalingen wordt behandeld. Artikel 1 beschrijft de vier belastbare feiten ter zake waarvan omzetbelasting wordt geheven. De belastbare feiten worden in de daarop volgende vier hoofdstukken behandeld en nauwkeurig omschreven. Deze hoofdstukken beginnen met de gedetailleerde omschrijving van het belastbare feit. Vervolgens wordt de maatstaf en tarief van heffing uiteengezet en worden de vrijstellingen beschreven. De hoofdstukken eindigen met de beschrijving van de wijze van heffing van omzetbelasting van het desbetreffende belastbare feit. Aan de hand van de volgende beschrijving van de gevallen wanneer belastingplichtigen Nederlandse omzetbelasting verschuldigd zijn, worden de belangrijkste begrippen toegelicht: Omzetbelasting wordt geheven wegens leveringen van goederen en diensten die in Nederland door een ondernemer worden verricht. De Ondernemer Het begrip ondernemer heeft in de Wet OB een andere betekenis dan in gewone spreektaal, wat tot enige verwarring kan leiden. Volgens de Wet OB wordt onder ondernemer verstaan 1 : Ondernemer is ieder die een bedrijf of beroep zelfstandig uitoefent. Daarnaast wordt een drietal uitzonderingen genoemd in welke gevallen niet het begrip ondernemer wordt gebruikt maar wel moet worden gehandeld alsof het een ondernemer betreft 1. Uiteindelijk is de ondernemer zoals gedefinieerd in de Wet OB altijd degene die omzetbelasting verschuldigd is, ofwel de belastingplichtige. De Zesde Richtlijn gebruikt het begrip belastingplichtige in plaats van het begrip ondernemer 2. Introductie BTW-determinant: B.17 TaxablePerson:TaxType Leveringen en Diensten Een ondernemer is omzetbelasting verschuldigd als hij in Nederland (in het kader van zijn onderneming) goederen levert of diensten verricht. Deze leveringen en diensten vormen de belastbare feiten voor de omzetbelasting. Leveringen en diensten worden onder dezelfde noemer ook wel prestaties genoemd. Alles waar een vergoeding tegenover staat wordt met omzetbelasting belast. Een tweede voorwaarde om te kunnen spreken over een belastbare prestatie is het feit dat de 1 Art. 7 Wet OB [WetOB, 1968] 2 Art. 4 Zesde Richtlijn [EEG, 1977] 27

49 BELASTING OVER DE TOEGEVOEGDE WAARDE (BTW) levering of dienst in Nederland wordt verricht. De belangrijkste begrippen kunnen nu worden vervangen door de overeenkomstige begrippen uit de Wet OB. Dit levert de volgende omschrijving voor de gevallen waarin omzetbelasting moet worden geheven: Omzetbelasting wordt geheven wegens belastbare prestaties verricht door belastingplichtigen in Nederland Belastingplichtig zijn betekent niet dat men in alle gevallen omzetbelasting verschuldigd is. Er wordt onderscheid gemaakt tussen meerdere categorieën belastingplichtigen. Een schema om te bepalen binnen welke categorie belastingplichtigen een Principal (zie Figuur 4.1) valt, is weergegeven in Bijlage C.3. In de volgende paragraaf wordt verder ingegaan op het begrip belastbare prestatie. Daarna wordt verder ingegaan op de plaats van levering en dienst. Dit is van belang bij de bepaling van het land waar omzetbelasting verschuldigd is. Belastbare prestatie Het verrichten van een belastbare prestatie is onderhevig aan de omzetbelasting. De belastbare prestatie vormt het aangrijpingspunt van de belastingheffing. Een belastbare prestatie is de levering van een goed of de verrichting van een dienst. Dit onderscheid is noodzakelijk omdat het relevant is voor de toepassing van de BTW-regels. Het begrip goed Voordat kan worden bepaald of iets een belastbare prestatie is, moet eerst worden vastgesteld wat BTW-wetgeving onder een goed of dienst verstaat. De Wet OB stelt 3 : Goederen zijn alle voor menselijke beheersing vatbare stoffelijke objecten, alsmede elektriciteit, gas, warmte, koude en dergelijke. Het begrip dienst Als er geen sprake is van een goed, dan kan alleen aan heffing worden toegekomen indien er sprake is van een dienst. De Wet OB stelt 4 : Diensten zijn alle prestaties, niet zijnde leveringen van goederen, welke tegen vergoeding worden verricht. Belastbare feiten Nu eenduidig is vastgesteld wat onder goederen en diensten wordt verstaan kan worden bepaald wanneer er sprake is van een belastbaar feit. De Zesde Richtlijn omschrijft het belastbare feit als volgt 5 : Aan de belasting over de toegevoegde waarde zijn onderworpen: de leveringen van goederen en de diensten, welke in het binnenland door een als zodanig handelende belastingplichtige onder bezwarende titel worden verricht als mede de invoer van goederen. 3 Art. 3 lid 7 Wet OB [WetOB, 1968] 4 Art. 4 lid 1 Wet OB [WetOB, 1968] 5 Art. 2 Zesde Richtlijn [EEG, 1977] 28

50 4.1. BELASTING OVER DE TOEGEVOEGDE WAARDE (BTW) 29 Met het binnenland worden de Lidstaten van de Europese Unie (EU) bedoeld. Een uitgebreid overzicht van deze Lidstaten zijn beschreven in Bijlage C.4. Wanneer sprake is van een levering van een goed door een ondernemer aan een andere ondernemer van de ene Lidstaat aan de andere Lidstaat, dan is er sprake van een intracommunautaire levering (ICL) 6. De ondernemer die deze levering ontvangt verricht een intracommunautaire verwerving (ICV). Deze ICV is eveneens een belastbaar feit voor de Wet OB. Onder een belastbaar feit wordt dus verstaan: Het leveren van goederen, de intracommunautaire verwerving, de invoer van goederen en het verrichten van diensten. Levering van goederen De Wet OB geeft een opsomming van wat als levering van goederen kan worden aangemerkt 7. De Zesde Richtlijn geeft naast een opsomming van wat onder levering van goederen wordt verstaan ook nog een algemene definitie 8 : Als levering van een goed wordt beschouwd de overdracht of overgang van de macht om als eigenaar over een lichamelijke zaak te beschikken. Aangezien het begrip levering hiermee vast is gelegd in de Zesde Richtlijn, wordt dit begrip losgekoppeld van de Lidstaat-afhankelijke juridische semantiek van het begrip. Indien dat niet het geval zou zijn, zou de harmonisatiedoelstelling van de richtlijn in gevaar komen. Een aparte vermelding verdient de installatie- en montage regeling. Een installatie of montage wordt beschouwd als een levering van een goed. Hiervoor geldt een aparte invulling van de vaststelling van de plaats van de belastbare prestatie. Deze invulling wordt verderop in het verslag behandeld. Introductie BTW-determinant: B.4 Installation-or-Assembly: Boolean Intracommunautaire verwerving De intracommunautaire verwerving (ICV) wordt pas als belastbaar feit aangemerkt sinds 1 januari 1993, toen de fiscale grenzen tussen de Lidstaten werden afgeschaft. Dit had tot gevolg dat de belastbare invoer bij het goederenverkeer tussen de Lidstaten moest komen te vervallen. Er kon geen sprake meer zijn van invoer omdat er geen grenzen meer waren. Om toch het zogenaamde bestemmingslandbeginsel te handhaven werd het nieuwe belastbare feit verwerving ingevoerd. De verwerving heeft in het intracommunautair goederenverkeer de plaats ingenomen van de invoer. Onder een ICV wordt verstaan 9 : De verwerving van goederen ingevolge een levering van deze goederen door een ondernemer in het kader van zijn onderneming, welke goederen worden verzonden of vervoerd van een Lidstaat naar een andere Lidstaat 6 Art.28bis lid 3 Zesde Richtlijn [EEG, 1977] 7 Art. 3 Wet OB [WetOB, 1968] 8 Art. 5 lid 1 Zesde Richtlijn [EEG, 1977] 9 Art. 17a lid 1 Wet OB [WetOB, 1968] 29

51 BELASTING OVER DE TOEGEVOEGDE WAARDE (BTW) Aangezien bij intracommunautair goederenvervoer sprake is van verplaatsing van goederen van het ene naar het andere EU-land, moet er afgesproken worden waar de belastbare handeling plaatsvindt (plaats van de verwerving). De Wet OB 10 en de Zesde Richtlijn 11 bepalen dat de plaats waar de ICV wordt verricht de plaats van aankomst van het vervoer is. Nu kan het voorkomen dat goederen worden vervoerd naar een andere Lidstaat dan waar de afnemer is gevestigd. Om te voorkomen dat door bovenstaande regeling geen BTW zou worden geheven, schrijft de Wet OB 12 dat de verwerving belastbaar is in het land dat aan de afnemer het BTWidentificatienummer heeft toegekend dat die afnemer bij de transactie heeft gebruikt. Invoer van goederen Van invoer van goederen is sprake wanneer goederen de EU binnenkomen vanuit een niet EU-land. De exacte definitie van invoer van goederen is beschreven in de Wet OB 13 en de Zesde Richtlijn 14. De invoer van goederen wordt niet verder behandeld omdat de scope van goederenstromen voor dit onderzoek gericht is op stromen binnen de Europese Unie. Verrichting van diensten Zoals eerder vermeld, wordt onder diensten verstaan: alle belastbare handelingen die geen leveringen van goederen zijn. De Wet OB 15 en de Zesde Richtlijn 16 geven een gedetailleerdere omschrijving van wat exact onder verrichting van diensten wordt verstaan. Het begrip belastbare prestatie is nu volledig ingevuld. In het MDM uit Figuur 4.3 is de belastbare prestatie weergegeven door middel van de klasse (TaxableTransaction). Deze bestaat uit óf een levering van een goed (SupplyOfGoods) óf uit de verrichting van een dienst (Service). Introductie BTW-determinant: B.3 TaxableTransaction: SupplyOfGoods Service Eerder is aangegeven dat een belastbare prestatie ook uit een intracommunautaire verwerving of invoer van goederen kan bestaan. Deze twee vormen van belastbare prestaties zijn bijzondere vormen van SupplyOfGoods en zijn niet apart aangegeven omdat deze uit de invulling van het domeinmodel kunnen worden afgeleid. Daarom zijn twee boolean velden aan deze klasse toegevoegd die expliciet maken of er sprake is van een van deze twee belastbare feiten. De klasse EconomicEvent representeert een invulling van de klasse Instance uit het generieke model. Een EconomicEvent is afhankelijk van een order die de data bevat waaruit bepaald kan worden of er sprake is van een ICV of invoer van goederen. De bepaling van de waarden van SupplyOfGoods.ICV en SupplyOfGoods.Import worden beschreven met de Object Constraint Language (OCL). Bepaling SupplyOfGoods.ICV in OCL: 10 Art. 17b Wet OB [WetOB, 1968] 11 Art. 28ter Zesde Richtlijn [EEG, 1977] 12 Art. 17b lid 2 Wet OB [WetOB, 1968] 13 Art. 18 Wet OB [WetOB, 1968] 14 Art. 7 Zesde Richtlijn [EEG, 1977] 15 Art. 4 Wet OB [WetOB, 1968] 16 Art. 6 Zesde Richtlijn [EEG, 1977] 30

52 4.1. BELASTING OVER DE TOEGEVOEGDE WAARDE (BTW) 31 CONTEXT SupplyOfGoods INV: IF ( Order.Ship-from-Country Order.Ship-to-Country AND (Order.Ship-from-Country.EU AND Order.Ship-to-Country.EU) ) THEN self.icv ELSE NOT(self.ICV) Bepaling SupplyOfGoods.Import: CONTEXT SupplyOfGoods INV: IF ( NOT(Order.Ship-from-Country.EU) AND Order.Ship-to-Country.EU ) THEN self.import ELSE NOT(self.Import) Het boolean veld EU uit klasse CountryInformation geeft aan of het land uit klasse Country tot de Lidstaten van de Europese Unie behoort. Alle gebieden die voor de Wet OB tot onderdeel van de Europese Unie behoren zijn beschreven in Bijlage C.4. Minimaal één van de velden SupplyOfGoods.ICV en SupplyOfGoods.Import moet de waarde false hebben, omdat nooit sprake kan zijn van een ICV en import bij één en dezelfde belastbare prestatie. Dit legt de volgende conditie op aan het domeinmodel: CONTEXT SupplyOfGoods INV: NOT(self.ICV) OR NOT(self.Import) De drie klassen VATlegislation, EconomicEvent en TaxableTransaction zijn gekoppeld aan respectievelijk Restriction, Instance en Object als klassen uit het generieke marktmodel. Bij de bepaling van de boolean velden SupplyOfGoods.ICV en SupplyOfGoods.Import is gebruik gemaakt van de plaats waarvandaan de goederen vertrekken en arriveren. Hierbij worden de volgende twee BTW-determinanten geïntroduceerd: Introductie BTW-determinant: B.5 Ship-from-Country: Country Introductie BTW-determinant: B.6 Ship-to-Country: Country Plaats van de levering Als vastgesteld is dat er sprake is van een belastbare prestatie door een belastingplichtige, dient vast te worden gesteld waar de prestatie belast is. Het algemene uitgangspunt van de wetgeving is dat de belasting geheven wordt in het land van bestemming van de goederen, het zogenaamde bestemmingslandbeginsel. De exacte bepaling van de plaats van levering is omschreven in de Wet OB Art. 5, 5b en 5c Wet OB [WetOB, 1968] 31

53 BELASTING OVER DE TOEGEVOEGDE WAARDE (BTW) Het algemene geval van bestemmingslandbeginsel bepaalt het volgende invariante statement voor het domeinmodel: CONTEXT SupplyOfGoods INV: self.placeofsupply = Order.Ship-to-Country De plaats van levering wordt geïntroduceerd als BTW-determinant: Introductie BTW-determinant: B.7 PlaceOfSupply: Country Plaats van de dienst De Zesde Richtlijn gaat uit van het principe dat diensten belastbaar zijn in het land waar de dienstverrichter is gevestigd. Een consequentie hiervan zou kunnen zijn dat ondernemers die buiten de EU zijn gevestigd geen BTW hoeven te voldoen, terwijl ondernemers gevestigd binnen de EU altijd BTW moeten afdragen. Dit gaat in tegen het neutraliteitsprincipe van de omzetbelasting. Daarom is in de Zesde Richtlijn een groot aantal uitzonderingen op de algemene regel opgenomen. In de Zesde Richtlijn 18 is een gedetailleerde beschrijving van de plaats van dienst opgenomen die eveneens terug te vinden is in de Wet OB 19. De algemene bepaling van plaats van dienst legt de volgende invariante betrekking vast in het domeinmodel: CONTEXT Service INV: self.placeofservice = Organization.Customer.CompanyCountry De plaats van dienst wordt geïntroduceerd als BTW-determinant: Introductie BTW-determinant: B.8 PlaceOfService: Country BTW-tarief Nu beschreven is wie er omzetbelasting verschuldigd en wanneer, is de afsluitende vraag hoeveel BTW er verschuldigd is. De Zesde Richtlijn 20 schrijft voor dat iedere Lidstaat zelf invulling mag geven aan de hoogte van de BTW-tarieven. Er moet een onderscheid maken tussen een verhoogd en één of twee verlaagde tarieven. Voor het verhoogde (normale) tarief stelt de Zesde Richtlijn een minimum van 15%. Voor het verlaagde tarief geldt een maximum van 5%. De Wet OB kent drie tarieven 21 waarvoor een goederenclassificatie is beschreven in de aanvullende tabellen 22 : 18 Art. 9 Zesde Richtlijn [EEG, 1977] 19 Art. 6, 6a en 6b Wet OB [WetOB, 1968] 20 Art. 12 lid 3 Zesde Richtlijn [EEG, 1977] 21 Art. 9 Wet OB [WetOB, 1968] 22 Tabellen I en II Wet OB [WetOB, 1968] 32

54 4.1. BELASTING OVER DE TOEGEVOEGDE WAARDE (BTW) 33 Algemeen tarief van 19% Verlaagd tarief van 6% Nultarief van 0% De goederen en diensten die aan 6% zijn onderworpen, zijn vermeld in Tabel I van de Wet OB 22. Het nultarief is van toepassing op leveringen en diensten die zijn beschreven in Tabel II van de Wet OB 22. De leveringen en diensten die zijn omschreven in Tabel I zijn verder niet aan bijzondere regelingen gebonden. Tabel II (nultarief) kan echter pas worden toegepast wanneer een ondernemer zijn aanspraak aan de hand van boeken en bescheiden aan kan tonen. De exacte voorwaarden zijn beschreven in het Uitvoeringsbesluit Wet OB [Uitv.besl., 1968]. De BTW-classificatie van producten is een BTW-determinant in het domeinmodel: Introductie BTW-determinant: B.16 ItemClassification: ItemType BTW-identificatienummer en verleggingsregeling Elke ondernemer die goederen levert of diensten verricht krijgt een BTW-identificatienummer toegewezen door de Belastingdienst. Dit geldt voor alle ondernemers binnen de EU. Op deze manier kunnen gegevens van ondernemers met andere EU-landen worden uitgewisseld. Dit is met name belangrijk bij het verrichten van intracommunautaire leveringen en -verwervingen. Ondernemers moeten in alle landen waar zij belastbare prestaties verrichten een landspecifiek BTW-identificatienummer aanvragen bij de nationale autoriteiten. Het land waarin de afnemer BTW moet rekenen aan zijn klant kan afhankelijk zijn van het feit of de klant een BTW-registratie in dat land heeft. Daarom worden de BTW-registraties van de klant en afnemer als BTW-determinanten geïntroduceerd: Introductie BTW-determinant: B.9 VATregistrationsSupplier: SET of VATIDNumber Introductie BTW-determinant: B.10 VATregistrationsCustomer: SET of VATIDNumber Dit BTW-identificatienummer moet altijd op de factuur worden vermeld, zowel bij binnenlandse als buitenlandse transacties. In een aantal gevallen moet het BTW-identificatienummer van de afnemer op de factuur worden vermeld. Dit is het geval bij een ICL en bij verlegging van de BTW 23. De zogenaamde verleggingsregeling houdt in dat de leverancier die een belastbaar feit verricht geen BTW factureert aan zijn afnemer maar dat de afnemer zelf BTW moet aangeven en betalen aan de Belastingdienst. Dit komt vooral voor in gevallen wanneer ondernemers die belastbare prestaties verrichten in een ander land zijn gevestigd dan degene die de levering of dienst afneemt. Op deze manier hoeven buitenlandse ondernemers zich niet te laten registreren in het land waar zij leveringen 23 Art.26ter lid F Zesde Richtlijn [EEG, 1977] 33

55 BELASTING OVER DE TOEGEVOEGDE WAARDE (BTW) of diensten verrichten. Elk land heeft zijn eigen verleggingsregeling. Deze is niet geharmoniseerd binnen de EU. Voor Nederland en België geldt op grote lijnen dezelfde regeling. Voor deze landen definiëren onderstaande OCL-statements de invariante conditie voor het domeinmodel: CONTEXT TaxableTransaction INV: IF ( NOT(Organization.Customer.FixedEstablishment) AND Organization.Customer.CompanyCountry Organization.ClientCustomer.CompanyCountry ) THEN self.reversecharge ELSE NOT(self.ReverseCharge) In deze OCL-statements wordt gebruik gemaakt van de plaats waar bedrijven gevestigd zijn. Deze variabele wordt geïntroduceerd als BTW-determinant, zowel voor de klant als voor de afnemer. Ook wordt bijgehouden waar bedrijven vaste inrichtingen (FixedEstablishment) hebben. Introductie BTW-determinant: B.1 SupplierCountry: Country Introductie BTW-determinant: B.2 CustomerCountry: Country Introductie BTW-determinant: B.18 FixedEstablishment: Boolean Driehoekstransacties Met driehoekstransacties worden transacties bedoeld tussen minimaal drie partijen, waarbij de goederen slechts eenmaal worden vervoerd. Er worden hierbij meerdere belastbare handelingen verricht, dus er moet meerdere malen BTW worden geheven. Figuur 4.4 illustreert een algemeen geval van een driehoekstransactie. Figuur 4.4: Voorbeeld van een driehoekstransactie 34

56 4.1. BELASTING OVER DE TOEGEVOEGDE WAARDE (BTW) 35 Eerder is beschreven dat de plaats van de belastbare handeling een rol speelt bij de bepaling van BTW. In bovenstaand voorbeeld vervoert partij A de goederen rechtstreeks naar partij D en zijn partijen B en C tussenhandelaren. Indien alle partijen gevestigd zijn in hetzelfde land, vinden de belastbare prestaties telkens in dat land plaats. Het feit of een transactie onderdeel uitmaakt van een driehoekstransactie is een BTWdeterminant: Introductie BTW-determinant: B.13 Triangulation: Boolean Als partijen zich in verschillende landen binnen de EU bevinden wordt het gecompliceerder. Er is altijd sprake van (een aantal) binnenlandse transacties gevolgd voor een intracommunautaire levering. Welke transacties geclassificeerd worden als binnenlands en welke als ICL, wordt bepaald door de transactie in het kader waarvan het vervoer plaatsvindt. Daarom is in de Order klasse het boolean-veld TransportParty weergegeven (zie Figuur 4.3), waarmee aangeven kan worden of de klant het vervoer verzorgt. Hiermee wordt de partij die het vervoer verzorgt als BTW-determinant geïntroduceerd: Introductie BTW-determinant: B.15 TransportParty: Boolean Omdat hierbij extra BTW-registratieverplichtingen voor tussenhandelaren op kunnen treden, is in de Wet OB 24 en de Zesde Richtlijn 25 een regeling opgenomen voor vereenvoudigde driehoekstransacties waarmee deze registratieverplichtingen worden vermeden. Hieraan is een aantal voorwaarden verbonden die zijn beschreven in Bijlage L.2. De vereenvoudigde driehoekstransactie wordt opgevoerd als BTW-determinant: Introductie BTW-determinant: B.14 SimplifiedTriangulation: Boolean Fiscale eenheid Verschillende organisaties die belastingplichtig zijn kunnen gezamenlijk een fiscale eenheid vormen 26. Dit kan uitsluitend als er op financieel, organisatorisch en economisch gebied een verwevenheid bestaat tussen de organisaties. Het directe gevolg hiervan is dat ze geen BTW hoeven te verrekenen als ze belastbare prestaties aan elkaar verrichten. Daarom moet bij de bepaling van BTW worden bekeken of de twee partijen waartussen een belastbare prestatie plaatsvindt een fiscale eenheid vormen. Dit wordt gecontroleerd door het bijhouden van de fiscale eenheid waarvan de klant en afnemer onderdeel uitmaken. De volgende twee BTW-determinanten worden hiervoor geïntroduceerd: 24 Art. 30 lid 2, 30a, 35 lid 1 sub g Wet OB [WetOB, 1968] 25 Art. 28 quater E lid 1 Zesde Richtlijn [EEG, 1977] 26 Art. 7 lid 4 Wet OB [WetOB, 1968] 35

57 BTW IN BEDRIJFSPROCESSEN Introductie BTW-determinant: B.11 VATGroupSupplier: Number Introductie BTW-determinant: B.12 VATGroupCustomer: Number BTW-advisering Binnen de marktcontext met betrekking tot BTW speelt een aantal derde partijen een rol die bedrijven ondersteunen bij het voldoen aan BTW-wetgeving. Enerzijds zijn dit partijen die adviseren omtrent BTW-wetgeving, zoals KPMG. Anderzijds partijen die voorzien in ERP-software waarmee bedrijven BTW-regels verankeren in de bedrijfsvoering. Omdat deze partijen een rol spelen bij de vraag-aanbod wisselwerkingen tussen toeleveranciers en afnemers, zijn deze partijen in het domeinmodel uit Figuur 4.3 geplaatst. Deze partijen vormen de overige stakeholders in dit onderzoek. Zij kunnen inspelen op de problemen die bedrijven met ERP-systemen hebben en opportunities benutten. Na installatie en customizing van het ERP-systeem, voorzien de ERP-vendors bedrijven in nieuwe updates en releases. Adviesbureaus (TAXERPconsultant) ondersteunen bij ERP-implementaties en specifieke advisering omtrent ERP-systemen in combinatie met BTW-wetgeving. De klasse Organization is een invulling van de generieke klasse Company. BTW-veranderingen worden in de huidige situatie niet systematisch afgehandeld door de verschillende partijen. Er wordt van geval tot geval bekeken voor wie de verandering gevolgen heeft en welke impact deze gevolgen hebben. De eventueel benodigde aanpassingen aan het ERP-systeem zijn niet af te leiden uit kennisvastlegging van de BTW-ERP context. Bedrijven schakelen adviesbureaus in voor het oplossen van ERP-problemen. Omdat geen kennisvastlegging aanwezig is worden dit soort oplossingen vaak kostbare aangelegenheden omdat problemen telkens van begin tot eind moeten worden bekeken en geen informatie kan worden hergebruikt. 4.2 BTW in Bedrijfsprocessen De marktcontext van BTW is beschreven en de BTW-determinanten zijn afgeleid. De invulling van de BTW-determinanten vindt vanuit de bedrijfsvoering plaats. Daarom wordt in deze sectie vastgesteld hoe binnen bedrijven een BTW-plicht ontstaat door het beschrijven van de omzetgenererende processen. Net als voor BTW wordt voor het positioneren van ERP eerst een bedrijfscontext beschreven van waaruit de huidige situatie wordt beschreven. Er wordt afgesloten met de bespreking van BTW-bepaling voor een specifiek ERP-systeem Beschrijving bedrijfscontext Alle bedrijven hebben met BTW te maken. BTW zit verankerd in meerdere bedrijfsprocessen die worden ondersteund door ERP-systemen. Risicoverlaging op operationeel-, financieel- en regelgeving vlak is een doelstelling van het gebruik van ERP-systemen. In de BTW-ERP context wordt vooral aandacht besteed aan de risico s met betrekking tot regelgeving (BTW-wetgeving). Het bedrijfsdomeinmodel (BDM) wordt opgebouwd aan de hand van hetzelfde generieke deel dat is opgesteld voor het marktdomein (zie sectie 4.1.4). 36

58 4.2. BTW IN BEDRIJFSPROCESSEN 37 De specifieke invulling van het bedrijfsdomein is weergegeven in Figuur 4.5. De BTW-determinanten zijn net als in het MDM in het rood weergegeven. Niet alle BTWdeterminanten komen terug in het BDM. Er is geen aparte klasse voor de eigenschappen van het desbetreffende bedrijf weergegeven, omdat dit geen onderdeel uitmaakt van de bedrijfsprocessen die relevant zijn voor de BTW. Deze klasse komt wel terug in het MDM waarin bedrijven als klasse worden weergegeven. De BTW-determinanten die uit die klasse volgen komen daarom niet terug in het BDM. ERP-systemen zijn een invulling van de klasse InstitutionalObject uit het generieke deel (zie Figuur 4.3) waaraan BTW-wetgeving functionele eisen stelt. De vraag-aanbod wisselwerkingen maken onderdeel uit van een Contract tussen entiteiten uit de klasse Principal door middel van de klasse Invoice. Bedrijfsprocessen zijn gekoppeld aan de generieke klasse Company en veroorzaken risico s die door middel van de Risk klasse in het domeinmodel weergegeven zijn. Figuur 4.5: Bedrijfsdomein BTW-ERP context 37

59 BTW IN BEDRIJFSPROCESSEN De klasse Invoice bevat een drietal specialisatieklassen waarin relevante informatie met betrekking tot de bepaling van BTW te vinden is. SalesLine geeft informatie over de producten op de factuur. Gegevens over betalingen worden bijgehouden in PaymentLine en informatie over de factuur- en goederenstroom wordt opgeslagen in de klasse TransportData Omzetgenererende processen De basis voor een BTW-plicht is de belastbare prestatie (zie sectie 4.1.4). Een belastbare prestatie ontstaat door een waardetoevoeging in de waardeketen. Een bedrijf voegt waarde toe aan een product en verkoop dit aan haar klanten. Aan dit product kan vervolgens opnieuw waarde worden toegevoegd totdat het belandt bij de eindgebruiker. In Figuur 4.6 is dit proces weergegeven. Een BTW-plicht ontstaat tijdens het verkoopproces waarbij twee partijen een rol spelen: de leverancier en de afnemer. De leverancier (supplier) stuurt de goederen naar de afnemer (customer) en ontvangt een betaling van de afnemer. De betaling die de afnemer verricht bestaat uit twee delen. Het eerste deel (payment) is de belastbare vergoeding die netto omzet voor zijn leverancier vormt. Het andere deel (tax payment) is een percentage van de belastbare vergoeding die hij als BTW aan zijn afnemer betaalt. Dit deel draagt de leverancier af aan de Belastingdienst (TAX authorities). Hiermee wordt BTW tevens geïllustreerd als een indirecte vorm van belasting. Figuur 4.6 laat één omzetgenererende stap in de totale waardeketen zien. Dit proces wordt herhaald totdat het eindproduct geproduceerd is. De afnemer wordt in de volgende stap de leverancier voor een nieuwe afnemer. De store-toestand ERP-system dient als ondersteunend middel voor deze omzetgenererende processen. Gegevens die in de transacties worden gebruikt worden opgeslagen in de database van het ERP-systeem en weer aangeroepen tijdens andere processen. Figuur 4.6: BTW-plicht in de waardeketen In Figuur 4.6 is gekeken naar het ontstaan van een BTW-plicht. Als deze BTW-plicht is vastgesteld bestaat de volgende stap uit het uitwerken van de bedrijfsactiviteiten die invloed heb- 38

60 4.2. BTW IN BEDRIJFSPROCESSEN 39 ben op de BTW-bepaling. Deze bedrijfsactiviteiten worden ondersteund door middel van ERPsystemen. In Figuur 4.7 zijn de bedrijfsactiviteiten verder uitvergroot. Er worden twee economic events gekoppeld aan het procesmodel voor de omzetgenerering. Verkoop (Sale) start met het ontvangen van een order waarin goederen worden besteld en worden afgeleverd. Het verkoopproces eindigt met de betaling van BTW aan de Belastingdienst. BTW-berekening (VAT calculation) is een subproces van het verkoopproces. Als de factuur wordt verstuurd, wordt de BTW berekend door het ERP-systeem. Na het versturen van de factuur eindigt het BTW-berekeningsproces. Deze twee processen komen terug in het BDM uit Figuur 4.5. De klassen SalesProcess en VATdeterminationProcess komen overeen met respectievelijk Sale en VAT calculation. Naast deze twee processen is in het BDM een derde subproces van de klasse BusinessProcesses weergegeven. De klasse TransportProcess komt overeen met de processen tussen de toestanden i send goods en o send goods uit Figuur 4.7. Hierin wordt de route van het vervoer bepaald. Zoals eerder beschreven speelt de plaats van de belastbare handeling een rol bij de bepaling van de BTW, zie sectie Figuur 4.7: Economic activity bij BTW-berekening De relatie tussen enerzijds het procesmodel uit Figuur 4.7 dat de koppeling legt tussen de economic activity van bedrijven en de relevante processen voor de bepaling van BTW en anderzijds het MDM en BDM is beschreven in Bijlage L.4. De bedrijfsprocessen die relevant zijn voor het ontstaan van een BTW-plicht zijn beschreven. Deze bedrijfsprocessen veroorzaken risico s waarbij ERP-systemen worden ingezet om deze te reduceren. In de volgende sectie worden ERP-systemen geïntroduceerd. Er wordt een korte ontstaansgeschiedenis beschreven en de ERP-markt en -vendors worden uiteengezet. 39

61 ENTERPRISE RESOURCE PLANNING SYSTEMEN Vervolgens wordt aan de hand van het bedrijfsdomein de positie en rol van ERP-systemen met betrekking tot BTW-bepaling beschreven in de huidige situatie. 4.3 Enterprise Resource Planning Systemen Enterprise Resource Planning (ERP) Systemen kennen een sterke opkomst vanaf eind jaren 80. Hoewel pas sinds begin jaren 90 een sterke groei van behoefte aan ERP-systemen is ontstaan, ligt de basis voor de ontwikkeling van ERP-systemen al in de jaren 60. De focus van productiesystemen was sterk gericht op voorraadbeheer. De meeste softwarepakketten waren gebaseerd op maatwerk en ontworpen voor ondersteuning bij voorraadbeheer met traditionele voorraadmodellen als basis. In de jaren 70 verschoof de focus naar Material Requirements Planning (MRP-I) Systemen voor het plannen en besturen van de productie. Bij MRP-I wordt aan de hand van stukslijsten en een voorspelde vraag naar producten via het hoofdproductieschema berekend welke productieorders en inkooporders te verwachten zijn [Wikipedia, 2006]. In de jaren 80 ontwikkelden MRP-I systemen zich verder tot Manufacturing Resource Planning (MRP-II) systemen dat begon met een gezamenlijke planning en het beheren van vraag en eindigde met een schema dat zowel componenten bevat die intern moeten worden geproduceerd als componenten die van buitenaf moeten worden verworven. MRP-II houdt in tegenstelling tot MRP-I ook rekening met capaciteiten van mensen en machines MRP-II wordt daarom gezien als een aanvulling op MRP-I [Gupta and Kohli, 2006]. Tegelijkertijd werden binnen andere functionele gebieden informatiesystemen ontwikkeld en geïmplementeerd maar een totaalpakket dat deze pakketten integreerde ontbrak nog. De behoefte ontstond aan één systeem dat de functionaliteiten bezat van bestaande pakketten die ondersteuning boden aan het beheren van bedrijfsprocessen. In het begin van de jaren 90 werden MRP-II systemen verder uitgebreid met functionaliteiten op het gebied van engineering, finance, human resources en projectmanagement. Deze nieuwe generatie systemen werden de ERP-systemen. Vanaf 2000 zijn de bestaande ERP-systemen uitgebreid met nieuwe modules voor onder andere customer relationship management (CRM), supply chain management (SCM) en advanced planning and scheduling (APS) en ontstonden de zogenaamde extended ERP-systemen ERP-markt en -vendors De ERP-softwaremarkt is een van de grootste en meest complexe markten van de gehele technologie industrie [Callaway, 2000]. Er zijn honderden ERP-vendors, waardoor de onderlinge concurrentie erg groot is en het lastig is om onderscheidbaar te zijn. De top 5 van ERPvendors bestaat op dit moment uit 27 : SAP ( Oracle ( Sage Group ( Microsoft Business Solution ( en SSA Global ( Andere bekende spelers in deze markt waren PeopleSoft, dat in 2005 over is genomen door Oracle en J.D. Edwards dat in 2003 is overgenomen door PeopleSoft. Het Nederlandse Baan dat eind jaren 90 nog een prominente rol speelde in de markt is in 2003 overgenomen door SSA Global. SAP is marktleider met een marktaandeel van ongeveer 45%, gevolgd door Oracle met 20%. 27 bron: AMR Research,

62 4.3. ENTERPRISE RESOURCE PLANNING SYSTEMEN ERP en BTW Er is een markt- en een bedrijfsdomein besproken waarbinnen ERP-systemen opereren en BTW-determinanten zijn geïdentificeerd. De omzetgenererende processen die relevant zijn voor het ontstaan van een BTW-plicht zijn beschreven. ERP-systemen ondersteunen het verloop van de omzetgenererende processen. Het ERPsysteem genereert facturen waarop het BTW-tarief wordt vermeld. BTW wordt intern door het ERP-systeem bepaald. In het BDM is dit proces weergegeven door de klasse VATdeterminationProcess (zie Figuur 4.5). Het veld ERPsystem.DeterminationRules maakt gebruikt van de BTW-determinanten uit de klasse VATdeterminants. In deze klasse zijn factoren beschreven waarvan ERP-systemen in de huidige situatie gebruik maken bij de bepaling van BTW. Deze klasse wordt beïnvloed door de klasse Restriction (BTW-wetgeving) uit het generieke deel van het bedrijfsdomein. Als de BTW-determinanten die in VATdeterminants beschreven zijn een toereikende verzameling BTW-determinanten bevat om BTW te kunnen bepalen en op de juiste manier worden gebruikt door het ERP-systeem, verloopt het BTWbepalingsproces correct. De BTW-bepalingsregels zijn dan in overeenstemming met de regels die door BTW-wetgeving voorgeschreven worden. Elk ERP-systeem heeft zijn eigen manier van BTW-bepaling. Daarom is gekozen om de BTW-bepaling uitgebreider te bekijken voor een specifiek ERP-systeem. De keuze hiervan is bepaald door twee factoren. Ten eerste moet het ERP-systeem een representatief marktaandeel hebben, zodat de impact van de conclusies zo groot mogelijk is. Ten tweede moet het ERP-systeem gebruikt worden door klanten van KPMG IRM, omdat zij zoveel mogelijk problemen bij klanten willen bedienen identificeren en oplossen. De keuze is gevallen op het ERP-systeem SAP R/3. Dit systeem voldoet het meest aan de hierboven gestelde criteria. In de volgende sectie wordt SAP R/3 geïntroduceerd en wordt het huidige BTW-bepalingsproces binnen SAP R/3 uitgebreid beschreven SAP R/3 Systems, Applications, Products in Data Processing (SAP) is marktleider op het gebied van Enterprise Business Software Solutions. SAP wordt gebruikt door meer dan 12 miljoen gebruikers in ruim 50 landen. R/3 is de client/server versie van SAP. Haar voorloper R/2 opereert in een mainframe omgeving en wordt steeds minder gebruikt. SAP R/3 was het eerste client/server-systeem dat een integrale oplossing bood voor alle bedrijfsfuncties binnen grote ondernemingen. Door de client/server-architectuur stelt R/3 bedrijven in staat optimaal gebruik te maken van nieuwe technologieën, zoals relationele database-systemen, grafische gebruikersinterfaces en open systemen [Curran and Keller, 1999]. In het vervolg van dit verslag zal telkens over SAP worden gesproken. Hiermee wordt telkens SAP R/3 bedoeld. SAP is niet functiegeoriënteerd maar gaat uit van processen die werken met zogenaamde bedrijfsobjecten zoals order, bestelling en factuur. Deze bedrijfsobjecten kunnen door parametrisering als verschillende vormen worden geconfigureerd zodat SAP geschikt is voor het modelleren van uiteenlopende processen. In Bijlage D.1 is de client/server architectuur van SAP R/3 uitgebreider beschreven. 41

63 ENTERPRISE RESOURCE PLANNING SYSTEMEN R/3 referentiemodel SAP heeft haar voorgedefinieerde bedrijfsprocessen vastgelegd in het R/3 referentiemodel. Dit referentiemodel bevat een complete functionele beschrijving van SAP R/3 en biedt een uitgebreid overzicht van alle processen en oplossingen die in het systeem zijn opgenomen. Het referentiemodel wordt gebruikt als uitgangspunt voor het ontwerp van de bedrijfsprocessen. Versie 3.0 van SAP kent meer dan 800 voorgedefinieerde bedrijfsprocessen met varianten voor verschillende ondernemingen of industrietakken [Curran and Keller, 1999]. Modules SAP is opgebouwd uit een aantal modules die een bepaald gebied van de ondernemingsactiviteiten ondersteunen. De belangrijkste drie zijn de financiële module (financial), de logistieke module (logistics) en de personeelsmodule (human resources). Deze modules zijn opgebouwd uit een aantal submodules die elk ondersteuning bieden aan het beheer van een deel van de organisatie. Een uitgebreide beschrijving van de modules is te vinden in Bijlage D.2. SAP pricing In het kader van dit onderzoek speelt het pricing onderdeel van SAP een cruciale rol. De term pricing wordt gebruikt voor het beschrijven van de manier waarop prijzen berekend worden in SAP. Hierbij wordt gebruik gemaakt van de condition technique. Conditions stellen een aantal omstandigheden voor die zich voordoen bij de berekening van een prijs. Ter illustratie, een klant bestelt een hoeveelheid van een bepaald product op een bepaalde dag. De variabele factoren die hier een rol spelen zijn: klant, product, hoeveelheid en datum. Deze factoren bepalen de uiteindelijke prijs die de klant moet betalen. Alle informatie over elk van deze factoren wordt opgeslagen als masterdata (zie Bijlage D) in de vorm van condition records. SAP condition technique De SAP condition technique is een belangrijk onderdeel van het pricingmechanisme van SAP. De sales and distribution module van SAP gebruikt de condition technique voor het bepalen van verschillende soorten gegevens, zoals: Welke prijzen en kortingen van toepassing zijn. Naar welk grootboek het systeem een boeking moet doen. Welke belastingen van toepassing zijn op een transactie. Welke teksten op documenten worden geprint. De condition technique bestaat uit vijf hoofdelementen [SAP, 2001],[SAP, 2006]: Condition types Een condition type is een representatie van een aantal aspecten van dagelijkse activiteiten in het systeem. Het is mogelijk om condition types te definiëren voor verschillende typen prijs, korting of toeslag die voorkomen in bedrijfstransacties. Procedures Een procedure is een groep van condition types, opgesteld in een bepaalde volgorde. Op 42

64 4.3. ENTERPRISE RESOURCE PLANNING SYSTEMEN 43 deze manier stelt het systeem vast dat een verzameling condition types in een bepaalde volgorde wordt toegepast in een gegeven omstandigheid. Procedure bepaling De bepaling van de procedure is afhankelijk van het onderwerp en de geldende omstandigheden. De bepaling van de pricing procedure is afhankelijk van een combinatie van sales organization, distribution channel, division, sales document type en customer master record information. Condition records en condition tables Een condition table legt de combinatie van velden vast (key) die een condition record vaststelt. Door middel van condition records slaat het systeem specifieke conditiegegevens op die ingevoerd worden in condition tables. Bij het invoeren van de prijs van een product of een speciale korting voor een klant worden afzonderlijke condition records gemaakt. Access sequences Een access sequence is een zoekstrategie die het systeem gebruikt voor het vinden van geldige data voor een specifiek condition type. De volgorde waarin het systeem naar data zoekt wordt vastgelegd. De onderdelen van de access sequence bepalen waar het systeem als eerste moet zoeken, waar vervolgens etc, totdat een geldig condition record is gevonden. Voor elk condition type waarvoor condition records zijn gedefinieerd moet een access sequence worden gespecificeerd. Figuur 4.8: Pricing in SAP Figuur 4.8 geeft de relaties tussen de elementen van de condition technique weer. Voor het bepalen van de prijs zijn vijf stappen geïdentificeerd: 43

65 ENTERPRISE RESOURCE PLANNING SYSTEMEN 1. Het systeem stelt de pricing procedure vast op basis van de gegevens uit het sales document (SD) en de customer master record. 2. De pricing procedure bevat condition types en de volgorde waarin ze voorkomen in de sales order. 3. De access sequence die aan de condition type kan zijn toegewezen wordt vastgesteld. 4. De access sequence bevat regels die zijn gekoppeld aan een condition table die keys verschaft waarmee het systeem naar condition records zoekt 5. Het systeem stelt de prijs vast zoals deze is opgeslagen in de condition record. In Figuur 4.8 is te zien dat voor elk sales document item (orderregel) een pricing procedure wordt bepaald. Wanneer een sales document uit meerdere items bestaat en elk van deze items verschillende pricing procedures, condition types etc. bevat kan dit de prestaties van het systeem in negatieve zin beïnvloeden. Bij het werken met de condition technique moet daarom rekening worden gehouden met de gevolgen die de inrichting heeft op de prestaties van het systeem. Figuur 4.9: Toepassing van condition technique bij een sales order Figuur 4.9 geeft een specifieke invulling aan het pricing process zoals dat in Figuur 4.8 is beschreven. De vijf stappen corresponderen met de stappen die hierboven beschreven zijn. Er is te zien dat de eerste entry van access sequence PR00 geen geldig condition record vindt. De tweede entry vindt een geldig record waarin is vastgelegd dat bij de bepaling van de prijs schaling (scale) moet worden toegepast zoals gespecificeerd in de condition record. Bij de 120 items die in de order besteld worden hoort een overeenkomstige prijs van 99 euro. BTW-berekening Bij de berekening van BTW in SAP wordt gebruik gemaakt van de condition technique die hierboven beschreven is. Het krachtige van de condition technique is dat deze in zeer hoge mate 44

66 4.3. ENTERPRISE RESOURCE PLANNING SYSTEMEN 45 gecustomized kan worden en daardoor erg flexibel is. De keerzijde is echter dat het daardoor erg complex en ingewikkeld wordt. Het gevolg hiervan is dat de inrichting van SAP met betrekking tot BTW meestal niet op maat plaatvindt maar dat bedrijven de standaardinrichting van SAP gebruiken bij de berekening van BTW. SAP kent een aantal voorgedefinieerde pricing procedures en condition types die voor de meeste bedrijven voldoende functionaliteit bieden. Met betrekking tot BTW kent SAP de condition type MWST. De meeste standaard pricing procedures, zoals RVAA01, maken gebruik van deze condition type voor de BTW. In de condition type MWST is vastgelegd dat de output een percentage moet zijn. Aan de condition type MWST is een access sequence gekoppeld met overeenkomstige benaming. Deze access sequence gaat drie dingen na: Type transactie Betreft het een binnenlandse of buitenlandse transactie? Dit is afhankelijk van het type transactie en is af te leiden uit de ordergegevens. BTW-classificatie klant Is de klant een belastingplichtige? De klantinformatie is vastgelegd in de masterdata. Item-classificatie Onder welke tariefklasse valt het product? Productinformatie is vastgelegd in de masterdata. Deze drie determinanten zijn weergegeven in de klasse VATdeterminants in het BDM. De bepaling van DomesticTransaction wordt door de volgende OCL-expressie uit het BDM afgeleid: CONTEXT Invoice INV: self.domestictransaction = (TransportData.TransportRoute.Origin = TransportData.TransportRoute.Destination) Op basis van bovenstaande drie BTW-determinanten bepaalt SAP welk BTW-tarief uiteindelijk gekozen wordt. Figuur 4.10 toont de werking van MWST volgens de vijf stappen die eerder zijn beschreven. Met betrekking tot binnenlandse transacties biedt de condition type MWST voldoende dekking voor de berekening van BTW. Bij ingewikkeldere transacties zoals intracommunautaire leveringen (zie Hoofdstuk 4.1.4) biedt BTW-bepaling op basis van deze drie transactie-eigenschappen onvoldoende dekking. Ter illustratie: Partij A gevestigd in België koopt goederen van Partij B die gevestigd is in Nederland. Partij A verkoopt de goederen rechtstreeks door aan Partij C die ook in Nederland is gevestigd. Partij A geeft Partij B de opdracht de goederen direct naar Partij C te sturen. De drie partijen zijn Liable for tax en de goederen vallen onder het hoge tarief (Full tax). De vraag is nu welk BTW-tarief Partij A op zijn factuur aan Partij C moet vermelden. Om dit te kunnen bepalen is naast de eerder genoemde eigenschappen (binnenlandse/buitenlandse transactie, tax classification customer en tax classification material) van belang te weten vanuit welk land de goederen worden vervoerd (BTW-determinant: B.5 45

67 SAMENVATTING Ship-from-Country) en in het kader van welke transactie (B-A of B-C) het goederenvervoer plaatsvindt (BTW-determinant: B.15 TransportParty). In dit geval zou SAP het nultarief toepassen terwijl bij deze transactie het hoge tarief in België op de factuur van A naar C moet staan. Standaard inrichting van SAP biedt voor dit soort transacties te weinig dekking. Door middel van customizing van BTW-condition types kunnen complexere transacties als bovengenoemde worden afgedekt. Figuur 4.10: Werking van condition type MWST 4.4 Samenvatting In dit hoofdstuk is de huidige situatie van de BTW-ERP context modelsgewijs beschreven. Generieke domeinmodellen zijn voor een markt- en bedrijfscontext ingevuld aan de hand van de beschrijving van BTW-wetgeving en identificatie van bedrijfsprocessen waarop het BTW-proces invloed heeft. Bij de beschrijving van de opbouw van BTW-wetgeving zijn systematisch BTW-determinanten geïntroduceerd die benodigd zijn bij de bepaling van BTW. De rol van ERP-systemen is uiteengezet en voor een specifiek ERP-systeem (SAP R/3) is onderzocht hoe met BTW-bepaling wordt omgegaan en welke BTW-determinanten worden gebruikt. Er is vastgesteld dat de standaard BTW-bepalingsregels van SAP R/3 in een aantal gevallen onvoldoende dekking bieden voor de correcte afhandeling van BTW omdat niet alle benodigde BTW-determinanten worden meegenomen. In deze gevallen bestaat er een kloof tussen de inrichting van het ERP-systeem en de regels die BTW-wetgeving voorschrijft. In het BDM veroorzaakt de klasse VATdeterminants de onvolledige brug tussen BTW-wetgeving en het ERP-systeem. Deze klasse moet aangepast worden om de kloof te overbruggen. Om deze brug zo constructief mogelijk te bouwen, moet eerst meer inzicht worden verkregen in de verschillende redenen die ten grondslag liggen aan het ontbreken van een volledige brug. In het volgende hoofdstuk wordt de BTW-ERP kloof vanuit stakeholderperspectief geanalyseerd en worden met de verkregen inzichten de ontwerpeisen beschreven waaraan het moet voldoen. 46

68

69 Hoofdstuk 5 Analyse BTW-ERP context In het vorige hoofdstuk is de huidige situatie met betrekking tot BTW en ERP modelsgewijs beschreven. Er is vastgesteld dat er een kloof bestaat doordat de huidige BTW-bepaling in ERPsystemen niet alle BTW-determinanten toepast die noodzakelijk zijn. Figuur 5.1 geeft schematisch weer hoe de BTW-ERP context in dit hoofdstuk geanalyseerd wordt. Figuur 5.1: Schematisch overzicht analyse BTW-ERP context Eerst wordt een stakeholderanalyse gehouden om de doelstellingen en belangen van de verschillende partijen inzichtelijk te maken. De kloof levert voor bedrijven directe problemen op, waardoor voor KPMG opportunities ontstaan. Voor andere partijen ontstaan niet direct problemen maar kunnen door het ontwerp van een BTW-ERP oplossing opportunities tot samenwerkingen ontstaan. De probleemgebaseerde oorzaken en de opportunities die daardoor ontstaan worden door middel van een oorzaak- gevolg analyse overzichtelijk in kaart gebracht door middel van een Interrelationship Digraph [Brassard, 1989]. Vervolgens worden kernoorzaken voor de problemen geformuleerd die ontwerpeisen aan het 48

70 5.1. STAKEHOLDERANALYSE 49 BTW-ERP model vaststellen. 5.1 Stakeholderanalyse Om inzicht te verkrijgen in de doelstellingen en belangen van de stakeholders in het collaboratieve BTW-ERP proces is voor elke stakeholder een Balanced Scorecard (BSC) ingevuld. Een introductie tot de BSC is beschreven in Bijlage B.1. De missies en visies van de stakeholders zijn vastgesteld. De missie verschaft inzicht in de primaire doelstellingen en verduidelijkt vanuit welke perspectieven organisaties opereren. Door de identificatie van (globale) indicatoren in de BSC kunnen uitspraken worden gedaan over de belangen van een BTW-ERP model met betrekking tot de stakeholders. Om een breder beeld te krijgen van de stakeholders buiten de BTW-ERP context is voor elke stakeholder een kwalitatieve beschrijving gegeven van de actuele marktcontext en ontwikkelingen. Hierbij is gebruik gemaakt van Actor-Network Theory [Latour, 1987]. Actor-Network Theory (ANT) is een methodiek waarmee inzicht wordt verkregen in innovatieprocessen. ANT legt de nadruk op wisselwerkingen van factoren die het innovatieproces beïnvloeden. Een BTW-ERP model vormt een sociaal-geconstrueerde oplossing voor de kloof tussen BTW-wetgeving en de inrichting van een ERP-systeem. Technologie (ERP) dient de sociale context in de vorm van wetgeving. Hoe deze technologie eruit gaat zien wordt bepaald door invloeden van sociale groepen als Belastingdienst, ERP-distributeurs en KPMG. De Balanced Scorecards vervullen onderdelen van het Value and Risk Model (VARM) (zie sectie 3.4.2) in de markt- en bedrijfsrepository. De overige resultaten van de stakeholderanalyse zijn weergegeven in Bijlage F. 5.2 Oorzaak- en gevolg analyse Het doel van de oorzaak- en gevolg analyse is het identificeren van oorzaken die ten grondslag liggen aan de BTW-ERP kloof, hierin verbanden aan te brengen en te komen tot kernoorzaken die aan moeten worden gepakt door het gekozen ontwerp. De oorzaken van het ontstaan van een BTW-ERP kloof en bijbehorende gevolgen voor de behoefte aan een BTW-ERP model worden opgesplitst in twee soorten. Enerzijds zijn dit oorzaken die ontstaan vanuit problemen die bedrijven hebben. Anderzijds zijn er oorzaken die ontstaan uit opportunities die bedrijven willen benutten Probleemgebaseerde oorzaken De probleemgerichte oorzaken zijn per stakeholder weergegeven in Figuur 5.2. Er is een ordening aangebracht in het type probleem. Strategisch: lange termijn, Tactisch: middellange termijn en Operationeel: korte termijn. De taak van BTW-wetgeving is het voorschrijven van wetten en regels. Zij zijn niet verantwoordelijk voor de voorschriften van uitvoering van wetgeving. Bedrijven mogen zelf invullen welke middelen ze gebruiken bij de naleving van wetgeving. Als de uitvoerbaarheid laag is ontstaan risico s bij bedrijven doordat ze niet weten hoe de wetgeving toegepast moet worden in de ERP-systemen. De noodzakelijke kennis hiervoor is niet aanwezig binnen bedrijven. Een andere strategische oorzaak komt voort uit het feit dat de impact van BTW-ERP wordt onderschat bij bedrijven. Er wordt tijdens lange ERP-implementatietrajecten nauwelijks aandacht besteed 49

71 OORZAAK- EN GEVOLG ANALYSE aan het BTW-aspect. Daarom wordt hiervoor vaak standaardconfiguratie gebruikt. In de beschrijving van de huidige situatie is aangetoond dat dit geen optimale BTW-bepaling oplevert. Figuur 5.2: Interrelationship Digraph - Probleemgerichte oorzaken ERP-vendors beschikken over onvoldoende fiscale kennis om de ingewikkelde BTW-regels te verankeren in het ERP-systeem. Deze organisaties zijn sterk IT-georiënteerd waardoor bij ERPimplementaties nauwelijks fiscalisten worden betrokken om de noodzakelijke specialistische kennis te voorzien. ERP-implementatietrajecten duren erg lang omdat de gehele bedrijfsvoering ondersteund wordt en dit complexe eisen aan het ERP-systeem stelt. De gele blokjes tonen de kernoorzaken die allen uiteindelijk leiden tot BTW-risico s voor bedrijven (rode blokje). In de volgende sectie worden deze risico s als basis genomen voor de identificatie van factoren die bijdragen aan de bereidheid tot het dichten van de BTW-ERP kloof Opportunities De oorzaken van het ontstaan van een BTW-ERP kloof zijn vastgesteld. De verschillende stakeholders hebben elk eigen belangen bij het dichten van deze kloof. In deze sectie worden factoren beschreven die de bereidheid van de stakeholders verduidelijkt tot de ontwikkeling van een BTW- ERP model. Deze factoren en de onderlinge relaties zijn weergegeven in Figuur

72 5.2. OORZAAK- EN GEVOLG ANALYSE 51 Het rode vlak vormt de directe aanleiding voor opportunities dat ook uit de probleemgerichte oorzaken volgde. De groene factoren zijn de belangrijkste punten die op strategisch vlak bediend kunnen worden bij de ontwikkeling van een BTW-ERP oplossing. Figuur 5.3: Interrelationship Digraph - Deugdzame keten van oorzaken KPMG IRM heeft een samenwerking met KPMG Meijburg (belastingadviseurs) opgezet omdat tijdens belastingadviesprojecten bleek dat de projectresultaten in de vorm van BTW-strategieën moeilijk uitvoerbaar bleken in ERP-systemen van grotere ondernemingen. Hierdoor ontstaan nieuwe BTW-risico s. KPMG Meijburg heeft niet de IT-kennis in huis om dit implementatietraject uit te voeren. IRM heeft ruime kennis op dit gebied en wil graag innovatieve dienstverlening aan klanten aanbieden. Uit deze context is dit onderzoek voortgevloeid. IRM wil met deze nieuwe dienstverlening BTW-ERP risico s bij klanten reduceren en bekijken of er samenwerkingen mogelijk zijn met andere partijen zoals ERP-vendors. Voor deze partijen kunnen samenwerkingen interessant zijn omdat de inzichten vanuit fiscaal perspectief de kwaliteit van ERP-systemen kunnen verhogen. Voor een partij als de Belastingdienst zijn samenwerkingen interessant omdat deze aansluiten bij het intensiveren van toepassing van horizontaal toezicht (zie Bijlage F) Kernoorzaken De belangrijkste kernoorzaak van de BTW-ERP kloof is het ontbreken van een uitvoerbaar model voor BTW-wetgeving. Een uitvoerbaar model vormt de noodzakelijke brug tussen wetgeving en 51

73 ONTWERPEISEN het naleven van wetgeving door ondersteunende technologie. BTW-wetgeving stelt specifieke fiscale eisen aan ERP-systemen waarvoor de kennis ontbreekt bij de inrichters. De impact van BTW binnen het ERP-systeem wordt onderschat omdat het slechts een klein onderdeel van het ERP-implementatietraject is. ERP-systemen zijn zeer complexe systemen [Rosemann and Wiese, 1999] waardoor ze minder toegankelijk zijn voor niet-specialisten om BTW-wetgeving uitvoerbaar te maken. De belangrijkste factor voor de behoefte aan een BTW-ERP model is de reductie van BTWrisico s bij bedrijven. Deze risicoreductie kan worden bewerkstelligd door de ontwikkeling van een BTW-ERP service door KPMG waarmee met derde partijen als de Belastingdienst en ERPvendors samenwerkingen aan kunnen worden gegaan. Tabel 5.1: Kernoorzaken BTW-ERP Problemen (P) en Opportunities (O) Id P1 P2 P3 Beschrijving kernoorzaak/opportunity Er is gebrek aan een uitvoerbaar model voor BTW-wetgeving, waardoor bedrijven problemen hebben bij het naleven van BTW-wetgeving in ERP-systemen. ERP-systemen zijn complex waardoor specialistische ERP-kennis vereist is bij het bedrijfsspecifiek inrichten. De impact van BTW wordt onderschat bij een ERP-implementatietraject waardoor vaak voor een standaardoplossing wordt gekozen. O1 O2 O3 Risicoreductie in BTW-strategie bij ERP-gebruikers. Ontwikkeling van BTW-ERP dienstverlening door KPMG waarmee meer klanten kunnen worden bediend. Mogelijkheid tot aangaan van kennissamenwerkingen tussen partijen in de BTW-ERP context waarmee win-win situaties worden gecreëerd. 5.3 Ontwerpeisen In de vorige sectie is een aantal kernoorzaken vastgesteld voor de problemen in de BTW-ERP context. Het gebrek aan een uitvoerbaar model speelt hierbij een centrale rol. Dit wordt niet alleen veroorzaakt doordat voorschrijving van regels voor uitvoerbaarheid niet tot het takenpakket van BTW-wetgeving behoort, maar ook door het gebrek aan kennis op het snijvlak van IT en fiscaliteit. Het BTW-ERP model dat tijdens het ontwerp uitgewerkt gaat worden moet voldoen aan een aantal eisen om deze kernoorzaken aan te pakken: E.1 Het ontwerp moet implementatie-onafhankelijk zijn. Het model moet toepasbaar zijn voor meerdere ERP-systemen. E.2 Het ontwerp moet gepositioneerd zijn tussen BTW-wetgeving en ERPsystemen. Op deze manier fungeert het als een brug en maakt het BTW-wetgeving uitvoerbaar binnen ERP-systemen. 52

74 5.3. ONTWERPEISEN 53 E.3 Het ontwerp moet flexibel zijn. Bij omgevingsveranderingen zoals wijzigingen in BTW-wetgeving moet het model eenvoudig uit te breiden cq. aan te passen zijn aan de nieuwe BTW-eisen. E.4 Het ontwerp moet correct zijn. De BTW-bepaling moet gemodelleerd worden naar het gedrag dat BTW-wetgeving voorschrijft. E.5 Het ontwerp moet waarde toevoegen voor alle stakeholders. Dit verhoogt de mate waarin het model geaccepteerd wordt in de BTW-ERP context. Aan eis E.1 wordt tegemoet gekomen door de constructie van een Computation Independent Model (CIM). Hierin worden geen implementatie-aspecten gebruikt. Pas tijdens de implementatiefase wordt het CIM (deels) vertaald naar een Platform Specific Model (PSM). De positionering tussen BTW-wetgeving en ERP-systemen (E.2) vindt plaats doordat de huidige situatie modelsgewijs beschreven is vanuit een markt- en bedrijfsrepository en het ontwerp gericht is op de koppeling tussen beide repositories. Flexibiliteit (E.3) wordt gevalideerd door een veranderingsscenario uit te voeren en te beschrijven welke stappen ondernomen moeten worden om het ontwerp aan te passen aan de nieuwe situatie. De correctheid van het model (E.4) wordt gewaarborgd door nauw samen te werken met BTWspecialisten van KPMG Meijburg en willekeurige lastige BTW-situaties door het model uit te laten voeren en te toetsen op correctheid. Waardetoevoeging voor alle stakeholders (E.5) wordt gemeten door het opstellen van een waardemodel en het uitvoeren van een waarde- en risicoanalyse voor het BTW-ERP model door middel van de e 3 -value approach methodiek [Gordijn and Akkermans, 2003]. 53

75 Deel III Ontwerp 54

76

77 Hoofdstuk 6 Onderzoeksontwerp In het vorige hoofdstuk zijn de ontwerpeisen voor het BTW-ERP model afgeleid uit de kernoorzaken die ten grondslag liggen aan de problematiek in de BTW-ERP context. Aan de hand van deze ontwerpeisen wordt in dit hoofdstuk het ontwerp van het BTW-ERP model beschreven. Omdat flexibiliteit en waardetoevoeging belangrijke eisen zijn aan het ontwerp van het model, wordt in dit hoofdstuk extra aandacht besteed aan de mate waarin aan deze ontwerpeisen wordt voldaan. 6.1 Ontwerp van het BTW-ERP model Het BTW-ERP model (uitvoerbaar model) is gepositioneerd tussen BTW-wetgeving en ERPsystemen met de BTW-determinanten als koppeling. De systeemgrenzen van het BTW-ERP model zijn weergegeven in Figuur 6.1 als Use Case Diagram (UCD). Figuur 6.1: Systeemgrenzen van het BTW-ERP model 56

78 6.1. ONTWERP VAN HET BTW-ERP MODEL 57 Hierin zijn de activiteiten beschreven die het BTW-ERP model ondersteunt bij een tweetal use cases: 1. BTW-verandering (VAT change) 2. Maken verkooporder (Create sales order) BTW-verandering is een externe use case, omdat deze ontstaat door invloeden buiten het ERPsysteem. Het maken van een verkooporder is een interne use case die door middel van het ERP-systeem gegenereerd wordt. Het BTW-ERP model is geen systeem maar een model waarin kennis is vastgelegd in de context van BTW en ERP. Het model stuurt de keuze voor een configuratie van ERP-systemen die BTW optimaal faciliteert. Het UCD laat zien welke acties binnen de grenzen van het BTW-ERP model vallen en welke acties door het ERP-systeem of door ERP-gebruikers worden verricht. In Bijlage K.1 zijn de use cases gedetailleerd beschreven. Er is te zien dat het BTW-ERP model invulling geeft aan de waarden van de BTWdeterminanten (Fill-in VAT-determinants) en BTW-patronen identificeert (Identify VAT patterns). In de volgende twee secties worden deze twee activiteiten van het BTW-ERP model beschreven Invulling BTW-determinanten De invulling van de BTW-determinanten voorziet de BTW-determinanten van waarden die volgen uit de specifieke bedrijfscontext. De regels die hiervoor gelden volgen uit de Wet OB [WetOB, 1968] en de Zesde Richtlijn [EEG, 1977]. In Bijlage L.2 is per BTW-determinant beschreven welke stappen moeten worden gevolgd om deze van een waarde te voorzien. De koppeling met BTW-wetgeving is telkens aangegeven Identificatie BTW-patronen In theorie kunnen alle mogelijke combinaties van invullingen van BTW-determinanten leiden tot een invulling van BTW-eisen. In de praktijk zit er een sterke overlap in de vereisten die volgen uit de waarden van de BTWdeterminanten. Om vat te krijgen op die overlap is gekozen voor een onderverdeling in BTWpatronen. Een BTW-patroon representeert een gezamenlijke groep van invullingen van de BTWdeterminanten die dezelfde eigenschappen hebben. Elk BTW-patroon kan op deze manier afzonderlijk worden bekeken met betrekking tot de BTW-vereisten die daaruit volgen zonder daarbij het complete overzicht uit het oog te verliezen. Per BTW-patroon wordt de uitwerking rechtstreeks vertaald naar de configuratie-eisen voor het ERP-systeem. Door bij bedrijven te identificeren welke BTW-patronen voorkomen binnen de bedrijfsvoering worden de ERP-eisen overzichtelijk in kaart gebracht. In plaats van naar alle achttien BTW-determinanten te kijken wordt in eerste instantie gekeken naar zeven BTW-determinanten die na invulling de patronen vastleggen. 57

79 ONTWERP VAN HET BTW-ERP MODEL Figuur 6.2: Gedeelte uit het Pattern Determination Model De volgende zeven BTW-determinanten leggen de patronen vast: B.1 CountrySupplier, B.3 TaxableTransaction, B.4 Installation-or-Assembly, B.5 Ship-from-Country, B.6 Ship-to-Country, B.7 PlaceOfSupply en B.8 PlaceOfService. Per BTW-patroon wordt vervolgens dieper ingegaan op de overige BTW-determinanten die BTW-eisen beïnvloeden. Het Pattern Determination Model (PDM) legt op basis van deze zeven BTW-determinanten de verschillende BTW-patronen vast. Figuur 6.2 geeft een gedeelte van het PDM weer. De roodgekleurde tekst refereert naar de BTW-determinanten die bij keuzemomenten van toepassing zijn. In het PDM leidt een aantal keuzes van de invulling van de BTW-determinanten tot de output out of scope. Hierbij gaat het om de gevallen waarin de belastbare prestatie buiten de EU plaatsvindt en dus niet belast is binnen de EU. Dit is vaak het geval bij import van goederen. De BTW-wetgeving buiten de EU is niet geharmoniseerd en valt buiten de scope van dit afstudeeronderzoek BTW-patronen De output van het PDM bestaat uit de identificatie van BTW-patronen. De BTWpatronen zijn opgesplitst in vijf typologieën die bepaald worden door enerzijds een combinatie van SupplierCountry en Ship-from-Country en anderzijds het onderscheid tussen Installation-or-Assembly en TaxableTransaction = Service: Typologie 1 SupplierCountry in EU en Ship-from-Country in EU Typologie 2 SupplierCountry in EU1 en Ship-from-Country in EU2 Typologie 3 SupplierCountry niet in EU en Ship-from-Country in EU Typologie 4 Installation-or-Assembly in EU Typologie 5 TaxableTransaction = Service en in EU 58

80 6.1. ONTWERP VAN HET BTW-ERP MODEL 59 Binnen deze vijf typologieën worden de verschillende patronen geïdentificeerd gebaseerd op plaats van de belastbare prestatie. Voor typologieën 1, 2 en 3 wordt hierbij het onderscheid gemaakt tussen de richtingen van de goederenstroom (Ship-from-Country en Ship-to-Country). In typologieën 4 en 5 wordt onderscheid gemaakt tussen respectievelijk PlaceOfSupply en PlaceOfService. Op deze manier worden per typologie drie of vier BTW-patronen onderscheiden. Ter illustratie is hieronder een grafische weergave van Patroon 1b weergegeven: Figuur 6.3: Typologie 1 - BTW-patroon 1b SF staat voor Ship-from-Country en ST staat voor Ship-to-Country. Een situatie waarop dit patroon betrekking heeft is het geval dat een Duitse onderneming van een Franse klant de opdracht krijgt om een hoeveelheid computers af te leveren in Nederland. EU1 is in dit geval Duitsland, EU2 is Nederland en EU3 is Frankrijk. De factuur wordt verstuurd van Duitsland naar Frankrijk. De verschillende stippellijnen in Figuur 6.3 tussen Supplier en Customer representeren de factuurstroom Koppeling BTW-patronen aan BTW-eisen Het doel van de opsplitsing in BTW-patronen is het groeperen van patronen met dezelfde karakteristieken. Deze karakteristieken komen tot uiting in BTW-eisen waaraan moet worden voldaan op de factuur die wordt gegenereerd door het ERP-systeem. Om tot de invulling van de BTW-eisen te komen, moet na de identificatie van het BTW-patroon dieper worden ingegaan op karakteristieken van het patroon. Hierbij spelen de overige BTWdeterminanten een rol. Deze bepalen aan welke BTW-eisen de factuur moet voldoen. De factuurvereisten zijn binnen de EU sinds 20 december 2001 geharmoniseerd en vastgelegd in de Richtlijn tot harmonisatie van de factuurvereisten [EEG, 2001]. De Wet OB is conform deze richtlijn aangepast 1. Daarnaast is in de Uitvoeringsbeschikking omzetbelasting nog een aantal uitzonderingen op dit artikel opgenomen 2. De factuurvereisten die de Wet OB voorschrijft zijn te vinden in Bijlage C.5. 1 Art. 35a Wet OB [WetOB, 1968] 2 Art. 33 Uitv.besch. [Uitv.besch., 1968] 59

81 FLEXIBILITEIT BTW-ERP MODEL Figuur 6.4: Uitwerking BTW-patroon Figuur 6.4 geeft het beslissingsmodel van de uitwerking van een willekeurig BTW-patroon weer. De gele blokjes stellen de BTW-eisen voor die volgen uit een aantal keuzemomenten in het model. Deze BTW-eisen gelden specifiek voor het desbetreffende BTW-patroon. Deze output is op te delen in vier hoofdcategorieën: no VAT Er hoeft geen BTW in rekening te worden gebracht EUx-VAT Het tarief uit EU-land x is van toepassing EUx-VAT Customer De BTW is verlegd naar de afnemer uit EU-land x ICL EUx-EUy Er is sprake van een intracommunautaire levering van EU-land x naar EU-land y In Bijlage L.7 is per BTW-patroon output aangegeven welke van de vier bovenstaande categorieën van toepassing is. Deze vier categorieën hebben karakteristieke BTW-eisen die op deze manier aan de output van de BTW-patronen zijn gekoppeld. In Bijlage L.7 zijn de hoofdcategorieën van BTW-patroon output gekoppeld aan de BTW-eisen. 6.2 Flexibiliteit BTW-ERP model Een van de eisen aan het ontwerp van het BTW-ERP model is de flexibiliteit bij veranderingen in de huidige situatie (E3). De fundering voor het BTW-ERP model wordt gevormd door de regels opgelegd vanuit BTW-wetgeving. Er moet vastgelegd worden hoe het BTW-ERP model omgaat met verandering van BTW-regels. Voordat het gedrag van het BTW-ERP model bij een veranderingsscenario wordt beschreven, wordt eerst de levenscyclus van de BTW-ERP context vastgesteld. 60

82 6.2. FLEXIBILITEIT BTW-ERP MODEL Gezamenlijke systeemlevenscycli BTW-ERP context De BTW-ERP context is modelsgewijs beschreven op macro- en meso-schaal. BTW-wetgeving legt de BTW-regels vast die voor de gehele markt gelden. Bedrijven moeten hieraan voldoen. De gezamenlijke systeemlevenscycli voor deze context zijn weergegeven in Figuur 6.5. Er wordt onderscheid gemaakt tussen twee foci: (1) Systeemontwikkeling en (2) Systeemoperaties en -onderhoud [Whitten et al., 2004]. Whitten (2004) heeft deze twee foci geïntroduceerd voor de beschrijving van objecten binnen bedrijven (meso-schaal). In Figuur 6.5 zijn deze twee foci ook voor de markt (macro-schaal) weergegeven. In de operaties- en onderhoud focus worden de prestaties van het systeem gemeten en bekeken of er behoefte is aan verandering. Prestatiemeting vindt bijvoorbeeld plaats door middel van de Balanced Scorecard. Figuur 6.5: Gezamenlijke systeemlevenscycli BTW-ERP context Als er behoefte aan verandering is, ontstaat een performance alert (PA) die het project portfolio management (PPM) triggert, waarin een aantal project charters (PC) is vastgelegd dat elk de 61

83 FLEXIBILITEIT BTW-ERP MODEL beschrijving van een project bevat. De PC legt de basiscontext en -doelstelling vast die het project dient te realiseren. Als in het PPM beslist wordt dat er behoefte is aan een nieuw project naar aanleiding van de PA wordt één of meerdere PC s geactiveerd dat leidt tot project uitvoering. De repositories worden waar nodig aangepast bij het doorlopen van een aantal fasen uit het 3-V model. Een PA in de macro-schaal kan leiden tot PA s in meso- en micro-schaal en andersom (zie blauwe pijl tussen Balanced Scorecards in Figuur 6.5) Het BTW-ERP model bevindt zich tussen markt- en bedrijfsrepository. Om te kunnen beschrijven hoe het BTW-ERP model reageert op veranderingen moet voor een mogelijke PA vanuit de markt bekeken worden welke PC s worden opgestart door de verschillende marktactoren. Voordat de project charters worden uiteengezet, worden eerst de BTW-ERP interacties beschreven waarin de interacties tussen de marktactoren bij aanwezigheid van een BTW-ERP model worden beschreven BTW-ERP interacties Vraag- en aanbod zijde De relevante BTW-ERP interacties voor de vraag- en aanbod zijde zijn procesmatig weergegeven in Figuur 6.6. KPMG verleent diensten aan bedrijven en ERP-vendors door gebruik te maken van het BTW- ERP model. Diensten aan ERP-vendors hebben betrekking op het gebied van productkennis, terwijl aan bedrijven diensten worden verleend ter reductie van BTW-risico s. Figuur 6.6: Vraag- en aanbod interacties BTW-ERP Bedrijven nemen producten af van ERP-vendors. Deze producten bestaan uit updates en nieuwe releases van ERP-systemen die eventueel onderbouwd zijn met BTW-ERP kennis die verschaft is door KPMG met behulp van het BTW-ERP model. 62

84 6.2. FLEXIBILITEIT BTW-ERP MODEL 63 Institutie zijde De relevante BTW-ERP interacties met betrekking tot instituties zijn weergegeven in Figuur 6.7. BTW-wetgeving voorziet alle marktactoren van regels waaraan ze moeten voldoen. Dit proces is eenzijdig, omdat de belastingen die moeten worden betaald worden geïnd door de Belastingdienst. Er is eerder aangegeven dat het BTW-ERP model een eerste stap tot samenwerking tussen de Belastingdienst en KPMG kan zijn. In dit geval voorziet KPMG de Belastingdienst van BTW-ERP kennis die ze bedrijfsspecifiek toe kunnen passen bij de controle van belastingaangiften. De stippellijn geeft een scheiding aan tussen instituties en bedrijven. Omdat KPMG een centrale rol speelt met betrekking tot het BTW-ERP model, is KPMG ook in deze context geplaatst. Figuur 6.7: BTW-ERP interacties instituties De marktinteracties geven input aan het opzetten van de project charters voor de marktactoren. In de volgende sectie worden de project charters beschreven en vervolgens gekoppeld aan een veranderingsscenario in de vorm van een BTW-verandering Project charters De project charters (PC) geven een beschrijving van de verschillende projecten in het PPM van de stakeholders uit de macro- en meso-schaal. Het PPM wordt getriggerd door een performance alert. De PC s die hier worden beschreven hebben betrekking op mogelijke projecten bij de performance alert BTW-verandering, zie Figuur

85 FLEXIBILITEIT BTW-ERP MODEL Figuur 6.8: Projectcharters bij BTW-verandering Macro-schaal Een BTW-verandering ontstaat vanuit BTW-wetgeving. Daarom wordt in de macro-schaal slechts een project charter voor de Belastingdienst beschreven. Tabel 6.1: Project charter Belastingdienst Identificatie Probleemstelling Aannamen Visiestelling Projectbereik Projectdoelstellingen Project risico s TA-ServiceRequest De verandering in BTW-wetgeving leidt ertoe dat BTW-regels veranderd kunnen zijn waarop de Belastingdienst bedrijven controleert, waardoor controlestappen herzien moeten worden. De BTW-verandering heeft gevolgen voor de configuratie van ERP-systemen. De specifieke kennis voor het aanpassen van controlestappen is geleverd en de controlestappen voldoen aan de nieuwe BTW-regels. Belastingdienst en KPMG die voorziet in de expliciete kennis. Kennis omtrent BTW-verandering verwerven Controlestappen aanpassen aan nieuwe BTW-regels Onzekerheid over draagvlak horizontaal toezicht op lange termijn Ingrijpende BTW-verandering te ingewikkeld om controlestappen met BTW- ERP model op te lossen Meso-schaal In de meso-schaal worden project charters gedefinieerd voor ERP-bedrijven, ERP-vendors en KPMG. 64

86 6.2. FLEXIBILITEIT BTW-ERP MODEL 65 Tabel 6.2: Project charter ERP-bedrijven (I) Identificatie Probleemstelling Aannamen Visiestelling Projectbereik Projectdoelstelling Project risico s Comp-UpdateRequest Door een BTW-verandering is het ERP-systeem niet meer compliant met de BTWwetgeving, waardoor BTW-risico s ontstaan. De BTW-verandering is door middel van een ERP-update op te vangen. Bedrijf is BTW-compliant. Bedrijven en ERP-vendors die de update leveren. BTW-compliant worden door een update van het ERP-systeem. Update bevat fouten ERP-update is niet tijdig geïnstalleerd Tabel 6.3: Project charter ERP-bedrijven (II) Identificatie Probleemstelling Aannamen Visiestelling Projectbereik Projectdoelstelling Project risico s Comp-ServiceRequest Door een BTW-verandering is het ERP-systeem niet meer compliant met de BTWwetgeving, waardoor BTW-risico s ontstaan. Er bestaat een BTW-service die het probleem oplost. Bedrijf is BTW-compliant. Bedrijven en KPMG die de BTW-bepaling onderzoekt. BTW-compliant worden door gebruik te maken van een BTW-service Return-on-Investment (ROI) opleveren op lange termijn Te weinig draagvlak bij hoge implementatiekosten Er worden geen onderhoudswerkzaamheden verricht Tabel 6.4: Project charter ERP-vendors Identificatie Probleemstelling Aannamen Visiestelling Projectbereik Projectdoelstelling Project risico ERP-KnowledgeRequest Door een BTW-verandering is een aanpassing aan de functionaliteit van het ERPsysteem vereist, waarvoor noodzakelijke fiscale kennis ontbreekt. Expliciete fiscale kennis benodigd om BTW-verandering door te voeren in ERPsysteem. ERP-systeem voldoet aan nieuwe BTW-regels. ERP-vendors en KPMG die de benodigde fiscale kennis levert om BTWverandering aan te kunnen pakken. ERP-systeem aanpassen zodat aan nieuwe BTW-eisen voldaan kan worden. BTW-verandering te ingrijpend om met BTW-ERP model op te kunnen vangen. Tabel 6.5: Project charter KPMG Identificatie Probleemstelling Aannamen Visiestelling Projectbereik Projectdoelstelling Project risico s KPMG-Modify Een BTW-verandering veroorzaakt incorrecte output van het BTW-ERP model waardoor de BTW-ERP service niet meer kan worden ingezet. BTW-verandering veroorzaakt fout in BTW-ERP model. BTW-ERP model is aangepast aan nieuwe BTW-regels. KPMG IRM en Meijburg die gezamenlijk het BTW-ERP beheren. Aanpassen van het BTW-ERP model waarin BTW-regels correct zijn vastgelegd. Onvoldoende resources beschikbaar ERP-specialisten worden niet getraind op BTW-gebied en vice versa Een uitgebreidere procesmatige beschrijving van de project charters die op worden gestart bij een BTW-verandering is beschreven in Figuur H.3 in Bijlage H.3. Hierin wordt Figuur 6.8 uit het begin van deze sectie dieper uitgewerkt. 65

87 FLEXIBILITEIT BTW-ERP MODEL Veranderingsscenario In Figuur 6.5 is voor bedrijven de performance alert BTW-tarief verandert weergegeven. Deze ontstaat bijvoorbeeld doordat in de markt een behoefte is ontstaan aan belastingverhoging. De markt reageert door het BTW-tarief te verhogen waardoor voor bedrijven risico s ontstaan omdat de ERP-systemen niet aangepast zijn aan de tariefwijziging. Bedrijven reageren door projecten op te starten om de ERP-systemen aan te passen aan de nieuwe situatie. Een ander voorbeeld van een BTW-verandering betreft een wijziging in de bepaling van de plaats van de levering. Er wordt voortaan niet meer van het bestemmingslandbeginsel uitgegaan maar van het land waarvandaan de goederen zijn verstuurd. Deze wijziging kan door BTW-wetgeving worden ingevoerd wanneer bijvoorbeeld blijkt dat bij de huidige bepaling van de plaats van de levering bedrijven de mazen van de wet op zoeken door fiscaal voordelige transacties te verrichten om zo weinig mogelijk belasting te betalen. De verwachte inkomsten uit BTW worden daardoor niet gehaald, waardoor te weinig geld voor de overheid binnenkomt. In deze sectie wordt uiteengezet waar dit gevolgen heeft in het BTW-ERP model. In het Use Case Diagram uit Figuur 6.1 is aangegeven dat de verandering eerst moet worden geanalyseerd in het BTW-ERP model. Een verandering is ergens in de wettekst van de Wet OB vastgelegd. BTW-wetgeving is modelsgewijs beschreven in het MDM aan de hand van de Wet OB. Vanuit deze beschrijving wordt in het MDM geïdentificeerd waar de BTW-regel is vastgelegd. Figuur 6.9: Plaats van levering in het marktdomeinmodel In Figuur 6.9 is dit deel van het MDM weergegeven. De bijbehorende invariante OCL-statement is: CONTEXT SupplyOfGoods INV: self.placeofsupply = Order.Ship-to-Country Deze moet gewijzigd worden in de volgende invariante OCL-expressie zodat het MDM weer correct is: CONTEXT SupplyOfGoods INV: self.placeofsupply = Order.Ship-from-Country Hiermee verandert de invulling van BTW-determinant [B.7 PlaceOfSupply]. Omdat de invulling nu weer correct beschreven is vanuit het domeinmodel verandert het PDM en de uitwerkingen van de patronen niet. Het BTW-ERP model is weer consistent met de nieuwe BTW-regels. Bij het aanpassen van het BTW-ERP model worden deze stappen achtereenvolgens doorlopen. 66

88 6.3. WAARDETOEVOEGING BTW-ERP MODEL 67 Deze stappen zijn onderdeel van de project charter KPMG-Modify van KPMG dat opgestart is door de BTW-verandering. De overige actoren kunnen nu weer gebruik maken van de BTW-ERP service van KPMG om de inconsistentie in het ERP-systeem te herstellen dat veroorzaakt is door de BTW-verandering. Dit doen ze door de hierboven beschreven project charters te activeren. 6.3 Waardetoevoeging BTW-ERP model Een van de ontwerpeisen die na analyse van de BTW-ERP kloof beschreven is, betreft de mate van waardetoevoeging voor de stakeholders (E.5). Om een uitspraak te kunnen doen over de waardetoevoeging van het BTW-ERP CIM is een waarde- en risico-analyse gehouden waarbij een waardemodel is opgesteld die de waardeuitwisselingen tussen de stakeholders articuleert Waarde- en risicoanalyse De waarde- en risicoanalyse is uitgevoerd door het opstellen van een waardemodel met behulp van de e 3 -value approach methodiek [Gordijn and Akkermans, 2003]. Het gebrek aan een uitvoerbaar model (P1) dat de belangrijkste kernoorzaak van de problemen in de huidige situatie is, wordt weggewerkt door de aanwezigheid van het BTW-ERP CIM. De complexiteit van ERP-systemen (P2) blijft bestaan. Er zullen altijd risico s blijven optreden door de uitgebreidheid van het ERP-systeem. Het BTW-ERP CIM draagt er toe bij dat de complexiteit met betrekking tot BTW-regels toegankelijker wordt en inzichtelijker wordt waar de specifieke risico s verankerd zitten in het systeem. Het BTW-ERP CIM helpt awareness te creëren bij bedrijven voor de impact die BTW op de bedrijfsvoering heeft (P3). Risicopatronen binnen bedrijven kunnen snel bloot worden gelegd zodat de kans op onderschatting van impact wordt verkleind. Het BTW-ERP model voegt waarde toe voor alle stakeholders als er kennissamenwerkingen worden opgestart tussen de onderlinge partijen. Het waardemodel laat dit zien door de waardestromen die lopen tussen KPMG en de Belastingdienst en ERP-vendors. Op deze manier voegt het model niet alleen waarde toe voor de ERP-bedrijven die meer controlezekerheid over hun ERP-systemen hebben, maar ook voor de andere partijen binnen de marktcontext. 6.4 Repository invulling In dit hoofdstuk is het ontwerp van het BTW-ERP model beschreven dat een oplossing vormt voor de problemen die in de huidige situatie optreden met betrekking tot BTW-berekening met behulp van ERP-systemen. Voorts is een tweetal ontwerpeisen gevalideerd door middel van het beschrijven van acties bij een veranderingsscenario en het houden van een waarde- en risicoanalyse voor het BTW-ERP model. De modelsgewijze beschrijving van de huidige BTW-ERP situatie zoals deze in Hoofdstuk 4 is uitgevoerd en de uitwerking van het ontwerp in dit hoofdstuk zijn gedocumenteerd in een markten bedrijfsrepository. De structuur van deze repository volgt de opbouw uit de repositorystructuur zoals beschreven in Figuur 3.3 uit Hoofdstuk 3.4. In deze sectie wordt de relatie aangegeven tussen de beschreven modellen uit de analyse- en ontwerpfase en de overeenkomstige invulling van de repositories zoals deze is gedocumenteerd in Bijlagen G t/m K. 67

89 REPOSITORY INVULLING Tenslotte wordt de koppeling (alignment) tussen beide repositories beschreven aan de hand van de bereikte onderzoeksresultaten Invulling marktrepository In de marktrepository zijn delen van het Value and Risk Model (VARM) en Worksystem Operations Model (WOM) beschreven. Tabel 6.6 koppelt de onderzoeksresultaten aan de overeenkomstige elementen uit de marktrepository. Tabel 6.6: Onderzoeksresultaten gekoppeld aan marktrepository (VARM en WOM) 1-V: VARM - Bijlage G Repository-element Beschrijving Verslag Repository-invulling Mission Statement De missie en visie van de publieke Sectie 5.1 Bijlage G.1 marktactoren (BTW-wetgeving en Belastingdienst). Domain Statement Niet expliciet beschreven - - Market Indicator Register De indicatoren, weergegeven in Balanced Sectie 5.1 Bijlage G.2 Scorecards, die de publieke marktactoren kunnen gebruiken om te meten of het BTW-ERP model waarde toevoegt. Market Value and Risk Register Het waardemodel, de waardeuitwisselingen en de waardeanalyse van het ontwerp van het BTW-ERP model in de marktcontext. Sectie 6.3 Bijlage G.3 2-V: WOM - Bijlage H Repository-element Beschrijving Verslag Repository-invulling Principal Model Market Asset Model Market Resource Model Interaction Refinement Model Een model waarin de splitsing tussen publieke instellingen en bedrijven aangegeven is en de mogelijke waardeuitwisselingen bij aanwezigheid van een BTW-ERP model. Het generieke deel van het marktdomeinmodel opgebouwd uit klassen voor Principals, Restrictions en InstitutionalObjects die gezamenlijk een raamwerk voor uitwisselingen van objecten creëren. Een model met alle BTW-ERP resources die door waardeuitwisselingen tussen rollen gekoppeld aan het Market Domain Model door het domein stromen. Een model met de specifiekere beschrijving van de interacties uit het Principal Model, waarin de project charters benadrukt worden. Sectie Bijlage H.1 Sectie Bijlage H.2 Sectie Bijlage H.2 Sectie Bijlage H.3 68

90 6.4. REPOSITORY INVULLING Invulling bedrijfsrepository In de bedrijfsrepository zijn delen van het Value and Risk Model(VARM), Worksystem Operations Model (WOM) en Cumulative Requirements Model (CRM) beschreven. Tabel 6.7 koppelt de onderzoeksresultaten aan de overeenkomstige elementen uit de bedrijfsrepository. Tabel 6.7: Onderzoeksresultaten gekoppeld aan bedrijfsrepository (VARM, WOM en CRM) 1-V Value and Risk Model (VARM) - Bijlage I Repository-element Beschrijving Verslag Repository-invulling Business Mission Statement Beschrijvingen van de missies en visies Sectie 5.1 Bijlage I.1 van de stakeholders in de meso- schaal waarmee ze services naar klanten kunnen verhogen en vasthouden. Business Context Statement Niet expliciet beschreven - - Business Indicator Register De indicatoren, weergegeven in Balanced Sectie 5.1 Bijlage I.2 Scorecards, die bedrijven in de BTW-ERP context kunnen gebruiken om te meten of het BTW-ERP model waarde toevoegt. Business Value and Risk Register Niet expliciet beschreven V Worksystem Operations Model (WOM) - Bijlage J Repository-element Beschrijving Verslag Repository-invulling Community Model Het Business Asset Model en Business Sectie 4.2 Bijlage J.1 Resource Model. Business Asset Model Zie Market Asset Model. Sectie Bijlage J.1 Business Resource Model Dit model beschrijft de specifieke invulling Sectie Bijlage J.1 van het Business Asset Model en koppelt de rollen en resources aan de assets uit het bedrijfsdomein. Work Refinement Model Dit model geeft een beschrijving Sectie Bijlage J.2 van de omzetgenererende processen die leiden tot een BTW-plicht voor bedrijven. Deze worden beschreven door middel van identificatie van ecnonomic activities in de waardeketen. 3-V Cumulative Requirements Model (CRM) - Bijlage K Repository-element Beschrijving Verslag Repository-invulling Relation Data Model Niet beschreven - - Business Asset Data Model Niet beschreven - - Enterprise Resource Data Model Niet beschreven - - Work Refinement Specification Een beschrijving van de systeemgrenzen Sectie 6.1 Bijlage K.1 van het BTW-ERP model door middel van een Use Case Diagram (UCD) en beschrijvingen van use cases. Non-Functional Requirements Niet beschreven - - Reference Architectural Analysis Niet beschreven

91 REPOSITORY INVULLING Alignment markt- en bedrijfsrepository De BTW-determinanten zijn de directe koppeling tussen markt- en bedrijfsrepository. Uit de BTW-determinanten zijn BTW-patronen afgeleid die na verdere uitwerking specifieke eisen aan ERP-systemen stellen. De koppeling tussen de BTW-determinanten en de verschillende modellen in de markt- en bedrijfsrepository vormen de alignment tussen beide repositories. In Tabel 6.8 worden de alignment-tabellen genoemd en gekoppeld aan de relevante delen uit de analyse- en ontwerpfase en de positionering in de Bijlage. Tabel 6.8: Alignment onderdelen gekoppeld aan onderzoeksresultaten - Bijlage L Alignment onderdeel Beschrijving Verslag Alignment Bijlage BTW-determinanten De geïdentificeerde BTWdeterminanten Sectie Bijlage L.1 die de basis vormen voor de uitwerking van de BTWpatronen. BTW-determinanten invulling Een beschrijving van de invulling Sectie Bijlage L.2 van de BTW-determinanten gerelateerd aan de relevante stukken uit BTW-wetgeving (nationaal en Europees). BTW-determinanten De relatie tussen de BTW- Sectie Bijlage L.3 ERP-systemen determinanten en de tabellen en velden van een specifiek ERPsysteem waarin informatie met betrekking tot invulling van de BTWdeterminanten te vinden is. BTW-determinanten De koppeling tussen de BTW Hoofdstuk 4 Bijlage L.4 Domeinmodellen -determinanten en het markt- en bedrijfsdomeinmodel. Omzetgenererende processen Een beschrijving van de relatie tus- Sectie Bijlage L.5 Domeinmodellen sen de toestanden van het Work Refinement Model en de klassen uit het markt- en bedrijfsdomeinmodel. Identificatie BTW-patronen Een beschrijving van het Pattern Sectie Bijlage L.6 Determination Model (PDM), dat leidt tot de identificatie van een BTW-patroon. Uitwerking BTW-patronen Voor elk BTW-patroon zijn beslissingsmodellen Sectie Bijlage L.7 ontworpen die leiden tot de specifieke BTW-eisen voor het BTW-patroon. BTW-patronen BTW eisen Een beschrijving van de koppeling tussen de uitkomsten van de beslissingsmodellen en de daaruit volgende BTW-eisen. Sectie Bijlage L.8 70

92

93 Deel IV Implementatie & Evaluatie 72

94

95 Hoofdstuk 7 Realisatie Zoals aangegeven in Hoofdstuk wordt bij de implementatie onderscheid gemaakt tussen een tweetal realisaties: Implementatie van het BTW-ERP CIM De markt- en bedrijfsrepository die ingevuld zijn tijdens de modelsgewijze beschrijving van de huidige situatie en het ontwerp, worden vertaald van een Computation Independent Model (CIM) naar een Platform Specific Model (PSM). Ontwikkeling van BTW-ERP service voor KPMG Met de verkregen inzichten en de beschrijving van het uitvoerbare BTW-ERP model kan een BTW-ERP service voor KPMG worden ontwikkeld. In dit hoofdstuk wordt een implementatieplan beschreven voor de implementatie van het BTW-ERP CIM. De ontwikkeling van een BTW-ERP service voor KPMG wordt in de aanbevelingen voor KPMG beschreven. De vertaling van het BTW-ERP CIM naar het PSM is schematisch weergegeven in Figuur 7.1. Het BDM dient als basis voor de implementatie omdat het BTW-ERP model specifiek toegepast gaat worden bij bedrijven met ERP-systemen. Figuur 7.1: Transformatie van CIM naar PSM 74

96 7.1. IMPLEMENTATIEPLAN 75 Een formele beschrijving van transformatie van CIM-domeinmodellen naar PSMimplementatiemodellen is beschreven in [Wagner, 2004]. Hierin worden domeinmodellen systematisch vertaald naar implementatiemodellen die gebaseerd zijn op databases. De implementatiemodellen in de BTW-ERP context zijn gebaseerd op het gedrag van SAP dat met de condition technique wordt bewerkstelligd. In de volgende sectie wordt een implementatieplan beschreven waarin de stappen worden toegelicht die moeten worden genomen om het BTW-ERP CIM te vertalen naar de configuratie van SAP R/3 zodat de BTW-berekening op een correcte manier verloopt. 7.1 Implementatieplan Whitten (2004) beschrijft een drietal stappen die de basis vormen voor een regulier implementatietraject [Whitten et al., 2004]: 1. Training Training is het proces waarin mensen expertise opdoen met betrekking tot de functionele eisen waarin de implementatie moet voldoen. 2. Conversie Wanneer expertise is opgedaan moet het ontwerp volgens ontwerpeisen worden geïmplementeerd. Dit is het conversieproces van de oude naar de nieuwe situatie. 3. Acceptatie De implementatie moet voldoen aan de wensen van de eindgebruikers. Door middel van acceptatietests wordt gecontroleerd of alle gebruikerseisen geïmplementeerd zijn. Deze drie implementatiestappen worden ingevuld voor de BTW-ERP context en beschreven in een implementatieplan. 7.2 Training In dit onderzoek is de invulling van een markt- en bedrijfsrepository beschreven aan de hand van een modelsgewijze beschrijving van de huidige situatie van BTW-wetgeving en ERP-systemen. De modellen in de repositories verschaffen inzicht in de eisen aan de inrichting voor een specifiek ERP-systeem, SAP R/3. BTW-berekening valt binnen SAP onder het pricingmechanisme. Pricing gebruikt de condition technique als instrument voor de bepaling van prijsgegevens op de factuur waaronder de BTW (zie Hoofdstuk 4.3.3). Een eerste vereiste om tot een aansluitende implementatie te komen is het trainen en bekend maken van mensen met de SAP condition technique. De BTW-determinanten die systematisch afgeleid zijn sluiten aan bij de mogelijkheden van de condition technique. Documentatie met betrekking tot de SAP condition technique is te vinden in [SAP, 2001] en [SAP, 2006] en in de resultaten van dit afstudeerrapport. 7.3 Conversie De conversie bestaat uit de nieuwe inrichting van de BTW-relevante condition types en condition tables. 75

97 CONVERSIE In Hoofdstuk is beschreven hoe SAP R/3 op dit moment omgaat met BTW en welke BTW-determinanten daarbij gebruikt worden. Er is vastgesteld dat de BTW-determinanten die worden gebruikt bij een standaardinrichting van SAP onvoldoende functionaliteit bieden bij complexe goederenstromen. Bij de beschrijving van BTW-wetgeving zijn extra BTW-determinanten afgeleid die in specifieke gevallen mee moeten worden genomen bij de bepaling van de BTW. In Bijlage L.3 is beschreven in welke velden en tabellen in SAP de informatie met betrekking tot de invulling van de BTW-determinanten te vinden is. Figuur 7.2: Aangepast condition type MWST In Figuur 7.2 is aan het condition type MWST één extra BTW-determinant toegevoegd: [B.15 TransportParty]. Deze BTW-determinant heeft de waarde TRUE als de leverancier (supplier) het vervoer regelt en FALSE als de afnemer (customer) het vervoer regelt. Op basis van de uitwerking van de BTW-patronen die beschreven zijn in Bijlage L.6 moet bij de combinatie van invullingen van BTW-determinanten de condition table zodanig ingericht worden dat de factuur voldoet aan de eisen die de uitkomst van het BTW-patroon voorschrijft Voorbeelduitwerking BTW-patroon Ter illustratie wordt BTW-patroon 1b uitgewerkt. Dit BTW-patroon valt binnen typologie 1 waarbij de leverancier gevestigd is in de EU en de goederen vanuit datzelfde EU-land vervoerd worden. In het PDM wordt een aantal stappen genomen die uitkomen bij BTW-patroon 1b. Dit zijn de gezamenlijk eigenschappen voor dit BTW-patroon. 76

98 7.3. CONVERSIE 77 Tabel 7.1: Gezamenlijke invulling BTW-determinanten BTW-patroon 1b Keuze in PDM BTW-determinanten Invulling TaxableTransaction = Supply of goods B.3 TRUE Installation-or-Assembly B.4 FALSE Ship-from-Country in EU B.5 TRUE SupplierCountry in EU B.1 TRUE SupplierCountry = Ship-from-Country B.1,B.5 TRUE Ship-from-Country = Ship-to-Country B.5,B.6 FALSE Ship-to-Country in EU B.6 TRUE Een combinatie van deze invullingen leidt altijd naar BTW-patroon 1b. Bij de verdere uitwerking moet een tabel in worden gevuld die de verschillende uitkomsten van BTW-patroon 1b representeert. De cijfers corresponderen met de identificatie van de BTWdeterminanten. De plaatsen die niet zijn ingevuld zijn niet meer van belang voor de bepaling van de factuurvereisten. Tabel 7.2: Specifieke invulling determinanten BTW-patroon 1b B.13 B.17= 1 B.15 B.2= EU2 B.2= NL BE B.18 Requirements FALSE B.1 TRUE FALSE TRUE B.1 TRUE FALSE FALSE B.2 TRUE TRUE TRUE FALSE - - 1B.3 TRUE TRUE TRUE TRUE FALSE - 1B.3 TRUE TRUE TRUE TRUE TRUE TRUE 1B.3 TRUE TRUE TRUE TRUE TRUE FALSE 1B.4 TRUE TRUE FALSE B.5 De data kan per BTW-determinant uit SAP worden gehaald. De condition table moet zo worden ingericht dat het gedrag van de BTW-patroon uitwerkingen hiermee overeenstemt, zie Tabel 7.2. Als op deze manier het condition type MWST en de bijbehorende condition tables worden ingevuld, wordt BTW op basis van de relevante BTW-determinanten op de correcte manier berekend. In Hoofdstuk is aangegeven dat de condition technique een belangrijke factor is bij de prestaties van SAP in termen van snelheid en optimalisatie. Na het maken van condition tables is een volgende stap het nadenken of deze op slimmere manieren kunnen worden ingevuld zodat dit de snelheid van het systeem ten goede komt. condition records die zelden worden geraadpleegd moeten zo laat mogelijk in de tabel worden opgenomen, omdat SAP de tabel telkens van begin tot eind doorloopt en stopt bij het vinden van een passend condition record, zie Figuur 7.2. Dit is een extra uitdaging die in een vervolgonderzoek nader kan worden onderzocht. 77

99 ACCEPTATIE 7.4 Acceptatie De laatste stap bij het implementatietraject betreft de acceptatie van de conversie van het systeem. Door middel van specifieke tests in een operationele bedrijfsomgeving kunnen de aangepaste condition types en condition tables op correcte implementatie worden getest. Door een pilot project op te zetten bij een bedrijf dat veel internationale transacties verricht, kunnen de eindgebruikers van SAP-systemen controleren of de facturen BTW-compliant zijn. Het BTW-ERP model is een eerder stadium van dit onderzoek gevalideerd in een representatieve bedrijfsomgeving waarin veel complexe nationale en internationale transacties plaatsvinden. In deze bedrijfsomgeving bood het BTW-ERP model voldoende mogelijkheden om de juiste instellingen van het ERP-systeem af te leiden. Als de acceptance tests positief uitvallen zal de bereidheid van eindgebruikers met betrekking tot het gebruik van het systeem verhogen. 7.5 Samenvatting In dit hoofdstuk is het implementatieplan beschreven dat het 3-V deel van de bedrijfsrepository tot op ICT-projectniveau uitwerkt. De drie fasen training, conversie en acceptatie zijn als basis voor het implementatieplan genomen. Hierin zijn de activiteiten beschreven die moeten worden ondernomen om het ontwerp in een praktijksituatie te implementeren. Om deze implementatie te kunnen testen moet een pilot project worden opgezet ter validatie van functioneel ontwerp naar gedetailleerd ontwerp (implementatie). Bij de implementatie speelt naast de uitwerking van systeemeisen ook de efficiëntie van de implementatie een belangrijke rol. Omdat de technieken die binnen SAP gebruikt worden een dermate grote invloed hebben op de prestaties van het gehele systeem, mag de impact van de deze optimalisatiestap niet worden onderschat. Het verdient aanbeveling om hier gedurende het gehele implementatietraject al rekening mee te houden, omdat de aard van de oplossing dermate complex is dat het toepassen van zogenaamde reverse engineering technieken zeer inefficiënt zal zijn. 78

100

101 Hoofdstuk 8 Conclusies en Aanbevelingen Dit hoofdstuk beschrijft de conclusies en aanbevelingen die volgen uit de resultaten van dit afstudeeronderzoek. Er is begonnen met de identificatie van het probleemkluwen in de BTW-ERP context tijdens de oriëntatiefase. De huidige situatie van BTW en ERP is modelsgewijs beschreven en er zijn relevante delen van een markt- en bedrijfsrepository ingevuld. Hierbij is een kloof geïdentificeerd tussen BTWwetgeving en de toepassing ervan in ERP-systemen. De BTW-ERP context waarin deze kloof bestaat is geanalyseerd en er zijn ontwerpeisen vastgesteld voor het te ontwerpen BTW-ERP model. Er is een ontwerp voor het BTW-ERP model beschreven dat over voldoende flexibiliteit beschikt en toegevoegde waarde voor de stakeholders oplevert. Tijdens de implementatiefase is een implementatieplan opgesteld dat de transformatie van het BTW-ERP Computation Independent Model (CIM) naar een Platform Specific Model (PSM) beschrijft. De regulatieve cyclus eindigt met de evaluatie van de bereikte resultaten. Dit hoofdstuk geeft invulling aan deze laatste stap waardoor de cyclus rond is en wordt bekeken of een nieuw probleemkluwen aanleiding geeft tot mogelijke vervolgonderzoeken. Eerst wordt geëvalueerd of aan de onderzoeksdoelstellingen die beschreven zijn in Hoofdstuk 3.1 is voldaan. Vervolgens wordt voor elk van de drie schalen (macro-, meso- en micro-schaal) beschreven wat bereikt is en wat hieruit geconcludeerd kan worden. Op basis van deze conclusies worden aanbevelingen voor KPMG beschreven naar aanleiding van de onderzoeksresultaten. 8.1 Beantwoording aan onderzoeksdoelstellingen Tijdens de analyse van de projectcontext is de volgende opdrachtomschrijving voor dit afstudeeronderzoek uiteengezet: (I) Geef een modelsgewijze beschrijving van de huidige situatie met betrekking tot de vraag- en aanbod interacties ondersteund door ERP-systemen en de beperkingen die hieraan op worden gelegd door BTW-wetgeving. Breng vervolgens de bestaande kloof in kaart. (II) Breng de door het ERP-systeem ondersteunde vraag- en aanbod interacties in overeenstemming met de door BTW-wetgeving opgelegde beperkingen middels het 80

102 8.1. BEANTWOORDING AAN ONDERZOEKSDOELSTELLINGEN 81 ontwerp van een Computation Independent BTW-ERP model en implementeer het BTW-ERP model voor een specifiek ERP-systeem. Hiermee wordt de kloof gedicht. Vervolgens zijn hieraan onderzoeksdoelstellingen gekoppeld. Per onderzoeksdoelstelling wordt hieronder bekeken of hieraan is voldaan in de bereikte resultaten. Verkrijging van inzicht in de aspecten van BTW-wetgeving en de huidige BTW-bepalingsregels binnen ERP systemen. De BTW-wetgeving is uitgebreid beschreven in dit afstudeerverslag. Tijdens de oriëntatiefase is een eerste verkenning van de BTW-wetgeving uitgevoerd. Aangezien de auteur voorafgaand aan dit onderzoek geen specifieke kennis op dit gebied had, was de belangrijkste eerste stap het verkrijgen van feeling voor het hoe en waarom van BTW. Daardoor was de logica gemakkelijker te abstraheren uit de gehele BTW-context. Vinden van een geschikte methodologie voor het beschrijven van de huidige situatie met betrekking tot de BTW-ERP context en het modelsgewijs beschrijven van de huidige situatie met behulp van de gekozen methodologie waarmee de aanwezige kloof in kaart wordt gebracht. Het 3-V model is gekozen als methodologie voor de modelsgewijze beschrijving door middel van een repository. De deliverables uit COMET zijn gekozen als specifieke repository-invulling. Het veelschalige 3-V model (markt, bedrijf, personen) biedt de mogelijkheid om de repository vanuit verschillende perspectieven in te vullen. Deze methodologie is geschikt voor de BTW-ERP context omdat hierin een onderscheid wordt gemaakt tussen instituties als representant van de markt en bedrijven die in deze samenleving opereren en gereguleerd worden door de instituties. Voor deze twee schalen zijn op deze manier een markt- en een bedrijfsrepository op verschillend niveau ingevuld als modelsgewijze beschrijving van de huidige situatie met betrekking tot BTW en ERP. De grootste uitdaging hierbij was het vinden van de relevante concepten die betrekking hebben op ERP-systemen en het achterwege laten van complexe kleinere BTW-bepalingen. De kloof is in kaart gebracht doordat een aantal aspecten (BTW-determinanten) in BTWwetgeving zijn geïdentificeerd die niet verankerd zitten in de huidige BTW-bepalingsregels van ERP-systemen. Ontwerpen van een Computation Independent BTW-ERP model dat de brug vormt tussen de BTW-bepaling binnen ERP-systemen en BTW-wetgeving waarmee de huidige kloof wordt overbrugd. De markt- en bedrijfsrepository zijn tijdens de ontwerpfase verder ingevuld. Er is een uitvoerbaar BTW-ERP model beschreven door de identificatie van BTWpatronen binnen BTW-wetgeving. De uitwerkingen van deze BTW-patronen leggen het gewenste gedrag van ERP-systemen vast. Op deze manier wordt een blauwdruk verkregen voor het overbruggen van de aanwezige kloof. De koppeling tussen deze repositories wordt gevormd door de BTW-determinanten die af 81

103 CONCLUSIES te leiden zijn uit BTW-wetgeving en te vertalen zijn naar eisen aan ERP-systemen. Om flexibiliteit bij BTW-veranderingen te waarborgen zijn voor elke stakeholder project charters beschreven die worden opgesteld bij de performance alert: BTW-verandering. Er is voor één veranderingsscenario aangegeven welke project charters op worden gesteld en hoe uit het BTW-ERP model volgt wat moet worden aangepast om de BTWverandering op te vangen. Vertaling van het Computation Independent Model (CIM) naar een Platform Specific Model (PSM) dat de implementatie voor een specifiek ERP-systeem vastlegt. Er is een implementatieplan gemaakt waarin de stappen worden beschreven die moeten worden genomen om het BTW-ERP CIM op een correcte manier te vertalen naar een BTW-ERP PSM, dat bestaat uit de correcte inrichting van SAP R/3. Voor één BTW-patroon is geïllustreerd hoe de vertaalslag naar de herinrichting van condition types en condition tables van SAP moet worden gemaakt. De specificatie van een BTW-ERP service van KPMG wordt aanbevolen als een vervolgstap op dit onderzoek. Geven van aanbevelingen over de toepasbaarheid van het ontwerp met betrekking tot services voor KPMG. De aanbevelingen richting KPMG en haar services naar aanleiding van de onderzoeksresultaten en de daarvan deel uit makende modellen worden in sectie 8.3 van dit hoofdstuk beschreven. Aan alle vooraf opgestelde onderzoeksdoelstellingen die hierboven zijn geëvalueerd is voldaan. Een kanttekening wordt geplaatst bij de daadwerkelijke implementatie. Deze is niet uitgevoerd maar vervangen door een implementatieplan. Hiermee is de probleemstelling aangepakt die als basis was genomen voor de onderzoeksdoelstellingen. In de volgende sectie worden de conclusies met betrekking tot elk van de drie projectschalen beschreven. 8.2 Conclusies Er is gekozen voor een scheiding tussen de schalen voor het beschrijven van de conclusies omdat de stakeholders binnen elk van de schalen eigen doelstellingen hebben waarvoor verschillende conclusies worden getrokken Macro-schaal: Markt De macro-schaal is ingevuld door instituties. Zij schrijven de spelregels van de samenleving voor [North, 1990]. BTW-wetgeving (regelgevend) en de Belastingdienst (uitvoerend) zijn de instituties in de context van dit onderzoek. In de analyse van de huidige situatie en het ontwerp zijn repositories ingevuld die de rol van 82

104 8.2. CONCLUSIES 83 BTW-wetgeving en de Belastingdienst articuleren. De volgende observaties kunnen worden gemaakt: Bedrijven zijn in toenemende mate afhankelijk van ERP-systemen voor het leveren van concurrentiële prestaties. Het configureren van ERP-systemen op basis van het raamwerk van voorwaarden opgesteld door BTW-wetgeving en Belastingdienst gebeurt niet feilloos, met name voor ingewikkelde grensoverschrijdende BTW-transacties. In de projectfocus (Hoofdstuk 2.2) is de relatie tussen vraag-aanbod interacties en instituties beschreven. Hierbij is aangegeven dat een BTW-ERP CIM de huidige kloof tussen institutioneel ontwerp en de ERP-ondersteunde marktwisselwerkingen dicht. Nu er verdere verdieping en inzicht in technologie (ERP-systeem) en instituties (BTWwetgeving) is verkregen kan worden geconcludeerd dat de kloof in theorie wordt gedicht, maar dat in de praktijk nog andere aspecten een rol spelen bij het overbruggen van problemen in de BTW-ERP context. Het BTW-ERP CIM dicht inderdaad de kloof met betrekking tot BTW-problemen die bedrijven hebben. Maar dit BTW-ERP CIM neemt de huidige situatie als basis. Waarom werkt de Belastingdienst zoals ze nu werkt? Waarom wordt bedrijven niet zelf de verantwoordelijkheid gegeven om aan te tonen dat ze correcte aangifte doen? Dit soort vragen wordt zelden gesteld omdat de macht van instituties groter is dan van bedrijven. Er bestaat een kernprobleem binnen het hele functioneren van de Belastingdienst waardoor bedrijven overmatig veel kosten maken en energie steken in het voldoen aan de eisen die hen wordt opgesteld. Een eerste stap die de Belastingdienst heeft gezet hieromtrent is de introductie van electronisch factureren. Naast deze vorm van institutionele verandering zouden meerdere stappen moeten worden genomen om de volwassenheid van de huidige technologie op één lijn te brengen met het raamwerk van voorwaarden gecreëerd door instituties. Europa-breed is al een aantal initiatieven genomen die vormen van overregulering moeten bestrijden. Daarnaast heeft de Europese Unie de visie om betere wetgeving in de vorm van modernisering van Europese regelgeving door te voeren. Het toevoegen van marktniveau CIM modellen met een documenterende rol aan de regelgeving is een mogelijke vorm van modernisering. Het invullen van een markt- en een bedrijfsrepository met deliverables vanuit COMET-modellen is een geschikte methodiek voor het beschrijven van de BTW-ERP situatie. Hoewel COMET sterk gericht is op de ontwikkeling van bedrijfsinformatiesystemen (macro-schaal: bedrijven) is de toepasbaarheid van COMET binnen een marktbrede benadering goed gebleken. Hierbij zijn de algemene COMET repository-elementen als basis genomen en vertaald naar specifieke elementen die in een marktcontext gebruikt kunnen worden. Deze toevoeging aan de bestaande COMET-elementen wordt COMET+ genoemd [Goossenaerts, 2006a]. Door repositories op marktniveau in te vullen kunnen de interacties tussen de stakeholders beter beschreven worden waardoor meer inzicht is verkregen in de toegevoegde waarde van het BTW-ERP CIM voor elk van de stakeholders. Dit is een belangrijke voorwaarde voor een succesvol implementatietraject. 83

105 CONCLUSIES Meso-schaal: Bedrijven Binnen deze schaal zijn de bedrijven die ERP-systemen gebruiken geïdentificeerd. Voor deze bedrijven kunnen de volgende conclusies worden getrokken: Het BTW-ERP CIM verhoogt het inzicht in mogelijkheden om het risico op boetes van uitvoerende instanties en het betalen van dubbele belastingen te verlagen. Tijdens de probleemanalyse is naar voren gekomen dat de risico s met betrekking tot het niet BTW-compliant zijn een belangrijke aanleiding zijn geweest tot nader onderzoek op dit gebied. Het ontwerp van het BTW-ERP CIM heeft vanuit bedrijfsperspectief als doelstelling deze risico s te verlichten en daarmee BTW-compliance te bewerkstelligen. De risico s ontstaan door het gebrek aan inzicht of BTW-strategie binnen bedrijven optimaal binnen grote ERP-omgevingen worden gestuurd. De resultaten van dit onderzoek hebben de inzichten gecreëerd die nodig zijn om meer zekerheid af te kunnen geven over potentiële risico s met betrekking tot BTW-gerelateerde zaken. De repository-invulling die onderdeel uitmaken van het ontwerp zijn vanuit markt- en bedrijfsperspectief opgesteld zodat ook bij marktveranderingen de oorzaak-gevolg relatie kan worden gelegd naar het impact hiervan op de bedrijfsvoering en de ERP-configuratie. Bij ERP-implementatietrajecten moet BTW-inrichting hogere prioriteit krijgen en niet als standaard worden beschouwd. ERP-implementatietrajecten duren vaak maanden tot zelfs jaren in zeer complexe bedrijfsomgevingen. Er is gebleken dat het BTW-aspect hierin nauwelijks aandacht krijgt. Er wordt volstaan met standaard-sap als inrichting voor de BTW. Bedrijven moet bewust worden gemaakt wat de risico s zijn wanneer te lage prioriteit wordt gegeven aan de BTW-aspecten. Het BTW-ERP CIM kan tijdens het implementatietraject als blauwdruk worden gebruikt voor de BTW-inrichting. Als hier in een vroeg stadium mee wordt begonnen zijn de kosten lager en levert het al vroeg in de systeemlevenscyclus van het ERP-systeem risicoreductie op. Het BTW-ERP CIM kan door bedrijven (in de toekomst) worden ingezet als proof of VAT-compliance richting uitvoerende instanties van wetgeving. Als het BTW-ERP CIM is vertaald naar een BTW-ERP PSM en de waarde vanuit de praktijk is aangetoond geeft dit een zekerheid op fiscaal gebied voor bedrijven. Uitvoerende instanties van wetgeving zoals de Belastingdienst hebben als doelstelling om de bereidheid van belastingplichtigen tot nakoming van de wettelijke verplichtingen te onderhouden en versterken [Belastingdienst, 2005a]. Hierbij trachten ze het particulieren en bedrijven zo gemakkelijk mogelijk te maken. Het BTW-ERP CIM past in deze filosofie van de Belastingdienst en kan voor bedrijven fungeren als proof of VAT-compliance. Bovendien past dit in het plaatje van horizontaal toezicht (zie sectie 8.3). 84

106 8.3. AANBEVELINGEN KPMG Micro-schaal: Personen De micro-schaal wordt ingevuld door de BTW-ERP specialisten binnen KPMG IRM en Meijburg. Voor deze schaal is geen repository ingevuld omdat deze groep de experts bevat die de markt- en bedrijfsrepository ontwikkelen en beheren. De specialisten hebben ambities die bijdragen aan optimale prestaties van ondernemingen. De aanbevelingen voor deze schaal, in het bijzonder KPMG Information Risk Management specialisten, worden in de volgende sectie beschreven. 8.3 Aanbevelingen KPMG Een van de onderzoeksdoelstellingen bestaat uit het geven van aanbevelingen aan KPMG Information Risk Management met betrekking tot de dienstverlening op BTW-ERP gebied. Implementatie van het BTW-ERP CIM als kennisvermogen ter ondersteuning van een BTW-ERP kloof overbruggende adviesdienst (serviceblauwdruk) op basis van de resultaten van dit onderzoek. In Hoofdstuk 7: Realisatie is een implementatieplan beschreven dat een aantal stappen omvat die de BTW-ERP eisen vertalen naar een invulling van de SAP condition types. Als deze vertaalslag gemaakt is, kunnen hieruit serviceblauwdrukken worden ontwikkeld waarmee bedrijfsspecifieke problemen bij klanten kunnen worden aangepakt. Opzetten van een BTW-ERP groep die het BTW-ERP CIM als adviesdienst in kan zetten bij klanten. Het BTW-ERP CIM vergt aanpassing op het moment dat veranderingen binnen de bestaande situatie vanuit wetgeving of andere partijen optreden. Deze veranderingen zijn eerder beschreven als performance alerts. Om ook op langere termijn gebruikt te kunnen maken van het BTW-ERP model moet een BTW-ERP groep worden opgesteld die zich verdiept in de context die in dit onderzoeksverslag beschreven is. Veranderingen moeten worden bijgehouden en doorgevoerd in het BTW-ERP CIM. Op deze manier kunnen langdurige relaties met klanten worden opgebouwd op het gebied van BTW-compliance. Aangaan van samenwerkingen met andere partijen als ERP-vendors en de Belastingdienst. De Belastingdienst heeft aangegeven in de toekomt meer gebruik te willen maken van horizontaal toezicht. Hierbij gaat het om wederzijds vertrouwen tussen de burger en bedrijfsleven enerzijds en de Belastingdienst anderzijds. Ook gaat het hierbij om het scherper naar elkaar aangeven wat ieders verantwoordelijkheden en mogelijkheden zijn om het recht te handhaven en het vastleggen en naleven van wederzijdse afspraken [Belastingdienst, 2005a]. KPMG kan hierin met het BTW-ERP CIM een belangrijke rol vervullen. Wanneer services op basis van het BTW-ERP CIM worden geleverd kan dit een soort van proof of VAT-compliance voor bedrijven vervullen. Dit past prima in het kader van horizontaal toezicht als interne doelstelling van de Belastingdienst. Een eerste stap hierin is het 85

107 SUGGESTIES VOOR VERVOLGONDERZOEK overtuigen van de Belastingdienst van de werking en toegevoegde waarde van het BTW-ERP CIM. Daarnaast kan KPMG een nauwere samenwerking met SAP en andere ERP leveranciers aangaan. Deze samenwerking kan bestaan uit het delen van kennis op ERP-BTW gebied en de ontwikkeling van pricing models die voor specifieke bedrijfstypologieën gelden. Het BTW-ERP CIM kan als basis fungeren voor de ontwikkeling van de pricing models. 8.4 Suggesties voor vervolgonderzoek Gedurende dit afstudeeronderzoek is een aantal aspecten naar voren gekomen die verdere verdieping verdienen en geschikt zijn voor vervolgonderzoek. Als eerste verdient de problematiek met institutioneel ontwerp extra aandacht. Tijdens dit onderzoek is inzicht verschaft in BTW-wetgeving en de rol van de Belastingdienst. Er is geconcludeerd dat de volwassenheid van technologie nog niet optimaal benut wordt door de spelregels die de instituties opleggen aan het ondernemen binnen de maatschappij. Een interessant onderzoek dat hierop aansluit is de vraag hoe de uitvoering van BTW-wetgeving door de Belastingdienst kan worden aangepast opdat bedrijven zo weinig mogelijk kosten maken voor het BTW-compliant worden. Een ethisch aspect dat hieraan kleeft is dat bedrijven kosten-baten analyses houden van de risico s op boetes ten opzichte van compliance-kosten. Deze tendens bevat interessante ethische aspecten, die het doel en uitvoerbaarheid van wetgeving ter discussies stelt. Het BTW-ERP CIM is een eerste stap, maar zegt nog niets over de gevolgen van de werkwijze van de Belastingdienst voor de toepassing van technologie. Een ander aspect betreft de invulling van de BTW-determinanten vanuit SAP. Er is een mapping beschreven van de BTW-determinanten naar de tabellen van SAP. Een interessante vraag is hoe deze data in de tabellen wordt geplaatst. En welke gevolgen heeft de organisatiestructuur van bedrijven voor de manier waarop de data in de tabellen wordt geplaatst? Een vervolgonderzoek kan dieper ingaan op de relatie tussen de plaats van de BTW-determinanten binnen SAP en de organisatiestructuur van het bedrijf. Met deze resultaten kunnen de BTW-determinanten op een dieper niveau binnen SAP worden beschreven alvorens de condition technique wordt gebruikt. 86

108

109 Bibliografie [Aken van, 2002] Aken van, J. E. (2002). Strategievorming en Organisatiestructurering: Organisatiekunde vanuit de Ontwerpbenadering. Deventer:Kluwer. [Belastingdienst, 2005a] Belastingdienst (2005a). Bedrijfsplan [Belastingdienst, 2005b] Belastingdienst (2005b). Beheersverslag [Berre et al., 2004] Berre, A.-J., Elvesaeter, J. O., Aagedal, J., Oldevik, J., Solberg, B., and Nordmoen, B. (2004). Component and Model-based Development Methodology; Methodology Handbook v Sintef ICT. [Bijker, 1990] Bijker, W. E. (1990). The Social Construction of Technology. PhD thesis, Universiteit Twente, Enschede. [Blijswijk et al., 2005] Blijswijk, J. A. M., Dijkhuizen, F. J., and Lengkeek, L. J. (2005). Elsevier BTW Almanak Elsevier Financieel en Fiscaal. [Brassard, 1989] Brassard, M. (1989). The Memory Jogger Plus+ ; Featuring the Seven Management and Planning Tools. Methuen: GOAL/QPC. [Callaway, 2000] Callaway, E. (2000). ERP - The Next Generation ; ERP is web-enabled for E-business. Charleston:Computer Technology Research Corporation. [Callon, 1997] Callon, M. (1997). Actor-Network Theory - The Market Test (draft). Centre for Social Theory and Technology (CSTT). [Chand et al., 2005] Chand, D., Hachey, G., Hunton, J., Owhoso, V., and Vasudevan, S. (2005). A Balanced Scorecard based Framework for assessing the strategic impacts of ERP systems. Computers in Industry, 56: [Curran and Keller, 1999] Curran, T. and Keller, G. (1999). SAP R/3 Business Blueprint. [EEG, 1967] EEG (1967). Eerste Richtlijn 67/227/EEG van de Raad van 11 april 1967 betreffende de harmonisatie van de wetgevingen der Lid-staten inzake omzetbelasting. [EEG, 1977] EEG (1977). Zesde Richtlijn 77/388/EEG van de Raad van 17 mei 1977 betreffende de harmonisatie van de wetgevingen der Lid-staten inzake omzetbelasting - Gemeenschappelijk stelsel van belasting over de toegevoegde waarde: uniforme grondslag. [EEG, 2001] EEG (2001). Richtlijn 2001/115/EEG van de Raad van 20 december 2001 tot wijziging van Richtlijn 77/388/EEG met het oog op de vereenvoudiging, modernisering en harmonisering van de ter zake van de facturering geldende voorwaarden op het gebied van de belasting over de toegevoegde waarde. 88

110 BIBLIOGRAFIE 89 [Goossenaerts, 2004] Goossenaerts, J. B. M. (2004). Interoperability in the Model Accelerated Society. In: Cunningham, P. and Cunningham, M.: eadoption and the Knowledge Economy: Issues, Applications, Case Studies. Amsterdam:IOS Press, pages [Goossenaerts, 2006a] Goossenaerts, J. B. M. (2006a). Deploying e-maintenance: A roadmap and its service infrastructure. Working Paper. [Goossenaerts, 2006b] Goossenaerts, J. B. M. (2006b). Presentation: A Society Wide Architectural Framework and its Research Challenges. SWAF YNU.pdf. [Goossenaerts, 2006c] Goossenaerts, J. B. M. (2006c). Strategy Modelling and Scenarios in Social Networks adopting Information Systems. Working Paper. [Gordijn and Akkermans, 2003] Gordijn, J. and Akkermans, J. M. (2003). Value-based requirements engineering: exploring innovative e-commerce ideas. Requirements Engineering, 8: [Gupta and Kohli, 2006] Gupta, M. and Kohli, A. (2006). Enterprise Resource Planning Systems and its implications for operations function. Technovation, 26: [Hee van, 1994] Hee van, K. M. (1994). Information System Engineering: a Formal Approach. Cambridge University Press. [Hruby, 2006] Hruby, P. (2006). Model-Driven Design Using Business Patterns. Springer-Verlag. [Kaplan and Norton, 1997] Kaplan, R. S. and Norton, D. (1997). Op kop met de Balanced Scorecard; Strategie vertaald naar actie. Harvard Business School Press. [KPMG, 2004] KPMG (2004). Business Unit Plan, IRM Zuid ( ). [KPMG, 2005] KPMG (2005). KPMG jaarverslag 2004/2005. [Lamb, 1996] Lamb, R. (1996). Interorganizational Relationships and Information Services:How Technical and Institutional Environments influence Data Gathering Practices. PhD thesis, University of California, Irvine. [Latour, 1987] Latour, B. (1987). Science in Action: How to follow Scientists and Engineers through Society. Milton Keynes: Open University. [McBride, 2005] McBride, N. (2005). Using Actor-Network Theory to predict the Organisational Success of a Communications Network. De Montfort University, Leicester, UK. [McMaster et al., 1997] McMaster, T., Vidgen, R. T., and Wastell, D. G. (1997). Towards an Understanding of Technology in Transition: Two Conflicting Theories. [Morioka et al., 2006] Morioka, T., Saito, O., and Yabar, H. (2006). The pathway to a sustainable industrial society - initiative of the Research Institute for Sustainable Science (RISS) at Osaka University. Integrated Research System for Sustainability Science and Springer Verlag. [North, 1990] North, D. C. (1990). Institutions, Institutional Change and Economic Performance. Cambridge University Press. [OMG, 2002] OMG (2002). UML 2.0 OCL Language Description, Object Management Group. 89

111 90 BIBLIOGRAFIE [OMG, 2004] OMG (2004). Unified Modeling Language 2.0, Object Management Group. [Praat van and Suerink, 2003] Praat van, J. and Suerink, H. (2003). Inleiding EDP-auditing. Ten Hagen & Stam B.V. [Rashid et al., 2002] Rashid, M. A., Hossain, L., and Patrick, J. D. (2002). The Evolution of ERP Systems: A Historical Perspective. Idea Group Publishing. [Rogers, 2003] Rogers, E. M. (2003). Diffusion of Innovations. London Free Press, 5th edition. [Rosemann and Wiese, 1999] Rosemann, M. and Wiese, J. (1999). Measuring the Performance of ERP software - a Balanced Scorecard Approach. Proceedings of the 10th Australasian Conference on Information Systems, pages [SAP, 2001] SAP (2001). Pricing and Conditions (SD-BF-PR) release 4.6c. SAP AG. [SAP, 2006] SAP (2006). Pricing using the Condition Technique. [Strien van, 1975] Strien van, P. J. (1975). Naar een methodologie van het praktijkdenken in de sociale wetenschappen. Nederlands Tijdschrift voor de Psychologie, 30: [Tatnall and Gilding, 1999] Tatnall, A. and Gilding, A. (1999). Actor-Network Theory and Information Systems Research. Proceedings 10th Australasian Conference, pages [Uitv.besch., 1968] Uitv.besch. (1968). Uitvoeringsbeschikking omzetbelasting [Uitv.besl., 1968] Uitv.besl. (1968). Uitvoeringsbesluit omzetbelasting [van Oosterom et al., 2006] van Oosterom, P. J. M., Lemmen, C. H. J., Ingvarsson, T., van der Molen, P., Ploeger, H. D., Quak, C. W., Stoter, J. E., and Zevenbergen, J. (2006). The core cadastrial domain model. Computer, Environments and Urban Systems, 30: [Vervloed and Bod, 1999] Vervloed, J. L. M. J. and Bod, W. B. (1999). Wegwijs in de BTW. Koninklijke Vermande. [Wagner, 2002] Wagner, G. (2002). Specification of Information Systems: part I and part II. Technical report, Technische Universiteit Eindhoven (TU/e). [Wagner, 2004] Wagner, G. (2004). Model Transformations in Data Object Modelling. Technical report, Technische Universiteit Eindhoven (TU/e). [WetOB, 1968] WetOB (1968). Wet van 28 juni 1968, houdende vervanging van de bestaande omzetbelasting door een omzetbelasting volgens het stelsel van heffing over de toegevoegde waarde. [Whitten et al., 2004] Whitten, J. L., Bentley, L. D., and Dittman, K. (2004). Systems Analysis and Design Methods. McGraw-Hill, 6th edition. [Wikipedia, 2006] Wikipedia (2006). 90

112

113 Deel V Bijlagen 92

114

115 Bijlage A Bedrijfsbeschrijving KPMG A.1 KPMG Nederland KPMG is een wereldwijd netwerk van professionele dienstverleners op het gebied van accountancy en consultancy en belastingadvies. KPMG behoort tot de Big 4 van internationale accountancykantoren. De naam KPMG staat voor: Klynveld: Piet Klynveld (NL) richtte in 1917 het accountantskantoor Klynveld Kraayenhof & Co. op in Amsterdam. Peat: William Barclay Peat (UK) richtte in 1870 het accountantskantoor William Barclay Peat & Co. op in London. Marwick: James Marwick (VS) richtte in 1897 het accountantskantoor Marwick, Mitchell & Co. op met Roger Mitchell in New York City. Goerdeler: Dr. Reinhardt Goerdeler (DE) was gedurende vele jaren voorzitter van de Duitse organisatie Deutsche Treuhandgesellschaft. KPMG in haar huidige vorm is in 1987 ontstaan uit een fusie van Peat Marwick International (PMI) en Klynveld Main Goerdeler (KMG). PMI is in 1911 ontstaan door een fusie van Marwick, Mitchell & Co. en William Barclay Peat & Co. KMG is in 1979 ontstaan uit een fusie van Kraayenhof & Co., Deutsche Treuhandgesellschaft en McLintock Main Lafrentz & Co. De dienstverlening van KPMG strekt zich uit over drie hoofdgebieden: Audit, Tax en Advisory Auditdiensten omvatten onder andere het toetsen van financiële verantwoordingen ten behoeve van derden, beoordelingen van strategie, bedrijfsrisico s en de implicaties voor de jaarrekening. Taxdiensten hebben betrekking op dienstverlening op alle deelterreinen van het fiscale vakgebied, waaronder vennootschaps-, inkomsten-, omzet-, en loonbelasting. Daarnaast worden diensten verleend met betrekking tot invoerrechten, onroerende zaakbelasting, milieuheffingen en transfer pricing. In Nederland wordt deze tak van dienstverlening uitgevoerd door KPMG Meijburg & Co. die als zelfstandige onderneming opereert en deel uitmaakt van het KPMG 94

116 A.2. KERNCIJFERS 95 netwerk. Advisorydiensten hebben betrekking op het adviseren betreffende het optimaal inrichten van organisaties. Hierbij valt te denken aan analyse, meting en beheersing van bedrijfsrisico s, financiële risico s, operationele risico s en project risico s (risk management). Hieronder valt ook de advisering over onder meer het managen van processen, kosten en performance (business performance improvement). KPMG betrekt haar klanten uit grote nationale en internationale ondernemingen, de middenmarkt en non-profitorganisaties, overheden en semi-overheidsinstellingen. Bij de grote nationale en internationale ondernemingen gaat het voornamelijk om beursgenoteerde bedrijven die gebonden zijn aan strikte wet- en regelgeving. De klanten uit het middenmarkt segment hebben een grote verbondenheid met de regio en daardoor een intensief contact met de accountant. A.2 Kerncijfers Nederland Internationaal Omzet 2005 e 603,5 miljoen $ 15,7 miljard Vestigingen in # landen 144 landen Vestigingen in # steden 19 steden 715 steden #Medewerkers Gemiddelde leeftijd 32 jaar 33 jaar Hoofdkantoor Amstelveen Amstelveen Tabel A.1: Kerncijfers KPMG Bron:[KPMG, 2005] A.3 Organigram KPMG International is een Zwitserse coöperatie. Alle nationale vestigingen van KPMG zijn lid van de coöperatie en hebben haar eigen organisatiestructuur. KPMG Meijburg & Co. is niet opgenomen in het organigram aangezien het een zelfstandige organisatie is en als zodanig onderdeel is van het KPMG netwerk. Het organisatieschema van KPMG Holding N.V. is weergegeven in Figuur A.1. 95

117 96 A.4. MARKTEN Figuur A.1: Organigram KPMG Holding N.V. A.4 Markten KPMG Information Risk Management (IRM) opereert in de volgende Lines of Businesses (LoBs): Financial Services (FS) Consumer Markets (CM) Industrial Markets (IM) Information Communication & Entertainment (ICE) Healthcare (HC) Government & Education (GE) De afzonderlijke LoBs worden in een aantal segmenten verdeeld. Binnen deze segmenten bevinden zich de klanten die door KPMG IRM worden bediend. Kijkend naar KPMG IRM Zuid is de belangrijkste markt de general practice markt in de regio Brabant, Zeeland en Limburg. De belangrijkste LoBs voor KPMG IRM Zuid zijn: Financial Markets, Consumer Markets en Industrial Markets. A.5 Service Lines De dienstverlening van KPMG IRM strekt zich uit over de volgende service lines: Package Solutions (PS) Ondersteuning bij de implementatie en/of selectie van ERP-pakketten. De implementatie 96

118 A.5. SERVICE LINES 97 van een ERP-pakket is een complex traject waarbij het noodzakelijk is dat risico s snel worden opgespoord en beheerst. Aangezien ERP-pakketten van grote invloed zijn op de kwaliteit van de operationele processen, is het van belang dat het implementatietraject optimaal verloopt. Informatiebeveiliging (IB) Ondersteuning bij het beschermen van ICT applicaties. Informatiestromen spelen een essentiële rol binnen ondernemingen. Het is daarom van groot belang dat deze stromen goed beschermd en beveiligd worden. Risico s moeten beheersbaar gemaakt worden en een goede beveiliging moet waarde toe kunnen voegen aan de interne bedrijfsprocessen. Projectmanagement (PM) Ondersteuning bij het beheersen van ICT projecten. Succesvolle ICT projecten zijn voor elke onderneming van groot belang. Goed projectmanagement verlaagt risico s en geeft meer inzicht in de kwaliteit, haalbaarheid en betrouwbaarheid van een project. ICT Performance Improvement (ITPI) Het behalen van meer rendement uit ICT. Efficiency en effectiviteit van besturing van ICT processen is van belang om duidelijk in kaart te hebben wat de doelstellingen en mogelijkheden zijn voor de organisatie ten aanzien van ICT. ICT Assurance (IA) Zekerheid en betrouwbaarheid van ICT. Continuïteit van bedrijfsvoering is een belangrijk aspect voor het optimaal kunnen opereren. Dit vereist tevens zekerheid over de continuïteit en betrouwbaarheid van informatiesystemen. Organisaties hebben zekerheid nodig over betrouwbaarheid van ICT als ondersteuning van de primaire processen. 97

119 Bijlage B Methodieken Probleemanalyse B.1 De Balanced Scorecard Ondernemingen opereren vanuit strategische plannen waarin missie en visie wordt vastgelegd. De missie beantwoordt de vraag waartoe een onderneming bestaat en waarom ze doet wat ze doet. De visie geeft aan waar de onderneming op lange termijn naar toe wil [Aken van, 2002]. Het strategisch plan beschrijft hoe de onderneming vanuit een vastgelegde missie haar beschreven doelen in de visie wil bereiken. Door doelstellingen te formuleren die de visie van de onderneming ondersteunen worden ondernemingen in staat gesteld om te meten in welke mate aan de visie wordt beantwoord. Wanneer doelstellingen niet meer behaald worden ontstaat behoefte aan verandering die bijdraagt aan de verbetering van de geformuleerde doelstellingen. Een instrument dat ruim tien jaar geleden is ontwikkeld door twee Amerikaanse hoogleraren, Robert S. Kaplan en David P. Norton, is de Balanced Scorecard [Kaplan and Norton, 1997]. De Balanced Scorecard (BSC) levert een kader voor een vertaling van strategie en visie van een onderneming in operationele termen. Een BSC verduidelijkt de strategische doelstellingen en identificeert de middelen waarmee deze doelstellingen getracht worden te behaald. De BSC is een systeem waarbij door middel van een groep samenhangende financiële en niet-financiële indicatoren inzicht wordt gegeven in het behalen van een aantal kwantitatieve en kwalitatieve doelen. Deze doelen zijn gebaseerd op kritieke succesfactoren voor het realiseren van de vastgestelde strategie. Kritieke succesfactoren zijn kwalitatieve omschrijvingen van een deel van de bedrijfsstrategie die voor de organisatie beheersbaar moeten zijn om succesvol te zijn. Voorbeelden van kritieke succesfactoren zijn kwaliteit, kosten en tijdigheid. Kritieke succesfactoren worden onderverdeeld in vier perspectieven waarnaar moet worden gekeken [Kaplan and Norton, 1997]: Financieel Hoe aanlokkelijk moeten we zijn voor beleggers voor financieel succes? Afnemers Hoe aanlokkelijk moeten we zijn voor onze afnemers om onze visie (doelstelling) te realiseren? Leerresultaten en groei Hoe blijven we in staat tot permanente verandering en verbetering om onze visie te realiseren? Interne bedrijfsvoering Waarin moeten we uitblinken om afnemers en aandeelhouders tevreden te stellen? 98

120 B.2. ACTOR-NETWORK THEORY 99 Figuur B.1: Vier perspectieven van de Balanced Scorecard Uit:[Kaplan and Norton, 1997] Naast een samenhangend geheel van oorzaken en gevolgen binnen ieder afzonderlijk perspectief bestaan er ook relaties tussen kritieke succesfactoren buiten de afzonderlijke perspectieven. Zo kunnen er verticale ketens van oorzaak en gevolg gevormd worden door de vier perspectieven in de BSC. Deze verticale ketens worden causale relaties genoemd. Om te meten of doelen worden bereikt, wordt een aantal prestatie-indicatoren vastgesteld die samen een kwantitatieve invulling geven aan een kritieke succesfactor. Deze indicatoren worden vaak scoredrivers genoemd. Een goede mix tussen resultaatmetingen en scoredrivers vormt de basis voor een goede implementatie van een BSC. B.2 Actor-Network Theory Innovatie is gedefinieerd als een idee dat door een persoon of groep van personen als nieuw wordt ervaren [Rogers, 2003]. Het ontwikkelen van een nieuwe service ter ondersteuning van BTW-berekening in ERPsystemen (BTW-ERP) kan worden gezien als een vorm van innovatie. Actor-Network Theory (ANT) beschrijft de samenleving als een wereld die is opgebouwd uit heterogene entiteiten bestaande uit menselijke en niet-menselijke elementen [Latour, 1987]. ANT is ontwikkeld als middel voor het analyseren van situaties waarin een scheiding van deze elementen lastig is [Callon, 1997]. De ontwikkeling van een BTW-ERP service opereert in een spanningsveld van ERP-distributeurs en -systemen, bedrijven die gebruikmaken van ERP-systemen en BTW-wetgeving. Daarnaast speelt de Belastingdienst als controlerende organisatie van wetgeving en KPMG (zowel IRM als Meijburg) als ondersteunende organisatie een rol binnen het geheel. Het betreft hier een wereld van niet alleen menselijke entiteiten zoals KPMG en de Belastingdienst maar ook niet-menselijke entiteiten als BTW-wetgeving en ERP-systemen. Bijker s sociale constructie van technologie (SCT) [Bijker, 1990] geeft zicht op adoptie van technologie door te kijken naar de invloeden van relevante sociale groepen [Lamb, 1996]. Sociale 99

121 100 B.2. ACTOR-NETWORK THEORY groepen beïnvloeden adoptie van nieuwe technologieën naar gelang haar eigen inzichten en belangen. Stabiliteit van de nieuwe technologie ontstaat pas wanneer overeenstemming is bereikt tussen de sociale groepen over de definitie van de nieuwe technologie [Lamb, 1996]. Actoren vormen netwerken van invloeden die stabiel worden op het moment dat deze aansluiten bij de technologie. Deze aansluiting wordt bereikt door de verschuiving (translation) van invloeden en het aanschuiven van actoren in het netwerk [McBride, 2005]. Een netwerk wordt sterker door opeenvolgende aansluitingen van actoren. Sommige actoren zullen door samen te werken allianties vormen om het netwerk te ondersteunen, terwijl andere actoren allianties zullen vormen om het netwerk te veranderen. Hoe meer invloed een actor heeft, des te groter de kans dat het netwerk uit haar huidige toestand verschuift naar een nieuwe toestand als reactie op de invloed van de actor [McMaster et al., 1997]. ANT biedt een krachtig raamwerk bij het begrijpen van het innovatieproces van informatiesystemen, voornamelijk in situaties waar sociale, technologische en politieke wisselwerkingen belangrijk zijn [Tatnall and Gilding, 1999]. 100

122

123 Bijlage C Wet op de Omzetbelasting C.1 Opbouw Wet OB De hoofdstukindeling van de Wet op de Omzetbelasting 1968 is als volgt [WetOB, 1968]: Hoofdstuk I. Inleidende bepalingen Artikel 1-2 Hoofdstuk II: Heffing ter zake van leveringen en diensten Artikel 3-17 Afdeling 1. Belastbaar feit Afdeling 2. Maatstaf en tarief van heffing Afdeling 3. Vrijstellingen Afdeling 4. Wijze van heffing Hoofdstuk IIa. Heffing ter zake van intracommunautaire verwervingen Artikel 17a-17h Afdeling 1. Belastbaar feit Afdeling 2. Maatstaf en tarief van heffing Afdeling 3. Vrijstellingen Afdeling 4. Wijze van heffing Hoofdstuk III. Heffing ter zake van invoer Artikel Afdeling 1. Belastbaar feit Afdeling 2. Maatstaf en tarief van heffing Afdeling 3. Vrijstellingen Afdeling 4. Wijze van heffing Hoofdstuk IV. Uitvoer van goederen Artikel 24 Hoofdstuk V. Bijzondere regelingen Artikel

124 C.2. HEFFINGSSTELSEL 103 Afdeling 1. Vermindering van belasting (kleine ondernemers) Afdeling 2. Voldoening naar ontvangsten Afdeling 3. Landbouwregeling Afdeling 4. Tabaksproducten en accijnsgoederen, andere dan tabaksproducten Afdeling 5. Regeling voor gebruikte goederen, kunstvoorwerpen, voorwerpen voor verzamelingen en antiquiteiten Afdeling 6. Regeling voor beleggingsgoud Afdeling 7. Regeling voor niet in de gemeenschap gevestigde ondernemers die elektronische diensten verrichten aan anderen dan ondernemers die in de gemeenschap wonen of zijn gevestigd Hoofdstuk VI. Bijzondere bepalingen Artikel Hoofdstuk VII. Bestuurlijke boete Artikel Hoofdstuk VIII. Strafbepaling Artikel 42 Hoofdstuk IX. Overgangs- en slotbepalingen Artikel Tabel I. Producten waarop verlaagd tarief van kracht is Tabel II. Producten waarop nultarief van kracht is C.2 Heffingsstelsel Nederland hanteert vanaf 1969 een geheel niet-cumulatief heffingsstelsel. In Tabel C.1 wordt de werking van dit stelsel geïllustreerd. Te zien is dat elke opeenvolgende schakel in de bedrijfskolom 5% voorbelasting in rekening gebracht krijgt die weer aftrekbaar is, met uitzondering van de consument die daadwerkelijk 5% over de verkoopprijs moet betalen. Het totaal aan de fiscus betaalde bedrag van e 58,75 - e 37,- = e 21,75. Dit is 5% van de consumentenprijs exclusief omzetbelasting (e 435,-). 103

125 104 C.3. BEPALING BELASTINGPLICHTIGE Inkoopprijs (excl. BTW) Kosten+ Winst Verkoopprijs (excl. BTW) 5% BTW 5% Voorbelasting Grondstoffenfabrikant e 0 e 100 e 100 e 5 - Fabrikant koopt van grondstoffenfabrikant en levert aan groothandel e 100 e 180 e 280 e 14 e 5 Groothandel koopt van fabrikant en levert aan kleinhandel e 280 e 80 e 360 e 18 e 14 Kleinhandel koopt van groothandel en levert aan consument e 360 e 75 e 435 e 21,75 e 18 Totaal e 435 e 58,75 e 37 Tabel C.1: Geheel meermalig, niet-cumulatief stelsel met voorbelasting Uit:[Vervloed and Bod, 1999] C.3 Bepaling Belastingplichtige Keuzemodel Figuur C.1: Bepaling categorie belastingplichtige 104

126 C.4. LIDSTATEN EUROPESE UNIE 105 Toelichting keuzemodel Figuur C.1 laat zien dat er tien categorieën belastingplichtigen kunnen worden onderscheiden. Op basis van een aantal keuzemomenten wordt hiertussen onderscheid gemaakt. Binnen een aantal keuzemomenten is aangegeven in welk deel van de Wet OB [WetOB, 1968] het begrip is vastgelegd. Het grootste deel van de belastingplichtigen waar KPMG services voor verricht, valt binnen de groep Nederlandse ondernemer in het kader van ondernemer. C.4 Lidstaten Europese Unie In de Europese Unie (EU) wordt onderscheid gemaakt tussen het douanegebied, het accijnsgebied en het BTW-gebied. Deze gebieden zijn niet geheel gelijk. Het volgende overzicht geeft aan welke landen en gebieden voor de heffing van de BTW tot de EU behoren [Blijswijk et al., 2005]: 105

127 106 C.4. LIDSTATEN EUROPESE UNIE EU-land met inbegrip van met uitzondering van België - - Cyprus - - Denemarken - Faeröer Eilanden, Groenland Duitsland - Büsingen, Helgoland Estland - - Finland - Åland Eilanden Frankrijk Monaco Overzeese departementen (DOM): Guadeloupe, Frans Guyana, Martinique en La Réunion Overzeese gebieden (TOM): Nieuw Caledonië, de Wallis Eilanden en Futuna Eilanden, Frans Polynesië, Franse Zuidelijke en Antarctische Territoria en de Franse territoriale lichamen (Mayotte, Saint-Pierre en Miquelon) Griekenland - Berg Átos Groot-Brittannië Eiland Man Kanaal Eilanden: Alderney, Guernsey, Jersey, en Noord-Ierland Sark en Hern Gibraltar, Overzeese gebieden: Anguilla, Cayman Eilanden, Falkland Eilanden, Zuid-Georgia en de Sandwich Eilanden, Turks en Caicos Eilanden, Britse Maagden Eilanden, Montserrat, Pitcairn Eilanden, Sint Helena en afhankelijke gebieden, Brits Antarctisch Territorium en Brits Territorium in de Indische Oceaan Hongarije - - Ierland - - Italië Aosta Livigno, Campione d Italia De nationale wateren van het Meer van Lugano die zijn gelegen tussen de oever en de politieke grens van het gebied tussen Ponte Tresa en Porto Ceresio, San Marino Letland - - Litouwen - - Luxemburg - - Malta - - Nederland - Aruba, Bonaire, Curaçao, Sint Maarten, Saba en Sint Eustatius Oostenrijk - - Polen - - Portugal Azoren, Madeira Macau Slovenië - - Slowakijke - - Spanje Balearen Andorra, Canarische Eilanden, Ceuta, Melilla Tsjechië - - Zweden - - Tabel C.2: Overzicht landen en gebieden EU 106

128 C.5. FACTUURVEREISTEN BTW 107 C.5 Factuurvereisten BTW De Wet OB 1 schrijft vanaf 1 januari 2004 een aantal factuurvereisten voor met betrekking tot BTW. Een aantal eisen geldt alleen onder bepaalde omstandigheden. De volgende tabel geeft een overzicht van alle eisen en vermeldt aan welke eisen altijd moet worden voldaan. Identification Invoice Requirement Always obligatory F1 The date of issue Yes F2 A sequential number, based on one or more series, Yes which uniquely identifies the invoice F3 The VAT identification number under which the Yes taxable person supplied the goods or services F4 The VAT identification number of the customer on No which goods are supplied or services are rendered F5 The full name and address of the taxable person Yes F6 The full name and address of the customer Yes F7 The quantity and nature of the goods supplied or Yes the extent and nature of the services rendered F8 The data on which the supply of goods or of Yes services was made or completed F9 The taxable amount per rate or exemption, the unit Yes price exclusive tax and any discounts or rebates if they are not included in the unit price F10 The VAT rate applied Yes F11 The VAT amount payable Yes F12 Reference to applied simplified triangulation rule No F13 Reference to applied margin scheme rule No Tabel C.3: BTW-eisen 1 Art. 35a Wet OB [WetOB, 1968] 107

129 Bijlage D SAP R/3 D.1 Architectuur SAP R/3 is een client/server systeem. De architectuur van SAP maakt het mogelijk om tegelijk op verschillende PC s te werken die onderling in een netwerk verbonden zijn. De systeemarchitectuur van SAP bestaat uit drie lagen die het mogelijk maken de presentatie, applicatielogica en gegevensbeheer door verschillende computers te laten uitvoeren. Figuur D.1 toont deze 3-laagse systeemarchitectuur. Figuur D.1: 3-laagse client-server architectuur Database server De Database server wordt ondersteund door een centrale computer. Op deze server worden alle gegevens centraal opgeslagen. Enkele ondersteunde platforms: IBM DB2, Microsoft SQL-server en Oracle. Application server De Application server is verantwoordelijk voor de systeemadministratie en voor functies als het afdrukken van rapporten en de bewerking van gegevens gebruikmakend van applicatielogica. Enkele ondersteunde platforms: UNIX, AS/400 en Windows NT. 108

130 D.2. MODULES 109 Presentation systems Door middel van de Presentation systems worden de verwerkte gegevens toegankelijk gemaakt voor de eindgebruikers. Binnen SAP R/3 fungeert de SAP GUI als grafische front-end. D.2 Modules In Hoofdstuk is beschreven dat SAP is opgebouwd uit een aantal modules en submodules. Figuur D.2 toont een grafische weergave van de module-opbouw van SAP. Figuur D.2: Modules binnen SAP R/3 SD - Sales & Distribution Request for Quotation (RFQ), Sales Orders, Pricing, Picking, Packing and Shipping MM - Materials Management Requisitions, Purchase Orders, Goods Receipts, Accounts Payable, Inventory Management, BOM s and Master Raw Materials PP - Production Planning Capacity Planning, Master Production Scheduling, Material Requirements Planning and Shop Floor QM - Quality Management Planning, Execution, Inspections and Certifications PM - Plant Maintenance Labour, Material, Down Time and Outages HR - Human Resources Employment History, Payroll, Training, Career Management and Succession Planning 109

131 110 D.3. ORGANISATIESTRUCTUUR FI - Financial Accounting General Ledger, Book Close, Tax, Accounts Receivable, Accounts Payable, Consolidation and Special Ledgers CO - Controlling Cost Elements, Cost Centres, Profit Centres, Internal Orders, Activity Based Costing and Product Costing AM - Fixed Asset Management Purchase, Sale, Depreciation and Tracking PS - Project Systems Make-to-order, Plant Shut Downs and Third Party Billing WF - Workflow IS - Industry Solutions Naast deze modulen is er binnen SAP een aantal tabellen aanwezig waar de modulen gebruik van maken. Deze tabellen zijn onderdeel van de SAP Masterdata. Zo bestaat er bijvoorbeeld een Customer-mastertabel en een Material-mastertabel. D.3 Organisatiestructuur Binnen de modules FI-CO wordt een aantal organisatie-eenheden onderscheiden die de organisatiestructuur vastlegt. Dit is met name belangrijk bij externe en interne accounting en rapportageverplichtingen die daarbij een rol spelen. Figuur D.3: Overzicht organisatie-eenheden binnen FI-CO De belangrijkste entiteiten worden hieronder toegelicht: 110

132 D.3. ORGANISATIESTRUCTUUR 111 Client De client is het hoogste hiërarchische niveau binnen SAP. Op dit niveau bevindt zich een complete database waarin alle tabellen opgeslagen zijn die benodigd zijn voor het functioneren van een volledige geïntegreerd systeem. De masterrecords zijn vastgelegd op dit niveau. Company Een client kan bestaan uit meerdere companies. Op company-niveau worden de geconsolideerde financial statements vastgelegd. Een company kan bestaan uit meerdere company codes. Company Code De company code is de kleinste (fiscale) eenheid waarbinnen een aparte boekhouding kan worden gevoerd. Wanneer SAP binnen een grote holding functioneert, wordt voor elk afzonderlijk onderdeel van de holding een company code aangemaakt. 111

133 Bijlage E Systeemontwikkeling E.1 FAST FAST (Framework for the Application of Systems Techniques) is een methodologie die het onderscheid maakt tussen de systeemlevenscyclus stadia System Development (SD) en System Operation and Maintenance (SOM) [Whitten et al., 2004]. In SD maakt FAST onderscheid tussen een aantal SD-fasen. Elke fase levert een aantal deliverables die meegenomen worden naar de volgende fase. Daarnaast zit er een aantal beslissingsmomenten in de cyclus waarbij een go-or-no go beslissing wordt genomen. Figuur E.1: FAST fasen bij systeemontwikkeling Uit: [Whitten et al., 2004] (p.98) In bovenstaande figuur geven de pijlen met aan het begin een diamant-figuurtje de beslissingsmomenten aan. De repository is de plaats waar alle informatie, documentatie en kennis van de ontwikkeling 112

134 E.2. COMET 113 van het systeem is opgeslagen. De repository is in dit onderzoek ingevuld door de deliverables voorgeschreven door de COMET-methodologie. E.2 COMET In Figuur E.1 is naast de acht ontwikkelfasen in het midden een repository geplaatst waarin de deliverables worden gedocumenteerd. De COMET-methodologie [Berre et al., 2004] beschrijft een repositorystructuur met een aantal voorgeschreven deliverables. De invulling van de repository wordt in COMET stapsgewijs beschreven. In COMET wordt de focus sterk gelegd op een model-georiënteerde manier van productontwikkeling en -onderhoud. COMET staat voor Component and Model-based development Methodology. Figuur E.2: COMET repositorystructuur 113

135 Bijlage F Resultaten Probleemanalyse F.1 Stakeholderanalyse F.1.1 Macro-schaal Belastingwetgeving Het primaire doel van belastingwetgeving is het innen van geld zodat de overheid haar beleid goed uit kan voeren. Belastingen vormen het grootste deel van de inkomsten van de overheid. Het takenpakket van de overheid is na de Tweede Wereldoorlog flink toegenomen waardoor er een aantal nieuwe belastingsoorten is ingevoerd waaronder omzetbelasting en vennootschapsbelasting. Het Nederlandse belastingstelsel kenmerkt zich sinds die tijd door twee belangrijke uitgangspunten: het draagkrachtbeginsel en het profijtbeginsel ( Het profijtbeginsel voorziet in het feit dat wanneer mensen meer profijt hebben van een bepaalde overheidsvoorziening, daar ook meer voor moeten betalen (bijvoorbeeld automobilisten die wegenbelasting betalen). Het draagkrachtbeginsel is erop gebaseerd dat mensen met een hoger inkomen meer belasting moeten betalen (inkomstenbelasting). Het Ministerie van Financiën is verantwoordelijk voor de totstandkoming van wetgeving op het gebied van belastingen. De daadwerkelijke inning van belastinggelden is de taak van de Belastingdienst. De heffing van omzetbelasting is in grote lijnen vastgelegd in de Wet op de Omzetbelasting (Wet OB) [?]. Deze wet bestaat uit: Uitvoeringsbesluit omzetbelasting 1968 (Uitv.besl.OB) Uitvoeringsbeschikking omzetbelasting 1968 (Uitv.besch. OB) Besluit uitsluiting aftrek van omzetbelasting 1968 (BUA) De Grondwet (art. 104) legt vast dat belastingen ten behoeve van s Rijkskas worden geheven uit kracht van een wet. Figuur F.1 geeft de opbouw van de Wet OB weer en laat zien welke partijen goedkeuring moeten verlenen voor de totstandkoming van (een deel van) de Wet OB. In wet- en regelgeving wordt onderscheid gemaakt tussen een aantal soorten regelingen: Wetten, Algemene Maatregelen van Bestuur (AMvB), Ministeriële Regelingen (MR), Koninklijke Besluiten (KB) en Circulaires en Beleidsregels. De Wet OB bestaat uit een AMvB, een MR en een KB. 114

136 F.1 STAKEHOLDERANALYSE 115 Figuur F.1: Opbouw en totstandkoming Wet OB De Uitvoeringsbeschikking OB maakt het mogelijk dat wijzigingen in de uitvoering van de Wet OB snel plaats kunnen vinden omdat hiervoor geen rechtstreekse betrokkenheid van de Staten-Generaal en Regering vereist is. De Wet OB is gebaseerd op richtlijnen opgelegd door de Europese Unie (EU). In 1967 zijn door de raad van de Europese Economische Gemeenschap (EEG) twee richtlijnen vastgesteld met als doel de belastingwetgeving in de Lidstaten van de EU te harmoniseren. Een richtlijn verplicht de wetgevende instanties van de Lidstaten om de nationale wetgeving in overeenstemming te brengen met de doelstellingen die in de richtlijn geformuleerd zijn. Hierbij hoeft de tekst van de nationale wetgeving niet een letterlijke weergave te zijn van de tekst in de richtlijn. Het resultaat dient wel hetzelfde te zijn. De overheid heeft zich ten doel gesteld om de toepassing van de Europese richtlijnen met betrekking tot de omzetbelasting zo nauwkeurig mogelijk in de Nederlandse wetgeving op te nemen. Omdat wetgeving in elke situatie moet voorzien dient alles zeer zorgvuldig te worden vastgelegd zodat er geen gaten ontstaan. Elke definitie moet haarscherp en eenduidig zijn. Aangezien omzetbelasting betrekking heeft op goederen en diensten en deze in allerlei soorten en maten bestaan, moeten zeer nauwkeurige categorieseringen gemaakt worden per soort. Daarnaast hebben plaats en tijdstip van leveringen en diensten invloed op de regels voor het te heffen tarief. Het eenduidig beschrijven van regels voor dit soort gevallen levert een grote hoeveelheid tekst op, waarbij complexiteit onvermijdelijk is. De industrie speelt hier op in door bedrijven die worstelen met het toepassen van complexe wetgeving te adviseren. 115

137 116 F.1 STAKEHOLDERANALYSE De Belastingdienst De Belastingdienst (BD) verricht taken op de volgende gebieden [Belastingdienst, 2005b]: Heffing, controle en inning van rijksbelastingen Toezicht op de in-, uit- en doorvoer van goederen Toezicht op de naleving van wetgeving op economisch, gezondheids-, milieu- en veiligheidsterrein, economische ordening en financiële integriteit Heffing en inning van premies volksverzekeringen en werknemersverzekeringen Toekenning van en controle op inkomensafhankelijke toeslagen Richting de overheid heeft de BD een uitvoerende rol. Richting particulieren en ondernemingen heeft de BD naast een controlerende tevens een voorlichtende rol. De BD treedt nooit op in de rol van adviseur. Compliance staat centraal bij het werk van de BD. De BD is er om de bereidheid van belastingplichtigen en toeslaggerechtigden om wettelijke verplichtingen na te komen, te onderhouden en te versterken. Er is sprake van compliance als burgers en bedrijven relevante feiten juist, tijdig en volledig opgeven en tijdig het juiste bedrag betalen [Belastingdienst, 2005a]. Selectie van ondernemingen op controle door een inspecteur wordt gedaan op basis van risicoanalyse en de combinatie van een aantal factoren als ervaring uit het verleden, blootstelling aan nieuwe wetgeving en expertise van de inspecteur. Deze controle vindt altijd achteraf plaats aangezien BTW een vorm is van indirecte belasting. Voor de periodieke controle van aangiften en de betalingstermijnen gebruikt de BD een geautomatiseerd systeem. Deze systemen worden ontwikkeld in een eigen IT-instituut: Belastingdienst Centrum voor ICT (B/ICT). Voor de controle van belastingaangiftes gebruikt de BD tools in de vorm van een standaard query en een auditfile. Hiermee kunnen standaardgegevens die bij elk bedrijf aanwezig dienen te zijn zoals grootboekrekeningen etc. worden gecontroleerd. Daarnaast is veel maatwerk nodig om bedrijfsspecifieke controles uit te voeren. De BD vraagt om de benodigde data die door bedrijven moeten worden aangeleverd. Het is niet de taak van de BD om deze data aan te leveren. De BD ziet toekomstperspectief in horizontaal toezicht. Hiermee wil de BD private partijen en maatschappelijke organisaties betrekken bij het houden van toezicht. De basis hiervoor is een vertrouwen in de samenwerking met derden. Op deze manier wil de BD bepaalde minder risicovolle toezichtstaken overlaten aan gerespecteerde bedrijven om zo zelf meer aandacht te kunnen besteden aan de ondernemingen of particulieren die het niet zo nauw nemen met de regels. In het segment (zeer) grote ondernemingen liggen de grootste kansen voor de toepassing van horizontaal toezicht. De BD wil samenwerkingen in dit segment aangaan door overleg met specifieke partijen te intensiveren. Het belangrijkste punt hierbij is de vraag hoe de BD en ondernemingen als twee professionele partijen met elkaar om willen gaan. Horizontaal toezicht sluit aan bij de huidige vorm van verticaal toezicht waarbij de overheid van bovenaf controleert of de naleving van wetten en regels correct gebeurt. Daarnaast heeft de BD convenanten afgesloten over samenwerking en informatie-uitwisseling met onder andere de Politie, het OM, het UWV en de Arbeidsinspectie. 116

138 F.1 STAKEHOLDERANALYSE 117 F.1.2 Meso-schaal ERP-gebruikers (Bedrijven) Onder ERP-gebruikers worden ondernemingen verstaan die ERP-systemen gebruiken ter ondersteuning van de bedrijfsprocessen. Vaak zijn dit middelgrote tot grote ondernemingen. Deze bedrijven moeten wetten en regels toepassen die hen op worden gelegd door de overheid. Doordat wetgeving voor elke onderneming een andere impact heeft op de dagelijkse bedrijfsvoering zijn geen standaardpakketten beschikbaar ter ondersteuning van de interne processen. Omdat de implementatie van een ERP-systeem specialistische kennis vereist wordt deze taak vaak uitbesteed aan externe bedrijven die hierbij ondersteuning bieden. De BTW-strategie van een onderneming is slechts een klein deel van de onderdelen die in een ERP-systeem geïmplementeerd moeten worden. De risico s die ondernemingen lopen bij het verkeerd implementeren van de BTW-strategie lopen uiteen van het betalen van boetes en heffingsrentes tot het betalen van dubbele belastingen. ERP-gebruikers hebben baat bij ondersteuning en advisering betreffende inrichting van ERP-systemen zodat de BTW strategie overeenkomt met de inrichting van het systeem. ERP-vendors De leveranciers van ERP-systemen zijn verantwoordelijk voor de functionaliteit van de systemen. Hierbij moeten ze inspelen op de eisen die worden gesteld door bedrijven. Deze eisen komen voort uit de sociale context waarin bedrijven opereren. Bedrijven hebben steeds vaker te maken met strenge wet- en regelgeving die impact heeft op de inrichting van ERP-systemen. Voorbeelden hiervan zijn de International Financial Reporting Standards (IFRS) en Sarbanes Oxley (SOx). ERP-vendors dienen hier op in te spelen door de ERP-systemen van functionaliteiten te voorzien die aansluiten bij de actuele wetten en regels. Ook omzetbelastingwetgeving vormt een belangrijke input voor de eisen aan functionaliteiten van ERP-systemen. De ontwikkeling van functionaliteiten die hierin voorzien vergt specialistische kennis van fiscale vraagstukken. Elk bedrijf heeft haar specifieke eisen aan een inrichting die voldoet aan de BTW-regels die gelden voor het desbetreffende bedrijf. Het is een complex verhaal wat de relatie is tussen de (verandering van) wetgeving en de relevante overeenkomstige onderdelen van het ERP-systeem. Op dit punt voorzien de ERP-vendors niet door slechts de juiste functionaliteit in de software implementeren. De directe link naar de wetgeving ontbreekt hier. Een BTW-ERP model legt de basis voor het invullen van deze ontbrekende link. ERP-vendors hebben er belang bij dat de toepassing van hun systemen zo gemakkelijk mogelijk te implementeren is bij hun klanten. Een BTW-ERP model verlaagt de complexiteit van de vertaling van een BTW-strategie naar de inrichting van een ERP-systeem. Onderstaande figuur geeft de huidige situatie weer bij de inrichting van ERP-systemen. 117

139 118 F.1 STAKEHOLDERANALYSE Figuur F.2: Stakeholders bij implementatie ERP-systemen Externe eisen bepalen de eisen aan functionaliteiten van ERP-systemen. Deze eisen kunnen van de bedrijven zelf komen maar kunnen ook door wet- of regelgeving worden opgelegd. De ERPsystemen worden vervolgens ingericht met hulp van externe bedrijven in samenwerking met de ERP-vendors en de organisatie. De rode lijnen geven de plaats van een BTW-ERP model in deze context weer. Dit model vormt een brug tussen de wetgeving en de functionaliteiten van het ERP-systeem en wordt gebruikt bij de inrichting van het systeem bij bedrijven. Een belangrijk aspect hierbij is dat veranderingen in wetgeving eenvoudig kunnen worden vertaald naar veranderingen aan de inrichting van het ERP-systeem. F.1.3 Micro-schaal Samenwerking KPMG IRM en KPMG Meijburg De samenwerking tussen IRM en Meijburg bundelt de fiscale kennis van Meijburg met de ERPkennis van IRM. Deze bundeling van kennis is noodzakelijk voor de ontwikkeling van een BTW- ERP service. Hierbij moet worden gekeken voor wie deze service aantrekkelijk is in de zin van het bieden van toegevoegde waarde aan de doelstellingen van het bedrijf. Op basis hiervan kunnen samenwerkingsverbanden worden aangegaan met bijvoorbeeld ERP-vendors, de Belastingdienst of de Overheid. Voor deze instanties zijn samenwerkingsverbanden interessant wanneer de investeringskosten op lange termijn worden terugverdiend. Om hier een beeld van te krijgen is het zinvol om te bekijken of samenwerking een Return On Investment (ROI) oplevert. 118

140

141 Deel VI Repository invulling 120

142

143 Bijlage G Marktrepository: Market Value and Risk Model (1-V) G.1 Mission Statement G.1.1 Missie Omzetbelastingwetgeving Het gemeenschappelijk stelsel van belasting over de toegevoegde waarde berust op het beginsel dat van goederen en diensten een algemene verbruiksbelasting wordt geheven welke strikt evenredig is aan de prijs van goederen en diensten, zulks ongeacht het aantal transacties welke tijdens het productie - en distributieproces voor de fase van heffing plaatsvonden [EEG, 1967]. G.1.2 Missie De Belastingdienst De Belastingdienst voert wet- en regelgeving die hem is opgedragen zo doeltreffend en doelmatig mogelijk uit. In zijn handelen streeft hij naar handhaving van rechtszekerheid en rechtsgelijkheid. Dienstverlening aan en respect voor het publiek zijn aan dat handelen onlosmakelijk verbonden [Belastingdienst, 2005a]. G.2 Market Indicator Register G.2.1 BTW-wetgeving Balanced Scorecard Bij BTW-wetgeving is gekeken naar welke doelstellingen ten grondslag liggen aan het ontstaan van wetgeving. Hierbij is gekeken naar BTW-wetgeving in de algemene zin van het woord en niet zozeer naar de mensen die verantwoordelijk zijn voor het ontstaan van de regels. 122

144 G.2. MARKET INDICATOR REGISTER 123 Tabel G.1: Balanced Scorecard Omzetbelastingwetgeving Financieel Afnemers Leerresultaten en Groei Interne Bedrijfsvoering Eenduidig zijn voor afnemers Continue evaluatie van veranderingen in de maatschappij Compleet zijn Lage complexiteit nastreven Het waarborgen van gemeenschapsbelangen Up-to-date blijven Continue kennisverwerving De gegevens zijn verkregen uit [EEG, 2001], [WetOB, 1968], [Vervloed and Bod, 1999] en ( Relevante indicatoren G.2.2 Financieel Gezond ondernemersklimaat Totale inkomsten uit omzetbelastingen Afnemers Eenduidige naleving Makkelijk toepasbaar # Vragen bij de overheid Belastingdienst Strategische doelstellingen Algemeen: Het onderhouden en versterken van de bereidheid van belastingplichtigen tot nakoming van de wettelijke verplichtingen [Belastingdienst, 2005a]. Primaire processen: Dienstverlening Dienstverlening snel en op maat. Intensief toezicht en opsporing Een effectief en doelmatig toezicht en een effectieve strafrechtelijke fraudebestrijding. Massale processen Een effectieve en efficiënte inrichting van de massale processen. Ondersteunende processen: Rechtstoepassing 123

145 124 G.2. MARKET INDICATOR REGISTER Eenheid van beleid en uitvoering. Personeel Medewerkers zijn gemotiveerd en betrokken werkzaam op de juiste plaats en het juiste moment, met de beschikking over de benodigde competenties en onder passende arbeidsvoorwaarden. Bedrijfsvoering Doeltreffend en doelmatig werken. Facilitaire processen Facilitaire processen dragen op een efficiënte effectieve en flexibele wijze bij aan de verwezenlijking van de doelen van de Belastingdienst. Balanced Scorecard De Belastingdienst heeft een maatschappelijke doelstelling en is niet commercieel ingesteld. Daarom is het relevanter het perspectief financieel te vervangen door finaliteit. Hierbij speelt de maatschappelijke kant een grote rol. Er kan niet gemeten worden in financieel succes voor beleggers, maar wel in de doelgerichtheid waarmee het maatschappelijk belang gediend wordt. Tabel G.2: Balanced Scorecard De Belastingdienst Finaliteit Afnemers Leerresultaten en Groei Interne Bedrijfsvoering Doelmatig inzetten van middelen Verbeteren klanttevredenheid Klanten gemakkelijk maken om aan fiscale verplichtingen te voldoen Werken in de actualiteit Verhogen van de kwaliteit van dienstverlening Versterken van competentie van personeel Optimaliseren van IT Doeltreffend en doelmatig werken Bevorderen van de samenwerking met derden Verbetering efficiency massale processen De gegevens zijn verkregen uit [Belastingdienst, 2005b], [Belastingdienst, 2005a] en gesprekken met de Belastingdienst. Relevante indicatoren Financieel Return On Investment (ROI) Kosten afname ten opzichte van profits Interne Processen Efficiency massale processen Operationele processen verbeteren (tijd, kwaliteit, kosten) Complexiteitsreductie ICT Bevordering samenwerking met derden (horizontaal toezicht) 124

146 G.3. MARKET VALUE & RISK REGISTER 125 G.3 Market Value & Risk Register G.3.1 Waardemodel Figuur G.1: Market Value Exchange Model Afkortingen BSBK Bedrijfsspecifieke BTW-kennis BSCS Bedrijfsspecifieke controle stappen BSCK Bedrijfsspecifieke controle kennis BSER Bedrijfsspecifieke ERP-releases updates etc. BTWERPS BTW-ERP services CIM Computation Independent Model 125

147 126 G.3. MARKET VALUE & RISK REGISTER G.3.2 Waardeuitwisselingen en risico s Tabel G.3 beschrijft waardeuitwisselingen en risico s die kunnen optreden in de huidige situatie. Tabel G.3: Market Value Exchanges & Risks Marktactoren Waardeuitwisseling Risico( s) Leverancier - Klant Goederen/Service Geld Verkeerde BTW op factuur Boetes door verkeerde BTW Dubbele belastingen BTW-wetgeving - Bedrijven BTW regels Naleving (Nieuwe) BTW-regel beïnvloedt BTW-strategie en ERP-systeem is niet meer BTW-compliant BTW-wetgeving - ERP vendor BTW regels Naleving (Nieuwe) BTW-regel niet implementeerbaar in ERP-referentiemodel BTW-wetgeving - Belastingdienst BTW regels Controle op naleving Onvoldoende resources om ingewikkelde regels te toetsen bij bedrijven ERP-vendors - Bedrijven ERP-systeem Geld BTW-strategie niet correct geconfigureerd in ERP-systeem Belastingdienst - Bedrijven Contole Geld Door strenge BTW-vereisten kans op belastingontduiking door bedrijven G.3.3 Waardeanalyse De waardeketens met betrekking tot de kernoorzaken voor de verschillende stakeholders zijn als volgt: Kernoorzaak P1: Gebrek aan uitvoerbaar model IT kennis BTW kennis = BTWERPK = BSCK Geld IT kennis BTW kennis = BTWERPK = BSBK Geld IT kennis BTW kennis = BTWERPK = BTWERPS Geld Het CIM vormt het uitvoerbaar model waaraan in de huidige situatie (AS-IS) een gebrek is. Het CIM wordt ontwikkeld door KPMG die kennis op het gebied van belastingwetgeving (KPMG Meijburg) en ERP (KPMG IRM) bundelt en daarmee kan inspelen op de behoefte van bedrijven aan services op BTW-ERP gebied (BTWERPS). KPMG is een kennisintensieve organisatie waardoor ze zich kan specialiseren op actuele thema s die spelen bij bedrijven. Bedrijven zijn hier niet op ingericht en hebben daar niet de capaciteit voor. Er is waardetoevoeging voor KPMG indien de ontwikkelkosten voor het CIM op termijn worden terugverdiend. Klanten van KPMG hebben op dit moment problemen op dit gebied. Er is een aantal pilots gelopen waarbij deze problemen direct aan het licht zijn gekomen. De ontwikkelkosten daarentegen zijn relatief laag (interne opleiding) waarmee deze kosten relatief snel worden terugverdiend. Kernoorzaak P2: Complexiteit ERP-systemen De complexiteit van de ERP-systemen blijft bestaan. Het BTW-ERP model vormt slechts een brug die het gemakkelijker maakt BTW-regels binnen ERP-systemen toe te passen. 126

148 G.3. MARKET VALUE & RISK REGISTER 127 Kernoorzaak P3: Onderschatting van BTW-impact Het BTW-ERP model helpt bedrijven de impact van BTW op de bedrijfsvoering in te laten zien. Door al vroeg tijdens ERP-implementatietrajecten gebruik te maken van het BTW-ERP model, worden risico s in een vroeg stadium gereduceerd. 127

149 Bijlage H Marktrepository: Market Worksystem Operations Model (2-V) H.1 Principal Model Figuur H.1: Principal Model - Civil and Public Agents 128

150 H.2. MARKET ASSET- & RESOURCE MODEL 129 H.2 Market Asset- & Resource Model Figuur H.2: Market Asset- & Resource Model 129

151 130 H.3. INTERACTION REFINEMENT MODEL H.3 Interaction Refinement Model Figuur H.3: Interaction Refinement Model 130

152

153 Bijlage I Bedrijfsrepository: Business Value and Risk Model (1-V) I.1 Business Mission Statement I.1.1 KPMG Missie Uitstekende professionals die waarde afleveren door samen te werken. Het leveren van Audit, Tax en Advisory services. Drie complementaire kennisgebieden en -inzichten die ons in staat stellen te voldoen aan de wensen van onze klanten. We vertalen kennis in waarde naar het voordeel voor onze klanten, mensen en kapitaalmarkten [KPMG, 2005]. Visie Toonaangevend willen zijn in de markten waarin we opereren. Het is ons streven de beste reputatie te hebben in onze branche. Wij willen erkend worden als marktleider op het gebied van onze professionele dienstverlening door onze kennis van de ontwikkelingen en issues in de markten, branches en sectoren waarin onze klanten actief zijn [KPMG, 2005]. I.1.2 KPMG Information Risk Management Missie Het minimaliseren, beheersen en managen van risico s op het gebied van informatie en alles wat daarmee te maken heeft, zodat de inzet van ICT maximaal bijdraagt aan de bedrijfsvoering en het eindresultaat van onze klanten [KPMG, 2004]. I.1.3 KPMG Meijburg & Co. Missie Het op een proactieve manier adviseren van klanten op fiscaal gebied, met het oog op risicobeheersing en belastingbesparing. 132

154 I.2. BUSINESS INDICATOR REGISTER 133 I.1.4 Bedrijven (ERP-gebruikers) Missie Het inrichten van ERP-systemen zodat deze compliant zijn met de belastingstrategie, waardoor boetes en dubbele belastingen voorkomen worden. I.1.5 ERP-Vendors Missie Het ontwikkelen van software ter ondersteuning en optimalisering van bedrijfsprocessen [Callaway, 2000]. I.2 Business Indicator Register I.2.1 KPMG Balanced Scorecard Vertrouwelijk I.2.2 KPMG Information Risk Management Balanced Scorecard Vertrouwelijk I.2.3 KPMG Meijburg & Co. Balanced Scorecard Vertrouwelijk I.2.4 Bedrijven (ERP-gebruikers) Balanced Scorecard Tabel I.1: Balanced Scorecard Bedrijven (ERP-gebruikers) Financieel Afnemers Leerresultaten en Groei Interne Bedrijfsvoering Return On Investment (ROI) Kostenreductie Verhogen omzet Hoge klanttevredenheid afnemers Hoge kwaliteit producten Hoge productiviteit werknemers Verhogen van efficiency bedrijfsprocessen 133

155 134 I.2. BUSINESS INDICATOR REGISTER Relevante indicatoren Financieel Kostenreductie Risicoreductie Return On Investment (ROI) Afnemers Klanttevredenheid Prijs product Relatie met klant Leren en Groeien Productiviteit medewerkers Interne Processen Efficiency bedrijfsprocessen Sneller voldoen aan nieuwe wet- en regelgeving I.2.5 ERP-vendors Balanced Scorecard Het beschrijven van doelstellingen en belangen van ERP-vendors in het algemeen is lastig, omdat geen enkele vendor hetzelfde is en daarom ook andere doelstellingen hebben. Waar moet naar worden gekeken om te weten of een ERP-systeem succesvol geïmplementeerd is? De vier perspectieven van de Balanced Scorecard bieden ook hier een handig raamwerk voor het in kaart brengen van de doelstellingen en prestatie-indicatoren. Chand (2005) heeft een raamwerk beschreven dat gebruikt kan worden bij het in kaart brengen van de strategische impact van ERP-systemen gebaseerd op de Balanced Scorecard [Chand et al., 2005]. De vier kernvragen bij de verschillende perspectieven zijn [Rosemann and Wiese, 1999]: 1. Financieel; Wat zijn de kosten van een ERP-implementatie? 2. Afnemers; Ondersteunt de ERP-software de individuele behoeften op een efficiënte manier? 3. Interne bedrijfsvoering; Verbetert ERP-software de interne processen? 4. Leerresultaten en groei; Is ERP-software flexibel genoeg om toekomstige veranderingen te integreren? Het succes van ERP-implementaties is afhankelijk van de intentie van de organisatie om het ERP-systeem te gebruiken om de organisatie te automatiseren, informeren of transformeren [Chand et al., 2005]. Het eerste doel van een ERP-implementatie behelst de automatisering van bedrijfsprocessen. Dit leidt al snel tot het inzicht dat organisaties in staat 134

156 I.2. BUSINESS INDICATOR REGISTER 135 zijn om andere partijen beter te bedienen en zo het beslissingsproces kunnen verbeteren. Met andere woorden, er ontstaan efficiëntere informatiestromen waardoor organisaties beter in staat zijn te informeren over de gehele waardeketen. Daarnaast is het van belang dat organisaties zich flexibel opstellen en zich aanpassen (transformeren) aan eisen van klanten en andere belangenpartijen om zo een rol te kunnen blijven spelen in concurrerende markten. Chand (2005) koppelt deze drie doelstellingen van ERP-implementaties aan drie lagen van voordelen die ERP-implementaties met zich meebrengen: operationele, tactische en strategische voordelen. In de BSC voor ERP-vendors zijn de voordelen per categorie beschreven voor elk van de vier perspectieven van de BSC. Tabel I.2: Balanced Scorecard ERP-Vendors Level Financieel Afnemers Leerresultaten en Groei Strategisch Verbeteren marktwaarde Voldoen aan nieuwe klanteisen of aan eisen van nieuwe klanten Productiviteit verhogen Bedrijfs- Interne voering Operationeel Kostenreductie Op een efficiëntere manier aan huidige klanteisen voldoen Tactisch Verhogen van omzet Op een proactieve wijze identificeren van en voldoen aan klanteisen Zorg ervoor dat werknemers effectiever beslissingen nemen Absorberen van verandering op basis van routine Het verbeteren van het proces op een efficiënte manier Verbeteren van tactische besluitvorming Neem veranderingen van omgeving routinematig aan Relevante indicatoren Financieel Verhogen omzet (door betere services) Afnemers Tevredenheid klanten Marktaandeel Leren en Groeien Functionaliteit in software Innovatief Interne Processen Competenties van medewerkers De gegevens zijn verkregen uit [Chand et al., 2005], [Rashid et al., 2002], [Rosemann and Wiese, 1999] en diverse gesprekken met SAP-consultants van KPMG. 135

157 Bijlage J Bedrijfsrepository: Business Worksystem Operations Model (2-V) J.1 Community Model 136

158 J.1. COMMUNITY MODEL 137 Figuur J.1: Community Model 137