Voorraad, B2B-prijsafspraken en een kassa in één systeem: waarom maatwerk hier wint van een standaard PoS.

Voor wie is dit een herkenbaar probleem?

Het profiel komt vaker voor dan je denkt: een groothandel in installatiemateriaal, een producent die ook aan dealers levert, een verkoper van onderdelen, een kwekerij met een zakelijke afzet en een verkooppunt aan huis. Negentig procent van de omzet gaat op rekening naar zakelijke klanten, met prijsafspraken die per klant verschillen. En dan staat er op vrijdagmiddag een particulier aan de balie die twee dingen wil kopen en wil pinnen.

Voor die particulier koop je een kassasysteem. Het is een logische reflex, en het is bijna altijd het begin van het probleem. Want die kassa wil zijn eigen artikelbestand, zijn eigen prijzen en zijn eigen voorraad. Vanaf dat moment houd je alles dubbel bij, en de vraag "hoeveel hebben we er nog" heeft twee antwoorden.

Waarom een standaard kassa hier wringt

Kassasystemen zijn ontworpen voor de winkel, en dat is geen verwijt: voor een winkel doen ze het uitstekend. Het probleem is dat de aannames waarop ze gebouwd zijn, bij zakelijke verkoop stuk voor stuk niet gelden.

• Eén prijs per artikel, inclusief btw. De winkel heeft een schapprijs. Jij hebt een basisprijs exclusief btw, een staffel per afname, een kortingsgroep per klantsoort en netto-afspraken met je grootste afnemers. Een kassa heeft hooguit een klantenkaart met een vast kortingspercentage.
• Afrekenen is betalen. In de winkel is de transactie klaar als de pin is geaccepteerd. Bij jou is de transactie klaar als de factuur betaald is, dertig dagen later, misschien in twee delen, misschien verrekend met een creditnota voor een retour van vorige maand.
• De voorraad is wat er in de winkel ligt. Jij hebt een magazijn, een bestelling die onderweg is, artikelen die gereserveerd zijn voor een order die nog niet is uitgeleverd, en een backorder bij je leverancier. De kassa kent één getal per artikel.
• Een bon is genoeg. Voor een particulier klopt dat. Zakelijke klanten hebben een factuur nodig met hun bedrijfsgegevens, btw-nummer en de btw per tarief. Volgens artikel 34c van de Wet op de omzetbelasting ben je verplicht die factuur uit te reiken bij leveringen aan andere ondernemers en rechtspersonen. Een kassa kan dat meestal niet, of alleen als losse "factuurmodule" die weer een eigen nummerreeks bijhoudt.
• Er is geen "later". Deelleveringen, pakbonnen, orderpicking, een klant die belt en twee regels toevoegt aan een order die al klaarstaat: het bestaat niet in een kassa, omdat het in een winkel niet bestaat.

De gebruikelijke oplossing is een kassa naast een ander pakket zetten: een ERP, een boekhouding met voorraadmodule, of een spreadsheet. En dan een koppeling ertussen, of iemand die het overtypt. Dat is waar het echte probleem begint.

Twee systemen, twee waarheden

Zodra je voorraad op twee plekken bijhoudt, heb je twee waarheden. Niet af en toe, maar structureel. Een retour aan de balie wordt in de kassa geboekt en niet in het ERP. Een inkoopontvangst wordt in het ERP geboekt en bereikt de kassa pas bij de volgende synchronisatie, of nooit, omdat het artikel in de kassa een ander nummer had. Een prijswijziging wordt in het ene systeem doorgevoerd en in het andere vergeten, en een klant krijgt aan de balie een andere prijs dan op zijn factuur van vorige week.

Synchroniseren lost dat niet op. Synchroniseren is per definitie achterlopen, en elke koppeling die twee getallen gelijk probeert te houden, moet ook beslissen wie er gelijk heeft als ze verschillen. Die beslissing wordt vrijwel nooit expliciet gemaakt. Het resultaat is dat er periodiek iemand met een lijst het magazijn in loopt om te tellen wat er "echt" ligt, en dat de telling het derde antwoord oplevert.

Een voorraadstand die op twee plekken staat, is geen voorraadstand meer maar een discussie.

