Contractsjablonen: de volledige gids

De verkoper pakt het contract van vorige maand, de jurist ziet het pas als het al is verstuurd, en bij een geschil blijkt dat er een oude bepaling in staat die twee jaar geleden is vervangen.

Software voor contractsjablonen is een bouwstenenbibliotheek met regels, gegevens en een route.

Het onderscheid met de buur zit in het moment. Contractbeheer begint als het contract is getekend: looptijd, opzegtermijn, verlenging, indexering, bewaking van data. Contractsjablonen gaan over de fase daarvoor: welke tekst, welke bepalingen, wie keurt goed, en wie tekent. Ze horen op elkaar aan te sluiten, want het getekende contract is de uitkomst van het ene en het begin van het andere.

De gebruikers zijn de verkoper of inkoper, de jurist en de tekenbevoegde. De verkoper stelt het contract samen en wil het vandaag versturen. De jurist beheert de bouwstenen en ziet alleen wat afwijkt. De tekenbevoegde ondertekent wat is goedgekeurd. Bij grotere organisaties komt inkoop of een contractmanager erbij.

De toepassingen lopen van een softwarebedrijf met abonnementen en verwerkersovereenkomsten tot een uitzender met opdrachtovereenkomsten, van een installateur met onderhoudscontracten tot een gemeente met inkoopcontracten en een verhuurder met huurovereenkomsten. Wat ze delen: een contract dat in de kern hetzelfde is en per geval iets verschilt.

Vraag een jurist wat er in een contract hoort, en het antwoord is: dat hangt ervan af. Waarvan het afhangt, is precies wat in de regels moet.

Vast

bepalingen die altijd in dit contracttype staan en die niemand mag aanpassen zonder de jurist

Keuze

bouwstenen die afhangen van het geval: wel of geen verwerking van persoonsgegevens, wel of geen onderaanneming, een looptijd met of zonder verlenging

Velden

namen, adressen, bedragen, data en nummers uit CRM, ERP of het Handelsregister; niet overtypen

Regels

welke keuze welke bouwsteen meebrengt, en welke combinatie niet mag; hetzelfde idee als bij een productconfigurator

De bibliotheek is het product. Elke bouwsteen heeft een eigenaar, een versie en een datum, en het systeem weet welk contract met welke versie is opgesteld. Als een bepaling wordt vervangen, blijft zichtbaar welke contracten nog de oude versie hebben. Dat is de vraag die bij een geschil of een wetswijziging als eerste wordt gesteld.

De velden zijn de stille winst. Een contract dat naam, KvK-nummer, adres, bedrag en ingangsdatum uit het systeem haalt, bevat die fouten niet meer. In organisaties die veel contracten maken, zijn juist die fouten de reden dat een contract terugkomt: een verkeerd adres, een oude bedrijfsnaam, een datum die niet klopt met de offerte.

De jurist wil niet elk contract zien; hij wil de afwijkingen zien. Een systeem dat dat onderscheid maakt, verkort de doorlooptijd en verlaagt het risico tegelijk.

De drempels bepalen hoeveel werk de jurist krijgt. Een bedrag boven een grens, een looptijd langer dan gebruikelijk, een aansprakelijkheidsbepaling die wordt aangepast, een buitenlandse partij: elk daarvan kan een route triggeren. Die drempels horen bij de start ruim te staan en na een kwartaal te worden bijgesteld op wat er werkelijk langskwam.

Wat een verkoper zelf mag, is een organisatievraag die de software zichtbaar maakt. In de praktijk blijkt vaak dat iedereen alles mocht omdat niemand het had vastgelegd. Het gesprek daarover is ongemakkelijk en het is de belangrijkste opbrengst van het project, nog voordat er software staat.

Een verkoper die een contract wil versturen voordat de klant van gedachten verandert, en een inkoper die een aanbestedingsdossier moet volgen, hebben tegengestelde belangen. Hetzelfde systeem, andere route.

Bij verkoop is snelheid de reden dat het systeem er komt, en de valkuil is dat de klant zijn eigen voorwaarden meebrengt. Het systeem hoort dat te kunnen: het contract van de klant als basis, met een controlelijst van de bepalingen die uw kant nodig heeft. Dat is een andere stroom dan opstellen uit sjabloon en hoort in het ontwerp.

