Historische Shopify orders e-Boekhouden: zo zet je ze alsnog over

De koppeling staat live, de testorder is groen, en dan opent de accountant de periode van vóór de installatie. Die orders zitten in Shopify, niet in e-Boekhouden.nl. Wie historische Shopify orders e-Boekhouden wil overzetten, zoekt in de app naar een importknop — en vindt die bewust niet.

Dit artikel legt uit waarom terugwerkende sync geen self-service is, wat de handmatige knoppen wél doen, hoe je een aanvraag indient zonder dubbele boekingen, en hoe de e-Boekhouden.nl Koppeling vanaf livegang realtime verdergaat.

We schreven eerder hoe Shopify-orders automatisch naar e-Boekhouden gaan (Paid of Fulfilled). Dat is de doorstroom. Hier gaat het om alles *vóór* die datum.

Waarom de historie niet vanzelf meekomt

De listing van de e-Boekhouden.nl Koppeling noemt automatische synchronisatie van orders, klanten en factuur-/mutatiegegevens, plus Historical data import als categorie. Nieuwe mutaties lopen via Shopify-webhooks: realtime, zonder CSV. Orders van vóór de installatie zitten niet in die webhookstroom. Er is geen “haal 2025 op”-schakelaar in Settings.

Dat is geen omissie. De docs Synchroniseren van historische orders en refunds zijn expliciet: gebruikers kunnen historische orders en refunds niet zelf terugzetten. Online Origins houdt die stap intern, omdat terugwerkende synchronisaties foutgevoelig zijn. Denk aan:

• dubbele boekingen — dezelfde Shopify-order al handmatig of via een eerdere koppeling in e-Boekhouden.nl;

• verkeerde datums — mutatie op de dag van de import in plaats van de orderdatum;

• ontbrekende koppelingen — grootboek, debiteur of btw-mapping die bij livegang anders stond dan in de historische periode.

Een knop “importeer alles” zou die fouten in één keer in je administratie zetten. Daarom beoordeelt support eerst of de sync technisch mogelijk is.

De app stuurt geen PDF-factuur mee en synct geen artikelen of voorraad. Historie importeren = mutaties (orders en/of refunds), geen productcatalogus terug in de tijd.

Wat shops nu proberen

1. De handmatige sync-knoppen op de mutatiepagina

Op de mutatie-overzichtspagina staan knoppen om handmatig te synchroniseren. Die zijn voor uitzonderingen ná livegang: een webhook die miste, een order die op fout bleef staan. De docs zijn stellig: die knoppen halen uitsluitend mutaties op vanaf het moment van installatie. Orders van 1 januari terwijl je op 15 maart installeerde, komen daar niet uit.

2. CSV uit Shopify, handmatig in e-Boekhouden.nl

Export, kolommen mappen, debiteuren aanmaken. Werkt voor een tiental regels. Bij honderden orders loop je tegen dezelfde mapping heen die de koppeling al doet — btw, verzendkosten, korting — plus het risico dat dezelfde order later nog eens via de app binnenkomt.

3. Alles overtypen vanaf de openingsbalans

Accountant-proof, duur, en je mist refunds die ná de openingsdatum in Shopify plaatsvonden. Een restitutie hoort als negatieve mutatie; een geannuleerde order zonder refund gaat niet mee. Wie historie “even snel” nabootst door orders te annuleren in plaats van te restitueren, krijgt een gat.

4. App deïnstalleren en opnieuw zetten “dan komt alles mee”

Herinstallatie reset de webhook-start, niet de historie. De docs noemen herinstallatie juist als context bij een supportaanvraag — niet als self-service-import.

Hoe de historische import wél werkt

Je vraagt de terugwerkende sync aan. Support voert hem uit. Jij levert de grenzen aan, zodat zij niet per ongeluk een periode dubbel boeken.

Wat je in de mail zet

De docs vragen minstens:

1. Tijdsperiode — bijvoorbeeld 1 januari t/m 14 maart 2026, de dag vóór livegang. Geen open einde (“alles tot nu”).

2. Orders, refunds of beide — refunds in die periode zijn aparte mutaties. Alleen orders vragen terwijl er al credits in Shopify staan, laat de creditkant scheef.

3. Context — herinstallatie, gewijzigde grootboekmapping, overstap van vestigingsland-btw naar OSS, of een periode die je al handmatig hebt ingeboekt.

