Wat kost een koppeling tussen twee systemen?

Waarom "tussen de 500 en 5000 euro" je niets vertelt

Bijna elke pagina over koppelingen eindigt met een bandbreedte. Ergens tussen de vijfhonderd en de vijfduizend euro, afhankelijk van de situatie. Dat is geen antwoord, dat is een disclaimer verkleed als prijsinformatie. Als ondernemer wil je weten wat jouw koppeling kost, niet wat een gemiddelde klant ooit heeft betaald voor iets dat misschien totaal niet op jouw geval lijkt.

Het probleem is dat een koppeling geen vast product is. Het is een optelsom van keuzes die per bedrijf anders uitpakken. Twee pakketten met allebei een moderne API koppelen is een ander project dan een legacy kassasysteem zonder enige documentatie aan een webshop hangen. Beide heten "een koppeling", maar de rekening verschilt met een factor vijf tot tien.

In dit artikel splits ik de prijs op in de vier posten die het bedrag echt bepalen. Daarna reken ik twee voorbeelden helemaal door, van simpel tot complex, zodat je zelf kunt inschatten in welke categorie jouw situatie valt. Wie breder wil kijken naar automatisering dan alleen een koppeling tussen twee systemen, vindt op automatisering een overzicht van wat er allemaal onder valt.

De vier posten die de prijs echt bepalen

Elke offerte voor een koppeling bestaat, of de bouwer het nu zo benoemt of niet, uit dezelfde vier bouwstenen. Ken je het antwoord op deze vier vragen, dan kun je zelf al een redelijke inschatting maken voordat er een offerte ligt.

• Heeft het pakket een koppelvlak, zoals een API of webhook, of moet er iets gebouwd worden om data eruit te trekken?
• Hoeveel velden en records moeten mee, en hoe schoon staat die data er nu bij?
• Hoe vaak moet de koppeling lopen: continu, elke nacht, of op een knop die iemand indrukt?
• Wie herstelt het als de koppeling op een dag stilvalt, en wat kost dat structureel?

De rest van dit artikel behandelt elke post apart, met de reden waarom die post de prijs juist omhoog of omlaag trekt. Daarna volgen twee complete rekenvoorbeelden.

Post 1: heeft het pakket een koppelvlak?

Dit is de post die het grootste prijsverschil veroorzaakt. Heeft een pakket een API of een webhook, dan kan een bouwer daar direct data uit halen of naartoe sturen volgens een vaste structuur. De documentatie bestaat al, de authenticatie is uitgedacht en de foutmeldingen zijn voorspelbaar. Dat scheelt uren bouwtijd en, minstens zo belangrijk, uren onderhoud later.

Heeft een pakket geen koppelvlak, dan zijn er twee routes. De eerste is exporteren en importeren via bestanden, wat werkt maar traag en foutgevoelig is zodra iemand het formaat van een export wijzigt. De tweede is een systeem via de gebruikersinterface aansturen, vaak robotic process automation genoemd, waarbij software doet alsof het een mens is die klikt en typt. Dat werkt, maar is kwetsbaar: verandert de leverancier iets aan het scherm, dan valt de koppeling stil totdat iemand het weer aanpast.

Concreet: een koppeling tussen twee pakketten die allebei een goed gedocumenteerde API hebben, kost meestal een fractie van een koppeling waarbij een van de twee systemen geen enkel koppelvlak biedt. Vraag dit dus als eerste na bij een offerte-aanvraag. Niet "kunnen jullie dit koppelen", maar "heeft dit pakket een API die wij kunnen gebruiken".

Post 2: hoeveel velden en records moeten mee?

De tweede post wordt vaak onderschat. Een koppeling die alleen naam, e-mailadres en ordernummer doorzet, is fundamenteel iets anders dan een koppeling die veertig velden meeneemt inclusief adresgegevens, kortingscodes, btw-tarieven en historische notities. Elk veld dat mee moet, is een keuze: hoe heet het in systeem A, hoe heet het in systeem B, welk formaat verwacht het doelsysteem, en wat gebeurt er als het veld leeg is.

