Finance

Magento boekhouding koppelen zonder dubbele facturen

Q: Werkt dedup op order-ID ook voor Magento 1?

Ja, in Magento 1 heet het veld ook `increment_id` en is het uniek per store. De logica is identiek. Wel goed om te weten: Magento 1 wordt sinds juni 2020 niet meer ondersteund door Adobe, dus security-updates ontbreken. Een migratie naar Magento 2 is op termijn onvermijdelijk.

Finance 28 april 2026 · 6 min leestijd

Een controller die op vrijdagmiddag 14 dubbele factuurregels uit het grootboek moet pluizen, weet precies waar dit artikel over gaat. De koppeling tussen Magento 2 en je boekhoudpakket draait technisch, maar levert een omzetregel die niet klopt. En de oorzaak is bijna altijd hetzelfde: dedup op timestamp in plaats van op order-ID.

Waarom dubbele facturen ontstaan bij Magento-koppelingen

Magento genereert een order-event op het moment dat de klant afrekent. Daarna volgen invoice-events, shipment-events en eventueel credit-memo-events. Veel standaard-connectoren synchroniseren via een polling-interval — bijvoorbeeld elke 5 minuten een batch ophalen.

Gaat de sync halverwege onderuit (timeout, 502 van Magento, een herstart van de connector), dan start hij opnieuw bij het laatste timestamp. Maar het laatste timestamp is een grijs gebied: een order van 14:03:02 staat in het ene log-systeem op 14:03:02 en in het andere op 14:03:03. Resultaat: dezelfde order komt twee keer binnen.

Bij 200 orders per dag merk je dat misschien niet. Bij 2.000 orders krijg je elke maand 30 tot 80 dubbele factuurregels in je boekhouding. Een controller die de BTW-aangifte voorbereidt, wil dat niet handmatig moeten reconciliëren.

De technische oorzaak: timestamp is geen unieke sleutel

In een Magento-database is entity_id op sales_order uniek. created_at is dat niet — twee orders kunnen op dezelfde seconde binnenkomen. Connectoren die dedupliceren op (created_at, customer_email) of op tijdvenster missen dit.

Erger: bij retries (bijvoorbeeld na een netwerk-glitch) stuurt de connector dezelfde payload nogmaals door. Het boekhoudpakket ziet "nieuwe" data en maakt een tweede factuur aan. Geen duplicate-key-error, want het pakket dedupliceert intern ook niet altijd op een externe ID.

Een rekenvoorbeeld om de impact zichtbaar te maken (geen branche-gemiddelde — vul je eigen cijfers in): stel je hebt een AOV van € 85 en je koppeling produceert hypothetisch 1,5% duplicates. Op 2.000 orders/maand is dat € 2.550 aan fantoom-omzet die je dan elke maand moet corrigeren — al snel een paar uur opruimwerk en extra risico bij accountantcontrole. Hoe vaak duplicates daadwerkelijk optreden hangt sterk af van je connector-instellingen en netwerk-stabiliteit.

Order-ID als enige betrouwbare dedup-sleutel

De juiste oplossing is dedup op de Magento-increment_id (de order-nummer-string, bijvoorbeeld 100000247) of op entity_id. Beide zijn gegarandeerd uniek binnen je Magento-instance.

Een goede koppeling werkt zo:

Bij elke synchronisatie wordt de Magento-increment_id opgeslagen als externe referentie op de factuur in het boekhoudpakket.
Voor een nieuwe factuur wordt aangemaakt, controleert de connector of die increment_id al bestaat. Zo ja: skip of update, geen nieuwe regel.
Bij een retry of herstart kan de connector dus dezelfde batch opnieuw verwerken zonder dat dat duplicates oplevert. Dit heet een idempotente sync.

Concreet betekent dit: of de sync nu 1 keer of 50 keer dezelfde batch ophaalt, het eindresultaat in de boekhouding is identiek. Timestamp speelt geen rol meer.

Wat te checken bij je huidige koppeling

Voordat je een nieuwe oplossing kiest, is het zinvol je bestaande integratie door te lichten. Een korte audit:

Check	Waar kijken	Wat je wilt zien
Dedup-veld	Connector-config of vendor-docs	`increment_id` of `entity_id`, niet timestamp
Externe referentie zichtbaar	Factuurregel in boekhoudpakket	Magento-ordernummer als veld of in omschrijving
Retry-gedrag	Connector-logs	Identieke batches bij herstart leveren 0 nieuwe regels op
BTW-mapping	Per land/tarief	OSS-drempel correct gerouteerd (zie hieronder)
Credit memo's	Steekproef 5 retours	Negatieve regel gekoppeld aan originele factuur

Als je connector op één van deze punten niet door de check komt, heb je een tijdbom. Bij een belastingcontrole worden dubbele factuurregels en niet-gekoppelde retouren als eerste opgemerkt.

BTW en OSS: extra reden om dedup goed te doen

Een Magento-shop die boven de € 10.000 drempel voor afstandsverkopen binnen de EU verkoopt, moet via de One Stop Shop-regeling BTW afdragen in elk EU-land waar de afnemer zit. Dat betekent dat je per ordernummer precies wilt weten welk BTW-tarief is toegepast.

