2.1 Rekenmethodiek

Bij het aanmaken van een nieuw project hoeft de gebruiker slechts een gering aantal parameters inzake

  • Bouwprogramma
  • Verkoopwaarde
  • Planning

in te voeren. 

Vervolgens wordt er een globale berekening (First Estimate) van de Investeringskosten, Opbrengsten en Cashflow van het beoogde Project gemaakt door tevens éénmalig gebruik te maken van bedrijfseigen defaults (deze zijn in het Reaforce applicatiebeheer vastgelegd). 

Worden na de initiële aanmaak van een Project vervolgens 1 of meerdere parameters gewijzigd, dan kijkt Reaforce niet meer naar de bedrijfseigen defaults maar is er altijd sprake van een projectspecifieke (parameter)wijziging.

Gedurende het ontwikkelingsproces zullen steeds meer bedrijfseigen defaults projectspecifiek worden ingevuld. 

 

2.2 Indexeringen

Indexeren in Reaforce vindt plaats voor 3 hoofdposten waarvan de bedragen ook op peildatum worden gegeven:

  • Aankoop grond en/of opstallen
  • Bouwkosten
  • Verkoopwaarde

 

Bijkomende kosten worden indirect geïndexeerd wanneer zij middels parameters als % van de grondwaarde, bouwkosten dan wel verkoopwaarde worden opgevoerd. Worden bijkomende kosten als bedrag ingevoerd, dan is dit een schatting van het contractbedrag waarin indexeringen in tijd worden geacht te zijn inbegrepen. 

 

Worden de opbrengsten en kosten van diverse Functies geconsolideerd op projectniveau, dan wordt alleen gekeken naar de geïndexeerde bedragen. Functies kunnen immers verschillende peildatums en indexeringen hebben. 

 

De indexatieperiode op Functie-niveau is als volgt:

 

2.2.1 Indexatieperiode voor: Aankoop grond en/of opstallen:

De indexatieperiode op Functie-niveau is als volgt:

Vanaf de peildatum wordt het gehele bedrag geïndexeerd tot ‘datum aankoop grond en/of opstallen’.

2.2.2. Indexatieperiode voor: Bouwkosten

De indexatieperiode op Functie-niveau is als volgt:

Vanaf de peildatum wordt het gehele bedrag geíndexeerd tot ‘datum start bouw’ met index% 1.

Vanaf Datum Start Bouw worden de Bouwkosten geïndexeerd conform de S-curve (afkoopbedrag) tot Datum Eind Bouw met index% 2. 

 

2.2.3 Indexatieperiode voor: Verkoopwaarde

De indexatieperiode op Type-niveau is als volgt:

Vanaf de peildatum kan het gehele bedrag worden geíndexeerd tot:

  • Datum start bouw
  • Datum eind bouw
  • Datum start verkoop

 

Let op!

Aangezien de invoer van ‘absolute bedragen Einde Werk’ voor:

  • Aankoop grond en/of opstallen
  • Bouwkosten
  • Verkoopwaarde

slechts ‘hulpinvoer’ is en er op Peildatum wordt opgeslagen, veranderen de bedragen Einde Werk dus wanneer er na het invoeren van deze bedragen alsnog wijzigingen plaats vinden in:

  • De planning;
  • De Peildatums;
  • De indexeringspercentages;

Indien er contracten zijn afgesloten voor bovengenoemde posten, is het beter om de daarbij behorende indexeringspercentages op 0% te zetten; men wil dan immers niet meer dat door het wijzigen van b.v. de planning de bedragen Einde Werk (contractbedragen) mee wijzigen. 

 

2.3 De dynamische rekenmethode

Reaforce rekent standaard dynamisch. Dat wil zeggen dat kosten en opbrengsten conform de ingegeven planning en termijn-en betalingsschema’s worden uitgezet in de tijd en dat op basis van het verschil tussen inkomende en uitgaande geldstroom de vermogensbehoefte en bijbehorende financieringsrente worden berekend. 

 

