Je koppeling draait weer: zo haal je de achterstand in zonder dubbelen

De koppeling draait weer. Dat was het makkelijke deel.

Wat er nu voor je ligt is drie dagen aan orders, facturen en voorraadmutaties die nergens zijn aangekomen, plus de verleiding om alles in één keer opnieuw door de pijp te duwen. Doe dat, en je grootste klant krijgt maandag twee facturen met verschillende nummers voor dezelfde levering. Deze gids is het herstelboek: hoe je het gat vaststelt, in welke volgorde je inhaalt, wat je bewust laat liggen, en hoe je aan het eind kunt bewijzen dat beide kanten weer gelijk staan.

Waarom de volgorde bepaalt of je dubbelen krijgt

Een inhaalslag is het gecontroleerd alsnog verwerken van alles wat tijdens een storing niet is doorgekomen. Je stelt eerst het venster vast, telt beide kanten op dezelfde sleutel, biedt daarna alleen de ontbrekende berichten opnieuw aan met een sleutel die dubbele verwerking blokkeert, en telt tot slot opnieuw. Het verschil met "gewoon opnieuw versturen" is dat je vooraf weet wat er precies mist.

Die volgorde is niet netjesheid, het is het hele verschil tussen een schone administratie en een week aan correcties. Drie dingen gaan mis als je hem omdraait. Bied je alles opnieuw aan zonder sleutel, dan verwerkt het doelsysteem de berichten die wél waren aangekomen voor de tweede keer. Zet je transacties vóór stamdata terug, dan verwijst een order naar een klant die nog niet bestaat en maakt je systeem er een tweede aan. En gooi je alles tegelijk naar binnen, dan loop je halverwege tegen een limiet aan en weet je niet meer wat wel en niet geland is.

Wat dit zo duur maakt is dat je geen foutmelding hebt om op terug te vallen. Een stilgevallen koppeling geeft geen foutmelding maar een leegte, en die leegte moet je achteraf reconstrueren uit twee systemen die geen van beide weten wat de ander heeft gezien. De detectiekant is een apart vak; hier ga ik ervan uit dat de storing voorbij is en dat het opruimwerk begint.

Wat je nodig hebt voordat je iets aanraakt

Voor een inhaalslag heb je geen nieuwe software nodig, wel zeven dingen die je meestal pas mist als je al bezig bent: leestoegang aan beide kanten, één sleutel die in allebei de systemen voorkomt, een plek om verwerkte sleutels vast te leggen, en de bevoegdheid om te corrigeren als het misgaat. Zet ze op tafel voordat je de eerste knop indrukt.

• Het begin- en eindmoment van de storing, met tijdzone. Niet "ergens vrijdagmiddag", maar het tijdstip van de laatste geslaagde verwerking en dat van de eerste geslaagde erna.
• Leestoegang tot beide kanten en de tussenlaag. De webhooklogs van je betaalprovider, de uitvoeringshistorie van je integratieplatform, de wachtrij en de dode brievenbus.
• Eén sleutel die aan beide kanten voorkomt. Een ordernummer, een betaalreferentie, een factuurnummer. Heb je die niet, dan is dat je eerste klus, want zonder sleutel kun je niet vergelijken en dus ook niet inhalen.
• Een tabel met verwerkte sleutels. Bron, sleutel, doel-id, tijdstip. Bestaat die niet, dan maak je hem nu, al is het een sheet: hij is straks je enige rem op dubbele verwerking.
• Een uitgang die je dicht kunt zetten. Factuurmail, verzendlabels, koerieropdrachten, klantnotificaties. Alles wat automatisch de deur uitgaat zodra er een record binnenkomt.
• De bevoegdheid om te corrigeren aan de doelkant. Crediteren, annuleren, boekingen terugdraaien, plus de afspraak wie dat mag doen.
• Een afgesproken tijdvenster waarin niemand anders repareert. Twee mensen die tegelijk hetzelfde gat dichten is de snelste route naar dubbelen.

