Redovisning för flera butiker i QuickBooks: Håll böckerna rena

Redovisning för flera butiker i QuickBooks avgörs den dag du lanserar butik nr 2 – de flesta operatörer upptäcker det fjorton månader för sent.

---

Agendan för torsdagens möte med dig själv har en punkt: stäng ner butik nr 2, eller satsa dubbelt på den.

Så du öppnar QuickBooks för att få svaret. Totala intäkter har ökat. Handelsavgifterna har ökat. Annonskostnaderna har ökat rejält. Och inget av det har en butik kopplad till sig. Ditt "Försäljning"-konto är båda varumärkena sammanslagna till en siffra. Ditt avgiftskonto är en blandad siffra. Du kan inte, med den data du har framför dig, säga om den andra butiken tjänade pengar förra kvartalet eller tyst åt upp den första butikens marginal.

Det här är delen som ingen varnar dig för när du lanserar en andra butik – ett nytt varumärke, en ny region eller en WooCommerce-butik bredvid din Shopify-butik. Bokföringen fördubblas inte. Den tredubblas, för nu finns det ett tredje jobb: att hålla de två butikerna åtskilda. Och om du hoppade över det jobbet, vet du exakt varför, för du sa samma mening som nästan alla säger: "Jag kommer bara att lägga båda butikerna i samma QuickBooks-konton och dela upp det senare när jag behöver det."

Senare är nu. Och här är den obekväma mekaniska sanningen om redovisning för flera butiker i QuickBooks: sammanslagen data kan inte delas upp retroaktivt. Fjorton månaders transaktioner utan butiksetikett väntar inte på att sorteras – informationen fångades aldrig in. Beslutet som spelar roll fattas dag ett, i strukturen. De goda nyheterna är att strukturen inte är komplicerad. Det handlar om fyra beslut, och det här inlägget går igenom alla.

Redovisning för flera butiker i QuickBooks: En fil eller två?

Före clearingkonton, före avgiftsmappning, före allt – den strukturella frågan: ska butik nr 2 leva i din befintliga QuickBooks-fil eller i sin egen?

Beslutsregeln är tillräckligt kort för att memorera: den juridiska enheten är filgränsen. Varumärket eller kanalen är en klass eller plats inuti filen.

Din konfiguration	QuickBooks-struktur
Två butiker, en juridisk enhet (två varumärken, eller Shopify + WooCommerce)	En QBO-fil, med en klass eller plats per butik
Två butiker, två juridiska enheter som lämnar in separata deklarationer	Två QBO-filer – inga undantag
Holdingbolag med dotterbolag	En fil per enhet; konsolidera på rapporteringsnivån

Resonemanget går åt båda hållen. En QuickBooks-fil är bokföringen för en skatteenhet. Blanda två enheter i en fil och du kan inte producera någondera enhetens deklaration utan att dela upp filen – varje transaktion blir en "vars är den här?"-fråga vid sämsta möjliga tidpunkt. Dela en enhet över två filer och du får det motsatta problemet: ingen enskild resultaträkning, ingen enskild balansräkning och manuell konsolidering varje gång din revisor eller en långivare ber om helhetsbilden.

De flesta operatörer som läser detta är den första raden: en LLC, två butiker. Om det är du, är svaret en fil med spårning per butik – och resten av det här inlägget handlar om att bygga den.

En förutsättning värd att nämna: klass- och platspårning kräver QuickBooks Online Plus eller Advanced. Om du använder Essentials är den uppgraderingen en del av den verkliga kostnaden för butik nr 2. Budgetera för den snarare än att arbeta runt den – lösningen är blendern.

Och en deadline värd att nämna: i samma ögonblick som du sätter på synkroniseringsverktyg slutar arkitekturen att vara reversibel. I LedgerPort binder ett företag en butik till ett QuickBooks-företag, och när den anslutningen har auktoriserats kan QBO-företaget aldrig bytas till ett annat senare. Filfrågan måste avgöras innan någon klickar på Auktorisera – inte omprövas efter sex månader av transaktioner har flödat.

Notera vad verktyget också antar: ett QuickBooks-företag per företag. "Två filer, en inloggning" är den inbyggda, stödda formen, och varje företag är helt isolerat – dokumentationen säger det rakt ut: ändringar som görs i ett företag påverkar inte ett annat. Så om dina butiker är separata enheter är tvåfiler-svaret inte en kompromiss du kommer att slåss med din programvara om; det är standard som programvaran är byggd kring.