De berekende kosten en opbrengsten zijn met de planning- en termijnschemagegevens de basis voor de cashflowberekeningen. 

Uit de uit de cashflowberekeningen voortkomende tijdsafhankelijke financieringssaldi kunnen de renten worden berekend. Rente valt als kosten in de periode nadat deze is veroorzaakt. De rentekosten in de investeringskostenopzet op Functieniveau is de gesommeerde rentecashflow. De periode waarover rente wordt berekend wordt voor alle Functies behorend tot 1 consolidatiegroep gelijkgesteld. 

 



2.4 Projectstructuur

Kern van Reaforce zijn projecten. Een project is een als eenheid beschouwde ontwikkelingsopgave in de vastgoedwereld. Op projectniveau wordt de koppeling gelegd tussen Reaforce en financieel administratieve systemen (middels Projectcontrol).  

 

Per project kunnen eventueel meerdere ProjectVarianten worden aangemaakt (b.v. een worst case-, best case- en base case scenario). 

 

Een ProjectVariant bestaat uit 1 of meerdere Functies. Onderscheid wordt gemaakt in verschillende Functies zoals kantoren, winkels, bedrijfsruimten, parkeergarages, woningen, leisure en utilitaire Functies. 

 

Planning, termijn- en betalingsschema’s, indexeringspercentages, peildatums en de residuele rekenmethodiek worden ingevoerd op Functieniveau en zijn daarmee bindend voor alle Typen behorende tot die Functie.

 

Dit betekent dat wanneer er sprake is binnen een project van:

  • een gefaseerde planning en/of;
  • verschillende indexeringspercentages en/of peildatums;
  • verschillende termijn- en betalingsschema’s;
  • verschillende residuele rekenmethodieken

dit de Reaforce-gebruiker dwingt tot het aanmaken van meerdere Functies van dezelfde soort, omdat deze zaken de cashflow en haalbaarheid van een project wezenlijk beïnvloeden. 


Voorbeeld van een mogelijke projectstructuur

 

Bij het aanmaken van een nieuw project is de projectstructuur als volgt:

Project – Variant – Functie(s) – Type(n)* 

 

Voor grote projecten (Bijvoorbeeld UCP, Zuidas Amsterdam) is het noodzakelijk om de mogelijkheid te hebben om een of meerdere tussenconsolidatieniveau’s te hanteren. 

Tussenconsolidaties kunnen eventueel na het aanmaken van een nieuw project aan de projectstructuur worden toegevoegd. 

Dit levert de volgende structuur:

Project – Variant – DeelProject(en) (optioneel) – BouwEenheid(en) (optioneel) – Functie(s) – Type(n)* 

 

* Typen zijn alleen van toepassing als het een Functie Woningen of Parkeren betreft. 

Voorbeeld van een projectstructuur incl. deelprojecten en bouweenheden

Eventueel kan er ook toe besloten worden om 1 project in meerdere projecten te gaan opsplitsen. Uitgangspunt hierbij is dat er alleen een opsplitsing kan plaatsvinden indien er BouwEenheden en/of DeelProjecten aanwezig zijn.

 

2.5 Methoden van Koopsombepaling

Voor het bepalen van de Koopsom per type wordt gebruik gemaakt van een Methode van Koopsombepaling. 

Onderstaande tabel geeft een overzicht van de Methoden van Koopsombepaling.

In Reaforce Applicatiebeheer kan worden ingesteld welke Methoden van Koopsombepaling voor de Reaforce gebruiker wel/niet beschikbaar moeten zijn.

 


De koopsom per type wordt verder opgesplitst in grond- en opstaltermijnen. 

Op typeniveau kan een keuze worden gemaakt uit het invoeren van de grondtermijn of de opstaltermijn (als percentage of als bedrag).  

(default instelling = Opstaltermijn als percentage)

 

Bij het muteren van de grondtermijn als vast bedrag kan eventueel gebruik worden gemaakt van ‘hulpinvoer’. 