Bij dubbele facturen krijg je ook dubbele BTW-regels — die je per kwartaal moet aangeven. Een correctie achteraf via een suppletie kan, maar boven de € 1.000 grens moet die officieel worden ingediend. Voor een controller die per kwartaal aangifte doet, is dit administratieve overhead die voorkomen had kunnen worden.

Voor B2B-orders binnen de EU geldt bovendien de verlegging-regel met geldig BTW-nummer. Je connector moet VIES-validatie ondersteunen op het moment van factureren — niet bij export. Dubbele facturen met een ongeldig of niet-gevalideerd BTW-nummer leveren bij controle direct discussie op.

Wat een goede koppeling nog meer doet

Dedup op order-ID is de basis. Maar een volwassen Magento-boekhoudkoppeling lost meer op:

Credit memo's automatisch matchen aan de originele factuur, zodat je netto-omzet per klant en per maand klopt.
Verzendkosten en kortingen apart boeken op de juiste grootboekrekening, niet samengevoegd in één omzetregel.
Multi-currency correct verwerken: bedrag in EUR, conversiekoers per orderdatum, koersverschil bij betaling apart geboekt.
Betaal-providers reconciliëren: Mollie/Adyen-uitbetalingen koppelen aan de onderliggende orders, inclusief transactiekosten als aparte regel.
Voorraadwaardering synchroon houden met de inkoop-flow — daar komt de naburige module om de hoek kijken.

Vooral dat laatste punt is voor controllers relevant. Als je inkoop en voorraad in een ander systeem zitten dan je verkoop, klopt je marge per product nooit op het juiste moment. Een gekoppelde inkoop- en voorraadmodule helpt om COGS automatisch mee te laten lopen met elke Magento-order, in plaats van die per maand handmatig na te rekenen.

Eerlijk over alternatieven: gevestigde NL-pakketten als Exact Online, Moneybird, e-Boekhouden en AFAS hebben elk hun eigen Magento-aanpak — sommige met directe API-koppeling, andere via tussenliggende connectoren als Storekeeper of Combidesk. De punten in dit artikel (dedup op increment_id, idempotente sync, externe-referentie-veld) gelden voor élke koppeling die je kiest, ongeacht welk pakket erachter zit.

Hoe Cloutyx hierbij helpt

De finance-module van Cloutyx is gebouwd rond dedup op increment_id en bewaart dat ID als externe referentie op elke factuur. Een retry of herstart van de sync hoort daardoor geen duplicates op te leveren — de tweede poging vindt de eerste terug en slaat over. BTW-tarieven worden per land toegepast volgens de OSS-regels, en credit memo's worden gekoppeld aan de originele factuur.

Wil je dit principe in je eigen setup toetsen: bekijk de finance-module of neem contact op via cloutyx.com om met je eigen Magento 2 setup mee te kijken.

Conclusie

Drie dingen om morgen te doen, in volgorde:

Open je boekhoudpakket, filter op factuurdatum van de afgelopen 30 dagen, en zoek op identieke bedragen + identieke klantnamen. Tel hoeveel duplicates je vindt.
Vraag bij je huidige connector-leverancier (of in de docs) op welk veld dedup plaatsvindt. Als het antwoord "timestamp" of "klant + datum" is, weet je genoeg.
Bereken het maandelijkse correctie-uren-getal × je interne uurtarief. Dat is je business case voor een betere koppeling.

Veelgestelde vragen

Werkt dedup op order-ID ook voor Magento 1?

Ja, in Magento 1 heet het veld ook increment_id en is het uniek per store. De logica is identiek. Wel goed om te weten: Magento 1 wordt sinds juni 2020 niet meer ondersteund door Adobe, dus security-updates ontbreken. Een migratie naar Magento 2 is op termijn onvermijdelijk.

Hoeveel orders per dag heb je nodig voordat een directe koppeling rendabel wordt?

Vanaf ongeveer 30-50 orders per dag wordt handmatig overzetten of CSV-import te tijdrovend. Onder die grens kan een wekelijkse export volstaan. Boven de 100 orders per dag is een real-time of near-real-time API-koppeling vrijwel altijd goedkoper dan correctie-werk achteraf.

Wat gebeurt er met orders die in Magento worden aangepast na facturatie?

Een goede connector verwerkt updates als een nieuwe versie op dezelfde increment_id. In de boekhouding zie je dan een aanpassing op de bestaande factuur (of een credit memo + nieuwe factuur, afhankelijk van fiscale regels). Wat je niet wilt: een tweede factuurregel met hetzelfde ordernummer.

Hoe ga je om met test-orders die per ongeluk in productie zijn aangemaakt?

Markeer ze in Magento met een specifieke status of customer-group en filter die in de connector-config uit. Achteraf verwijderen kan, maar levert gaten in de factuurnummering — wat de Belastingdienst niet waardeert. Beter voorkomen dan opruimen.

Deze post is voorbereid met AI-ondersteuning en redactioneel beoordeeld door het Cloutyx-team.