De 20% uitzonderingen die 80% van je automatisering breekt

Door Clen Mourik

Je koppeling draait, geeft geen foutmelding, maar verwerkt bepaalde orders gewoon niet. Niemand merkt het — tot een klant belt of de boekhouder de cijfers niet sluitend krijgt. Waarom breekt jouw automatisering juist op die ene afwijkende BTW-code, die dubbele artikelcode, of die leverancier met een apostrof in de naam?

Hoeveel uur per week besteed je aan het handmatig oplossen van 'uitzonderingen'? Orders die net iets anders zijn. Facturen met een afwijkend formaat. Klanten zonder postcode. Werkbonnen met overuren op een feestdag. Je hebt een koppeling gebouwd tussen je systemen, de flow draait — maar bij elke afwijking crasht het. En die afwijkingen? Die zijn er vaker dan je denkt.

Wat ik in de praktijk zie: de meeste automatiseringsprojecten in het MKB werken prima voor 80% van de gevallen. Het zijn die andere 20% — de uitzonderingen, de randgevallen, de 'edge cases' — die 80% van de problemen veroorzaken. En vaak worden die problemen pas opgemerkt als het al weken mis is gegaan.

Dit artikel gaat niet over waarom automatisering goed is. Dat weet je wel. Het gaat over waarom jouw automatisering wél breekt terwijl die van een ander niet breekt. En belangrijker: hoe je dat voorkomt.

Inhoudsopgave

• Belangrijkste punten
• Waarom uitzonderingen je koppeling breken
• De stille faalmodus: het gevaarlijkste scenario
• Concrete voorbeelden uit de praktijk
• Technische oorzaken die je moet kennen
• Fouten die bijna iedereen maakt
• Hoe bouw je robuuste koppelingen
• Wanneer wel automatiseren en wanneer niet
• Veelgestelde vragen

Belangrijkste punten

Waarom uitzonderingen je koppeling breken

De standaard flow werkt. Je webshop stuurt een order naar je ERP. Je urenregistratie synchroniseert met je salarisadministratie. Je inkooporders worden automatisch naar leveranciers gestuurd. Totdat er een afwijking is.

Een buitenlandse klant plaatst een order met een BTW-nummer dat een ander formaat heeft. Een medewerker werkt op twee projecten op dezelfde dag. Een leverancier heeft een minimale afnamehoeveelheid die afwijkt van je standaard bestelpunt. En dan crasht alles.

Waarom? Omdat de meeste koppelingen gebouwd worden voor het standaard scenario. We testen met een perfecte testorder: Nederlandse klant, geldig BTW-nummer, standaard product, normale levertijd. Dat werkt. En dan gaat het live.

De technische koppeling is zelden het lastigste deel. De meeste problemen ontstaan op de randen van het proces — afwijkende klantafspraken, incomplete brondata, uitzonderingen in prijslogica.

Volgens Chef Data geldt in de praktijk: automatiseer de 80% die standaard is, en laat de 20% uitzonderingen bij een mens. Een flow die stilletjes faalt zonder dat iemand het merkt, is erger dan geen automatisering.

Het probleem: die 20% uitzonderingen zijn geen uitzondering. Bij een groothandel met 200 orders per dag zijn 40 orders afwijkend. Bij een bouwbedrijf met 50 medewerkers hebben er 10 bijzondere regelingen (overuren, feestdagen, meerdere projecten). Bij een productiebedrijf zijn 20% van de inkooporders net iets anders.

Het verschil tussen een koppeling die werkt en een die breekt

Een koppeling die werkt heeft een plan voor afwijkingen. Een koppeling die breekt heeft dat niet.

Simpel voorbeeld: je koppelt je webshop aan Exact Online. Een order komt binnen zonder postcode (internationale klant, afhaalpunt). Een standaard koppeling crasht — postcode is een verplicht veld. Een goede koppeling plaatst die order in een exception queue met de melding 'postcode ontbreekt' en stuurt een notificatie naar de verantwoordelijke medewerker.

Het verschil tussen de twee? De eerste denkt alleen aan het standaard scenario. De tweede denkt na over wat er mis kan gaan.

De stille faalmodus: het gevaarlijkste scenario

Er zijn twee manieren waarop een automatisering kan falen. De ene is irritant. De andere is rampzalig.

Scenario 1: De flow crasht met foutmelding
Je krijgt een melding. De order is niet verwerkt. Je lost het handmatig op. Vervelend, maar je weet ervan.

