--- title: "Een herhaalde import mag niet dubbel herinneren: duplicaten testen" canonical: https://www.billabex.com/nl/blog/import-herhalen-dubbele-herinneringen-voorkomen/ lang: nl alternate: https://www.billabex.com/fr/blog/import-rejoue-doublons-relances.md alternates: fr: https://www.billabex.com/fr/blog/import-rejoue-doublons-relances.md en: https://www.billabex.com/en/blog/replayed-import-duplicate-reminders.md de: https://www.billabex.com/de/blog/wiederholter-import-doppelte-mahnungen.md es: https://www.billabex.com/es/blog/importacion-repetida-no-debe-duplicar-recordatorios-probar-duplicados.md it: https://www.billabex.com/it/blog/importazione-ripetuta-evitare-solleciti-duplicati.md nl: https://www.billabex.com/nl/blog/import-herhalen-dubbele-herinneringen-voorkomen.md pl: https://www.billabex.com/pl/blog/ponowny-import-unikaj-podwojnych-przypomnien.md pt: https://www.billabex.com/pt/blog/importacao-repetida-duplicados-lembretes.md updated: 2026-10-24 index: https://www.billabex.com/llms.txt --- # Een herhaalde import mag niet dubbel herinneren: duplicaten testen De boekhoudsynchronisatie valt uit. De ondersteuning stelt voor de laatste import opnieuw uit te voeren en bevestigt daarna dat de facturen weer zichtbaar zijn. Een uur later ontvangen verschillende klanten een tweede, identieke betalingsherinnering. Toch is het aantal facturen in de software niet toegenomen. Dit incident laat twee afzonderlijke vraagstukken zien: eerder ontvangen gegevens herkennen en een al uitgevoerde actie herkennen. Software kan dubbele dossiers voorkomen en toch een bericht herhalen. Wie een koppeling voor debiteurenbeheer beoordeelt, moet daarom door testen tot het resultaat dat de klant daadwerkelijk ziet, in een omgeving die voor zulke proeven is ingericht. ## Bepaal wat herhalen zonder extra effect betekent Technische teams spreken van idempotentie wanneer een herhaling van dezelfde bewerking geen nieuw bedrijfseffect veroorzaakt. Vertaal dat principe naar uw situatie: één factuur blijft één factuur, een betaling telt niet tweemaal mee en hetzelfde besluit om een herinnering te sturen veroorzaakt niet meerdere verzendingen. AWS legt uit dat twee verzoeken die er identiek uitzien toch twee verschillende bedoelingen kunnen hebben. De technische bibliotheek adviseert om die bedoeling herkenbaar te maken, in plaats van een duplicaat altijd uitsluitend uit de inhoud af te leiden. Bron: AWS Builders’ Library, veilig herhalen met idempotente API’s. In debiteurenbeheer voorkomt dit ook een andere fout: een latere, legitieme herinnering ten onrechte blokkeren omdat de tekst op een eerder bericht lijkt. De test moet onderscheid maken tussen herhaling van dezelfde actie en een nieuwe, toegestane actie op een andere datum. Het uitgangspunt is niet dat een klant nooit meer mag worden benaderd. ## Houd de identiteit stabiel, ongeacht de bestandsnaam Een bestand hernoemen maakt geen nieuwe facturen. De volgorde van de regels wijzigen evenmin. Om een document te herkennen, moet het systeem de herkomst en de identificatie binnen de juiste afbakening terugvinden, waaronder de uitgevende onderneming. Alleen het zichtbare factuurnummer vergelijken kan tot verwarring tussen twee rechtspersonen leiden. Odoo 18 beschrijft het gebruik van constante externe identificaties om bestaande records via import bij te werken. De documentatie waarschuwt dat een verwijderde of gewijzigde identificatie dubbele records kan veroorzaken. Deze importregel illustreert het belang van een blijvende identiteit, maar bewijst niet hoe een andere koppeling zich gedraagt. Bron: Odoo 18, gegevens importeren en bijwerken. Bereid daarom een identieke versie van het bestand voor, een versie met een andere naam en een versie waarin de regels anders zijn gesorteerd. Het verwachte resultaat moet gelijk blijven. Het onderscheid tussen [factuurnummer en rechtspersoon](https://www.billabex.com/nl/blog/facturen-zelfde-nummer-entiteiten-controleren/) helpt u de referenties te kiezen waarmee deze controle betrouwbaar wordt. ## Maak een voorbeeld waarin totalen het probleem niet verhullen Neem een simulatie met tien klanten en veertig facturen van € 2.000, samen aanvankelijk € 80.000 openstaand. De import wordt driemaal aangeleverd. Over die leveringen worden dus 120 regels verwerkt, maar het blijven veertig werkelijke facturen en tien klanten. Een openstaand bedrag van € 240.000 zou op een duidelijke duplicatie van gegevens wijzen. Alleen controleren of er € 80.000 staat, is niet voldoende. De software kan tachtig extra facturen hebben aangemaakt en deze vervolgens buiten het getoonde totaal houden. Vraag om het aantal actieve documenten, hun referenties en hun koppelingen met gesprekken. Een herhaalde importregistratie is normaal; een tweede schuld voor hetzelfde document is dat niet. Kies voor een afzonderlijke testreeks zes van deze klanten met elk twee facturen van € 2.000. Dat zijn twaalf facturen voor € 24.000. De testregel bepaalt één gebundeld bericht per klant voor ditzelfde besluit: zes verwachte berichten, niet twaalf. Deze bundeling is een testaanname en geen universele regel voor het ritme van betalingsherinneringen. Als dezelfde import driemaal wordt herhaald en voor deze ene reeks achttien berichten worden verzonden, zijn er twaalf extra verzendingen. Het aantal berichten is verdrievoudigd, ook als de facturen en het saldo nog kloppen. Het testverslag moet die afwijking bij de communicatie benoemen en niet alleen melden dat de import geen dubbele records heeft opgeleverd. ## Test hervatting na een onzekere uitkomst Het meest leerzame geval ontstaat wanneer de dienst de bewerking wel heeft uitgevoerd, maar de bevestiging de aanvrager niet heeft bereikt. Een herhaling kan dan een eerder geslaagde actie opnieuw uitvoeren. Vraag een gecontroleerde demonstratie van deze situatie met testontvangers en verzendingen die gescheiden blijven van de productieomgeving. Stripe beschrijft automatische herleveringen van gebeurtenissen die in de live-modus tot drie dagen kunnen doorgaan. Het vermeldt ook dat gebeurtenissen meerdere keren en in een andere volgorde dan hun ontstaan kunnen aankomen. Dit laat zien waarom een koppeling rekening moet houden met herhalingen; het beschrijft niet uw herinneringsritme. Bron: Stripe, levering van gebeurtenissen en duplicaten. Maak in het testverslag onderscheid tussen een poging, een door de verzenddienst geaccepteerde actie en een bekende uitkomst. Ontbreekt de bevestiging, dan moet het systeem die onzekerheid zichtbaar maken en oplossen vóór een herhaling die de klant kan bereiken. Een regel met ‘fout’ bewijst niet dat er niets is verzonden. ## Controleer dat oude gegevens een betaalde factuur niet heropenen Neem opnieuw de zes klanten uit de gesimuleerde testreeks. Vóór verzending betaalt één van hen zijn twee facturen, samen € 4.000. De betaling is gecontroleerd en toegewezen. Voor deze reeks blijven dan vijf klanten, tien facturen en € 20.000 over waarvoor een herinnering relevant kan zijn. Importeer vervolgens opnieuw de oude export die nog € 24.000 toonde. Het dossier moet het effect van de recente betaling behouden of om een expliciete oplossing van het gegevensconflict vragen. Een oude import is geen nieuw bewijs van wanbetaling. De regel ‘de laatst ontvangen informatie wint’ kan de feitelijke volgorde van gebeurtenissen juist omkeren. Dit scenario sluit aan op [facturen die na een herinnering zijn gewijzigd](https://www.billabex.com/nl/blog/factuur-gewijzigd-na-herinnering-versies-bewaren/). In beide gevallen zijn de ontvangstdatum van informatie en de datum van de beschreven gebeurtenis niet onderling uitwisselbaar. Bekijk in de test ook de berichten die al vóór ontvangst van de betaling waren voorbereid. ## Neem ook een nieuwe, legitieme actie mee in de controle Een te brede beveiliging kan het duplicaat én alle volgende herinneringen onderdrukken. Voeg daarom een scenario toe waarin na beoordeling van het dossier werkelijk een nieuwe actie wordt besloten. Deze moet te onderscheiden zijn van de eerdere herhaling, met inachtneming van de betalingen, antwoorden en afspraken die sindsdien zijn binnengekomen. AWS benadrukt ook dat de periode waarin een verzoek herkenbaar blijft, afhangt van de dienst en het bijbehorende contract. Vraag tot hoever terug een herhaling wordt ondersteund en wat er daarna gebeurt. Een geslaagde test na vijf minuten bewijst niet automatisch dat het gedrag na meerdere dagen hetzelfde zal zijn. ## Vraag om bewijs dat het financiële team kan nalezen Een bruikbaar testresultaat bevat de gebruikte bestanden, de verwachte bedragen, de teruggevonden documenten en de werkelijk geproduceerde berichten. Het [logboek van betalingsherinneringen](https://www.billabex.com/nl/blog/herinneringslogboek-sporen-voor-automatisering/) helpt deze gegevens bijeen te brengen zonder technische tussenstappen te verwarren met communicatie die de klant heeft bereikt. Beoordeel de [integraties van Billabex](https://www.billabex.com/nl/product/integraties/) met deze hervattingsscenario’s om uw eigen proces te toetsen. Laat de waarneembare resultaten en de grenzen van de betreffende connector toelichten. Een belofte van betrouwbaarheid vervangt geen controle van drie zaken: hetzelfde dossier, het juiste actuele saldo en uitsluitend de actie waarvoor daadwerkelijk toestemming bestaat. ## Bronnen - AWS Builders’ Library, Making retries safe with idempotent APIs. - Odoo 18, Export and import data, identificaties en opnieuw importeren. - Stripe, Receive Stripe events, levering en duplicaten. Bronnen geraadpleegd op 7 september 2026.