Strukturen per butik inuti en fil

Ren bokföring för flera butiker i en enda QBO-fil kommer ner till fyra delar. Ingen av dem är exotisk. Alla måste finnas innan transaktionerna flödar, inte efter.

1. En klass eller plats för varje butik

QuickBooks ger dig två taggningsdimensioner. Plats tillämpar en tagg per transaktion – vilket är exakt vad en butik är, så det är oftast den renare passformen. Klass kan dela upp enskilda rader inom en transaktion, vilket gör den bättre för saker som produktkategorier. En vettig standard: använd Plats för butiken och behåll Klass i reserv för en andra dimension du kanske vill ha senare.

Oavsett vilken du väljer är regeln total täckning. Varje kvitto, varje avgift, varje återbetalning får en butikstagg. En otaggad transaktion är en transaktion tillbaka i blendern.

2. Ett clearingkonto per butik, per gateway

Varje butiks betalningshanterare får ett eget clearingkonto i din kontoplan: Shopify Payments Clearing — Brand A, Shopify Payments Clearing — Brand B, Stripe Clearing — Woo Store. Försäljning flödar in i butikens clearingkonto; utbetalningar flödar ut från det till banken; kontot återgår till noll när allt stäms av.

Dela ett clearingkonto mellan butiker och du förlorar din bästa diagnostik. Ett clearingkonto som inte nollställs talar om för dig att något specifikt är fel – men bara om det tillhör en butik. Blanda två butiker i det och ett fel i Brand A döljs i Brand B:s saldo på obestämd tid.

Om din kontoplan föregår butik #2, är detta ögonblicket att omstrukturera den – vår mall för kontoplan för e-handel är startlayouten, och du duplicerar clearing- och avgiftsavsnitten per butik.

3. Avgiftsrader per butik

Mappa avgifter så att de är synliga per butik – antingen separata konton (Merchant Fees — Brand A) eller ett avgiftskonto med butikstaggen konsekvent tillämpad.

Detta är viktigare än det ser ut. Effektiv bearbetningskostnad skiljer sig per butik: olika gateway-mixar, olika genomsnittliga orderbelopp, olika återbetalningsfrekvenser. Om Brand B:s effektiva avgiftsränta är 3,1 % medan Brand A:s är 2,4 %, är det en verklig marginalskillnad du kan agera på – men bara om avgifterna aldrig har blandats.

4. En skriftlig regel för delade kostnader

Två butiker delar saker: ett annonskonto, ett 3PL-kontrakt, din egen lön. Välj en allokeringsgrund – intäktsdelning är bra – bokför det månadsvis med en återkommande journalpost, och skriv ner regeln. Perfekt allokering existerar inte. Konsekvent allokering är det som gör per-butik P&L trovärdig, och konsekvens överlever bara om regeln är dokumenterad snarare än ombeslutas varje månad.

[BILD: Utdrag ur kontoplan som visar parallella avsnitt per butik – två clearingkonton och två avgifter för handlare, märkta Brand A och Brand B]

Om en av dina butiker är WooCommerce, kommer dess orderdata in rörigare än Shopifys – bokföringsguiden för WooCommerce täcker dessa specifikationer innan du införlivar den butiken i denna struktur.

De tre fällorna som blandar ihop böckerna igen

Även en korrekt installation försämras på förutsägbara platser. Tre av dem står för det mesta av skadan.

Lageröverföringar mellan butiker. Att flytta lager från Brand A till Brand B är inte en försäljning – ni är samma juridiska enhet. Registrera det som en och Brand A visar intäkter som den aldrig tjänat medan Brand B:s COGS (kostnad för sålda varor) går snett. Överför till självkostnad med en journalpost mellan lagerstillgångskonton, ingen intäktsrad någonstans. (Om dina butiker *är* separata enheter gäller motsatsen: det är en verklig intern försäljning, till ett försvarbart pris – ännu en anledning till att beslutet om enhetsgränsen kommer först.)

Delad annonskostnad. Ett Meta-konto finansierar båda butikernas kampanjer, och kortavgiften hamnar som en enda utgift. Låt det vara osplittrat och en butik bär tyst den andras förvärvskostnad — vanligtvis den äldre butiken som subventionerar den nya, vilket får den nya butiken att se bättre ut än vad den är. En gång i månaden, hämta utgifter per kampanj och dela upp kostnaden per butikstagg. Det tar tjugo minuter, och det är skillnaden mellan en P&L per butik och fiktion per butik.