Scenario 2: De flow draait, maar verwerkt sommige zaken gewoon niet
Geen foutmelding. De flow lijkt te werken. Maar bepaalde orders verdwijnen in het niets. Facturen worden niet geboekt. Niemand merkt het — tot een klant belt drie weken later: waar blijft mijn bestelling?

Die tweede situatie is wat ik de stille faalmodus noem. En het komt vaker voor dan je denkt.

Een flow die stilletjes faalt zonder melding is erger dan geen automatisering. Je denkt dat het werkt terwijl je klanten zitten te wachten.

Hoe ontstaat dit? Simpel: de koppeling heeft geen check of de data daadwerkelijk verwerkt is. De flow runt, geeft geen error, maar slaat bepaalde records gewoon over omdat ze niet aan de voorwaarden voldoen.

Voorbeeld uit de praktijk: een koppeling tussen een planningsapp en AFAS voor een bouwbedrijf. De koppeling werkt perfect voor vaste medewerkers op standaard diensten. Maar zodra een medewerker overuren heeft of op een feestdag werkt, weet de automatisering niet welk tarief te gebruiken. Resultaat: die uren worden niet doorgezet. Geen foutmelding. De medewerker merkt het pas bij de salarisstrook.

Hoe voorkom je dit?

Bouw altijd een 'heartbeat' in: een verificatie die controleert of de flow niet alleen gedraaid heeft, maar ook daadwerkelijk data heeft verwerkt. Als er 50 nieuwe orders zijn maar de flow heeft er maar 35 verwerkt, moet er een alarm afgaan.

En nog belangrijker: bouw een exception queue. Alles wat de automatisering niet kan verwerken, komt in een apart overzicht terecht met de reden van falen. Een medewerker checkt dit dagelijks in een vaste routine van 30 minuten.

Concrete voorbeelden uit de praktijk

Laten we concreet worden. Hieronder drie situaties uit echte projecten waar uitzonderingen de automatisering braken.

Groothandel: order-uitzonderingen

Een technische groothandel met 30 medewerkers koppelt hun webshop aan Exact Online. Standaard orders? Werken perfect. Maar dan:

• Een buitenlandse B2B-klant plaatst een order met een BTW-nummer in een ander formaat dan Nederlandse nummers
• Een klant vraagt om deellevering (50 stuks nu, 50 stuks volgende week)
• Een artikel staat als 'uitverkocht' in de webshop maar ligt nog wel op voorraad in een tweede magazijn

Al deze orders landen als foutmeldingen in de integratielog — die niemand dagelijks leest. Resultaat: klanten krijgen geen bevestiging, bestellingen blijven hangen, frustratie aan beide kanten.

De oplossing: een exception dashboard gebouwd. Elke ochtend om 9 uur checkt een medewerker welke orders de afgelopen 24 uur niet automatisch verwerkt zijn. Gemiddelde tijd: 30 minuten. Probleem opgelost.

Bouwbedrijf: urenregistratie met tariefuitzonderingen

Een bouwbedrijf gebruikt AFAS voor HR en salaris, met een planningsapp voor werkbonnen. De koppeling werkt voor 80% van de gevallen. De andere 20%:

• Medewerker werkt overuren (ander tarief)
• Medewerker werkt op feestdag (150% tarief)
• Medewerker staat op twee projecten op één dag (systeem weet niet welke uren waar horen)

In al deze gevallen wist de automatisering niet welk tarief te gebruiken. De koppeling sloeg dan óf de verkeerde uren over, óf verdubbelde regels. Pas bij de maandelijkse salariscontrole vielen de fouten op.

De oplossing: AFAS als enig leidend systeem voor tarieven. De planningsapp mag alleen werkuren aanleveren, nooit tariefinformatie overschrijven. Uitzonderingen (overuren, feestdagen) worden vooraf in AFAS geconfigureerd met de juiste tariefregels.

Productiebedrijf: inkooporders met afwijkende hoeveelheden

Een metaalbewerkingsbedrijf automatiseert inkooporders: zodra een artikel onder de minimumvoorraad komt, wordt automatisch een order naar de leverancier gestuurd. Klinkt slim. Totdat:

• Een leverancier heeft een minimale afnamehoeveelheid van 100 stuks, terwijl het bestelpunt op 50 staat
• Een artikel is seizoensgebonden — de drempelwaarden kloppen niet in de zomer
• Een nieuwe medewerker voert hetzelfde artikel in onder een andere productcode — nu bestaan twee records

De automatisering bestelt dan óf te weinig (wordt geweigerd door leverancier), óf dubbel (omdat het systeem twee verschillende artikelen 'ziet').