Hetzelfde geldt voor prijzen. Inkoopprijzen staan in de boekhouding of in een leverancierslijst, verkoopprijzen in de kassa, klantafspraken in een map of in het hoofd van de verkoper. Je marge per artikel is dan een schatting, en je weet pas achteraf, bij de jaarrekening, of een klant eigenlijk wel winstgevend was.

Build of buy: wat de verkoper belooft en wat de factuur zegt

Op dit punt komt bijna altijd de tegenwerping: "maar het kassasysteem kan dat toch allemaal?" En in het verkoopgesprek klopt dat ook. Klantprijzen? Er is een module. Op rekening leveren? Er is een factuurmodule. Koppeling met je boekhouding, je webshop, je vervoerder? Allemaal beschikbaar. De demo laat het zien en de verkoper heeft gelijk: het kán.

Wat in dat gesprek minder aandacht krijgt, is wat het kost om het te laten kunnen. Het abonnement dat je in de vergelijking hebt gezet, is het instaptarief. Elke wens uit je lijst is een module met een eigen maandbedrag, en de koppelingen die je nodig hebt komen zelden mee in het pakket. Daar zit vaak een eenmalig bedrag aan vast voor "configuratie" of "activering", en daarna weer een maandelijks bedrag per koppeling. Voor de leverancier is die activering een vinkje: je bent echt niet de eerste die een koppeling met dat boekhoudpakket of die vervoerder wil, dus de koppeling bestaat al en het aanzetten kost hen een handeling. Voor jou is het een factuur die je vooraf niet had ingecalculeerd.

Tel dat bij elkaar op en de vergelijking kantelt. Het instaptarief is een fractie van wat je maandelijks betaalt zodra het systeem doet wat jij nodig hebt, en dat bedrag groeit met elke wens die erbij komt. Maatwerk werkt andersom: je investeert vooraf in precies de onderdelen die je proces vraagt, en daarna zijn de doorlopende kosten hosting en onderhoud, niet een licentie per functie. Het omslagpunt hangt af van hoeveel modules en koppelingen je nodig hebt, maar bij het profiel uit dit artikel — klantprijzen, op rekening, voorraad buiten de kassa, later een webshop — is de terugverdientijd snel in zicht. Niet omdat maatwerk goedkoop is, maar omdat het maandbedrag van het pakket blijft stijgen om aan je wensen te voldoen, en dat van maatwerk niet.

Daar komt bij dat je bij een pakket betaalt voor de belofte dat het kan, niet voor de zekerheid dat het bij jou past. De klantprijsmodule kent staffels, maar niet jouw netto-afspraak per artikel met een einddatum. De factuurmodule maakt facturen, maar in een eigen nummerreeks naast die van je magazijn. Elke module lost een deel van je probleem op en laat een rand over die je alsnog met de hand doet. Wie de afweging serieus wil maken, zet de eerlijke vragen op een rij: welke modules heb ik daadwerkelijk nodig, wat kosten die samen per maand, welke koppelingen komen daar bovenop, en welk deel van mijn proces blijft dan nog steeds handwerk? Dat rekensommetje wint het pakket zelden meer.

De optelsom over vijf en tien jaar

De terugverdientijd van maatwerk wordt pas zichtbaar als je de kosten van een pakket op dezelfde manier optelt als de investering in maatwerk: over de looptijd, niet per maand. Doe die som eens eerlijk voor je eigen situatie. Wat je bij een pakket maandelijks kwijt bent, is zelden alleen het abonnement uit de vergelijking:

• De modules die je nodig hebt: klantprijzen, facturatie op rekening, voorraad per locatie, partijen of serienummers, rapportages. Elk een eigen regel op de factuur.
• De koppelingen: boekhouding, betaalprovider, vervoerder, later de webshop. Per koppeling een maandbedrag, en vooraf de eenmalige activering die voor de leverancier een vinkje is en voor jou een rekening.
• Per gebruiker, per kassa, per vestiging: de tweede balie en de derde medewerker die erbij moet kunnen, tellen mee.
• De hardware als "kassasysteem": de gebundelde tablet, scanner, printer en lade van de leverancier, vaak duurder dan dezelfde onderdelen los, en soms alleen bruikbaar met dat ene pakket.
• De webshop die je misschien wilt: een extra module of een tweede platform, een koppeling ertussen, transactiekosten per bestelling, en opnieuw activering. De onzekerheid of je die stap zet, is bij een pakket zelf al een kostenpost, want je bouwt er niet naartoe maar koopt hem er later bij.
• De jaarlijkse verhoging: abonnementen worden geïndexeerd, en je hebt daar geen invloed op.
• Het handwerk dat overblijft: de uren die iemand elke week kwijt is aan overtypen, corrigeren en tellen, omdat het pakket net niet doet wat je proces vraagt.

