--- title: "Verhuursoftware op maat: zo voorkom je dubbele reserveringen | Coding Agency" description: "Hoe je beschikbaarheid, ombouwtijd en reserveringen modelleert in verhuursoftware — en op databaseniveau afdwingt dat hetzelfde artikel nooit twee keer uitgaat." url: https://coding.agency/kennisbank/verhuursoftware-beschikbaarheid-dubbelboekingen source: Coding Agency (https://coding.agency) language: nl --- Maatwerk 10 min leestijd # Verhuursoftware op maat: zo voorkom je dubbele reserveringen. Hoe je beschikbaarheid, ombouwtijd en reserveringen modelleert in verhuursoftware — en op databaseniveau afdwingt dat hetzelfde artikel nooit twee keer uitgaat. [ Jasper Koers ](https://coding.agency/over/jasper-koers) · 2 sep. 2026 ## In het kort - Verhuur draait om perioden, niet om voorraadaantallen — dat verschil bepaalt je hele datamodel - Ombouw-, transport- en keuringstijd hoort in de blokkade, niet in de huurperiode die de klant betaalt - Een beschikbaarheidscheck in de applicatie is niet genoeg: leg de garantie tegen overlap in de database - Onderscheid uniek genummerde artikelen van uitwisselbare artikelen; ze vragen een andere beschikbaarheidsberekening - De meeste verliezen ontstaan niet bij de reservering maar bij retour: schade, ontbrekende onderdelen en te late terugkomst ## Wat maakt verhuursoftware anders dan een webshop? Kort antwoord Verhuursoftware verkoopt geen aantallen maar perioden. Hetzelfde artikel komt terug en gaat opnieuw uit, met transport, schoonmaak en controle ertussen. Beschikbaarheid is daarmee een vraag over overlappende tijdvakken, en die vraag moet je databaseniveau beantwoorden — anders levert twee gelijktijdige boekingen vroeg of laat dezelfde aanhanger op twee adressen op. Verhuur- en evenementenbedrijven bellen me zelden met "we willen software". Ze bellen met een verhaal: er stond een set op twee klussen tegelijk, of een klant boekte online iets wat allang op transport stond. In vrijwel alle gevallen was er wél een systeem — een webshop, een gedeelde agenda, een planbord in een spreadsheet — maar was dat systeem gebouwd rond een aantal in plaats van rond een periode. Dat is het punt waar verhuur structureel anders werkt dan verkoop, en waar de meeste standaardoplossingen stukgaan. ## Beschikbaarheid is een periode, geen voorraadaantal In een webshop is beschikbaarheid een getal. Je hebt er twaalf, je verkoopt er drie, je hebt er negen. Bij verhuur zegt dat getal niets: twaalf partytenten kunnen volgende maand allemaal beschikbaar zijn en volgend weekend allemaal weg. De juiste vraag is niet "hoeveel heb ik er" maar "hoeveel zijn er vrij in exact dit tijdvak" — en dat antwoord verandert per uur. ### Uniek genummerd of uitwisselbaar? De eerste ontwerpkeuze die ik in elk verhuurproject maak: reserveert de klant een specifiek exemplaar, of alleen een type? Dat onderscheid loopt door je hele systeem heen. - **Uniek genummerde artikelen:** een aanhanger met kenteken, een steiger met keuringsnummer, een camera met serienummer. Elk exemplaar heeft een eigen historie, eigen onderhoud en een eigen agenda. Je reserveert het exemplaar, niet het type. - **Uitwisselbare artikelen:** honderd klapstoelen, twintig biertafels, vijftig bordjes. Niemand vraagt om stoel nummer 43. Je reserveert een aantal uit een pool en wijst pas bij het laden toe welke exemplaren meegaan. - **Sets en samenstellingen:** een springkussen mét blower, verlengsnoer en grondankers. Zo'n set is pas beschikbaar als álle onderdelen beschikbaar zijn — en als één onderdeel op reparatie staat, is de hele set weg. De praktijk is bijna altijd gemengd. Een bedrijf dat aanhangers verhuurt, verhuurt ook spanbanden per stuk. Bouw je alleen het uitwisselbare model, dan kun je geen onderhoudshistorie per exemplaar bijhouden. Bouw je alleen het genummerde model, dan zit je personeel honderd stoelen individueel aan te vinken. Het datamodel moet beide aankunnen, met per artikeltype een expliciete keuze. ### De overlaptoets Twee perioden overlappen als de een begint vóór de ander eindigt én eindigt ná de ander begint. Klinkt triviaal, maar er zit één detail in dat in de praktijk het vaakst misgaat: gebruik halfopen intervallen. Een reservering loopt van het startmoment tot en met net vóór het eindmoment. Doe je dat niet, dan botst een reservering die om 12:00 eindigt met een reservering die om 12:00 begint, terwijl dat in de echte wereld prima aansluit. > Bij verhuur is het antwoord op "hebben we er nog een?" altijd een wedervraag: wanneer precies? ## Ombouwtijd, transport en keuring horen in de blokkade De huurperiode die je klant afspreekt, is nooit de periode dat het artikel bezet is. Er zit transport voor en na, er moet schoongemaakt worden, er moet gecontroleerd, geladen, soms gekeurd of getest. Reken je daar niet mee, dan boekt je systeem netjes een set die fysiek nog op de vrachtwagen ligt. De oplossing is niet om de klant een langere periode in rekening te brengen, maar om twee perioden te onderscheiden: - **De huurperiode:** wat de klant afspreekt, ziet in de bevestiging en terugziet op de factuur. - **De blokkadeperiode:** de huurperiode plus je eigen buffer aan beide kanten. Dit is de periode waarop je beschikbaarheidscheck en je planning rekenen. Die buffer is zelden een vast getal. Bezorgen kost meer tijd dan afhalen. Een tent die nat terugkomt moet drogen; een set die alleen gecontroleerd hoeft te worden, kan dezelfde middag weer uit. Maak de buffer daarom instelbaar per artikeltype, en overrulebaar per reservering — je planner weet beter dan je systeem wanneer iets sneller kan. ### Dagdelen, dagen en weken door elkaar Een tweede reden om periodes serieus te modelleren: verhuurbedrijven rekenen zelden in één eenheid. Een zaal gaat per dagdeel, materieel per dag, een steiger per week, een evenementenset per weekend waarbij vrijdagmiddag brengen en maandagochtend halen als "één dag" telt. Als je tariefstructuur en je beschikbaarheid allebei op dezelfde periodenotatie zijn gebouwd, is dat gewoon een rekenregel. Zijn het twee losse systemen, dan blijf je uitzonderingen handmatig corrigeren. ## Dubbele reserveringen voorkom je in de database, niet in het scherm Vrijwel elk systeem dat ik overneem, controleert beschikbaarheid in de applicatie: eerst kijken of het vrij is, dan opslaan. Op een rustige dinsdag werkt dat prima. Het gaat mis op het moment dat het ertoe doet — de vrijdagmiddag waarop drie klanten tegelijk hetzelfde weekend willen. Tussen de controle en het opslaan zit altijd een moment, en in dat moment past een tweede reservering. De enige harde garantie leg je in de database. In PostgreSQL is dat een [range-kolom met een exclusion constraint](https://www.postgresql.org/docs/current/rangetypes.html): je slaat de periode op als `tstzrange` en laat de database weigeren dat twee rijen voor hetzelfde artikel elkaar overlappen. Voor de gelijkheidstoets op de artikelkolom heb je de extensie `btree_gist` nodig. ``` CREATE EXTENSION btree_gist; CREATE TABLE reserveringen ( id bigserial PRIMARY KEY, artikel_id bigint NOT NULL, periode tstzrange NOT NULL, -- halfopen: [start, eind) EXCLUDE USING gist (artikel_id WITH =, periode WITH &&) ); ``` Vanaf dat moment is een dubbele reservering geen bug meer maar een foutmelding. Dat is precies wat je wilt: je applicatie mag zich vergissen, je scherm mag verouderde data tonen, je API mag een verzoek dubbel binnenkrijgen — het artikel gaat niet twee keer uit. Werk je op MySQL, dan bestaat dit type constraint niet. Dan doe je de controle en de insert binnen één transactie met een expliciete rijvergrendeling op het artikel, zodat een tweede boeking wacht tot de eerste klaar is. Dat werkt, maar de garantie hangt nu af van de discipline dat élk pad in je code die vergrendeling gebruikt — de webshop, het backoffice-scherm, de importscript, de API. Dat is precies de soort afweging die in [PostgreSQL vs MySQL](https://coding.agency/kennisbank/postgresql-vs-mysql) uitgebreider aan bod komt. ### Tijdelijk vasthouden tijdens het afrekenen Er zit nog een gat tussen "klant klikt op reserveren" en "betaling is binnen". Laat je de reservering pas ontstaan ná de betaling, dan kan iemand anders er in die minuten tussenkomen. Leg je hem meteen definitief vast, dan blokkeren afgebroken bestellingen je agenda. De werkbare tussenvorm is een reservering met een houdbaarheidsdatum: je legt hem direct vast met een status en een vervalmoment van enkele minuten, en een achtergrondtaak ruimt verlopen holds op. De constraint uit de vorige paragraaf beschermt ook die holds, dus je hoeft geen tweede beschikbaarheidslogica te bouwen. Belangrijk daarbij: de bevestiging vanuit je betaalprovider komt soms dubbel binnen, en soms in de verkeerde volgorde. Verwerk die berichten [idempotent](https://coding.agency/kennisbank/idempotency-bij-api-koppelingen), zodat een tweede melding geen tweede reservering of tweede factuur oplevert. ## Wat verhuursoftware verder echt nodig heeft De beschikbaarheidskern is het moeilijkste stuk, maar niet het enige. Wat ik in verhuurprojecten steevast terugzie als noodzakelijk: - **Uitgifte en retour met scan:** vastleggen welke exemplaren daadwerkelijk meegingen en wat terugkwam. Met barcodes of QR-codes op de artikelen is dat een handeling van seconden in plaats van een paklijst die 's avonds wordt overgetypt. Hoe zo'n flow eruitziet, staat in [scan- en registratieapps](https://coding.agency/kennisbank/scan-en-registratie-apps). - **Schade, borg en verbruik:** de eindafrekening wijkt bij verhuur vaker af van de reservering dan bij verkoop. Ontbrekende onderdelen, te laat terug, extra dagen, brandstof. Bouw dat als expliciete regels op de reservering, niet als handmatige correctie op de factuur. - **Onderhoud en keuring als blokkade:** een artikel dat gekeurd moet worden, is niet "kapot" maar "niet beschikbaar in deze periode". Als onderhoud dezelfde perioden-tabel gebruikt als verhuur, kan je systeem er automatisch rekening mee houden. - **Een planbord dat de werkelijkheid toont:** planners werken visueel. Een tijdlijn per artikel of per voertuig, met slepen om te verschuiven, wint het altijd van een formulier — mits de verplaatsing dezelfde controles doorloopt als een nieuwe boeking. - **Koppeling met betalen en boekhouding:** aanbetaling, borg en eindafrekening lopen via je betaalprovider en gaan automatisch door naar je boekhoudpakket. Zie [webshop koppelen aan je boekhoudpakket](https://coding.agency/kennisbank/webshop-koppelen-boekhoudpakket) voor het patroon daarachter. ### Valkuilen die ik in verhuurprojecten zie - **Alleen op datum werken in plaats van op tijdstip:** zodra je 's ochtends terugkrijgt en 's middags weer uitgeeft, is een dag als kleinste eenheid te grof en verlies je een verhuurdag per omloop. - **Beschikbaarheid tonen zonder de buffer:** de klant ziet online groen, de planner ziet dat het niet kan. Toon in de webshop dezelfde blokkadeperiode als in de backoffice. - **Retour als bijzaak behandelen:** het geld lekt bijna nooit weg bij de boeking maar bij de terugkomst. Als niemand registreert dat er twee spanbanden ontbreken, staat je voorraad structureel te hoog. - **Overboeken zonder het te weten:** soms is bewust overboeken zinvol, omdat je weet dat je bij kunt huren. Maak dat een expliciete instelling met een zichtbare waarschuwing, geen bijwerking van een lekke controle. - **De telefoon vergeten:** een groot deel van de reserveringen komt binnen via telefoon en mail. Als het backoffice-scherm trager werkt dan de spreadsheet die het vervangt, keert je team terug naar de spreadsheet — en heb je twee waarheden. ## Mijn kijk op verhuursoftware Wat me in deze sector opvalt, is hoeveel kennis er in hoofden zit. De planner weet welke aanhanger je niet aan die ene klant meegeeft, welke set eigenlijk altijd een reserveblower nodig heeft en welke klus altijd uitloopt. Software die dat negeert en alles dichttimmert, wordt binnen een maand omzeild. Software die alleen registreert wat de planner al doet, voegt niets toe. De winst zit ertussenin: het systeem bewaakt de harde regels — geen overlap, geen artikel zonder keuring, geen uitgifte zonder scan — en laat de planner vrij in alles wat een afweging is. Daarom begin ik bij verhuurbedrijven het liefst met één artikelgroep helemaal af: reserveren, plannen, uitgeven, retour, factureren. Niet alle artikelen half. In die ene keten kom je alle uitzonderingen tegen die er werkelijk toe doen, en je hebt binnen enkele weken iets waar de operatie op kan draaien. Alles daarna is herhaling van een patroon dat zich al bewezen heeft. En wees streng op waar de garantie ligt. Ik heb meer verhuursystemen gezien met een prachtig planbord en een lekke beschikbaarheidscontrole dan andersom. Een dubbele boeking kost je een klus, een klant en een middag bellen — dat is te veel om over te laten aan een controle die net iets te vroeg werd uitgevoerd. > — Jasper ## Zo helpt Coding Agency hierbij Wij bouwen verhuur- en reserveringsplatformen vanuit Meppel: een beschikbaarheidskern die overlap onmogelijk maakt, een planbord waar je planner sneller mee is dan met zijn spreadsheet, een uitgifte- en retourflow op de telefoon of scanner, en koppelingen naar je betaalprovider en [boekhouding](https://coding.agency/kennisbank/webshop-koppelen-boekhoudpakket). Vaak in het verlengde van een bestaande site of webshop, zodat je online kunt laten reserveren zonder je hele landschap te vervangen. Meer over onze aanpak lees je bij [software voor evenementen en verhuur](https://coding.agency/software-voor/evenementen) en [maatwerk software](https://coding.agency/expertises/maatwerk-software-laten-maken). Twijfel je of je huidige pakket het aankan, of wil je weten hoe een eerste werkende keten eruit zou zien? Neem [contact](https://coding.agency/contact) op voor een vrijblijvend gesprek — we kijken eerst naar je proces, dan naar software. Bron: [PostgreSQL-documentatie (range types & exclusion constraints)](https://www.postgresql.org/docs/current/rangetypes.html). ## Veelgestelde vragen Een webshop verkoopt een aantal uit voorraad: de voorraad gaat omlaag en komt niet terug. Verhuursoftware verkoopt een periode: hetzelfde artikel is straks weer beschikbaar, maar niet tijdens de gereserveerde periode en niet tijdens de ombouw- en controletijd eromheen. Dat verschil raakt je datamodel, je beschikbaarheidscheck en je facturatie. Door de garantie in de database te leggen in plaats van in het scherm. In PostgreSQL doe je dat met een range-kolom en een exclusion constraint, waardoor overlappende perioden op hetzelfde artikel simpelweg niet opgeslagen kunnen worden. Een controle in de applicatie alleen is niet genoeg: tussen de check en het opslaan zit altijd een moment waarop een tweede boeking ertussen kan komen. Leg de klantperiode en de blokkadeperiode apart vast. De klant ziet en betaalt de huurperiode; je planning en beschikbaarheidscheck rekenen met de ruimere periode inclusief transport, schoonmaak, keuring en laden. Zet je die tijd in de huurperiode zelf, dan klopt je factuur niet meer met wat de klant heeft afgesproken. Vaak wel, zeker als je verhuurt zoals de rest van je markt. Wijkt je proces af — gekoppelde sets, keuringsplicht, personeel dat meegaat, verhuur per dagdeel naast verhuur per week — dan ga je in een pakket velden misbruiken voor iets waarvoor ze niet bedoeld zijn. Dat is meestal het moment waarop maatwerk goedkoper uitpakt dan aanpassen. Ja. Reserveringen, aanbetalingen, borg en eindafrekeningen laat je via een betaalprovider lopen en boek je automatisch door naar je boekhoudpakket. Het belangrijkste is dat die verwerking herhaalbaar is: een dubbel binnengekomen betaalmelding mag nooit een tweede factuur of een tweede reservering opleveren. Gerelateerde expertise — Maatwerk Software **Maatwerk software laten maken?** Bekijk onze aanpak, werkwijze en referentieprojecten. Vanaf € 3.000, 16+ jaar ervaring, 150+ projecten opgeleverd. [ Bekijk onze aanpak ](https://coding.agency/expertises/maatwerk-software-laten-maken) [ Gratis prijsindicatie ](https://coding.agency/prijsindicatie) Onderwerpen Verhuur Evenementen Reserveringen Beschikbaarheid Maatwerk PostgreSQL Planning ## Gerelateerde artikelen [ 14 feb. 2026 Webapplicaties ### Registratiesystemen Waarom handmatige registratieprocessen je organisatie vertragen en hoe een registratiesysteem op maat je tijd, fouten en frustratie bespaart... ](https://coding.agency/kennisbank/registratiesystemen) [ 14 feb. 2026 Apps ### Scan & registratie apps Barcodes scannen, aanwezigheid registreren, assets tracken — hoe een scan-app handmatige registratie vervangt door real-time datacaptuur. ](https://coding.agency/kennisbank/scan-en-registratie-apps) [ 1 aug. 2024 Hosting ### PostgreSQL vs MySQL Welke database past bij jouw project? De technische afweging en praktische gevolgen van deze keuze. ](https://coding.agency/kennisbank/postgresql-vs-mysql) ## Hulp nodig? Vragen over dit onderwerp? Laten we het erover hebben. [ Neem contact op ](https://coding.agency/contact) --- *Bron: [Coding Agency](https://coding.agency/kennisbank/verhuursoftware-beschikbaarheid-dubbelboekingen)*