De oplossing: maandelijkse controle op artikelen die vaker dan 3x een uitzondering genereerden. Dat signaal betekent: de basislogica klopt niet, pas de drempelwaarden of productcodes aan.

Meer praktijkvoorbeelden van vergelijkbare koppelingen vind je op onze pagina integratie-combinaties, waar we ruim 3300 systeem-scenario's beschrijven.

Technische oorzaken die je moet kennen

Laten we even technisch worden. Niet omdat het leuk is, maar omdat je dit moet weten om te begrijpen waarom jouw koppeling breekt.

Volgens EPLAN ligt de grootste oorzaak van mislukte automatiseringsprojecten niet bij de software, maar bij inconsistente stamdata. Wanneer artikelen dubbel bestaan, revisies niet synchroon lopen of coderingen per afdeling anders worden gebruikt, raakt de basis al scheef voordat er überhaupt geautomatiseerd wordt.

De meest voorkomende technische valkuilen

Even concreet: bij een klant synchroniseerden we klantgegevens tussen een CRM en een boekhoudsysteem. Alles werkte, tot een klant zijn bedrijfsnaam wijzigde naar 'Café De Zon & Maan'. Die apostrof en ampersand? De API van het boekhoudsysteem weigerde die. De koppeling crashte. Geen enkele testcase had een apostrof in de naam gehad.

Het probleem van realtime synchronisatie

Realtime klinkt aantrekkelijk. Elke wijziging direct gesynchroniseerd. Maar realtime synchronisatie is ook het meest kwetsbaar voor uitzonderingen.

Waarom? Omdat elke microseconde-verstoring een uitzondering kan genereren. Netwerkprobleem? Crash. Andere systeem tijdelijk offline? Crash. API rate limit bereikt? Crash.

Vaak is een geplande synchronisatie (elk kwartier, elk uur) stabieler. Je verwerkt data in batches, kunt fouten beter afvangen, en een tijdelijke storing van 5 minuten legt de hele operatie niet plat.

Simpele vuistregel: gebruik realtime alleen als het echt moet (voorraad bij een webshop met hoge omzet). Voor administratieve processen is elk uur of zelfs eens per dag vaak genoeg.

Fouten die bijna iedereen maakt

Na tientallen implementaties zie je patronen. Dezelfde fouten komen steeds terug. Hier zijn de zes grootste.

Fout 1: Geen leidend systeem aanwijzen

De grootste fout volgens Acertus-IT: bouwen zonder te kiezen welk systeem leidend is per datatype. Zonder die keuze automatiseer je verwarring.

Wat gebeurt er? Als zowel je webshop als je ERP klantgegevens mogen overschrijven, ontstaan conflicten zodra een klant zijn adres op beide plekken wijzigt. Welke versie wint? De koppeling weet het niet en kiest willekeurig — of crasht.

Oplossing: maak een matrix. Klantgegevens: leidend in CRM. Productgegevens: leidend in ERP. Voorraad: leidend in magazijnsysteem. En communiceer dit naar je team — anders gaan mensen handmatig wijzigingen aanbrengen in het verkeerde systeem.

Fout 2: Te complex beginnen

Een flow met 50 beslissingen is onbeheersbaar. Veel MKB-bedrijven proberen bij de eerste implementatie álle uitzonderingen ook al te automatiseren. Dat leidt tot spaghetti-logica die niemand meer begrijpt.

Beter: begin met de 80% standaard gevallen. Laat de 20% uitzonderingen handmatig verwerken via een exception queue. Na drie maanden kijk je: welke uitzonderingen komen het vaakst voor? Die automatiseer je dan in fase 2.

Fout 3: Bouwen voor de standaard, vergeten te testen op uitzonderingen

Testscenario's bevatten de meest voorkomende use case. Maar vrijwel nooit: een klant zonder postcode, een order met 0 stuks, een leveranciersnaam met apostrof, een datum in Amerikaans formaat.

Juist deze randgevallen breken de koppeling in productie. Oplossing: bouw een testset met bewust gekke data. Speciale tekens. Lege velden. Afwijkende formaten. Test daar expliciet op.

Fout 4: Geen monitoring na oplevering

Je koppeling werkt. Je gaat live. En dan? Vaak: niets. Geen monitoring, geen controle, geen updates.

Probleem: softwareleveranciers brengen updates uit. Een veldnaam verandert, een API-endpoint wordt verplaatst, een authenticatiemethode vervalt. Zonder monitoring ontdek je dit pas als de flow al dagen stil ligt.

