- 1De tre sätten att bygga en WooCommerce QuickBooks-integration
- 2Varför ordernivå-synkronisering bryter avstämningen
- 3Ett arbetat exempel
- 4"Det är öppen källkod — ett gratis plugin borde hantera detta"
- 5Arkitekturen som fungerar: Clearingkonton, dagliga sammanfattningar, avgiftsrader
- 6In LedgerPort, this architecture is a settings page
- 7När ett plugin räcker — och när det inte gör det
- 8The engineering bar a sync layer should clear
- 9Vad detta ser ut som automatiserat
- 10And when a webhook fails — because one will
- 11Flexibilitetsskatten
Att få in ordrar i QuickBooks är den enkla delen. Den här guiden handlar om den del som plugin-listningen inte nämner: att få böckerna att stämma med banken.
Det finns 1 400 nya fakturor i din QuickBooks Online-fil, och varenda en av dem är korrekt.
Du installerade anslutningen, mappade några fält och såg den fungera. Varje WooCommerce-order kom in i QBO med kundnamnet, produktartiklarna, frakten, skatten. Enligt alla mått på pluginets funktionssida var din WooCommerce QuickBooks-integration klar.
Sedan öppnade du bankflödet. Stripe satte in 6 782,40 USD på måndagen. PayPal släppte 1 911 USD på onsdagen. Och inte en enda av dessa 1 400 fakturor — inte en enda — stämmer med något av beloppen. QuickBooks ber dig nu att matcha en enda insättning mot dussintals öppna fakturor, varav ingen summerar till det.
Om du har varit med om detta gjorde du förmodligen som de flesta butiksägare: avinstallerade pluginet, gick tillbaka till CSV-export, och drog slutsatsen att hela kategorin är trasig. Det är den inte. Men det du blev såld — order-synkronisering — var aldrig det verkliga problemet.
Det verkliga problemet är att WooCommerce och ditt bankkonto beskriver två olika verkligheter, och ingen mängd order-synkronisering översätter mellan dem. Det här inlägget förklarar varför, med siffror, och går igenom den konfiguration som faktiskt stämmer.
De tre sätten att bygga en WooCommerce QuickBooks-integration
I stort sett faller varje metod i en av tre kategorier.
1. Den officiella QuickBooks Connector. Intuits egen anslutning (byggd på den gamla OneSaas-motorn) skickar WooCommerce-ordrar till QBO som fakturor eller kvitto. Den är billig, den stöds av Intuit, och för grundläggande orderkopiering gör den vad den lovar. Vad den känner till är ordrar — vad en kund köpte och vad WooCommerce debiterade dem.
2. Dedikerade synkroniseringsplugins. Verktyg som MyWorks Sync går mycket djupare: dubbelriktad synkronisering, detaljerad fältmappning, lager- och kundsynkronisering, realtidsöverföringar. Om din verksamhet bygger på enskilda fakturor — grossistkonton, B2B-kunder, betalningar knutna till specifika personer — är den per-order-troheten genuint värdefull, och MyWorks är stark på det. Vi har skrivit en detaljerad jämförelse på LedgerPort vs. MyWorks om du överväger den vägen.
3. Manuell CSV-export. Exportera ordrar från WooCommerce, bearbeta kalkylbladet, ange journalposter i QBO manuellt. Total kontroll, noll programkostnad, och någonstans mellan två och åtta timmar i månaden beroende på volym — plus varje fel en trött människa gör under timme tre.
| Metod | Vad den flyttar | Kostnad | Stämmer mot banken? |
|---|---|---|---|
| QuickBooks Connector | Ordrar → fakturor/kvitton | Låg | Not on its own |
| Sync plugin (e.g., MyWorks) | Orders, customers, inventory | $ – $$ | Only with careful payout configuration |
| Manual CSV | Whatever you type | Your time | Only if you do the payout math yourself |
Notice what all three have in common: they start from order data. And order data is only half the dataset you need.
Varför ordernivå-synkronisering bryter avstämningen
Here’s the structural problem, and it has nothing to do with which plugin you chose.
WooCommerce knows about orders: customer, items, totals, tax. It does not know what Stripe deducted in processing fees, when PayPal batched a payout, which refund from last week got netted against this week’s deposit, or what a chargeback fee did to Tuesday’s disbursement. That information lives with your payment gateways — a completely separate dataset, on a completely separate schedule.
Your bank feed, meanwhile, only ever sees the gateway’s side of the story: net deposits, batched on the gateway’s timeline. So when a sync tool copies orders into QBO, it’s faithfully recording a dataset your bank account will never confirm.
Ett arbetat exempel
Say your store takes 96 orders over a weekend, totaling $7,200 gross. WooCommerce reports this as three separate days of sales, and your order-level sync creates 96 invoices in QBO.
On Monday, Stripe sends one payout:
| Stripe payout — Monday | Amount |
|---|---|
| Gross weekend sales (96 orders) | $7,200.00 |
| Processing fees (2.9% + $0.30 × 96) | −$237.60 |
| Refunds (2 orders from last week) | −$180.00 |
| Net deposit to your bank | $6,782.40 |
QuickBooks now holds 96 invoices totaling $7,200, spread across Friday, Saturday, and Sunday. Your bank feed holds one Monday deposit of $6,782.40. The $237.60 in fees exists nowhere in your books. The $180 in refunds belongs to orders that aren’t even in this weekend’s data. There is no combination of those 96 invoices that equals that deposit — the math is unmatchable by construction.
Multiply by every payout, every gateway, every month. That’s how you end up with 1,400 pristine invoices and a bank feed that agrees with none of them.
[IMAGE: Diagram showing WooCommerce order data and Stripe payout data as two separate streams, with the bank feed only connected to the payout stream — and the gap where fees and refund timing live]
At this point most people conclude one of three things: some decide they need to hire a bookkeeper, some go back to spreadsheets, and some realize the problem is architectural and fix the architecture. This section is for the third group.
"Det är öppen källkod — ett gratis plugin borde hantera detta"
Let’s name the assumption directly, because it’s reasonable and it’s wrong.
WooCommerce is open-source, the ecosystem has a plugin for everything, and most of them are free or cheap. So the instinct is: a free plugin should handle QuickBooks too. And a free plugin can handle what plugins are good at — moving order data from one database to another. That part genuinely is a solved problem.
But reconciliation isn’t a data-transfer problem. It’s a translation problem between two datasets that disagree about amounts (gross vs. net), timing (order date vs. payout date), and scope (this weekend’s orders vs. last week’s refunds). No plugin fixes that by moving orders faster or mapping fields more precisely — you didn’t configure it wrong, and neither did the plugin developer. The tool solved the problem it understood. The problem you actually have is bigger than the tool’s model of it.
Arkitekturen som fungerar: Clearingkonton, dagliga sammanfattningar, avgiftsrader
The fix is a structure accountants have used for decades, applied to gateways. Three components: a clearing account per gateway, daily summaries instead of per-order invoices, and explicit fee lines on every payout. Here’s the manual setup, step by step.
Create a clearing account for each gateway. In QBO, add an account of type Other Current Asset named “Stripe Clearing,” another for “PayPal Clearing,” and one per additional gateway. This account represents money customers have paid that hasn’t reached your bank yet — which is exactly what it is.
Post daily sales summaries instead of individual invoices. Once per day, record one entry per gateway: gross sales, discounts, refunds issued, shipping income, and sales tax collected. Debit the clearing account for the gross amount; credit your income, shipping, and tax-liability accounts. Your P&L now shows revenue by day — which is all tax prep and margin analysis need — without 96 orphan invoices. (If you’re setting up income and tax accounts from scratch, our WooCommerce bookkeeping guide covers the full chart-of-accounts structure.)
Record each payout as a journal entry when it lands. Credit the clearing account for the payout’s gross amount. Debit your checking account for the net deposit. Debit a “Merchant Processing Fees” expense account for the fee difference, and post refund reversals against income. Using the weekend example: credit Stripe Clearing $7,200, debit checking $6,782.40, debit fees $237.60, book the $180 of refunds against revenue. Every dollar now has a home.
Match the deposit in the bank feed. Because your journal entry’s bank line is $6,782.40 and the deposit is $6,782.40, QuickBooks matches them in one click. This is the moment the whole structure pays off: reconciliation becomes confirmation instead of investigation.
Watch the clearing account balance. It should hover near the amount currently in transit with the gateway — a few days of sales, nothing more. A steadily growing balance means fees or refunds are going unrecorded somewhere. This single number is your early-warning system, and it’s the first thing a good CPA will check.
[IMAGE: Flow diagram — daily summary entries flowing into a Stripe Clearing account, then a payout journal splitting out to Checking (net) and Processing Fees (expense), with the bank feed match at the end]
Detta görs för hand, tar en kompetent bokförare 30–60 minuter per gateway per vecka, och varje steg är en chans för ett skrivfel. Men strukturen är korrekt — och struktur är det som ingen order-synkroniseringsplugin ger dig.
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.
När ett plugin räcker — och när det inte gör det
Ärligt svar: ibland är verktygen på ordernivå rätt val.
En synkroniseringsplugin på ordernivå räcker troligen om: du har ungefär 100–200 ordrar per månad och kan överskåda luckorna; du använder en enda gateway med enkla, sällsynta återbetalningar; eller din verksamhet är fakturadriven — grossist- och B2B-butiker där betalningar verkligen knyts till specifika kundfakturor. I det sista fallet är synkronisering per order inte en bugg, det är kravet, och ett verktyg som MyWorks är byggt exakt för det.
Du behöver utbetalningsmedvetna lagret om: du använder flera gateways (Stripe plus PayPal är där de flesta butiker passerar gränsen); återbetalningar och tvister är en veckovis verklighet; din volym gör poster per order ohanterliga; eller en revisor stänger dina böcker månadsvis och förväntar sig att bankflödet ska stämma. Vid den tidpunkten kan orderdata ensam inte producera avstämda böcker — oavsett hur väl den synkroniseras.
Om du lutar åt den utbetalningsmedvetna vägen, dyker tre praktiska invändningar vanligtvis upp härnäst:
”Kommer den att hantera mina prenumerationer?” LedgerPort synkroniserar standard WooCommerce order- och kunddata, och prenumerationsförnyelser kommer som vanliga ordrar när WooCommerce skapar dem — så återkommande intäkter flödar genom samma pipeline, inget speciellt att konfigurera.
”Vad händer om en synkronisering misslyckas tyst?” Synkronisering i realtid bygger på WooCommerce webhooks, och WooCommerce försöker automatiskt igen med misslyckade leveranser. Om något ändå slinker igenom, skickar en sida för manuell synkronisering inuti wp-admin data på begäran — du behöver aldrig vänta på support för att skicka om en order.
”Kan jag köra flera butiker mot ett konto?” Ja — varje ansluten butik räknas som en anslutning mot din plans gräns, synlig på anslutningssidan. Resten av de praktiska frågorna (HPOS-kompatibilitet, lagring av autentiseringsuppgifter, nödvändiga användarroller) besvaras i Komma igång med LedgerPort för 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.
Vad detta ser ut som automatiserat
LedgerPort är byggd som det utbetalningsmedvetna lagret, och den stöder WooCommerce tillsammans med Shopify. Den ansluter till din butik *och* dina gateways, kör sedan arkitekturen ovan automatiskt: dagliga sammanfattningar bokförda på gatewayens clearingkonton, utbetalningsjournaler med avgifter specificerade, insättningar som stämmer exakt med ditt bankflöde. Installationen tar cirka 15 minuter, och butiker med betydande volym rapporterar att de sparar timmar varje vecka.
Här är hela WooCommerce-installationen, från början till slut:
Installera plugin-programmet. I din WordPress-admin, gå till Plugins » Lägg till ny plugin, sök efter LedgerPort, klicka på Installera nu, sedan Aktivera. Du behöver HTTPS på din webbplats och ett LedgerPort-konto — hela installationsguiden täcker båda förutsättningarna.
Kör installationsguiden. Efter aktivering öppnar LedgerPort guiden automatiskt som ett helskärmsöverlägg. Klicka på Anslut till LedgerPort för att börja.
Auktorisera anslutningen. Du omdirigeras till app.ledgerport.com för att logga in, välja det företag du ansluter, och klicka på Auktorisera — sedan skickas du direkt tillbaka till din WordPress-admin.
- Låt provisionering köras. LedgerPort skapar en WooCommerce REST API-nyckel med läsåtkomst, registrerar webhooks för beställningar, återbetalningar, produkter och kunder, och bekräftar anslutningen. Om något steg misslyckas rullas allt tillbaka automatiskt — ingen halvkonfigurerad butik. När det lyckas hamnar du på LedgerPort-instrumentpanelen, ansluten.
Därifrån lever allt under en LedgerPort-meny i wp-admin — Instrumentpanel, Mappningar, Manuell synkronisering, Granskningsloggar — så att kontrollera installationen innebär aldrig att lämna WordPress. Och clearingkontostrukturen från föregående avsnitt är inte ett separat konfigurationsprojekt: det är metoden för daglig sammanfattningssynkronisering, en rullgardinsmeny bland fem, vald en gång.
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.
Avvägningen, rakt på sak: LedgerPort sammanfattar. Den kommer inte att synkronisera enskilda kundposter eller hantera lager i QBO — om ditt företag behöver fakturor per kund, är ett verktyg som MyWorks fortfarande den starkare lösningen, och jämförelsen går igenom den linjen ärligt.
Prissättning börjar gratis — upp till 30 beställningar per månad, en butik, manuell synkronisering vid behov — så att du kan se en verklig utbetalning stämma innan du betalar något. Tillväxt börjar från 25 USD/månad med daglig automatiserad synkronisering; Skala, från 67 USD/månad, lägger till realtidssynkronisering plus utbetalningsjournalerna och avgiftshanteringen som detta inlägg handlar om. Varje betald plan har en 14-dagars ovillkorlig pengarna-tillbaka-garanti — inte en provperiod, full återbetalning, inga frågor ställda.
Flexibilitetsskatten
Här är den tragikomiska sanningen om WooCommerce: det som gör det bra är det som förstör dina böcker.
Du kan köra vilken gateway, vilket kassa-plugin, vilken prenumerationsförlängning, vilken regional betalningsmetod som helst — och ekosystemet kommer att stödja allt detta. Den flexibiliteten är genuint anledningen till att du valde plattformen. Men det innebär också att dina finansiella data härstammar från fyra eller fem system som aldrig kom överens om att tala samma språk, och redovisningslagret ärver alla dessa dialekter.
Plugin-ekosystemet kan inte strukturera det åt dig, eftersom struktur är precis vad ett öppet ekosystem inte påtvingar. Så strukturen måste leva i redovisningslagret: clearingkonton, dagliga sammanfattningar, avgiftsrader. Det är skatten du betalar för flexibilitet överallt annars – och det är ett rimligt pris, när du slutar förvänta dig att ordningsynkroniseringen ska betala den åt dig.
De där 1 400 fakturorna från öppningen var inte fel. De svarade bara på en fråga som din bank aldrig ställde. Om du hellre vill att dina böcker ska svara på rätt fråga, anslut din WooCommerce-butik till LedgerPort – gratisplanen täcker din första utbetalning, och i samma ögonblick som insättningen matchar vet du att arkitekturen fungerar.