Vermenigvuldig dat maandbedrag met zestig voor vijf jaar, of honderdtwintig voor tien. Bedrijven die deze som voor het eerst maken, schrikken vrijwel altijd van de uitkomst: het bedrag dat ze alleen al aan maandelijkse kosten kwijt zijn, los van activering en hardware, ligt ruim boven wat een systeem op maat zou hebben gekost. En aan het eind van die tien jaar is het pakket nog steeds niet van hen, staat hun data nog steeds in de structuur van de leverancier, en werkt het proces nog steeds zoals het pakket het wil. Dat is vendor lock-in, en het hoort in de optelsom thuis: je hele bedrijf draait op iets wat bij een ander staat, en je zit aan die ander vast.

Wat de som er bij maatwerk anders uit laat zien

Maatwerk is een eenmalige investering in een systeem dat precies op jouw maat en jouw proces is ingericht. Daarna betaal je hosting en onderhoud, geen licentie per functie, per gebruiker of per koppeling. Wil je koppelen aan iets nieuws, dan bouw je dat één keer en het is van jou. De logica en de waarheden staan op één plek: inkoop, verkoop, voorraad, prijsafspraken en betalingen, zonder dat er iets tussen systemen heen en weer hoeft.

Er is een besparing die in de meeste rekensommen ontbreekt, en die is niet klein: je accountant. Wie met een kassa, een boekhoudpakket en een spreadsheet werkt, levert elk kwartaal een puzzel af. De accountant verzamelt uit drie bronnen, sluit voorraad aan op omzet, zoekt de retouren die in de kassa staan maar niet in de boekhouding, en stelt vragen die jij weer moet uitzoeken. Die uren staan op zijn factuur en op die van jou. Met één systeem waar de boekhouding automatisch uit gevuld wordt, is de jaarrekening een export in plaats van een reconstructie. Een blije accountant is de indirecte besparing waar jij weer blij van wordt, en hij komt elk jaar terug.

Hoe je zo'n berekening opzet, staat in ROI van maatwerk software. Wil je het voor je eigen situatie doorrekenen, dan kun je met de ROI-calculator de maandelijkse kosten en het handwerk naast een eenmalige investering zetten.

Eén systeem dat leidend is: wat daar precies in zit

Het alternatief is niet "een groter pakket" maar een andere ordening: één kern die de waarheid vastlegt, en alle kanalen daaromheen die alleen lezen en schrijven via die kern. In de projecten die ik bouw bestaat die kern uit vier onderdelen.

Eén artikelstam

Elk artikel bestaat één keer, met één intern nummer, en alle andere nummers — leveranciersartikelnummer, EAN, het nummer dat je grootste klant er zelf aan geeft — zijn eigenschappen van dat ene artikel. Zo kun je een bestelling van een klant met zijn eigen nummers ontvangen, inkopen op het nummer van je leverancier en aan de balie scannen op EAN, zonder dat het ooit drie artikelen worden.

Voorraad als journaal, niet als getal

Dit is de belangrijkste ontwerpkeuze. Sla de voorraad niet op als een getal dat je overschrijft, maar als een reeks mutaties: ontvangst van leverancier, uitgifte op order, verkoop aan balie, retour, correctie na telling, afboeking wegens schade. De actuele stand is de som van die mutaties. Het verschil merk je pas als er iets misgaat: bij een getal weet je alleen dát het niet klopt, bij een journaal zie je wélke boeking ontbreekt of dubbel staat.