En gateway som betjänar två butiker. Det är frestande att köra den andra butikens kassa genom betalkontot du redan har. Gör inte det. Varje utbetalning innehåller nu två butikers beställningar, och det finns inget rent sätt att dela en insättning efter att den har landat. Ett gateway-konto per butik. Den extra administrationen är trivial jämfört med ett bankflöde du aldrig kan hänföra.

Fällorna som verktygen vägrar låta dig falla i

Blandade böcker kommer vanligtvis från processavvikelser, och synkroniseringsverktyg stänger vissa avvikelspunkter strukturellt. Två skyddsräcken och en kvarvarande risk, alla namngivna i LedgerPorts egna dokument.

Skyddsräcke ett: en butik kan inte hävdas två gånger. Försök att ansluta en butik som redan är länkad till ett annat LedgerPort-konto och anslutningen misslyckas med ett tydligt felmeddelande — "Den här webbplatsen är redan ansluten till ett annat konto." Det blockerar faran med flera operatörer där två synkroniseringspipelines tyst kämpar om en butik, var och en skriver sin egen version av böckerna.

Skyddsräcke två: butiksgränser är synliga, inte upptäckta. Antal anslutningar är planbaserade och visas direkt på anslutningssidan, så "hur många butiker täcker detta" är aldrig en supportbiljett — du når "Maximalt antal anslutningar nått" vid gränsen, inte en tyst partiell synkronisering.

Den kvarvarande risken värd att känna till: Dubbel postning i QuickBooks. När en manuell synkronisering och en autosynkronisering överlappar samma beställning, kan samma beställningsnummer postas två gånger. Det yttrar sig som ett namngivet fel med en dokumenterad lösning — verifiera i QBO, ta bort dubbletten, synkronisera om — snarare än att gömma sig i dina intäkter tills avstämning.

Vad synlighet per butik faktiskt förändrar

Gå tillbaka till torsdagens möte. Samma fråga — lägg ner eller dubbla insatserna — men nu kör du P&L per plats och svaret finns i två kolumner.

Säg att Varumärke B omsatte 38 000 dollar förra månaden. Efter *sina egna* avgifter, *sin* allokerade annonskostnad, *sin* frakt, ligger det på 4 % netto medan Varumärke A ligger på 12 % — nu vet du att den andra butiken är ett marginalproblem av en specifik storlek, och du kan se vilken rad som är boven. Eller så vänder kolumnerna: B är den bättre marginalverksamheten och A:s volym hade dolt det, i vilket fall det att lägga ner B skulle ha varit ett dyrt misstag gjort med självsäkert klingande blandade siffror.

Det är den verkliga avkastningen av denna struktur. Inte ordning – styrning. Vilken butik som får nästa 10 000 USD i lager. Om varumärke B:s fraktprissättning behöver ändras. Vad du visar en långivare som frågar efter butiksnivåprestanda. Din revisor får en ren fil istället för en skokartong med två företag i, och vart och ett av dessa samtal görs baserat på bevis.

Butiksspecifik synlighet har ett andra lager som de flesta operatörer missar: synlighet för synkronisering per butik. I LedgerPort har varje företag sin egen revisionslogg – entitetstyper inkluderar utbetalning och daglig sammanfattning, inte bara beställningar – så att kontrollen före mötet är ett filter, inte ett kalkylblad: ställ in status till osynkroniserad eller fel per butik, sextio sekunder per butik, och du vet att varje butiks böcker faktiskt är aktuella innan någon öppnar resultaträkningen. Om en butik inte är aktuell, är återställningen receptet för dokumentens egen driftstörning: datumintervallfilter över luckfönstret, Markera alla, Synkronisera markerade – per butik, utan att röra de butiker som är okej. En ärlig anmärkning: loggbevarandet är planbaserat (7, 30 eller 90 dagar, upp till obegränsat), så ett företag som gör kvartalsvisa granskningar behöver ett av de längre fönstren.

Var LedgerPort passar in

Allt ovanstående kan uppnås manuellt. Det är också en permanent disciplin: varje beställning, återbetalning, utbetalning och avgift, taggad till rätt butik och dirigerad till rätt clearingkonto, varje dag, över alla butiker. Felmodellen är inte okunskap – det är en hektisk Q4.

