Atlas Academy · POS · Horeca · Integratie
Een POS aan een ERP koppelen klinkt als een technisch feestje — in de praktijk is het meestal een organisatorische opgave waar de techniek het laatste van is. Dit artikel beschrijft vijf concrete valkuilen, met de symptomen waaraan je ze herkent en de checks die je vooraf doet.
De meest voorkomende fout: producten worden zowel in de POS als in de ERP onderhouden, zonder duidelijke «master». Een nieuwe pizza komt op de menukaart, de POS-medewerker voegt het toe aan de POS-prijslijst, en in de ERP staat het product een week later nog niet. Voorraadbewegingen kloppen niet, omzetrapporten missen items, en in de boekhouding ontstaan onverklaarbare verschillen.
De fix: kies expliciet welk systeem master is voor de productcatalogus. In een horeca-setting is dat doorgaans de ERP — daar zit de inkoop, de receptuur, de calculatie. De POS leest de productlijst éénrichting uit de ERP. Wijzigingen aan prijzen, namen of beschikbaarheid gebeuren in de ERP en zijn binnen seconden in de POS zichtbaar. Geen dubbele invoer.
Veel horecabedrijven willen voorraadafboeking real-time per item: een burger verkocht = drie items afgeboekt (broodje, vlees, kaas). In theorie ideaal, in praktijk een onderhoudsmonster. Recepten veranderen, leveranciers wisselen, portiegrootte schommelt. Per maand zijn er tientallen aanpassingen aan recepten, en als die niet bijgehouden worden, gaat de voorraadlogica binnen weken stuk.
De fix: begin grof. Boek de inkoopkosten per categorie af tegen de verkochte omzet per categorie. Voor de meeste horecabedrijven is een marge-rapport per productgroep waardevoller dan een fictief-precies item-voor-item rapport. Naarmate de organisatie volwassener wordt, kun je verfijnen. Maar begin met iets dat onderhoudbaar is.
Een POS levert orders op (eten gemaakt, geserveerd) en betalingen (pin, contant, online). Te vaak wordt alleen de orderstroom naar de ERP gestuurd en de betaalstroom blijft in de POS-rapportage. Resultaat: de boekhouding kent de omzet wel maar niet de cashflow, of andersom. Aan het einde van de maand is de afstemming tussen kasregistratie en grootboek pijnlijk.
De fix: koppel beide stromen door. Elke order krijgt een betaalstatus, en de betalingen lopen via een zichtbaar kanaal naar de boekhouding (pinprovider-export, bankkoppeling, contant via dagstaat). De ERP weet zowel wat er verkocht is als wat er ontvangen is, en kan automatisch flag'en wanneer er een gap is.
Een veelgehoorde belofte: «de POS synchroniseert ’s nachts naar de ERP». Klinkt onschuldig, maar het betekent dat je gedurende de dag geen actuele rapporten hebt, en als de batch ’s nachts faalt, mist de hele dag in de boekhouding. Bovendien: als er fouten zijn (een product dat de POS kent maar de ERP niet), worden ze pas de volgende dag zichtbaar.
De fix: real-time of bijna-real-time synchronisatie. Een verkoop in de POS landt binnen seconden in de ERP. Fouten worden direct gemeld zodat ze gecorrigeerd kunnen worden vóór ze zich opstapelen. Dit vereist een meer doordachte integratie-architectuur dan een nachtelijke batch, maar betaalt zich uit op elke afsluiting.
Wat gebeurt er als de internetverbinding wegvalt? Veel POS-implementaties hebben geen duidelijke fallback. De medewerker weet niet of orders nog landen, en of orders die wel zijn opgenomen later alsnog worden verstuurd. In horeca, waar piek-uren onverbiddelijk zijn, is dit een operationele crisis die niet op de software-architectuur niveau is opgelost.
De fix: een POS die offline kan werken (lokale buffer) en bij herverbinding automatisch sync't. Plus duidelijke procedures: wat doet de medewerker, wie wordt gebeld, hoe wordt later gecontroleerd dat alles is doorgekomen. Dit is geen technisch probleem — het is een operationeel proces dat de techniek moet ondersteunen.
Voor je een POS-ERP-integratie laat bouwen, beantwoord deze vragen schriftelijk:
1. Welk systeem is master voor producten? Voor klanten? Voor prijzen?
2. Hoe fijnmazig wordt voorraad afgeboekt — per item, per categorie, of niet automatisch?
3. Hoe lopen betalingen mee in de integratie? Hoe stem je kassageld af?
4. Real-time of batch? Wat is de SLA voor synchronisatie?
5. Wat is de offline-modus en wie is verantwoordelijk voor recovery na een uitval?
Een leverancier die op deze vragen direct antwoord heeft, weet wat hij doet. Een leverancier die deze vragen ontwijkt of pas in fase-3 oppakt, geeft de organisatie een operationeel risico cadeau.
Atlas implementeert POS-ERP-koppelingen op deze wijze: ERP als product- en prijs-master, voorraadafboeking op categorie-niveau (verfijnen kan later), real-time order- en betaalstroom, lokale buffer met automatische sync, expliciete dagsluiting-procedure. Dit zijn keuzes die in de eerste twee weken van een implementatie gemaakt moeten worden — niet ontdekt worden in maand zes.
Plan een intake als je voor een POS-vervanging staat en wilt voorkomen dat je in deze valkuilen stapt.