Op die mutaties bouw je ook de begrippen die een kassa niet kent: fysieke voorraad, gereserveerde voorraad voor orders die nog niet zijn uitgeleverd, vrij beschikbare voorraad, en verwachte voorraad op basis van inkooporders. De webshop toont straks de vrije voorraad, de planner ziet de verwachte.

Inkoopprijs en kostprijs per artikel

Elke ontvangst legt de inkoopprijs van dát moment vast. Daaruit bereken je een kostprijs per artikel, meestal een gewogen gemiddelde of op volgorde van ontvangst. Omdat elke verkoop een mutatie is met een kostprijs erbij, weet je per orderregel wat je marge was, en per klant of die zijn korting waard is. Dat inzicht is er nu simpelweg niet als inkoop en verkoop in verschillende systemen leven.

Verkoopprijs als regel, niet als veld

In plaats van "de prijs van artikel X" leg je vast hoe de prijs voor een klant tot stand komt: een basisprijs, staffels per hoeveelheid, een kortingsgroep per klantcategorie, een netto-afspraak voor een specifieke klant op een specifiek artikel, met een geldigheidsperiode. Bij elke orderregel bepaalt het systeem welke regel wint, en legt het vast wélke dat was. De particulier aan de balie is dan gewoon een klant in de standaardgroep, met prijzen inclusief btw. Geen aparte prijslijst, geen aparte kassa-artikelen.

Dit is ook het punt waar een pakket het meestal aflegt. Het heeft een prijsveld en een kortingsveld, en alles wat daarbuiten valt wordt handwerk. Hoe je dat soort domeinregels in software op maat modelleert, staat uitgebreider in ERP systeem op maat.

Branches waar voorraad meer is dan een aantal

Bij veel bedrijven met dit profiel is "hoeveel hebben we er" niet eens de juiste vraag. De vraag is: hoeveel hebben we er van welke partij, met welke datum, uit welke charge, met welk serienummer. Een kassa kent één getal per artikel. Een boekhoudpakket met voorraadmodule kent er meestal ook maar één, hooguit per locatie. En precies daar zit voor een hele reeks branches het dagelijkse handwerk.

Houdbaarheid en partijen

Levensmiddelen, dranken, diervoeding, supplementen, cosmetica, bloemen en planten: per ontvangst leg je een lotnummer en een houdbaarheidsdatum vast, je levert uit op de kortste houdbaarheid in plaats van op volgorde van ontvangst, en je moet kunnen aantonen welk lot naar welke klant is gegaan. Voor levensmiddelen is dat laatste geen keuze: artikel 18 van de Europese General Food Law verplicht elke schakel om één stap terug en één stap vooruit te kunnen traceren. Geneesmiddelen en medische hulpmiddelen gaan verder, met serialisatie per verpakking en een unieke hulpmiddelidentificatie (UDI) per product onder de Europese verordening medische hulpmiddelen.

Charges die bij elkaar moeten blijven

Tegels, verf, laminaat, behang, stoffen en garens verschillen per productiecharge in kleur en structuur. Een order moet uit één charge komen, anders ligt er straks een vloer in twee tinten. Dat vraagt "reserveer uit dezelfde partij", en de mogelijkheid om te zien dat er van charge A nog net genoeg ligt voor deze klant maar niet voor de volgende. Chemie en bouwmaterialen voegen daar per charge een veiligheidsinformatieblad en soms een houdbaarheid aan toe.

Serienummers, edities en jaargangen

Elektronica, machines, gereedschap, fietsen en apparatuur met garantie wil je per exemplaar volgen: welk serienummer staat bij welke klant, wat is de garantietermijn, wat is de servicehistorie, wat kwam er retour. Boeken hebben drukken met een eigen ISBN, wijn heeft jaargangen, software heeft versies. Steeds hetzelfde patroon: één artikel in de stam, meerdere voorraadlijnen eronder met elk een eigen inkoopprijs, verkoopprijs en aantal.

Variabele maat, samenstellingen en emballage