Dit betekent dat dan éénmalig het huidige bedrag aan:

  • Aankoop grond en/of opstallen of
  • Inbrengwaarde of 
  • Grondkosten

op typeniveau wordt overgenomen als grondtermijn. 

Wordt er vervolgens weer een wijziging doorgevoerd op het bedrag van de geselecteerde hulpinvoer, dan wordt deze wijziging niet meer verwerkt in de grondtermijn. 

 

 

Voorbeeld van de invoer van de grondtermijn als bedrag

 

Afhankelijk van overige (fiscale) instellingen worden de op basis van de koopsom bepaalde grond- en opstaltermijnen omgerekend naar netto grond- en opstaltermijnen die samen uiteindelijk de verkoopwaarde bepalen.


Hierna worden de verschillende Methoden van Waardebepaling verder toegelicht. 

 

2.5.1 Methode 1: Huur/BAR

Koopsom = Huuropbrengst in het 1e jaar bij volledige huur/BAR%

 

Indien gewenst, kan i.p.v. het BAR de kapitalisatiefactor worden ingevuld. Hiervoor geldt: 

Kapitalisatiefactor = 1/BAR. 

 

2.5.2 Methode 2: Huur (Opbrengstwaarde en Onrendabele top) 

Koopsom = Opbrengstwaarde (OW) + Onrendabele Top (ORT)

 

2.5.3 Methode 3: Koopsom

Koopsom = Koopsom

 

2.6 Methoden van Realisatie

Bij het aanmaken van een functie resp. type kan de Gebruiker kiezen uit 3 Methoden van Realisatie, namelijk: 

  • Nieuwbouw
  • Renovatie
  • Sloop/Nieuwbouw

Deze indeling kan o.a. in de R&A rapportages gebruikt worden als filtering. 

 

2.7 Soort verkoop

Bij het aanmaken van een functie resp. type kan de Gebruiker kiezen uit 2 soorten verkoop, namelijk: 

  • V.O.N.
  • K.K.

De gemaakte keuze bepaalt, afhankelijk van het fiscale verkoopscenario, of de Koopsom gelijk is aan de Verkoopwaarde.

 

Zie voor een nadere toelichting op de fiscale scenario’s Hoofdstuk 9 in deze handleiding.

 

2.8 Methoden van financieringsrenteberekening

In Reaforce wordt gedurende de totale looptijd van het project financieringsrente toegerekend. 

 

2.8.1 Op basis van 1 of 2 rentevoeten

De financieringsrente wordt in Reaforce op Functieniveau berekend. Hiervoor zijn 2 methoden beschikbaar:

  1. op basis van 1 rentevoet over de cumulatieve bruto cashflow gedurende de totale looptijd van de functie;
  2. op basis van 2 verschillende rentevoeten gedurende de looptijd van de functie;

 

Indien de gebruiker kiest voor methode 2, dan dient de gebruiker op functieniveau of eerste consolidatieniveau de rentevoet gedurende periode 1 en periode 2 op te geven, evenals het moment waarop er dient te worden overgestapt naar rentevoet 2. Als restrictie geldt: 0% ≤ rentevoet ≤50%.

 

Dit moment kan een aan de planning binnen Reaforce gekoppelde datum zijn, maar ook een ongekoppelde datum.

 

Voor het moment waarop er wordt overgestapt van rentevoet 1 naar rentevoet 2 kan een keuze worden gemaakt uit:

  • Ongekoppelde datum (zonder restricties);
  • Datum Start Verkoop[1];
  • Datum Grondaankoop;
  • Datum Start Bouw;

Indien de gebruiker binnen een project kiest voor een andere methode, dan worden de tot dan toe gebruikte waarden bewaard voor het geval er later weer naar de oorspronkelijke methode dient te worden teruggekeerd (dan dienen deze te worden voorgesteld). Het is dan aan de gebruiker om deze dan eventueel aan te passen.

 

2.8.2 Op basis van Financieringsmodule Eigen Vermogen/Vreemd Vermogen