Detta är det specifika jobb som automatiserad synkronisering för flera butiker finns till för – oavsett om du hanterar redovisning för flera Shopify-butiker eller en blandning av Shopify-plus-WooCommerce. LedgerPorts synkronisering för flera butiker ansluter varje Shopify- eller WooCommerce-butik till samma QuickBooks Online-fil och upprätthåller gränserna åt dig: varje butik får sitt eget clearingkonto, sin egen avgiftsmappning och sin egen klass- eller platsmärkning, med beställningar, återbetalningar, utbetalningar och avgifter som bokförs per butik automatiskt.

Inne i instrumentpanelen är gränsen strukturell, inte en namngivningskonvention: varje butik lever som sitt eget företag under en inloggning. Klicka på företagsnamnet i det övre vänstra hörnet och växlingsknappen listar varje butik på kontot – var och en helt isolerad, med sina egna anslutningar, synkroniseringsloggar, mappningar och inställningar, så att inget från varumärke A blöder in i varumärke B.

Att lägga till butik nr 2 – eller nr 3 – kräver ett namn, en valuta och en tidszon. Sedan ansluter du den butiken och dess QuickBooks-företag på samma sätt som du gjorde den första.

Åtkomst följer samma gränser. Roller ställs in per företag, så du kan bjuda in din bokförare till Butik A:s böcker – där de kan se synkroniseringsloggar och köra manuella synkroniseringar – utan att de någonsin ser Butik B eller din fakturering. Uppdelningen Admin/Medlem täcks i Hur man lägger till teammedlemmar och hanterar roller.

För firmor som hanterar klientbutiker: samma struktur skalar till klientarbete – varje klientbutik är sitt eget isolerade företag under din firmas inloggning, med rollbaserad åtkomst per klient. Se CPA Partner Program och Guide till LedgerPort CPA Partner Program.

Driver du butiker på två plattformar? Shopify-plus-WooCommerce-fallet fungerar på samma sätt, från samma konto. Shopify-butiken ansluts på cirka 15 minuter – Kom igång med LedgerPort är hela vägen – och WooCommerce-butiken installeras som en plugin och slutförs via en installationsguide, enligt Installera LedgerPort i en WooCommerce-butik och anslut till QuickBooks Online. Båda butikerna synkroniseras till QuickBooks med sina egna gränser intakta – ingen andra verktyg, inget andra abonnemang.

Om prissättning: Scale-planen (från 67 USD/månad, 5 000 ordrar/månad) hanterar upp till 3 butiker med synkronisering i realtid och journaler för utbetalningar och avgiftshantering per butik – vilket täcker de flesta två-varumärkes- eller Shopify-plus-Woo-operatörer. Enterprise (från 169 USD/månad) tar bort gränserna: obegränsade butiker och ordrar, redovisning av presentkort och butikskrediter, och en dedikerad kontoansvarig. Årlig fakturering sparar 15 %, och allt har en 14-dagars pengarna-tillbaka-garanti – 100 % återbetalning, inga frågor ställda.

Ärlig gräns: LedgerPort kommer inte att bestämma din regel för fördelning av delade kostnader eller bokföra dina lageröverföringar mellan butiker. Dessa bedömningsbeslut stannar hos dig och din revisor. Vad det tar bort är den dagliga transaktionsdisciplinen – den del som tär.

Två-klicksmötet

Nästa kvartal sker mötet igen – den här gången handlar det om huruvida butik #3 är en bra idé.

Du öppnar QuickBooks. Rapporter. Resultaträkning per plats. Två klick. Varumärke B ligger på 9 % netto och klättrar sedan du ändrade priset på frakten i april. Varumärke A är stabilt. Mötet tar fyra minuter, varav de flesta spenderar du på att fundera på vad du ska göra med resten av timmen.

Det är det mest antiklimaktiska strategimötet du någonsin kommer att ha. Det är målet.

Blender kör bara åt ett håll – butiksdata som du inte separerar idag är den resultaträkning per butik som du inte kan dra nästa år. Om du sätter upp butik #2 nu, eller om butik #2 anlände för fjorton månader sedan och böckerna aldrig kom ikapp, se hur LedgerPort håller varje butiks böcker separata automatiskt, eller börja gratis och anslut din första butik på cirka 15 minuter.