Bij personeelscontracten is de wet de grootste bron van wijzigingen. Als een bepaling verandert, moeten alle sjablonen die hem gebruiken mee, en moet zichtbaar zijn welke lopende contracten de oude versie hebben. Die vraag komt altijd, en een bibliotheek met versies is het enige antwoord.

Een contract is het sluitstuk van een proces dat al in systemen staat: de offerte, de klant, de prijsafspraak. Alles wat opnieuw wordt ingetypt, is een kans op een fout.

CRM

klant, contactpersoon, offerte en afgesproken prijs; de bron van wat er in het contract komt te staan

Register

bedrijfsgegevens en tekenbevoegdheid uit het Handelsregister, zodat de juiste rechtspersoon en de juiste tekenaar erin staan

Tekenen

een ondertekendienst voor elektronische handtekeningen, met het bewijs van ondertekening bij het contract

Beheer

het getekende contract met looptijd en opzegtermijn naar het contractbeheer, en het bestand naar het dossier

De controle op tekenbevoegdheid wordt vaak overgeslagen en is bij grotere bedragen wezenlijk: tekent de persoon die het contract ondertekent namens de rechtspersoon die erin staat. Een koppeling met het Handelsregister maakt dat een controle van een seconde in plaats van een aanname.

De overdracht naar contractbeheer is de stap die het meest oplevert en het minst wordt gebouwd. Een getekend contract waarvan looptijd, opzegtermijn en indexering automatisch in het beheer staan, is een contract dat niet stilzwijgend verlengt zonder dat iemand het wilde. Zonder die stap blijft het beheer handwerk, en dan is het contract na ondertekening weer een bestand in een map.

Een sjabloon met invulvelden is een middag. Een bibliotheek met versies, regels per contracttype, routes per afwijking en koppelingen met CRM en ondertekening is meer inrichting dan bouw.

Typen

één contracttype is één set bouwstenen; verkoop, inkoop en personeel naast elkaar zijn drie bibliotheken met eigen eigenaren

Omvang

twintig bouwstenen zijn te overzien; tweehonderd met versies en regels vragen een beheeromgeving

Routes

één goedkeurder is eenvoudig; drempels op bedrag, looptijd en soort afwijking vragen een schema en onderhoud

Koppeling

CRM en ondertekendienst zijn standaardwerk; een vakpakket zonder koppelvlak is eerst een gesprek

Wat meestal meevalt: het document, de velden en de ondertekening. Wat tegenvalt: de bouwstenen. Ze bestaan nu als alinea's in tientallen documenten, en iemand moet ze ontdubbelen, op elkaar afstemmen en vaststellen. Dat is juridisch werk en het is de tijd van de jurist, niet van de bouwer.

Vraag ook wat u al heeft. Documentgeneratie zit in veel CRM-pakketten en in de meeste kantoorsoftware, en voor één contracttype met een handvol velden is dat genoeg. Waar het stopt, is bij regels tussen bouwstenen, bij versiebeheer van bepalingen en bij routes per afwijking. Daar begint het maatwerk.

De volgorde hieronder begint bij de documenten die er al zijn, want daar staat uw praktijk in. Het eindigt bij de overdracht aan het contractbeheer, waar het contract zijn tweede leven begint.

1. Eén type kiezenHet contract dat het vaakst wordt gemaakt. Twintig recente exemplaren naast elkaar leggen.
2. Ontdubbelen tot bouwstenenWat is overal gelijk, wat verschilt, en waarom. De jurist stelt de vaste tekst vast.
3. Velden uit het systeemNamen, bedragen en data uit CRM of ERP, plus het Handelsregister voor rechtspersoon en tekenbevoegdheid.
4. Route voor afwijkingenWie mag wat zonder jurist, en welke drempels sturen het contract langs goedkeuring. Ruim beginnen, later bijstellen.
5. OndertekeningElektronisch tekenen met bewijs, of een uitdraai voor wie dat wil. Het getekende exemplaar is de bron.
6. Overdracht aan beheerLooptijd, opzegtermijn en indexering naar het contractbeheer; het bestand naar het dossier.