Met behulp van de Financieringsmodule EV/VV is het mogelijk om op Projectvariantniveau een financieringsscenario met Eigen en Vreemd Vermogen vast te leggen en zodoende op een gedetailleerde manier te rekenen aan de (optimale) financiering van projecten en inzicht te geven in: 

  • de inzet van Eigen en Vreemd Vermogen per periode;
  • de financieringsrente Eigen en Vreemd Vermogen per periode;
  • het rendement op Eigen Vermogen (ROE) voor de gehele looptijd van het project;

De cumulatieve bruto cashflow van Reaforce vormt de basis voor deze berekening.

Zie voor een uitgebreidere toelichting hoofdstuk 10 in deze handleiding. 

 

2.9 Kostenstructuur Reaforce

De kostenstructuur bestaat uit diverse kostengroepen. Een groot aantal kostengroepen wordt als bedrijfseigen kostengroep beschouwd en deze kunnen verder worden ingericht met bedrijfseigen subkostengroepen en bedrijfseigen kostenregels, zodanig dat in de fijnste uitsplitsing aansluiting wordt gezocht bij het administratieve systeem. Dit is met name van belang indien er d.m.v. Reaforce Projectcontrol een uitwisseling van gegevens tussen Reaforce en het administratieve systeem plaats vindt. 

 

2.9.1 Bedrijfseigen kostengroepen

Per bedrijfseigen kostengroep geldt:

  1. Wel/niet gebruiken van de kostengroep is bedrijfseigen

 

Indien een bedrijfseigen kostengroep wordt gebruikt, dan geldt tevens:

  1. Naamgeving van de kostengroep (niveau 1) is bedrijfseigen
  2. Inrichting en naamgeving van deze kostengroep met subgroepen (niveau 2) is bedrijfseigen; maximaal kunnen 99 subgroepen worden ondergebracht in een bedrijfseigen kostengroep
  3. Inrichting en naamgeving van deze subgroepen met kostenregels (niveau 3) is bedrijfseigen; maximaal kunnen 99 kostenregels worden ondergebracht in een bedrijfseigen subkostengroep
  4. Invoer van kosten kan zowel op Type-, Functie- als eerste, tweede en derde consolidatieniveau plaatsvinden
  5. Invoer van kosten vindt per kostengroep plaats op het laagste niveau
  6. Per mutatie kan desgewenst een opmerking worden vastgelegd
  7. Invoer van kosten vindt plaats op basis van een berekeningsmethode die geselecteerd wordt uit een keuzelijst (zie voor meer details, hoofdstuk 8.3 in dit document)
  8. Per kostengroep en per defaultset wordt in Reaforce Applicatiebeheer een berekeningsmethode en defaultwaarde vastgelegd op het laagste niveau
  9. Betalingsschema ligt op kostengroepniveau

 

De structuur van een bedrijfseigen kostengroep ziet er dan als volgt uit:            

 

2.9.2 Bedrijfseigen kosten- en opbrengstengroep voor tussentijdse exploitatie

Voor het rekenen aan tussentijdse exploitatiekasstromen is er 1 bedrijfseigen kostengroep en 1 bedrijfseigen opbrengstengroep beschikbaar.

 

Kenmerken van deze kosten- en opbrengstengroep:

  1. Naamgeving van de groep (niveau 1) is bedrijfseigen
  2. Inrichting en naamgeving van deze groep met subgroepen (niveau 2) is bedrijfseigen; maximaal kunnen 99 subgroepen worden ondergebracht in een bedrijfseigen groep
  3. Inrichting en naamgeving van deze subgroepen met kostenregels (niveau 3) is bedrijfseigen; maximaal kunnen 99 kostenregels worden ondergebracht in een bedrijfseigen subgroep
  4. Het totaalbedrag van de kosten resp. opbrengsten wordt bepaald door middel van het plannen van de cashflow op typeniveau op kostenregelniveau.