Daar komt de staat van de data bij. Staan er dubbele klantrecords in het CRM, gebruiken twee afdelingen andere productcodes voor hetzelfde artikel, of staan telefoonnummers in vijf verschillende notaties? Dan moet die rommel eerst opgeschoond of tijdens de koppeling automatisch genormaliseerd worden. Dat opschonen kost vaak meer tijd dan de koppeling zelf.

Een vuistregel die in de praktijk goed standhoudt: reken niet in "één koppeling", maar in aantal velden maal complexiteit per veld. Tien simpele, altijd gevulde velden zijn in een dag te mappen. Tien velden waarvan de helft afhankelijk is van een andere waarde, of waarvoor validatie nodig is, kosten al snel het dubbele.

Post 3: hoe vaak moet de koppeling lopen?

De derde post gaat over frequentie, en die bepaalt niet alleen de bouwkosten maar ook de architectuur. Een koppeling die één keer per nacht draait, kan vaak met een simpel geplande taak of een no-code-tool worden opgezet. Loopt er iets mis, dan zie je dat de volgende ochtend en herstel je het rustig.

Een koppeling die realtime moet reageren, bijvoorbeeld omdat een klant direct een orderbevestiging moet zien nadat hij heeft afgerekend, vraagt om een andere opzet. Dan bouw je op basis van webhooks of events, met foutafhandeling die meteen ingrijpt als er iets misgaat, en met monitoring die alarm slaat binnen minuten in plaats van de volgende dag. Die robuustheid kost extra bouwtijd, en dat zie je terug in de prijs.

Handmatig getriggerde koppelingen, waarbij iemand op een knop drukt als het nodig is, zijn vaak de goedkoopste optie om te bouwen, maar verschuiven de kosten naar de persoon die op die knop moet blijven drukken. Reken dat mee als "onzichtbare" kostenpost: tijd van een medewerker is ook geld, ook als het niet op de factuur van de koppeling staat.

Post 4: wie herstelt het als het stilvalt?

Dit is de post die de meeste offertes stilzwijgend weglaten, en die achteraf de meeste discussie oplevert. Een koppeling die vandaag perfect werkt, valt op een gegeven moment stil. Een leverancier wijzigt zijn API, een wachtwoord verloopt, een veld krijgt een nieuwe naam, of het ene systeem staat tijdelijk offline voor onderhoud. Dat gebeurt niet omdat de koppeling slecht gebouwd is, dat gebeurt gewoon omdat software van derden blijft veranderen.

De vraag is dan: wie merkt dat de koppeling stilligt, en wie repareert het? Zonder monitoring merk je het pas als een klant belt dat zijn bestelling niet is aangekomen in het systeem, of als de boekhouder een maand later ontdekt dat er facturen missen. Met monitoring krijg je een melding zodra er iets misgaat, en kan het binnen een paar uur hersteld zijn in plaats van weken later ontdekt te worden.

Reken dit dus als aparte kostenpost, los van de bouwkosten. Sommige koppelingen worden eenmalig gebouwd zonder vervolgafspraak, wat prima kan als het om iets kleins en stabiels gaat. Zodra de koppeling bedrijfskritisch is, is een vaste afspraak over onderhoud en herstel vaak goedkoper dan telkens opnieuw een spoedklus inkopen als het misgaat. Bij de diensten die ik aanbied hoort dat onderhoud standaard bij een koppeling die structureel blijft draaien, en via contact bespreek ik graag wat dat in jouw geval betekent.

Rekenvoorbeeld 1: twee standaardpakketten met een API

Stel: je wilt nieuwe klanten uit je CRM automatisch als debiteur laten aanmaken in je boekhoudpakket. Beide pakketten zijn bekende, veelgebruikte software met een goed gedocumenteerde API. Er hoeven acht velden mee: naam, adres, e-mail, telefoonnummer, klantnummer, btw-status, betalingstermijn en een notitieveld. De koppeling hoeft niet realtime te zijn, eenmaal per nacht synchroniseren is ruim voldoende. Fouten hoeven niet binnen minuten gesignaleerd te worden, een melding de volgende ochtend volstaat.

