
Je installeert de koppeling op 12 maart. In Shopify staan nog 400 orders uit januari en februari. Op de mutatiepagina zie je twee knoppen. Je duwt. De teller draait. Januari blijft leeg.
Shopify handmatige sync niet voor installatie is geen storing. De docs Handmatig synchroniseren van orders en refunds zeggen het in één zin: die knoppen halen uitsluitend mutaties op vanaf het installatiemoment tot nu. Wat daarvóór ligt, zit niet in die actie.
De e-Boekhouden.nl Koppeling synct vanaf livegang realtime via webhooks. Historie is een andere route: support, niet self-service. Dit stuk is die grens, zonder de knop af te kraken — hij is wél nuttig, alleen voor een ander gat.
Gisteren ging het over een order zonder factuuradres. Eerder over wanneer je wél handmatig duwt ná livegang. Hier: waarom januari nooit uit die knop komt.
Tijdens normale werking zijn de knoppen overbodig. Shopify-webhooks sturen Paid- of Fulfilled-events (afhankelijk van je trigger) naar e-Boekhouden.nl. De listing belooft automatische sync van orders, klanten en mutaties, plus een overzicht succesvol versus fout. $13.95 per maand, 14 dagen trial, 5.0 uit 1 review. Facturatie in USD.
De knoppen bovenaan de mutatiepagina zijn de uitzondering: een webhook die miste, een regel die op fout bleef staan nadat je Settings hebt rechtgezet. Ze kijken naar het venster installatie → nu. Niet naar 1 januari. Niet naar “alles wat Shopify nog heeft”.
Dat is een andere belofte dan de listing-categorie *Historical data import*. Die categorie bestaat. Zelf op de mutatiepagina een backfill starten bestaat niet. De docs Synchroniseren van historische orders en refunds houden die stap intern.
Wat de app nooit doet, plan of knop maakt niet uit:
Geen Shopify-PDF naar e-Boekhouden.nl.
Geen artikelen of voorraad.
Geen geannuleerde orders — alleen restituties als negatieve mutatie.
In andere tools is handmatig synchen: kies een datumrange, haal alles op. Hier is handmatig: herhaal de webhookstroom voor het venster ná installatie. Zonder die nuance duw je, wacht je, en concludeer je dat de API-key stuk is.
Herinstallatie verschuift het installatiemoment. Het vult e-Boekhouden.nl niet met de maanden vóór de eerste install. Wat al geboekt is, blijft. Wat nooit is aangeboden, blijft weg tot support de backfill doet. Je krijgt wel verwarring over welke periode de nieuwe knop wél pakt.
Dubbele mutaties. Support moet dan uitzoeken wat jij al hebt geboekt. De historische-docs noemen precies dat risico: dubbele boekingen, verkeerde datums, ontbrekende koppelingen. Tik niet “voor de zekerheid” 400 orders in terwijl je een mail naar info@onlineorigins.nl stuurt.
Geen van die routes vervangt: knop voor gaten ná livegang, mail voor alles van vóór livegang.
Venster A — ná installatie. Webhooks. Mist er één, open de mutatielijst. Staat 1842 op fout? Lees de tekst (`billing_address`, mapping, trigger). Fix Settings of de Shopify-order. Dáárna de handmatige knoppen. Ze mogen 1842 opnieuw aanbieden omdat 1842 ná 12 maart ligt.
Venster B — vóór installatie. Geen webhook. Geen knop. Geen Settings-schakelaar “haal Q1 op”. Mail info@onlineorigins.nl met:
periode (bijvoorbeeld 1 januari t/m 11 maart 2026);
orders, refunds of beide;
context: eerste install, herinstallatie, of gewijzigde grootboekmapping.
Support beoordeelt of de sync technisch kan, en plant hem. Dat staat in de historische docs, niet in de knoptekst.
We schreven de backfill-kant al bij historische Shopify-orders. Dit artikel is de andere kant van dezelfde medaille: de knop is geen verkorte versie van die mail.
Shop “Linnen & Co”. Koppeling live 12 maart. Trigger: Paid. Mapping: debiteuren 1300 (balans), omzet 8000, verzend 4590, betaalkosten 4550 — voorbeelden uit de instellingendocs, geen wet. Vanaf 12 maart lopen nieuwe betalingen door. Drie POS-orders zonder `address1` blijven rood tot de standaarddebiteur erin staat; daarna duw je de knop. Die drie zijn van 14 maart. Dat mag.
De accountant wil januari en februari in hetzelfde dagboek. Op de mutatiepagina blijven die orders onzichtbaar, ook na vijf keer duwen. Dat is het installatievenster, geen kapotte key.
Wat je wél doet:
Check in e-Boekhouden.nl of januari al handmatig of via een oude export staat. Zo ja: zeg dat in de mail, anders boekt support dubbel.
Mail de periode, orders én refunds (januari had 12 restituties), en dat de mapping op 12 maart is gezet.
Laat support draaien. Controleer steekproef: debiteur, bedrag, btw, verzendkosten. Refund = aparte min-mutatie, geen overschrijving van de verkoop.
Nieuwe dagen blijven webhooks. De knop bewaar je voor een misser ná 12 maart.
Installeer je in november en wil je het hele boekjaar: dezelfde mail, grotere periode, groter risico op al ingetikte mutaties. Noem wat er al in e-Boekhouden.nl staat.
Installeer de e-Boekhouden.nl Koppeling. Zet API-key, grootboek, trigger, eventueel standaard- of POS-debiteur.
Bestel zelf ná installatie. Groene mutatie = venster A werkt.
Ontbreekt een order van ná livegang: mutatielijst, fout lezen, fixen, knop.
Ontbreekt een order van vóór livegang: niet de knop. Mail support met periode en type.
Verwacht geen PDF en geen voorraadkaart. Verwacht een mutatieboeking.
Annuleren in Shopify is geen credit. Restitutie wel.
Installatieservice blijft optioneel (info@onlineorigins.nl). Die zet Settings; die verandert de knopgrens niet.
Shopify handmatige sync niet voor installatie betekent: de twee knoppen op de mutatiepagina kijken naar “sinds livegang”, niet naar “alles in Shopify”. Webhooks doen het dagelijkse werk. De knop repareert een gat in dat venster. Januari terwijl je in maart installeerde is historische import via support, omdat terugwerkende sync te makkelijk dubbel of op de verkeerde datum boekt.
Duw de knop voor 1842 van vorige week. Mail voor Q1. Allebei in de e-Boekhouden.nl Koppeling — alleen niet met dezelfde handeling.
Diensten
Reviews
5/5
Mail: info@onlineorigins.nl
Tel: 073 234 0612
KVK: 89825624
BTW: NL865123639B01
Bruistensingel 500,© 2026 Online Origins