De invoeropties zijn:

  • Éénmalig bedrag in maand …
  • Maandelijks bedrag van maand … tot maand …
  • Jaarlijks bedrag van maand … + aantal betalingen
  1. De (totaal)bedragen per type per kostenregel worden teruggerekend als een bedrag per eenheid per kostenregel, welke vervolgens worden getoond op het scherm Budgetoriëntatie.
  2. Bedragen kunnen worden geïndexeerd. Vanaf datum ‘start index’ worden bedragen dan met het ingegeven indexeringspercentage geïndexeerd.

Concreet betekent dit dat

  • als dtm start index ligt voor de betalingsdatum -> bedrag wordt geïndexeerd
  • als dtm start index ligt na de betalingsdatum -> bedrag wordt niet geïndexeerd
  1. Op het scherm Cashflow metrisch wordt de cashflow op groepsniveau getoond.

De mutaties die in een bepaalde maand vallen worden verwerkt op de 15e van deze maand.

  1. Plaats van de kostengroep in de kostenstructuur is direct boven de kostenregel ‘niet terug te vorderen BTW’
  2. Plaats van de opbrengstengroep in de kostenstructuur is direct boven de kostenregel ‘niet af te dragen BTW’.

 

2.10 Organisatiestructuur

Om per gebruiker onderscheid te kunnen maken in:

  • De toegang tot projecten
  • Bewerkingsrechten op projecten

wordt er gebruik gemaakt van een organisatiestructuur.  

 

Kenmerken van de organisatiestructuur:

  1. De organisatiestructuur wordt vastgelegd in Reaforce Applicatiebeheer
  2. De organisatiestructuur bevat minimaal 1 organisatie-eenheid genaamd: <naam klant>
  3. Gebruikers worden altijd gekoppeld aan een organisatie-eenheid op het laagste niveau
  4. Bewerkingsrechten worden per gebruiker per organisatie-eenheid vastgelegd.

 

Bij het aanmaken van een nieuw project zal de Reaforce-gebruiker in de Wizard Projectdefinitie het project moeten koppelen aan één van de organisatie-eenheden waar hij/zij toegang toe heeft.

Indien de gebruiker maar gekoppeld is aan 1 organisatie-eenheid verschijnt deze automatisch in het veld ‘Organisatie-eenheid’; in overige situaties maakt de gebruiker zelf een keuze uit de beschikbare organisatie-eenheden. 

Voorbeeld van een mogelijke inrichting van de organisatiestructuur

 

2.11 Residueel rekenen

Als alle Opbrengsten en Investeringskosten juist zijn gewijzigd kan er vervolgens zowel op Functieniveau als op PV-niveau Residueel worden gerekend. 

Onder Residueel Rekenen wordt verstaan: het toerekenen van de Verevening naar één van de, door de Gebruiker aan te wijzen, Residuele Waarden t.w.:

  • Residuele Aankoop Grond en/of Opstallen;
  • Residuele Ontwikkelingswinst;
  • Residuele Bouwkosten;
  • Residuele Verkoopwaarde (Koopsom, BAR en/of Onrendabele Top);
  • Residuele Verkoopwaarde (Koopsom, Huur en/of Onrendabele Top);

 

Elke Parameterwijziging leidt, behalve tot een aantal parameterafhankelijke wijzigingen, tot een wijziging in de residuele post.

Residueel rekenen is een iteratief proces waarbij de laatste bewerking bestaat uit het berekenen van de Financieringsrente van de Vermogensbehoefte in de tijd.

 

2.12 Bedrijfseigen Defaults

Bedrijfseigen Defaults zijn alle in Reaforce Applicatiebeheer instelbare Parameters (door een Reaforce gebruiker met adminrechten ‘Defaults’). 

In Reaforce Applicatiebeheer kunnen meerdere defaultsets worden vastgelegd, zodat bij het aanmaken van een project, functie of type een defaultset kan worden gekozen die in de First Estimate het meest reële beeld oplevert. 

 

Opmerking:

Zie ook: de Handleiding van Reaforce Applicatiebeheer