In dit scenario is de bouw relatief overzichtelijk: koppelvlak aanwezig aan beide kanten, beperkt aantal velden, lage frequentie, licht onderhoud. Dit is het type koppeling dat in de praktijk vaak in de orde van enkele honderden tot rond de duizend euro eenmalig te bouwen is, met een klein bedrag per maand voor monitoring en het opvangen van kleine wijzigingen aan een van beide kanten. De grootste kostenpost hier is niet het bouwen zelf, maar het goed testen: wat gebeurt er met een klant die al bestaat, met een leeg veld, of met een dubbele invoer.

Rekenvoorbeeld 2: een koppeling zonder koppelvlak en met logica

Nu een ander scenario: een verouderd voorraadsysteem zonder API moet de actuele voorraad doorgeven aan een webshop, en dat moet vrijwel realtime omdat je anders producten verkoopt die niet meer op voorraad zijn. Er moeten veertig velden mee, waaronder samengestelde artikelen, verschillende maten en kleuren, en een berekende beschikbaarheid op basis van meerdere magazijnen. Daarnaast moet er logica in zitten: bij een negatieve voorraad moet het artikel automatisch offline gaan, en bij een correctie moet het weer online komen.

Hier tellen alle vier de posten zwaar mee. Geen koppelvlak betekent dat er eerst een manier gebouwd moet worden om data uit het voorraadsysteem te trekken, bijvoorbeeld via een tussenlaag die het systeem periodiek uitleest. Veertig velden met onderlinge afhankelijkheden vragen om zorgvuldige mapping en testen. De gewenste snelheid vraagt om een architectuur die continu draait in plaats van een nachtelijke taak. En omdat een verkeerde voorraadstand direct klanten en omzet raakt, is stevige monitoring met snelle foutafhandeling geen luxe maar noodzaak.

Dit type project zit al snel in de orde van enkele duizenden euro's, met een navenant onderhoudsbudget per maand omdat de kwetsbaarheid nu eenmaal groter is. Dat is geen reden om ervan af te zien als het businessprobleem groot genoeg is, maar het is wel de reden waarom "een koppeling" geen vaste prijs heeft. Wie voor dit soort projecten breder wil kijken dan alleen de koppeling zelf, bijvoorbeeld naar workflow rond het hele voorraadproces, vindt achtergrond op de kennisbank.

Wat de meeste offertes vergeten mee te rekenen

Naast de vier hoofdposten zijn er een paar kleinere zaken die het verschil kunnen maken tussen een offerte die klopt en een die achteraf tegenvalt. Vraag deze punten actief na voordat je een prijs accepteert.

• Wat gebeurt er als de authenticatie, zoals een API-sleutel of token, na verloop van tijd vernieuwd moet worden?
• Is er een limiet op het aantal aanroepen per uur bij een van beide systemen, en wat als je daar overheen groeit?
• Wordt er getest in een aparte omgeving voordat de koppeling op echte klantdata losgaat?
• Is er documentatie van hoe de koppeling werkt, zodat een ander dan de bouwer het ook kan begrijpen bij uitval?
• Wat gebeurt er als een van beide systemen tijdelijk offline is voor onderhoud van de leverancier zelf?

Een offerte die deze punten benoemt, is meestal betrouwbaarder dan een offerte die alleen een totaalbedrag noemt zonder uitleg. Vraag er gerust naar, ook als de bouwer het zelf niet uit zichzelf aankaart.

Wil je weten hoe ik dit soort trajecten aanpak, of gewoon even sparren over jouw specifieke situatie voordat je een offerte opvraagt? Lees meer over mijn manier van werken, of kijk breder naar wat er onder automatisering allemaal mogelijk is voor jouw bedrijf.