Oplossing: stel alerts in. Als er 24 uur geen data gesynchroniseerd is terwijl dat wel zou moeten, krijg je een melding. Check maandelijks de integratielog op nieuwe foutmeldingen.

Fout 5: Geen eigenaar van de koppeling

Wie is verantwoordelijk voor de koppeling? Vaak: niemand expliciet. IT denkt dat de afdeling het checkt. De afdeling denkt dat IT het monitort. Resultaat: niemand kijkt naar de exception queue.

Oplossing: wijs een eigenaar aan. Iemand die wekelijks (of dagelijks, afhankelijk van volume) de exceptions checkt en trends signaleert.

Fout 6: Integreren zonder proces eerst op te schonen

Je hebt dubbele artikelcodes. Inconsistente BTW-nummers. Klanten die drie keer voorkomen onder verschillende schrijfwijzen. En dan ga je automatiseren.

Wat gebeurt er? Je automatiseert de rommel. De koppeling verspreidt de fouten alleen maar sneller door je systemen heen.

Oplossing: ruim eerst je stamdata op. Merge dubbele records. Standaardiseer schrijfwijzen. Check je data voordat je integreert.

Hoe bouw je robuuste koppelingen

Nu de problemen duidelijk zijn: hoe doe je het dan wél goed?

Stap 1: Begin met de 80%

Automatiseer eerst de standaard gevallen. Perfecte orders. Standaard medewerkers. Normale inkooporders. Laat de uitzonderingen voorlopig handmatig.

Dit geeft je drie voordelen: je koppeling blijft simpel, je leert welke uitzonderingen vaak voorkomen, en je hebt snel resultaat.

Stap 2: Bouw een exception queue

Alles wat niet automatisch verwerkt kan worden, komt in een apart overzicht. Met de reden waarom het niet kon (veld ontbreekt, format klopt niet, waarde voldoet niet aan regel).

Een medewerker verwerkt dit dagelijks. In het begin kost dat misschien een uur. Na een maand: 30 minuten. Na drie maanden: 15 minuten, omdat je de vaakst voorkomende uitzonderingen inmiddels geautomatiseerd hebt.

Stap 3: Monitor en optimaliseer

Elke maand kijk je: welke uitzonderingen kwamen het vaakst voor? Als een bepaald type uitzondering meer dan 10 keer per maand voorkomt, is het geen uitzondering meer — dan moet de basislogica aangepast worden.

Voorbeeld: als 15% van je orders een afwijkend BTW-tarief heeft, bouw dan logica die dat tarief automatisch herkent in plaats van elke keer handmatig in te grijpen.

Stap 4: Test met gekke data

Bouw een testset met bewust rare gevallen:

