WooCommerce redovisning för byråer: Guiden för första klienten

WooCommerce-bokföring för revisionsbyråer är mestadels din Shopify-spelbok, som överlever resan intakt. De tre ställen där den inte gör det är exakt där uppdraget går över budget.

---

Remissmejlet ligger i din inkorg. En av dina Shopify-klienter har en vän som "driver sin butik på WordPress — WooCommerce, tror jag?" — och eftersom du har stängt hans böcker senast den 10:e varje månad i år, sa han att du är byrån som hanterar e-handel.

Det har du förtjänat. Du har en Shopify onboarding-checklista som en medarbetare kan köra på under en timme: anslutningar, en standardmappningsmall, historisk återfyllning, en utbetalning spårad från början till slut. Så du öppnar den nya klientens system och förväntar dig Shopify med en annan logotyp.

Istället hittar du: Stripe *och* PayPal *och* en köp-nu-betala-senare-leverantör som du aldrig har stämt av. Ingen appbutik — en pluginsida med 31 poster, varav fyra vill ha uppdateringar. Och inget plattformsföretag som hostar något av det — klienten hyr en server från ett hostingföretag du aldrig hört talas om heller, och hennes brorson "hanterar webbplatsgrejerna."

Den frestande slutsatsen är den som de flesta byråer tyst drar: *WooCommerce-klienter är bara Shopify-klienter med extra steg — samma spelbok, mer tålamod.* Det är lögnen, och den är dyr, eftersom den innebär att varje Woo-specifik överraskning landar mitt i uppdraget istället för i offerten. Sanningen är att WooCommerce skiljer sig för revisionsbyråer på tre specifika, strukturella sätt — och var och en av dem har ett standardiserat svar som du kan fastställa som policy före kickoff-samtalet.

Varför WooCommerce-bokföring för revisionsbyråer är ett annorlunda jobb

Ingen av de tre skillnaderna handlar om bokföringen. Intäkter, avgifter, motkonton för returer, skatteskulder — identiskt med dina Shopify-klienter. Vad som ändras är var datan kommer ifrån och vem som kontrollerar maskinen som producerar den.

1. Det finns ingen enskild betalningskanal

En typisk Shopify-klient använder Shopify Payments, och de flesta av deras pengar kommer in via en enda utbetalningsström med en enda avgiftslogik. Din muskelminne för avstämning är byggd på det.

WooCommerce har ingen egen betalningsleverantör. Kassan är sammansatt: Stripe för kort, PayPal för att kunder förväntar sig det, kanske Klarna eller en regional processor som klienten lade till under en kampanj för två år sedan. Varje betalningsleverantör batchar utbetalningar enligt sitt eget schema, drar av sina egna avgifter och nettoutför returer enligt sin egen tidslinje. Det finns inget som heter "WooCommerce-utbetalningen" — det finns tre eller fyra orelaterade insättningsströmmar som träffar samma checkkonto.

Företagssidan svarar: rensning per gateway, deklarerad som stående policy. Ett rensningskonto och en avgiftsrad för varje gateway som är aktiv i butiken, skapad innan den första transaktionen synkroniseras – aldrig en delad "handelsavgifter"-behållare. Detta är samma rensningsarkitektur som du redan litar på; Woo-skillnaden är att du kör den parallellt, flera spår samtidigt. Mer om policyn nedan.

2. Klienten äger infrastrukturen

Shopify är en hostad plattform: drifttid, säkerhet och försäljningsdatabasen är Shopifys problem. En WooCommerce-butik är mjukvara som kunden kör på hosting som kunden valt. WordPress kärna, WooCommerce, PHP-versioner, SSL-certifikat och 30 andra plugins lever alla på infrastruktur som ditt företag inte har någon insyn i – och allt detta ligger uppströms från dina källdata.

Det gör dig inte till deras IT-avdelning. Det gör infrastrukturen till en scopingsfråga, på samma sätt som "är det QuickBooks Online eller Desktop?" är en scopingsfråga för Shopify-kunder.

Företagssidan svarar: åtkomst och uppdateringshygien hör hemma i ditt intagsmejl, inte i tredje månaden. Lägg till fyra frågor till checklistan före samtalet: Vem hostar webbplatsen och vem underhåller den? Är HTTPS aktiverat? (Synkroniseringsverktyg vägrar att ansluta utan det.) Matchar butikens valuta QuickBooks-företagets hemvaluta? Och vem har wp-admin-åtkomst med rättigheter att installera ett plugin? Fem minuters intag; det eliminerar hela kategorin av "webbplatsen var nere / certifikatet löpte ut / brorsonen uppdaterade något"-överraskningar.

3. Synkroniseringslagret är ett plugin som klienten installerar