Zo loopt een schone inhaalslag

In zeven stappen staat je administratie weer gelijk: je zet het venster vast, telt beide kanten op dezelfde sleutel, kijkt waar berichten nog liggen, herstelt eerst stamdata en dan pas transacties, biedt opnieuw aan met een idempotentiesleutel, zet de onomkeerbare gevallen op een handmatige lijst, en ruimt op wat er alsnog dubbel staat. Stap 2 bepaalt hoe klein het werk daarna wordt.

1. Zet het venster vast, ruimer dan de storing zelf

Zoek het tijdstip van de laatste geslaagde verwerking en dat van de eerste geslaagde daarna. Neem aan beide kanten een uur marge, want berichten die net over de grens liepen zijn precies de gevallen die je anders mist. Schrijf beide tijdstippen op mét tijdzone: je betaalprovider logt in UTC, je boekhouding toont Amsterdamse tijd, en in de zomer scheelt dat twee uur. Dat is geen detail, dat zijn twee uur aan orders.

Heb je een hartslag of een uitvoeringslogboek, dan staat het beginmoment daar exact in. Zo niet, dan neem je het laatste record dat in het doelsysteem is aangekomen en rond je naar beneden af.

2. Tel beide kanten voordat je iets aanraakt

Dit is de stap die de meeste mensen overslaan omdat hij saai voelt, en hij is de enige die het werk daarna klein maakt. Trek aan beide kanten de lijst met sleutels over het venster en vergelijk ze als verzamelingen, niet als aantallen. Zestig tegen zestig kan nog steeds twee ontbrekende en twee dubbele records betekenen.

Je houdt drie lijsten over, en alle drie hebben ze een eigen vervolg:

• Alleen in de bron. Dit is je inhaallijst. Hier gaat de rest van deze gids over.
• Alleen in het doel. Verdacht. Meestal is dit handmatig invoerwerk van een collega die tijdens de storing zelf is gaan redden, soms met een typefout in het ordernummer waardoor de sleutel niet matcht. Los dit eerst op, anders haal je dat record straks nog een keer in.
• Aan beide kanten. Niets doen. Deze groep is groter dan je denkt en elke aanraking is hier pure winstderving.

Shopify zegt zelf dat webhookbezorging niet gegarandeerd is en dat je periodiek data moet ophalen om in de pas te blijven, met een filter op het veld dat de laatste wijziging bijhoudt. Dat is precies de query die je hier gebruikt, alleen nu eenmalig over het storingsvenster.

Bewaar het resultaat als bestand. Het is je werklijst, en later je bewijs.

3. Inventariseer de drie plekken waar berichten kunnen liggen

Niet alles wat mist is verdwenen. Voordat je zelf begint met ophalen, kijk je op de drie plekken waar je koppeling dingen bewaart, want een bericht dat er nog staat kun je opnieuw aanbieden zonder het te reconstrueren.

De wachtrij. Berichten die nog wachten op een volgende poging. Die lopen vaak vanzelf door zodra de koppeling weer draait, dus tel ze wel mee maar haal ze niet apart op.

De dode brievenbus. Wat na alle pogingen is gestrand. Bij Amazon SQS zet je die berichten terug met redrive, maar let op de bewaartermijn: de vervaltijd telt door vanaf het moment dat het bericht oorspronkelijk in de wachtrij kwam, niet vanaf het moment dat het strandde. Bij een storing van drie dagen kan je bewijs dus eerder verdwijnen dan je denkt.

Het integratieplatform. In n8n filter je de uitvoeringen op de status Failed en draai je ze opnieuw, waarbij je kiest tussen de oorspronkelijke of de huidige versie van je workflow; heb je de fout net gerepareerd, dan wil je de huidige. In Make heet hetzelfde ding incomplete executions, met één addertje dat veel mensen op het verkeerde been zet: die opslag staat standaard uit en moet per scenario aangezet zijn. Stond hij uit, dan is er niets bewaard en val je terug op de bron.