• Klant met apostrof in de naam (O'Brien)
• Artikel met 0 stuks besteld
• Factuur zonder BTW-nummer (particuliere verkoop)
• Order met drie verschillende leveradressen
• Medewerker met twee contracten (part-time + ZZP)

Test daar expliciet op voordat je live gaat. Die rare gevallen komen altijd voor in de praktijk.

Stap 5: Documenteer je keuzes

Welk systeem is leidend voor welke data? Hoe gaan we om met uitzonderingen? Wie is verantwoordelijk voor de exception queue?

Schrijf het op. Niet in een 50-pagina document dat niemand leest, maar in een simpele tabel die iedereen begrijpt.

Wil je meer weten over welke systemen we koppelen en hoe we dat aanpakken? Bekijk ons overzicht van 176+ systeemintegraties voor het MKB.

Wanneer wel automatiseren en wanneer niet

Niet alles moet geautomatiseerd worden. Soms is handmatig gewoon slimmer.

Automatiseer als:

• Je hetzelfde proces meer dan 50 keer per maand doet
• De stappen duidelijk en gestandaardiseerd zijn
• Fouten kostbaar of tijdrovend zijn om te herstellen
• Het proces geen menselijke beoordeling vereist

Voorbeeld: facturen van leveranciers verwerken. Bij 50+ facturen per maand kost handmatige verwerking volgens Pailot al snel 4-8 uur per week. Dat is automatisering waard.

Blijf handmatig als:

• Het proces minder dan 20 keer per maand voorkomt
• Elke keer menselijke beoordeling nodig is
• De uitzonderingen meer tijd kosten dan het standaard proces
• De data te ongestructureerd of wisselend is

Voorbeeld: offertes maken. Elke offerte is maatwerk, vereist overleg met de klant, pricing is situatie-afhankelijk. Zelfs met templates blijft dit grotendeels handwerk.

Het grijze gebied: hybride aanpak

Veel processen zitten ertussenin. Automatiseer dan het standaard deel en laat de beoordeling bij een mens.

Voorbeeld: inkomende e-mails categoriseren en doorsturen. AI kan 80% correct indelen. De andere 20% komt in een 'onzeker' wachtrij waar een mens dagelijks doorheen gaat. Kost 15 minuten in plaats van een uur alle mails handmatig verwerken.

Voor meer inspiratie over welke processen zich lenen voor automatisering per branche, bekijk onze branche-specifieke oplossingen.

Veelgestelde vragen

Wat zijn edge cases in procesautomatisering?

Edge cases zijn afwijkende situaties die niet voldoen aan de standaard aannames van je automatisering. Denk aan een klant zonder postcode, een order met 0 stuks, of een factuur met een afwijkend BTW-tarief. Ze komen vaker voor dan je denkt en breken vaak de automatisering als je er niet op anticipeert.

Hoeveel kosten uitzonderingen die handmatig afgehandeld moeten worden?

Simpele berekening: stel je automatisering verwerkt 95% foutloos, maar 5% vereist handmatige interventie van 15 minuten per geval. Bij 200 orders per dag zijn dat 10 uitzonderingen × 15 minuten = 2,5 uur handwerk per dag = 12,5 uur per week. Dat is een halve FTE die je dacht te hebben bespaard.

Waarom faalt mijn ERP-integratie bij grenssituaties?

Meestal omdat de integratie alleen getest is met perfecte testdata. Een standaard klant, standaard product, standaard order. In productie kom je klanten tegen met apostrofs in de naam, producten met seizoensprijzen, orders met deelleveringen. Als de koppeling daar niet op gebouwd is, crasht hij.

Hoe zorg ik dat mijn systeemintegratie niet breekt?

Drie dingen: (1) Bouw een exception queue voor alles wat niet automatisch verwerkt kan worden. (2) Test expliciet met rare data — speciale tekens, lege velden, afwijkende formaten. (3) Monitor actief: als er 24 uur geen data gesynchroniseerd is, moet er een alarm afgaan.

Wat kost het om een koppeling te laten bouwen die robuust is?

Volgens Schmeits ligt een eenvoudige koppeling vanaf €2.500, complexe integraties tussen €5.000-€15.000. De doorlooptijd is 3-6 weken afhankelijk van de kwaliteit van de API en complexiteit van datastromen. Reken ook op €400-€800 per maand aan onderhoud voor monitoring en updates.

Welk systeem moet leidend zijn bij integraties?

Dat hangt af van het datatype. Algemene regel: klantgegevens leidend in je CRM, productgegevens leidend in je ERP, voorraad leidend in je magazijnsysteem, financiële data leidend in je boekhouding. Maak een matrix en communiceer dit helder naar je team — anders gaan mensen handmatig wijzigingen doorvoeren in het verkeerde systeem.

Hoe vaak moet ik mijn integratie controleren?

Dagelijks als je hoge volumes hebt (100+ transacties per dag). Wekelijks bij normale volumes. En altijd direct na een update van een van de gekoppelde systemen. Softwareleveranciers wijzigen API's regelmatig zonder grote aankondiging — zonder monitoring ontdek je dit pas als het al dagen mis is.

Stop met vechten tegen uitzonderingen, bouw er een plan voor

Even eerlijk: de meeste automatiseringen breken niet omdat de techniek slecht is. Ze breken omdat we vergeten na te denken over wat er mis kan gaan.

Die 20% uitzonderingen? Die zijn geen uitzondering. Het zijn signalen dat je proces rijker is dan je dacht. Een klant die een afwijkende vraag heeft. Een leverancier met andere afspraken. Een medewerker met een bijzondere situatie.

De oplossing is niet alles proberen te automatiseren. De oplossing is een systeem bouwen dat weet wat het niet kan, en daar netjes mee omgaat. Een exception queue. Een dagelijkse controle. Een maandelijkse evaluatie van welke uitzonderingen vaker voorkomen.

En dan, langzaam, automatiseer je steeds meer. Van 80% naar 85%. Van 85% naar 90%. Niet in één keer, maar stap voor stap. Met de zekerheid dat wat je automatiseert ook echt werkt.

Wil je weten hoe jouw processen zich lenen voor automatisering, inclusief een eerlijke blik op welke uitzonderingen je kunt verwachten? Plan een vrijblijvend adviesgesprek. We kijken samen naar je huidige situatie en bespreken een aanpak die past bij jouw bedrijf — niet bij een theoretisch ideaalplaatje.