• Per meter of per kilo: staal, hout, kabel, buis, stof op rol, vlees en kaas. De voorraad bestaat uit lengtes of gewichten, restlengtes blijven apart beschikbaar, en inkoop gaat per pallet van veertig dozen van twaalf terwijl verkoop per stuk gaat.
• Stuklijsten: producenten en assembleurs maken van grondstoffen een eindproduct. Een verkoop van het eindproduct verbruikt de onderdelen, een productieorder maakt voorraad in plaats van dat hij die afboekt.
• Emballage en ruilonderdelen: fusten, kratten, pallets en rolcontainers per klant bijhouden; in de onderdelenhandel een inruilbedrag dat pas vervalt als het oude onderdeel terugkomt.
• Meerdere locaties: magazijn, balie, de bus van de monteur, consignatievoorraad bij een klant, met overboekingen ertussen die zelf ook mutaties zijn.

Waarom dit in maatwerk eenvoudig is en elders niet

Al deze gevallen zijn variaties op één ontwerpkeuze uit de vorige paragraaf: voorraad als journaal, met per mutatie een verwijzing naar de partij, het exemplaar of de charge waar hij over gaat. Zodra die verwijzing er is, zijn houdbaarheid, traceerbaarheid, uitleveren uit dezelfde charge en garantie per serienummer gewone rapportages op dezelfde tabel. Het kost in het ontwerp een extra kolom en een paar regels, niet een module.

Een kassa heeft die kolom niet, omdat een winkel hem niet nodig heeft. Een boekhoudpakket met voorraadmodule heeft hem lang niet altijd, en als hij er is, zit hij vaak in een duurdere editie en dan nog zonder de logica eromheen: wel een lotnummer kunnen invoeren, niet automatisch het oudste lot uitleveren of een order aan één charge binden. Het gevolg is dat het bedrijf de partijen in een spreadsheet of op stickers bijhoudt, naast het systeem dat het aantal bijhoudt. Twee waarheden, opnieuw, maar nu met een recall-risico erbij.

De kassa is een scherm op je eigen systeem

Als de kern er staat, is de kassa geen apart systeem meer maar een kanaal: een scherm dat artikelen scant, de prijs opvraagt bij dezelfde prijsregels, een voorraadmutatie schrijft in hetzelfde journaal en de betaling afhandelt. Voor de balie is dat een simpele, snelle interface op een tablet of een vaste computer. Voor het systeem is het een order met het kanaal "balie" en de betaalwijze "pin" of "contant".

De hardware hoef je niet als "kassasysteem" te kopen

Een misverstand dat ik vaak hoor: "maar dan moeten we toch een kassa aanschaffen?" Nee. Een kassasysteem is gewoon hardware met software erop, en bij maatwerk is die software van jou. Wat je aan de balie nodig hebt is een tablet of een gewone computer met je eigen kassascherm in de browser, een barcodescanner die als toetsenbord werkt, een pinterminal van je betaalprovider, en als je bonnen meegeeft een bonprinter met een kassalade. Ook die bonprinter is geen bijzonder geval: het is een gewone printer die je eigen software aanstuurt, met het bon- of factuurformaat dat jij bepaalt. Dat is allemaal standaard hardware die je los koopt en die met elk systeem werkt; er zit niets in dat alleen met een specifiek kassapakket praat. Een tweede balie of een tweede vestiging is dan een tweede tablet, geen tweede licentie.

De betaalterminal via je betaalprovider

Het pinnen zelf hoef je niet te bouwen. Betaalproviders bieden terminals die je vanuit je eigen software aanstuurt: je software meldt het bedrag, de terminal handelt de betaling af en meldt het resultaat terug. Adyen en Mollie hebben daar beide een gedocumenteerde koppeling voor, en omdat het dezelfde provider is als voor je toekomstige webshop, komen pinbetalingen en online betalingen straks in dezelfde uitbetaling en dezelfde afletterlogica terecht.

Eén ding om vanaf het begin goed te doen: verwerk de terugmelding van de terminal idempotent. Een netwerkhapering tijdens het pinnen mag nooit een dubbele order, een dubbele voorraadafboeking of een bon zonder betaling opleveren. Dat is precies de fout die in gekoppelde kassa's het vaakst voorkomt, en die in een eigen systeem eenvoudig te voorkomen is omdat de order, de mutatie en de betaling in één transactie zitten.

Bon of factuur: het systeem beslist