De bron zelf. Stripe bewaart gebeurtenissen dertig dagen en laat je gericht de niet-bezorgde ophalen: de List Events API accepteert een filter op alleen mislukte bezorgingen plus een startpunt vlak voor de storing. Handmatig opnieuw versturen vanuit het dashboard kan tot vijftien dagen na de gebeurtenis. Bij Mollie werkt het anders: het overzicht van betalingen kent geen datumfilter maar alleen een cursor, dus je bladert met from en een limit van maximaal 250 terug tot je voorbij het begin van je venster bent. Staat het webhookkanaal op geblokkeerd, dan zet je het eerst weer aan in het dashboard onder Developers, anders levert Mollie ook nieuwe betalingen niet af.

4. Herstel eerst stamdata, dan pas transacties

Hier ontstaan de dubbelen die niemand ziet, want het zijn geen dubbele facturen maar dubbele klanten. Een order die verwijst naar een relatie of een artikel dat nog niet bestaat, doet één van twee dingen: hij faalt, of hij maakt zelf een nieuw record aan. Dat tweede is erger, want het faalt niet en je merkt het pas als de accountmanager twee klantkaarten met dezelfde naam vindt.

De volgorde is dus altijd dezelfde:

1. Relaties: klanten, leveranciers, contactpersonen.
2. Artikelen en prijzen: nieuwe artikelnummers, gewijzigde staffels, nieuwe btw-codes.
3. Transacties, chronologisch van oud naar nieuw.
4. Afgeleide documenten: facturen, pakbonnen, boekingen.

Chronologisch is geen esthetiek. Als de order van maandag en de annulering van dinsdag in willekeurige volgorde binnenkomen, staat de order aan het eind weer open. Systemen die zelf ontdubbelen helpen hier maar half: HubSpot herkent contacten automatisch aan het e-mailadres en bedrijven aan het domein, maar zodra iemand een order plaatst met een ander e-mailadres dan de vorige keer, is dat voor het systeem een nieuwe klant. Voor stamdata die je zelf inhaalt geldt: zoek eerst op de sleutel, maak pas aan als je niets vindt.

5. Bied opnieuw aan met een sleutel, ook als het bericht er geen had

Idempotent betekent dat dezelfde opdracht twee keer uitvoeren hetzelfde resultaat geeft als hem één keer uitvoeren. Dat je die bescherming nodig hebt is geen randgeval: dezelfde gebeurtenis kan twee keer binnenkomen zonder dat er iets stuk is, en tijdens een inhaalslag vergroot je die kans zelf. Bij Stripe geef je daarvoor een zelfgekozen sleutel van maximaal 255 tekens mee, en het systeem bewaart de uitkomst van de eerste aanroep, ook als die mislukte; komt dezelfde sleutel met andere parameters terug, dan volgt er bewust een foutmelding.

Nu de val waar bijna iedereen in trapt. Die bescherming van je leverancier helpt je bij een inhaalslag niet, want sleutels worden na ongeveer 24 uur opgeruimd en daarna wordt je verzoek als nieuw behandeld. Bij een gat van drie dagen ben je dus volledig aangewezen op je eigen administratie van wat je al verwerkt hebt. Dat is die tabel uit de vereisten, en het is niet toevallig ook de kern van het advies dat je de sleutel lokaal vastlegt vóórdat je de externe actie doet: zodra je een factuur in een ander systeem hebt aangemaakt, kun je dat niet meer terugdraaien, alleen nog corrigeren.

Voor berichten die geen sleutel hebben maak je er zelf een. Neem een combinatie die stabiel is over de hele keten: bronsysteem, objecttype en het id uit de bron, bijvoorbeeld shopify-order-1042. Verandert het object nog (een order die van status wisselt), voeg dan de laatste wijzigingsdatum toe, zodat een echte update wél doorkomt maar een herhaling niet. Pakketten als Moneybird kennen geen idempotentiesleutel op hun API, dus daar controleer je vóór het aanmaken op je eigen referentieveld: bestaat er al een factuur met dit ordernummer, dan sla je hem over.