För Shopify-kunder är synkroniseringsverktyget en appbutiksinstallation på en plattform som garanterar miljön. För WooCommerce är synkroniseringsverktyget ett WordPress-plugin, installerat i kundens wp-admin, som kommunicerar med butikens REST API. Anslutningen du är beroende av för rena böcker lever inom systemet från skillnad #2.

Företagssidan svarar: din onboarding-körlista inkluderar deras wp-admin. Inte som en börda – som ett tiominuters guidad steg du kör under kickoff-samtalet, med kunden (eller vem som nu har administratörsrättigheter) som styr. Installations- och anslutningsflödet är kort och standard, och att gå igenom det tillsammans innebär att du vet exakt vad som körs i deras butik. Nästa avsnitt täcker det.

Onboarding-skillnaden: Vad som ändras från din Shopify-checklista

Om du har byggt den femstegs Shopify-onboardingen, behåll den. Ryggraden överlever: förberedelser före samtal, anslutningar, mappning mot ditt företags standarddiagram, historisk återfyllning, första avstämningskontroll. Här är Woo-skillnaden, steg för steg.

Förberedelser före samtal ger infrastrukturfrågorna. Hosting, HTTPS, valutamatchning, wp-admin-åtkomst – de fyra från ovan. Allt annat i mejlet före samtalet (QBO-revisorinbjudan, vilket QuickBooks-företag, datumintervallet för återfyllning) är oförändrat.

Lägg till en femte frågeställning medan du ändå håller på: säljer kunden grossist? Det är den som oftast ändrar engagemangets form. En Woo-butik som driver B2B vid sidan av detaljhandeln genererar kundfordringar, kreditrisk och skattefria beställningar som en ren D2C-fil aldrig producerar – och svaret avgör om du mappar till ett clearingkonto eller ett AR-konto innan du mappar något. Fråga vad de kör det med också: Wholesale Suite och plugins som den hanterar roller, prisregler och kreditgränser som förklarar varför en viss beställning bokfördes som den gjorde, och du vill ha det synligt i wp-admin bredvid synkroniseringspluginet snarare än att upptäcka det i tredje månaden.

Anslutningssteget flyttas in i wp-admin. Istället för en URL-och-installera-app-handskakning på en hostad plattform, installerar kunden ett plugin. Med LedgerPort ser sekvensen under samtalet ut så här:

1. Installera. I klientens WordPress-admin: Plugins » Lägg till nytt plugin, sök efter LedgerPort, Installera nu, Aktivera. Installationsguiden öppnas automatiskt som ett helskärmsfönster.

2. Anslut. Guiden ber om ett klick för att starta anslutningsflödet.

3. Auktorisera. Klienten omdirigeras till app.ledgerport.com, loggar in, väljer företaget och auktoriserar — sedan landar de tillbaka i sitt WordPress-admin. Inga lösenord skickas, vilket är värt att säga högt under samtalet, precis som du skulle göra för en QuickBooks OAuth-behörighet.

4. Provisionering körs själv. LedgerPort skapar en WooCommerce REST API-nyckel med läsåtkomst och registrerar webhooks för ordrar, återbetalningar, produkter och kunder. Om något steg misslyckas rullas allt tillbaka automatiskt — butiken lämnas aldrig halvfärdigkonfigurerad. När det lyckas landar klienten på en ansluten instrumentpanel.

Här är delen att visa klienten — och den skeptiska IT-syskonbarnet — innan du går vidare: allt som pluginet provisionerade är synligt i butikens egna WooCommerce-inställningar, under Webhooks. Namngivet, listat, granskningsbart.

Den transparensen är det ärliga svaret på oron för åtkomsthygien från skillnad #2. Pluginet har läsåtkomst, dess fotavtryck kan inspekteras i wp-admin, och att koppla bort raderar API-nyckeln och webhooks som det skapade — inget dröjer sig kvar i en klients butik som du inte längre betjänar.

Mappning, återfyllning och verifiering är samma muskel. Din standard e-handelskarta gäller; produkt- och kontomappning körs från LedgerPort-menyn som nu finns i klientens wp-admin-sidofält — Dashboard, Mappings, Manual Sync, Audit Logs — så att kontrollera synkroniseringshälsan kräver aldrig att du loggar in på något nytt. Historisk återfyllning och steget för att filtrera revisionsloggen till Fel fungerar exakt som de gör på dina Shopify-filer.

Nettoförändring till körschemat: fyra intagningsfrågor och en tio minuters guidad installation. Det är hela "extra steg"-delen av lögnen — och det är den mindre halvan av historien.

Avstämning av betalningsleverantörer som stående policy

Den större halvan är skillnad #1, eftersom den återkommer varje avslut, inte bara vid introduktion. Skriv ner det som fast policy — tre rader:

Ett clearingkonto per gateway, inga undantag. Stripe Clearing, PayPal Clearing, en per ytterligare kanal — var och en ett Other Current Asset i klientens QBO-fil, skapad vid introduktion. Ett delat clearingkonto över gateways återuppbygger exakt det pussel du anlitades för att lösa.

En avgiftsrad per gateway. Blandade avgifter kan inte rimlighetskontrolleras. Varje gateways effektiva ränta blir en månads två minuters granskning: Stripe ligger normalt på cirka 3 %, och den månad den visar 4,1 %, hände något som är värt två minuter.

Klareringssaldon är hälsokontrollen. Varje klareringskonto bör endast innehålla pengar i transit – några dagars försäljning. Ett krypande saldo innebär att avgifter eller återbetalningar inte registreras på den specifika kanalen, och det talar om för dig vilken.

Vi härleder medvetet inte mekaniken här – arkitekturen för dagliga sammanfattningar och utbetalningsjournaler täcks, med uträknade siffror, i våra guider för butiksägare om att synkronisera WooCommerce med QuickBooks och bokföringsstrukturer för WooCommerce. Dessa två inlägg är också användbara ordagrant som kundutbildning: skicka dem till butiksägaren före starten och konversationen "varför kan du inte bara matcha insättningarna?" har redan ägt rum.

Det som är viktigt för firman är att denna policy är konfiguration, inte disciplin. LedgerPort upptäcker automatiskt varje gateway som är aktiv i butiken och ger varje en egen rad – klareringskonto, QBO-betalningsmetod, hantering av återbetalningar – med en standardåterkoppling för allt som inte är konfigurerat. Din junior ställer in det en gång vid introduktionen mot firmans standardkontoplan, och arkitekturen per gateway utför sig själv från och med då.

Underbetjänad och lojal

Nu argumentet för att bygga upp praktiken, eftersom det är starkare för WooCommerce än nästan någon annanstans inom e-handeln.

De flesta verktyg för e-handelsbokföring är Shopify-först. Det mesta innehållet, den mesta CPA-marknadsföringen, de flesta "vi talar e-handel"-positioneringar – Shopify-först. WooCommerce driver en jämförbar andel av världens onlinebutiker, men en Woo-butiksägare som letar efter en revisor som förstår utbetalningar per gateway och plugin-baserad synkronisering hittar nästan ingen. De Woo-inbyggda verktyg som finns löser mestadels ett annat problem – dubbelriktad synkronisering per order för fakturadrivna företag, vilket MyWorks gör genuint bra – inte avstämningsnivån för utbetalningar som en månadsavslutning beror på.

För en firma gör sådan knapphet två saker. Det gör remisskanalen oproportionerligt generös: betjäna en WooCommerce-kund väl och du blir "firman som kan hantera WordPress-butiker" i samhällen där den meningen är sällsynt. Och det gör kunderna klibbiga – en butiksägare vars böcker äntligen stämmer med banken, producerade av en firma som visste att fråga om hennes hosting innan hennes brorson förstörde den, går inte och letar efter en generalist för att spara 50 dollar i månaden.

Det är samma infrastrukturargument som vi gjorde i varför e-handelskunder förstör företagsmarginaler — marginalen bestäms av verktyg, inte kundtyp — med en uppgradering: på WooCommerce har konkurrensen inte läst det inlägget. Och portföljhanteringen förs över hel: CPA Partner Program tillämpar din Master Template-diagramkonfiguration över kunder oavsett om de kör Shopify eller WooCommerce, under en företagsinloggning, så att din sjätte Woo-kund ärver de beslut du fattade om din första.

Den andra remissen

Föreställ dig nästa. Ännu en WordPress-butik, ännu en sammansatt kassa — Stripe, PayPal och något nordiskt den här gången. Ditt intagsmejl ställer redan de fyra infrastrukturfrågorna. Ditt kickoff-samtal inkluderar en tio minuters plugin-installation som du har gjort tidigare. Din mappningsmall har redan rader för clearing per gateway, och månadsslutet för den här kunden är samma granskning-inte-rekonstruktion-avslutning som du kör på dina Shopify-filer.

Samma spelplan trots allt — bara inte den som lögnen lovade. Tre policyer, antagna en gång, och plattformsskillnaden slutar vara en anledning att skicka bort remissen.

Du har de tre skillnaderna och deras stående svar; det snabbaste sättet att trycktesta dem är på en riktig kundfil. Boka ett CPA-introduktionssamtal → och vi kör din första WooCommerce-kund med dig — de fyra intagsfrågorna, wp-admin-installationen, clearinginställningen per gateway och en första avslutning som knyter an till vart och ett av dessa insättningsströmmar.