Omdat de kassa dezelfde klant- en ordergegevens gebruikt als de rest van het systeem, is het verschil tussen een bon en een factuur alleen nog een keuze bij het afrekenen. Particulier zonder gegevens: bon, prijzen inclusief btw. Bekende zakelijke klant aan de balie: dezelfde order, maar dan op rekening met zijn eigen prijsafspraken en een factuur die in dezelfde nummerreeks valt als de facturen die vanuit het magazijn gaan. Geen tweede nummerreeks, geen "factuurmodule" die je 's avonds moet overboeken.

Wettelijke eisen aan een eigen kassa

Een zelfgebouwde kassa mag, maar niet vrijblijvend. Artikel 52 van de Algemene wet inzake rijksbelastingen verplicht je om je administratie zeven jaar te bewaren, op een manier waarop de Belastingdienst die binnen redelijke tijd kan controleren. Voor een kassa betekent dat in de praktijk:

• elke transactie wordt vastgelegd en kan daarna niet meer worden gewijzigd of verwijderd;
• een correctie of retour is een nieuwe boeking die naar de oorspronkelijke verwijst, geen aanpassing van het origineel;
• trainings- en testverkopen zijn als zodanig herkenbaar en gescheiden;
• de bewaarde gegevens zijn exporteerbaar in een controleerbaar formaat.

De branche heeft daar het Keurmerk Betrouwbare Afrekensystemen voor, opgezet door leveranciers samen met de Belastingdienst. Het keurmerk zelf is niet verplicht, maar de normen erachter zijn een goede lat voor wat je eigen systeem moet kunnen. Als je voorraad al als journaal is opgezet, is dit vrijwel gratis: dezelfde discipline van "nooit overschrijven, altijd bijboeken" geldt voor je transacties.

Met het oog op later: de webshop erbij

Veel bedrijven met dit profiel hebben nu geen webshop, maar sluiten het niet uit. Soms voor zakelijke klanten die 's avonds willen nabestellen, soms voor consumenten, soms voor allebei. Precies daar wordt de keuze voor één kern beloond, en precies daar loopt een kassa-plus-koppeling definitief vast.

Eén kern, drie kanalen

Als de voorraad, de prijsregels en de orders al in één systeem zitten, is een webshop een derde kanaal naast balie en backoffice. Een B2B-bestelportaal laat een ingelogde klant zijn eigen prijzen zien, zijn eigen artikelnummers, zijn openstaande orders en zijn factuurhistorie, en bestelt op rekening binnen zijn kredietlimiet. Een consumentenshop toont dezelfde artikelen met prijzen inclusief btw en laat vooraf betalen via dezelfde betaalprovider als de terminal aan de balie. Beide trekken uit dezelfde vrije voorraad, dus een artikel dat aan de balie wordt verkocht, is online meteen niet meer beschikbaar.

Kies je nu voor een kassa met eigen voorraad en later voor een webshop met eigen voorraad, dan heb je straks drie waarheden. Dat is niet theoretisch; het is de situatie waarin ik de meeste bedrijven aantref als ze bellen.

Pakbonnen, picken en deelleveringen

Een webshop verkoopt niet aan iemand die voor je staat. Er komt een orderafhandeling bij die in een winkel niet bestaat en die geen kassa voor je regelt:

• Pakbonnen en picklijsten: per order een lijst wat er mee moet, in de volgorde van je magazijn, met een controle bij het inpakken. Met een scanner op de telefoon is dat een handeling van seconden in plaats van een uitdraai die 's avonds wordt afgevinkt.
• Deelleveringen en backorders: een zakelijke klant bestelt twintig regels waarvan er achttien op voorraad zijn. Je levert achttien, de andere twee gaan in backorder en volgen automatisch bij de volgende ontvangst. De factuur volgt de levering, niet de order.
• Verzenden en track-and-trace: een label bij je vervoerder, een verzendbevestiging naar de klant, een terugmelding als het bezorgd is. Dat is een koppeling op de order die je al hebt, niet een aparte verzendmodule met een eigen adressenbestand.
• Retouren: een retour is een mutatie op de oorspronkelijke orderregel en een creditnota op de oorspronkelijke factuur. Bij een consument komt daar herroepingsrecht bij, bij een zakelijke klant je eigen retourvoorwaarden. Beide zijn regels op dezelfde order.