6. Zet de uitzonderingen apart en haal ze niet automatisch in

Niet alles wat mist hoort ingehaald te worden. Zes categorieën vragen om een mens, en ze hebben allemaal dezelfde reden: het zijn stappen die je niet ongedaan kunt maken of besluiten die een script niet mag nemen. De architectuurrichtlijnen van Microsoft noemen dat de punten waarop je niet meer terug kunt, en het advies is om er expliciet een mens bij te halen zodra de impact groot of het geval dubbelzinnig is.

• Creditnota's en correctiefacturen. Een verkoopfactuur haal je niet even weg: de Belastingdienst eist dat je opeenvolgende nummers gebruikt en dat elk factuurnummer maar één keer voorkomt. Een dubbele factuur repareer je dus met een creditnota, en dat is klantcontact, geen scriptregel.
• Geannuleerde of gewijzigde orders. In je bron staat een reeks gebeurtenissen, in je doel telt alleen de eindstand. Haal de eindstand op, niet de reeks.
• Prijswijzigingen met terugwerkende kracht. Een korting die maandag telefonisch is afgesproken staat nergens in de data van vrijdag.
• Alles wat de deur uitgaat. Facturen die automatisch gemaild worden, verzendlabels, koerieropdrachten. Maak ze als concept en verstuur ze in één gecontroleerde ronde.
• Betalingen die inmiddels handmatig zijn afgeletterd. Die staan in je lijst "alleen in het doel" uit stap 2 en zijn dus al klaar.
• Alles boven een bedragsdrempel. Zet er een concreet getal op dat bij je bedrijf past, bijvoorbeeld vijfduizend euro, en laat iemand daar met de neus op kijken.

Deze lijst is geen restpost. Bij de meeste storingen is het tien tot twintig procent van het volume, en het is precies het deel waar een klant je op belt. Werk je al met een uitzonderingenwachtrij voor orders die niet automatisch door kunnen, dan zet je ze daarin en houd je één plek waar het handwerk landt.

7. Spoor dubbelen op en voeg ze samen als het toch misging

Ging het mis, dan is de eerste stap niet opruimen maar stoppen: zet de flow uit, anders ruim je op terwijl er nieuwe bijkomen. Zoek daarna binnen het herstelvenster naar records met dezelfde natuurlijke sleutel, en als die ontbreekt op de combinatie relatie, bedrag en datum. Sorteer op aanmaakmoment: dubbelen uit een inhaalslag zijn bijna altijd binnen dezelfde minuut aangemaakt.

Voor stamdata is samenvoegen meestal ingebouwd. In Moneybird open je het contact dat je wilt houden en kies je Extra, dan Contacten samenvoegen; alle documenten van beide contacten staan daarna onder het contact dat je bewaart, met de kanttekening dat documenten in een vergrendelde periode niet meeverhuizen. Exact Online heeft dezelfde functie onder de knop Ontdubbelen op de relatiekaart. Doe dit met beleid: samenvoegen is niet terug te draaien.

Voor transacties bestaat samenvoegen niet. Daar geldt de fiscale route uit stap 6: crediteren met verwijzing naar het originele factuurnummer, of de order annuleren voordat hij de productie in gaat.

Waar het alsnog misgaat

De faalmodi van een inhaalslag zijn anders dan die van een koppeling. Ze komen bijna allemaal voort uit tempo en timing, niet uit logica.

