- 1De drie manieren om een WooCommerce QuickBooks-integratie te bouwen
- 2Waarom order-level synchronisatie reconciliatie verstoort
- 3Een uitgewerkt voorbeeld
- 4“Het is Open-Source — een gratis plugin zou dit moeten regelen”
- 5De architectuur die werkt: Clearing accounts, dagelijkse samenvattingen, kostenregels
- 6In LedgerPort, this architecture is a settings page
- 7Wanneer een plugin voldoende is — en wanneer niet
- 8The engineering bar a sync layer should clear
- 9Hoe dit er geautomatiseerd uitziet
- 10And when a webhook fails — because one will
- 11De flexibiliteitstaks
Bestellingen in QuickBooks krijgen is het makkelijke deel. Deze gids gaat over het deel dat de plugin-vermelding niet noemt: ervoor zorgen dat de boekhouding overeenkomt met de bank.
Er staan 1.400 nieuwe facturen in uw QuickBooks Online-bestand, en elk van hen is correct.
U hebt de connector geïnstalleerd, een paar velden gemapt en toegekeken hoe deze werkte. Elke WooCommerce-bestelling kwam aan in QBO met de klantnaam, de artikelen, de verzending, de belasting. Volgens elke maatstaf op de functiespagina van de plugin was uw WooCommerce QuickBooks-integratie voltooid.
Toen opende u de bankkoppeling. Stripe stortte maandag € 6.782,40, PayPal stortte woensdag € 1.911. En niet één van die 1.400 facturen — geen enkele — komt overeen met een van beide bedragen. QuickBooks vraagt u nu om een enkele storting te matchen met tientallen openstaande facturen, waarvan geen enkele optelt tot dat bedrag.
Als u dit hebt meegemaakt, hebt u waarschijnlijk gedaan wat de meeste winkel eigenaren doen: de plugin verwijderd, teruggegaan naar CSV-exports en geconcludeerd dat de hele categorie kapot is. Dat is niet zo. Maar het ding dat u werd verkocht — order synchronisatie — was nooit het eigenlijke probleem.
Het eigenlijke probleem is dat WooCommerce en uw bankrekening twee verschillende realiteiten beschrijven, en geen enkele order synchronisatie vertaalt daartussen. Deze post legt uit waarom, met de cijfers, en leidt u door de setup die daadwerkelijk reconcilieert.
De drie manieren om een WooCommerce QuickBooks-integratie te bouwen
Grofweg valt elke aanpak in een van de drie categorieën.
1. De officiële QuickBooks Connector. Intuit's eigen connector (gebouwd op de oude OneSaas-engine) stuurt WooCommerce-bestellingen naar QBO als facturen of ontvangstbewijzen. Het is goedkoop, het wordt ondersteund door Intuit, en voor basale orderkopie doet het wat het belooft. Wat het kent, zijn bestellingen — wat een klant kocht en wat WooCommerce hen in rekening bracht.
2. Speciale synchronisatieplugins. Tools zoals MyWorks Sync gaan veel dieper: tweerichtingssynchronisatie, gedetailleerde veldmapping, voorraad- en klantensynchronisatie, real-time pushes. Als uw bedrijf draait op individuele facturen — groothandelsaccounts, B2B-klanten, betalingen gekoppeld aan specifieke personen — is die per-order nauwkeurigheid echt waardevol, en MyWorks is daar sterk in. We hebben een gedetailleerde vergelijking geschreven op LedgerPort vs. MyWorks als u die route overweegt.
3. Handmatige CSV-exports. Exporteer bestellingen uit WooCommerce, bewerk de spreadsheet, voer handmatig journaalposten in QBO in. Totale controle, geen softwarekosten, en ergens tussen de twee en acht uur per maand, afhankelijk van het volume — plus elke fout die een vermoeide mens maakt in het derde uur.
| Methode | Wat het verplaatst | Kosten | Reconcilieert met de bank? |
|---|---|---|---|
| QuickBooks Connector | Bestellingen → facturen/ontvangstbewijzen | Laag | Niet op zichzelf |
| Sync-plugin (bijv. MyWorks) | Bestellingen, klanten, inventaris | € – €€ | Alleen met zorgvuldige uitbetalingsconfiguratie |
| Handmatige CSV | Wat je ook typt | Jouw tijd | Alleen als je zelf de uitbetalingsberekeningen doet |
Merk op wat alle drie gemeen hebben: ze beginnen met bestelgegevens. En bestelgegevens zijn slechts de helft van de dataset die je nodig hebt.
Waarom order-level synchronisatie reconciliatie verstoort
Hier is het structurele probleem, en het heeft niets te maken met welke plugin je hebt gekozen.
WooCommerce weet van bestellingen: klant, artikelen, totalen, belasting. Het weet niet wat Stripe heeft afgetrokken aan verwerkingskosten, wanneer PayPal een uitbetaling heeft gebundeld, welke terugbetaling van vorige week is verrekend met de storting van deze week, of wat een terugboekingskosten hebben gedaan met de uitbetaling van dinsdag. Die informatie leeft bij je betaalproviders - een volledig aparte dataset, volgens een volledig aparte planning.
Je bankkoppeling ziet ondertussen alleen de kant van de provider van het verhaal: netto stortingen, gebundeld volgens de planning van de provider. Dus wanneer een synchronisatietool bestellingen naar QBO kopieert, registreert het getrouw een dataset die je bankrekening nooit zal bevestigen.
Een uitgewerkt voorbeeld
Zeg dat je winkel in een weekend 96 bestellingen ontvangt, met een totaal van € 7.200 bruto. WooCommerce rapporteert dit als drie afzonderlijke verkoopdagen, en je synchronisatie op bestelniveau creëert 96 facturen in QBO.
Op maandag stuurt Stripe één uitbetaling:
| Stripe-uitbetaling — Maandag | Bedrag |
|---|---|
| Bruto weekendverkopen (96 bestellingen) | $7,200.00 |
| Verwerkingskosten (2,9% + € 0,30 × 96) | −€ 237,60 |
| Terugbetalingen (2 bestellingen van vorige week) | −€ 180,00 |
| Netto storting op je bank | $6,782.40 |
QuickBooks bevat nu 96 facturen met een totaal van € 7.200, verspreid over vrijdag, zaterdag en zondag. Je bankkoppeling bevat één storting van € 6.782,40 op maandag. De € 237,60 aan kosten bestaat nergens in je boekhouding. De € 180 aan terugbetalingen hoort bij bestellingen die niet eens in de gegevens van dit weekend staan. Er is geen combinatie van die 96 facturen die gelijk is aan die storting - de berekening is onmogelijk te matchen bij constructie.
Vermenigvuldig met elke uitbetaling, elke provider, elke maand. Zo kom je aan 1.400 perfecte facturen en een bankkoppeling die met geen van hen overeenkomt.
[AFBEELDING: Diagram dat WooCommerce-bestelgegevens en Stripe-uitbetalingsgegevens toont als twee afzonderlijke stromen, waarbij de bankkoppeling alleen is verbonden met de uitbetalingsstroom — en de kloof waar kosten en de timing van terugbetalingen zich bevinden]
Op dit punt concluderen de meeste mensen een van de drie dingen: sommigen besluiten dat ze een boekhouder moeten inhuren, sommigen gaan terug naar spreadsheets, en sommigen realiseren zich dat het probleem architectonisch is en lossen de architectuur op. Dit gedeelte is voor de derde groep.
“Het is Open-Source — een gratis plugin zou dit moeten regelen”
Laten we de aanname direct benoemen, omdat deze redelijk is en fout.
WooCommerce is open-source, het ecosysteem heeft een plugin voor alles, en de meeste zijn gratis of goedkoop. Dus de instelling is: een gratis plugin zou QuickBooks ook moeten afhandelen. En een gratis plugin kan afhandelen waar plugins goed in zijn — bestelgegevens van de ene database naar de andere verplaatsen. Dat deel is echt een opgelost probleem.
Maar reconciliatie is geen data-overdrachtsprobleem. Het is een vertalingsprobleem tussen twee datasets die het oneens zijn over bedragen (bruto vs. netto), timing (ordendatum vs. uitbetalingsdatum) en reikwijdte (bestellingen van dit weekend vs. terugbetalingen van vorige week). Geen enkele plugin lost dat op door bestellingen sneller te verplaatsen of velden preciezer te mappen — je hebt het niet verkeerd geconfigureerd, en de plugin-ontwikkelaar ook niet. Het gereedschap loste het probleem op dat het begreep. Het probleem dat je werkelijk hebt, is groter dan het model dat het gereedschap ervan heeft.
De architectuur die werkt: Clearing accounts, dagelijkse samenvattingen, kostenregels
De oplossing is een structuur die accountants al tientallen jaren gebruiken, toegepast op gateways. Drie componenten: een clearingrekening per gateway, dagelijkse samenvattingen in plaats van facturen per bestelling, en expliciete kostenregels op elke uitbetaling. Hier is de handmatige installatie, stap voor stap.
Maak een clearingrekening aan voor elke gateway. Voeg in QBO een rekening van het type Other Current Asset toe met de naam "Stripe Clearing", een andere voor "PayPal Clearing", en één per extra gateway. Deze rekening vertegenwoordigt geld dat klanten hebben betaald en dat uw bank nog niet heeft bereikt — wat het precies is.
Boek dagelijkse omzetsamenvattingen in plaats van individuele facturen. Boek één keer per dag één boeking per gateway: bruto verkopen, kortingen, terugbetalingen, verzendinkomsten en geïnde omzetbelasting. Debiteer de clearingrekening voor het brutobedrag; crediteer uw inkomsten-, verzendings- en belastingaansprakelijkheidsrekeningen. Uw P&L toont nu inkomsten per dag — wat alles is wat belastingvoorbereiding en margeanalyse nodig hebben — zonder 96 weesfacturen. (Als u inkomsten- en belastingrekeningen vanaf nul opzet, behandelt onze WooCommerce boekhoudgids de volledige structuur van de rekeningen.)
Boek elke uitbetaling als een journaalpost wanneer deze binnenkomt. Crediteer de clearingrekening voor het brutobedrag van de uitbetaling. Debiteer uw betaalrekening voor de netto storting. Debiteer een "Merchant Processing Fees"-kostenrekening voor het verschil in kosten, en boek terugboekingen van terugbetalingen tegen inkomsten. Gebruikmakend van het weekendvoorbeeld: crediteer Stripe Clearing € 7.200, debiteer betaalrekening € 6.782,40, debiteer kosten € 237,60, boek de € 180 aan terugbetalingen tegen de omzet. Elke euro heeft nu een thuis.
Vergelijk de storting in de bankfeed. Omdat de bankregel van uw journaalpost € 6.782,40 is en de storting € 6.782,40, koppelt QuickBooks deze met één klik. Dit is het moment waarop de hele structuur zijn vruchten afwerpt: reconciliatie wordt een bevestiging in plaats van een onderzoek.
Houd het saldo van de clearingrekening in de gaten. Het zou dicht bij het bedrag moeten zweven dat momenteel onderweg is met de gateway — een paar dagen aan verkopen, niets meer. Een gestaag groeiend saldo betekent dat kosten of terugbetalingen ergens niet worden geregistreerd. Dit ene getal is uw waarschuwingssysteem, en het is het eerste wat een goede accountant zal controleren.
[AFBEELDING: Stroomdiagram — dagelijkse samenvattingsboekingen die in een Stripe Clearing-rekening stromen, vervolgens een uitbetalingsjournaal dat zich opsplitst naar Betaalrekening (netto) en Verwerkingskosten (kosten), met de bankfeed-match aan het einde]
Handmatig gedaan, kost dit een bekwame boekhouder 30-60 minuten per gateway per week, en elke stap is een kans op een typefout. Maar de structuur is correct — en structuur is wat geen enkele order-syncing plugin je geeft.
In LedgerPort, this architecture is a settings page
If those five steps sound like a lot of journal discipline, here’s the part worth knowing: in LedgerPort’s WooCommerce plugin, each component exists as configuration. The Payments tab of Sync Config auto-detects every payment gateway active on your store and assigns each one its own clearing account, with a default clearing account as the fallback for anything you haven’t configured. One clearing account per gateway isn’t journal gymnastics — it’s a dropdown per gateway.
Tax gets the same treatment: sales tax posts to a QuickBooks liability account you designate, and a rounding line item absorbs the cent-level differences between WooCommerce’s tax math and QuickBooks’ — the reconciliation papercut nobody warns you about. How orders post is one more dropdown: Sales Receipt for paid orders, Invoice when payment comes later, Estimate for quotes. And the taxonomy of sync methods is platform-general — the docs’ own guidance puts roughly 100+ orders a day as the point where per-order records stop being bookkeeping and start being sediment, which is exactly where daily summaries earn their keep.
None of this demands a configuration project, either. Per the docs’ own FAQ, every tab ships with sensible defaults — most stores can start syncing without touching Sync Config at all, and tighten the settings later as the books demand it.
Wanneer een plugin voldoende is — en wanneer niet
Eerlijk antwoord: soms zijn de tools op orderniveau de juiste keuze.
Een sync plugin op orderniveau is waarschijnlijk voldoende als: je ongeveer 100-200 bestellingen per maand verwerkt en de hiaten kunt overzien; je één gateway beheert met eenvoudige, zeldzame terugbetalingen; of je bedrijf factuurgedreven is — groothandels- en B2B-winkels waar betalingen daadwerkelijk aan specifieke klantfacturen worden gekoppeld. In dat laatste geval is per-order synchronisatie geen bug, maar de vereiste, en een tool zoals MyWorks is er precies voor gebouwd.
Je hebt de uitbetalingsbewuste laag nodig als: je meerdere gateways beheert (Stripe plus PayPal is waar de meeste winkels de grens overschrijden); terugbetalingen en geschillen wekelijks voorkomen; je volume de invoer per bestelling onbeheersbaar maakt; of een accountant je boeken maandelijks afsluit en verwacht dat de bankkoppeling overeenkomt. Op dat punt kan ordergegevens alleen geen te reconciliëren boeken opleveren — hoe goed het ook synchroniseert.
Als je neigt naar de uitbetalingsbewuste route, komen de volgende drie praktische bezwaren naar voren:
“Kan het mijn abonnementen verwerken?” LedgerPort synchroniseert standaard WooCommerce order- en klantgegevens, en abonnementsverlengingen komen binnen als reguliere bestellingen wanneer WooCommerce ze aanmaakt — dus terugkerende inkomsten stromen door dezelfde pijplijn, niets speciaals te configureren.
“Wat als een synchronisatie stilzwijgend mislukt?” Real-time synchronisatie maakt gebruik van WooCommerce webhooks, en WooCommerce probeert mislukte leveringen automatisch opnieuw. Als er toch iets doorheen glipt, pusht een handmatige synchronisatiepagina binnen wp-admin gegevens op aanvraag — je hoeft nooit te wachten op ondersteuning om een bestelling opnieuw te verzenden.
“Kan ik meerdere winkels koppelen aan één account?” Ja — elke verbonden winkel telt als één verbinding tegen de limiet van je abonnement, zichtbaar op de Verbindingspagina. De rest van de praktische vragen (HPOS-compatibiliteit, opslag van inloggegevens, vereiste gebruikersrollen) worden beantwoord in Aan de slag met LedgerPort voor WooCommerce.
The engineering bar a sync layer should clear
There’s one more evaluation axis, and it’s the one plugin listings never show: what the software does to your store when it connects — and when it leaves. LedgerPort’s provisioning is automatic and transactional. Connecting creates a read-only WooCommerce REST API key — it reads your store, it doesn’t write to it — and registers 13 named webhooks covering orders, products, variations, customers, and refunds. If any provisioning step fails midway, everything already completed is rolled back automatically, so your store is never left half-configured.
The rest of the security posture is equally checkable: credentials are stored AES-256-CBC-encrypted using your site’s own WordPress security keys, connecting requires the manage_woocommerce capability (Administrators and Shop Managers), and LedgerPort never touches webhooks you created yourself. Disconnecting is just as clean — it deletes exactly the API key and webhooks it created, your store and orders are untouched, and your mappings survive for reconnection. A botched first attempt costs nothing.
The same discipline shows up when a sync goes wrong. Failures aren’t a silent gap or a PHP notice — they’re a named taxonomy with documented fixes: an expired QuickBooks token (the docs’ own pick for the most common sync error), an unmapped product, a duplicate entry, a missing required field. Each error states its cause and its recovery path. That, more than any feature checkbox, is the real boundary of “a plugin is enough”: it ends where unrecoverable, invisible failure begins.
Hoe dit er geautomatiseerd uitziet
LedgerPort is gebouwd als die uitbetalingsbewuste laag, en het ondersteunt WooCommerce naast Shopify. Het maakt verbinding met je winkel *en* je gateways, voert vervolgens de bovenstaande architectuur automatisch uit: dagelijkse samenvattingen geboekt op gateway-afrekeningsaccounts, uitbetalingsjournaals met uitgesplitste kosten, stortingen die exact overeenkomen met je bankafschrift. Installatie duurt ongeveer 15 minuten, en winkels met een aanzienlijk volume melden dat ze wekelijks uren besparen.
Hier is de volledige WooCommerce-installatie, van begin tot eind:
Installeer de plugin. Ga in je WordPress-admin naar Plugins » Nieuwe Plugin Toevoegen, zoek naar LedgerPort, klik op Nu Installeren, en vervolgens op Activeren. Je hebt HTTPS op je site nodig en een LedgerPort-account — de volledige installatieweergave behandelt beide vereisten.
Voer de Setup Wizard uit. Na activering opent LedgerPort de wizard automatisch als een volledig scherm overlay. Klik op Verbinden met LedgerPort om te beginnen.
Autoriseer de verbinding. U wordt doorgestuurd naar app.ledgerport.com om in te loggen, het bedrijf te kiezen waarmee u verbinding maakt en op Autoriseren te klikken — daarna wordt u direct teruggestuurd naar uw WordPress-admin.
- Laat de provisioning lopen. LedgerPort maakt een WooCommerce REST API-sleutel met leesrechten aan, registreert webhooks voor bestellingen, terugbetalingen, producten en klanten, en bevestigt de verbinding. Als een stap mislukt, wordt alles automatisch teruggedraaid — geen half geconfigureerde winkel. Als het slaagt, komt u terecht op het LedgerPort Dashboard, verbonden.
Vanaf daar leeft alles onder een LedgerPort-menu binnen wp-admin — Dashboard, Mappings, Handmatige synchronisatie, Audit Logs — dus het controleren van de infrastructuur betekent nooit WordPress verlaten. En de structuur van het verrekeningsaccount uit de vorige sectie is geen apart configuratieproject: het is de Dagelijkse Samenvattingssynchronisatiemethode, een dropdown uit vijf, eenmalig gekozen.
And when a webhook fails — because one will
Real-time sync rides on webhooks, and webhooks are honest about their nature: sooner or later, a delivery fails. The question most free plugins can’t answer is what happens next. Here the answer has layers. WooCommerce itself retries failed webhook deliveries automatically. Anything that still slips through doesn’t vanish — it surfaces as a per-record sync status, recoverable from the Manual Sync page inside wp-admin.
The workflow is checkbox selection, then Push Selected or Push All, then a live progress modal that shows each record land or fail — with a reason attached, not just a red icon. And the detail that makes catch-up after an outage safe: pushing is guaranteed not to duplicate. Already-synced records are skipped automatically, and re-pushing a failed record creates or updates the QuickBooks entry rather than posting it twice. “Select everything, push all” after a bad week can’t double-post revenue.
Two more facts from the FAQ that belong here: the plugin is fully compatible with WooCommerce’s High-Performance Order Storage with zero extra configuration, and — as covered above — WooCommerce Subscriptions renewals ride the same pipeline as regular orders. Historical backfill uses this same page, too, which means “we’ve been on spreadsheets all year” is an import, not a data-entry project: page through the year, push, watch the statuses turn green.
De afweging, simpel gezegd: LedgerPort vat samen. Het synchroniseert geen individuele klantgegevens of beheert geen voorraad in QBO — als uw bedrijf facturen per klant nodig heeft, is een tool zoals MyWorks de betere keuze, en de vergelijking loopt eerlijk door die lijn.
Prijzen beginnen gratis — tot 30 bestellingen per maand, één winkel, handmatige synchronisatie op aanvraag — zodat u een echte uitbetaling kunt zien reconciliëren voordat u iets betaalt. Groei begint vanaf $25/maand met dagelijkse geautomatiseerde synchronisatie; Schaal, vanaf $67/maand, voegt realtime synchronisatie toe plus de uitbetalingsjournaals en kostenafhandeling waar dit bericht over gaat. Elk betaald plan heeft een onvoorwaardelijke 14-dagen geld-terug-garantie — geen proefperiode, een volledige terugbetaling, zonder vragen.
De flexibiliteitstaks
Hier is de tragikomische waarheid over WooCommerce: het ding dat het geweldig maakt, is het ding dat uw boeken breekt.
U kunt elke gateway, elke checkout-plugin, elke abonnementsuitbreiding, elke regionale betaalmethode gebruiken — en het ecosysteem zal dit allemaal ondersteunen. Die flexibiliteit is echt de reden waarom u voor het platform hebt gekozen. Maar het betekent ook dat uw financiële gegevens afkomstig zijn van vier of vijf systemen die nooit zijn overeengekomen om dezelfde taal te spreken, en de boekhoudlaag erft elk van die dialecten.
Het plugin-ecosysteem kan dat niet voor u structureren, omdat structuur precies is wat een open ecosysteem niet oplegt. De structuur moet dus in de boekhoudlaag leven: clearingrekeningen, dagelijkse samenvattingen, kostenregels. Dat is de prijs die u betaalt voor flexibiliteit elders - en het is een eerlijke prijs, zodra u niet langer verwacht dat de order-sync die voor u betaalt.
Die 1.400 facturen van de opening waren niet verkeerd. Ze beantwoordden gewoon een vraag die uw bank nooit stelde. Als u liever wilt dat uw boekhouding de juiste vraag beantwoordt, koppel uw WooCommerce winkel aan LedgerPort - het gratis abonnement dekt uw eerste uitbetaling, en op het moment dat de storting overeenkomt, weet u dat de architectuur werkt.