Omdat dit allemaal op dezelfde order en hetzelfde voorraadjournaal werkt, hoef je het niet twee keer te bouwen voor twee kanalen. Een order die aan de balie is begonnen, kan naar het magazijn voor nalevering. Een webshoporder kan aan de balie worden afgehaald en daar worden afgerekend. Dat zijn geen uitzonderingen meer maar gewone paden door hetzelfde systeem.

Beginnen zonder webshop, en er toch klaar voor zijn

Het mooie is dat je hiervoor nu niets extra's hoeft te bouwen. Als de kern een fatsoenlijke API heeft — artikelen, prijzen voor een klant, vrije voorraad, order aanmaken, orderstatus — dan is de webshop later een front-end op die API. Of dat een eigen shop wordt of een bestaand webshopplatform dat je aan je kern koppelt, is dan een keuze die je op dat moment maakt, zonder dat je voorraad of je prijzen ergens anders gaan wonen.

Vastzitten of vrij bewegen: je eigen werkwijze houden

Er is nog een verschil dat pas zichtbaar wordt als je een tijdje met een pakket werkt. Een kassasysteem heeft een werkwijze, en die werkwijze is niet de jouwe. De volgorde waarin je een order aanmaakt, hoe een retour gaat, wat een klant is en wat een artikel, welke velden er zijn en welke niet: dat ligt vast. In het begin lijkt dat prettig, want je hoeft niets te bedenken. Na een paar maanden merk je dat je bedrijf zich heeft aangepast aan de software in plaats van andersom. De verkoper voert de netto-afspraak in als korting omdat er geen ander veld is. Het magazijn boekt deelleveringen als losse orders omdat het pakket geen deellevering kent. En niemand weet meer of dat de bedoeling was.

Ook stapt je er niet zomaar uit. Je artikelen, je klanten, je prijsafspraken en je transactiehistorie staan in het pakket, in een structuur die van de leverancier is. Overstappen betekent exporteren wat er te exporteren valt, de rest opnieuw invoeren en de historie kwijtraken. Die drempel is precies waar het verdienmodel van de leverancier op rust: het maandbedrag mag stijgen, want weggaan is duurder.

Dit heet vendor lock-in, en het werkt subtieler dan een contract met een lange looptijd. Je hebt je hele bedrijf gecommitteerd om op dat pakket te draaien. Je medewerkers zijn erop ingewerkt, je hele historie zit erin, je hebt er al zoveel in geïnvesteerd aan activeringen, modules en inrichting dat je dat grapje niet nog een keer wilt doen. Dus blijf je, ook als het maandbedrag stijgt, ook als een functie verdwijnt, ook als de leverancier wordt overgenomen en het product een andere kant op gaat. Niet omdat het pakket zo goed is, maar omdat overstappen nog duurder voelt dan blijven.

Bij maatwerk ligt dat andersom. Het systeem is gebouwd op hoe jij werkt, dus je proces hoeft niet te veranderen om in de software te passen. Wil je over een jaar een tweede vestiging, een andere vervoerder, een grote klant die via EDI wil bestellen, of een andere manier van picken omdat het magazijn is verbouwd, dan verander je het systeem en niet je bedrijf. De code en de data zijn van jou, de database is een gewone database waar elke ontwikkelaar mee uit de voeten kan, en niemand kan een module uitzetten of een tarief verhogen. Je zit nergens aan vast, behalve aan je eigen keuzes — en die kun je terugdraaien.

Dat is uiteindelijk het argument dat bij mij het zwaarst weegt. Niet dat maatwerk meer kan dan een pakket, want een pakket kan van alles. Maar dat je bij maatwerk je eigen werkwijze houdt en de vrijheid hebt om door te ontwikkelen in de richting die je bedrijf op gaat, in plaats van de richting die de leverancier voor zijn duizend andere klanten heeft gekozen.

Wanneer een standaard kassa wél de juiste keuze is

Eerlijkheidshalve: het profiel uit dit artikel is specifiek. Heb je een winkel met consumenten, één prijs per artikel, voorraad die in de winkel ligt en een boekhouding die maandelijks een omzettotaal nodig heeft, koop dan een kassa. Die is daar beter in dan iets wat ik voor je bouw, en goedkoper. Ook als je zakelijke klanten hebt maar zonder eigen prijsafspraken en zonder leveren op rekening, kom je met een kassa plus een factuurmodule meestal een heel eind.