• Tijdzones en zomertijd. Je bron logt in UTC, je pakket toont lokale tijd. Fix: zet alles om naar één tijdzone voordat je vergelijkt, en gebruik altijd de tijdstempel van de bron als waarheid.
• Je loopt tegen een limiet aan. Exact Online staat per app en administratie zestig aanroepen per minuut en vijfduizend per dag toe (stand mei 2026), Moneybird throttelt op 150 aanroepen per vijf minuten per ip-adres en antwoordt daarna met een 429. Reken vooraf uit hoeveel aanroepen je inhaalslag kost: één factuur is al gauw drie of vier. Fix: doseer met een pauze tussen de batches en bouw de afhandeling van een 429 in vóór je begint.
• De uitgang stond open. Vijftig facturen die tegelijk gemaild worden, of vijftig verzendlabels bij de koerier. Fix: kanalen uit vóór stap 5, en pas aan na de eindtelling.
• Je eigen bewaking gaat af. Een inhaalslag ziet er voor je monitoring uit als een piek of juist als een tweede storing. Fix: zet de alarmering voor dat ene venster op stil, met een wekker om hem weer aan te zetten. Vergeten is een klassieker.
• Iemand repareert mee. De binnendienst tikt uit goede wil dezelfde orders over terwijl jouw script draait. Fix: het tijdvenster uit de vereisten, expliciet afgesproken.
• Je speelt gebeurtenissen na terwijl je standen wilt. Voor voorraad en prijzen is de huidige stand ophalen veiliger dan drie dagen mutaties naspelen. Welke van de twee bij je stroom hoort, bepaal je met het synchronisatiepatroon dat je hebt gekozen: bij batch-sync tel je standen, bij event-driven speel je gebeurtenissen na.

Beslis-kader: automatisch inhalen, laten naleveren of met de hand

De keuze hangt aan vier dingen: hoeveel records er ontbreken, hoe omkeerbaar de actie is, of de bron nog kan naleveren binnen zijn bewaartermijn, en of je doelsysteem een sleutel kent waarmee je dubbel werk kunt blokkeren. Dat levert vier duidelijke uitkomsten op.

Minder dan ongeveer 25 records, en onomkeerbaar. Met de hand, met de lijst uit stap 2 als werklijst. Je bent sneller klaar dan het schrijven van een script kost, en bij facturen en betalingen wil je toch elke regel zien.

Ongeveer 25 tot 500 records, en de bron kan nog naleveren. Laat de bron opnieuw sturen en laat je eigen sleuteltabel het dubbele werk vangen. Dit is de goedkoopste route, mits die tabel er echt is.

Meer dan 500 records, meerdere systemen tegelijk, of een venster ouder dan de bewaartermijn van de bron. Een eenmalig inhaalscript op je eigen data, met een droogloop eerst: laat het eerst alleen rapporteren wat het zou doen, controleer tien willekeurige regels met de hand, en draai het pas daarna echt.

Vaker dan eens per kwartaal. Dan is de inhaalslag je symptoom, niet je probleem. Kies eerst een ander synchronisatiepatroon of leg er een bewakingslaag onder, want handmatig herstel dat elke maand terugkomt is duurder dan het opnieuw ontwerpen.

Over kant-en-klaar tegenover maatwerk kan ik kort zijn: standaardconnectors zijn gebouwd voor de happy path en hebben zelden een herstelknop. Ze bezorgen prima, maar "haal alles opnieuw op tussen vrijdag 16:40 en dinsdag 09:30, sla over wat er al staat" zit er meestal niet in. Bij een keuze tussen een standaardconnector, een integratieplatform of een eigen koppeling is de vraag "wat doet dit ding als het drie dagen stil heeft gelegen" dus een reëel selectiecriterium, geen randgeval.

Hoe je per systeem de achterstand ophaalt

Elke bron heeft zijn eigen route terug en zijn eigen horizon. Dit is waar je begint met zoeken (stand augustus 2026).

Uitgewerkt voorbeeld: 63 orders over een lang weekend

Een groothandel in technische onderdelen verkoopt via Shopify, verwerkt orders in een eigen ordersysteem en factureert in Moneybird; betalingen lopen via Mollie. Op vrijdag om 16:40 valt de orderkoppeling stil na een certificaatwissel. Dinsdag om 09:30 draait hij weer.