Stuur naar info@onlineorigins.nl. Telefoon: 073 234 0612. Support beoordeelt of de sync technisch mogelijk is en laat weten wanneer hij draait. Claim niet dat elke periode altijd kan: de beoordeling staat in de docs.

Wat je eerst in de app op orde zet

Historie volgt dezelfde mapping als nieuwe orders. Zet die vast *vóór* je de aanvraag doet:

• Trigger: Paid of Fulfilled — dezelfde keuze als voor de doorstroom. Wisselen halverwege maakt nazoeken lastiger.

• Grootboek: debiteuren, omzet, verzendkosten, betaalkosten.

• Optioneel: vaste debiteurcode; aparte POS-debiteur als kassa en web door elkaar lopen.

• Btw en eventueel OSS: per land een 1600-rekening als je OSS gebruikt. Historische EU-orders met bestemmingslandtarief landen anders op de Nederlandse rekening.

De koppeling neemt tarieven over zoals ze in Shopify staan. Verkeerde shop-taxes worden keurig verkeerd historisch geboekt.

Wat je ná de import controleert

Op de mutatiepagina zie je welke regels succesvol of met fouten zijn verwerkt — dezelfde listing-belofte als voor de dagelijkse sync. Check een steekproef: orderdatum, bedrag, btw, verzendkosten, en of een refund als negatieve mutatie naast de oorspronkelijke order staat. Een foutregel opnieuw pushen ná livegang kan met de handmatige knoppen; een hele historische batch opnieuw vragen zonder overleg is hoe dubbele boekingen ontstaan.

Voorbeeld: live op 15 maart, Q1 nog leeg in e-Boekhouden.nl

Stel: je installeert op 15 maart 2026. Trigger = Paid. Mapping staat, testorder #10402 is groen. In Shopify staan 180 betaalde weborders van 1 januari t/m 14 maart, plus 11 restituties in die periode. Tien oude orders had de boekhouder al handmatig ingeboekt in januari.

Aanvraag:

• Periode: 1 januari t/m 14 maart 2026.

• Beide: orders én refunds.

• Context: tien handmatige boekingen in januari (ordernummers bijvoegen); die niet opnieuw. Geen POS in Q1. Geen OSS in die maanden.

Support draait de batch. Jij controleert op de mutatiepagina of #10001 t/m #10401 binnen zijn, of de 11 credits als negatief staan, en of de tien al ingeboekte nummers ontbreken. Vanaf 15 maart blijft de webhook de nieuwe Paid-orders sturen. De handmatige knoppen gebruik je alleen als een webhook ná livegang mist — niet om Q1 nog eens te halen.

Listingprijs: $13.95 per maand, 14 dagen trial, facturatie via Shopify in USD. De listing is Nederlandstalig (5.0 uit 1 review). Optioneel: eenmalige installatieservice via info@onlineorigins.nl; de historische batch blijft een supportactie, geen extra scherm in de app.

Wat je nodig hebt om te starten

1. Installeer de e-Boekhouden.nl Koppeling en zet API-key, trigger en grootboek klaar — stappen in de documentatie.

2. Doe een testorder (en desnoods een testrefund) ná livegang. Groen = mapping klopt.

3. Bepaal de historische periode tot de dag vóór installatie. Noteer wat al handmatig in e-Boekhouden.nl staat.

4. Mail info@onlineorigins.nl met periode, orders/refunds/beide, en die context. Wacht op bevestiging; druk niet zelf op “historie” — die knop is er niet.

5. Controleer na de batch de mutatiepagina. Gebruik daarna alleen de handmatige sync voor nieuwe uitzonderingen.

De app meldt je niet aan bij de Belastingdienst en maakt geen openingsbalans. Dat blijft accountantwerk. De koppeling vult mutaties; jij bewaakt dat dezelfde order niet twee keer bestaat.

Tot slot

Historische Shopify orders e-Boekhouden is geen CSV-import en geen knop “alles vanaf 1 januari”. Nieuwe orders synct de app realtime. Terugwerkende orders en refunds voert support uit, omdat dubbele boekingen en verkeerde datums duurder zijn dan een mail. De handmatige knoppen op de mutatiepagina beginnen pas bij de installatiedatum.

Zet de mapping vast, vraag de periode aan, en laat de e-Boekhouden.nl Koppeling daarna de volgende Paid-order zelf boeken.