Het kantelpunt zit bij drie vragen. Verschillen je prijzen per klant? Lever je op rekening en in delen? Staat je voorraad ergens anders dan bij de kassa? Twee keer ja, en de kassa is niet meer je systeem maar een kanaal dat je aan je systeem moet hangen. Dan is de vraag alleen nog of dat systeem een pakket is of maatwerk, en die afweging hangt af van hoe ver je proces afwijkt van wat het pakket verwacht.

Valkuilen die ik in dit soort projecten zie

• De kassa als vertrekpunt nemen. Beginnen bij het kanaal met de minste omzet en de rest daaromheen bouwen. Begin bij inkoop en voorraad; de balie volgt vanzelf.
• Voorraad als getal opslaan. Het lijkt eenvoudiger en het is de reden dat je over een jaar weer gaat tellen. Een journaal kost één dag extra ontwerp en scheelt jaren discussie.
• Prijzen inclusief btw opslaan. Zakelijke prijzen zijn exclusief, de consument ziet inclusief. Sla exclusief op, reken inclusief uit bij het tonen, en leg per regel vast welk btw-tarief gold.
• De kassa laten winnen bij conflicten. Als de balie en het magazijn allebei een mutatie schrijven op hetzelfde artikel, moet de database dat afhandelen met een transactie, niet een koppeling die "de laatste wint" doet.
• De boekhouding als bron van waarheid gebruiken. Je boekhoudpakket is de plek waar het resultaat landt, niet waar het ontstaat. Boek orders, facturen en betalingen automatisch door, zoals beschreven in webshop koppelen aan je boekhoudpakket, maar laat de boekhouding nooit je voorraad bepalen.
• Te breed beginnen. Alle artikelgroepen, alle kanalen, alle klanten tegelijk. Neem één artikelgroep en één zakelijke klant met een echte prijsafspraak, en bouw de keten van inkoop tot factuur helemaal af. Daarin kom je elke uitzondering tegen die ertoe doet.

Mijn kijk hierop

Wat me opvalt bij bedrijven met dit profiel is hoe lang ze het volhouden met twee of drie systemen. De verkoper kent de prijsafspraken uit zijn hoofd, de magazijnmedewerker weet welk getal je moet geloven, en de administratie corrigeert het aan het eind van de maand. Het werkt, tot de verkoper met vakantie is, of tot de omzet groeit en het handwerk niet meer meegroeit.

Het is verleidelijk om de kassa te zien als het probleem dat opgelost moet worden. Dat is hij niet. De kassa is een symptoom van een ontbrekende kern: er is geen plek waar inkoop, verkoop en voorraad samenkomen, dus elk kanaal maakt zijn eigen versie. Los dat op en de kassa wordt een middag werk aan een scherm. Los het niet op en elke volgende stap — een webshop, een tweede vestiging, een koppeling met een grote klant — voegt een waarheid toe.

Daarom begin ik bij dit soort bedrijven nooit met de kassa. Ik begin met de artikelstam, het voorraadjournaal en de prijsregels voor de drie klanten die het meest afwijken. Als dat staat en klopt, is de rest aanhaken.

— Jasper

Zo helpt Coding Agency hierbij

Wij bouwen vanuit Meppel de kern die in dit artikel beschreven staat: één artikelstam, een voorraadjournaal met inkoop- en kostprijzen, prijsregels per klant en per afname, en daarop de kanalen die je nodig hebt — een kassa aan de balie met pinterminal via je betaalprovider, een bestelportaal voor zakelijke klanten, en als je zover bent een webshop voor consumenten. Met koppelingen naar je boekhouding, je vervoerder en de leveranciers waar je het meest bij inkoopt. Meer over onze aanpak lees je bij software voor groothandels en maatwerk software.

Herken je het profiel en wil je weten hoe een eerste werkende keten van inkoop tot balie eruit zou zien? Neem contact op voor een vrijblijvend gesprek — we kijken eerst naar hoe je nu verkoopt, en dan pas naar software.