Het venster wordt vrijdag 15:40 tot dinsdag 10:30, een uur marge aan beide kanten, alles omgerekend naar Amsterdamse tijd.

De telling. In Shopify staan 63 orders in dat venster. In het ordersysteem staan er 5, allemaal maandag met de hand ingetikt door de binnendienst na klantvragen. Dat betekent 58 ontbrekende orders, 5 aan beide kanten, en 0 die alleen in het doel staan. Bij Mollie staan 57 betalingen, waarvan er 51 nog niet zijn afgeletterd.

Stamdata eerst. In de 58 ontbrekende orders zitten 6 nieuwe klanten en 3 nieuwe artikelnummers. Die worden eerst aangemaakt. Was dat niet gebeurd, dan had de import 6 klantkaarten aangemaakt met alleen een e-mailadres, zonder btw-nummer en zonder de juiste prijsafspraak.

De uitzonderingen. Twee orders zijn maandag telefonisch geannuleerd, drie liggen boven de drempel van vijfduizend euro, en bij één klant is achteraf een andere staffelprijs afgesproken. Zes orders gaan dus naar de handmatige lijst. Blijven over: 52 orders om automatisch in te halen.

Het tempo. Elke order kost in Moneybird ongeveer vier aanroepen: contact zoeken, factuur aanmaken, regels toevoegen, status zetten. Dat is ruim 200 aanroepen, en bij 150 per vijf minuten is dat zeven à acht minuten netjes gedoseerd. De factuurmail gaat vooraf uit; de 52 facturen worden als concept aangemaakt, gecontroleerd, en daarna in één ronde verstuurd.

Wat er alsnog misging. Twee van de vijf handmatig ingevoerde orders bleken met een typefout in het ordernummer te zijn ingetikt. Daardoor matchte de sleutel niet, stonden ze in de lijst "alleen in de bron", en werden ze een tweede keer gefactureerd. Dat kostte twee creditnota's en een telefoontje. Precies daarom is de lijst "alleen in het doel" uit stap 2 geen bijvangst: had die controle op relatie plus bedrag plus datum gedraaid in plaats van alleen op ordernummer, dan waren ze eruit gerold.

De rekening. De hele operatie kostte drie en een half uur, waarvan veertig minuten daadwerkelijk inhalen. De rest was tellen, uitzoeken en de zes uitzonderingen afhandelen. De reparatie van de koppeling zelf had twintig minuten geduurd.

De telling die bewijst dat je klaar bent

Je bent niet klaar als het script groen is. Je bent klaar als je het opnieuw kunt tellen en het klopt. Draai daarom dezelfde vergelijking als in stap 2, over hetzelfde venster, en verwacht drie dingen: de lijst "alleen in de bron" is leeg, de lijst "alleen in het doel" bevat alleen records die je bewust hebt aangemaakt, en het totaal aan beide kanten is gelijk.

Herhaal die telling nog één keer 24 uur later. Nagekomen betalingen, late statuswijzigingen en de handmatige uitzonderingen landen vaak pas in die tweede ronde, en een verschil dat dan opduikt is een aanwijzing dat de koppeling nog iets mist.

Sluit af met vier controles die er samen voor zorgen dat je dit gesprek niet nog eens hoeft te voeren: de wachtrij is leeg, de dode brievenbus staat op nul, de uitgaande kanalen staan weer aan, en de bewaking die je hebt stilgezet is weer actief. Leg het venster, de drie lijsten en de genomen besluiten vast in één document. Bij de volgende accountantsvraag over een gat in de nummering is dat het enige wat je nodig hebt.

Een koppeling repareren is techniek. De achterstand inhalen is administratie, en administratie kent maar één bewijs: dezelfde telling, twee keer, met dezelfde uitkomst. Wie die telling vooraf inricht, hoeft hem achteraf alleen nog maar te herhalen.