Kontoplan för e-handel: Hur du undviker dåliga mappningsbeslut

Du tar dig an en ny Shopify-kund. Du bygger deras kontoplan i QuickBooks Online — fem kategorier, vettiga underkonton, kontonummer som följer standardkonventionen. Du ansluter Shopify-integrationen. Allt ser korrekt ut på pappret.

Sedan kommer den första Shopify-utbetalningen.

Shopify satte in 14 200 USD på banken. QuickBooks visar 15 800 USD i Shopify-intäkter. Shopify-instrumentpanelen rapporterar 16 100 USD i bruttoförsäljning. Tre olika siffror, samma månadsaktivitet, ingen av dem stämmer. Du spenderar fyra timmar på att jaga skillnaden. Till slut hittar du den: avgifter registrerade som banköverföringar, återbetalningar som inte bokfördes mot rätt konton, ett skatteinbetalningsbelopp som ligger i intäkterna istället för en skuld. Kontoplanen saknade inget. Den var bara inte byggd för hur Shopify faktiskt flyttar pengar.

Här är det falska antagandet som de flesta kontoplan-guider bygger på: *om du har rätt konton i rätt kategorier, kommer avstämningen att fungera — det är bara en fråga om att göra jobbet varje månad.* Det stämmer inte för Shopify. Kontonamn och numrering är grundläggande. Vad som avgör om dina Shopify-böcker stämmer är om kontoplanen är arkitektoniskt kompatibel med hur Shopify betalar ut medel — som en nettoutbetalning, inte som bruttointäkter. Fem specifika mappningsbeslut avgör om månadsslutet tar 30 minuter eller större delen av en eftermiddag.

Kontoplanen som ser rätt ut fram till månadsslutet

De flesta standardmallar för kontoplaner — även de som är specifika för e-handel — bygger på antagandet att inkomster kommer in som bruttointäkter. En försäljning på 100 USD bokförs som 100 USD i intäkter. Avgifter registreras när du betalar dem. Så fungerar de flesta företag.

Shopify fungerar inte så.

Shopify skickar dig inte 100 USD när en kund betalar 100 USD. Den skickar dig en nettoutbetalning — bruttoförsäljning minus betalningsbehandlingsavgifter, minus återbetalningar, minus Shopifys transaktionsavgifter, ibland minus moms som samlats in å dina vägnar, allt samlat i en enda banköverföring som täcker allt från en till fjorton dagars beställningar. När den utbetalningen når din kunds bankkonto representerar den minst fem distinkta finansiella händelser. Din kontoplan måste ta emot och disaggregera alla fem, annars kommer avstämningen att misslyckas varje månad.

Kontona är inte fel. Arkitekturen är det.

Varför Shopifys nettoutbetalningsstruktur är det arkitektoniska problemet

Här är vad en typisk Shopify-utbetalning faktiskt innehåller, uppdelat som specificerade poster:

• Bruttoförsäljning — topplinjeintäkter från alla ordrar under utbetalningsperioden
• Avgifter för betalningshantering — vanligtvis 2,9 % + 0,30 USD per online-transaktion för Shopify Payments (Basic-plan); dras av före utbetalning
• Shopify-transaktionsavgifter — ytterligare 2 % per transaktion om butiken *inte* använder Shopify Payments; vanligt på äldre planer
• Utfärdade återbetalningar — bruttoåterbetalningar för returnerade ordrar under utbetalningsperioden
• Marknadsplats-hanterad moms — belopp som Shopify samlat in och kommer att betala in direkt till delstatsmyndigheter å handlarens vägnar (i de flesta amerikanska delstater är Shopify marknadsplatsfacilitatorn)

När din integration mappar insättningen direkt till ett inkomstkonto för ”Shopify-försäljning”, slår du ihop alla fem händelser till ett enda nummer. Inkomsten är underrapporterad eftersom avgifter redan har dragits av. Kostnader för avgifter är osynliga. Balansräkningen har en spökande skatteskuld eftersom du registrerade skatteinbetalningen som intäkt.

Lösningen är inte att städa upp efteråt månad efter månad. Det är att bygga upp kontoplanen så att varje komponent dirigeras till rätt konto automatiskt — och ett clearingkonto kopplar dem tillbaka till bankinsättningen. Det kräver fem specifika beslut. De nedströmskostnader som uppstår om de blir fel är den tid din firma avskriver på e-handelsuppdrag.

Beslut 1 och 2: Bruttobokföringskonton och clearingkonto

Beslut 1: Registrera bruttoförsäljning som intäkt, inte insättningsbeloppet.

Your income accounts should reflect what customers actually paid — before Shopify deducts anything. Create separate income accounts for each sales channel (Shopify sales, WooCommerce sales, wholesale revenue) rather than a single “e-commerce sales” bucket. Once you combine Shopify and Amazon revenue into one account, you lose per-channel margin visibility, and there’s no practical way to recover it without rebuilding the books.

En ren inkomstsektion för enbart Shopify-klienter ser ut så här:

• 4100 — Shopify-försäljning (brutto, före avdrag)
• 4110 — Shopify-fraktintäkter (om frakt debiteras kunderna)
• 4200 — Returer och rabatter (motintäkt)

Inkomstkontona registrerar vad som såldes. Bankinsättningen återspeglar vad som betalades ut efter avdrag. Dessa två siffror är strukturellt olika, och din kontoplan behöver ett konto som kopplar ihop dem.

Beslut 2: Använd ett clearingkonto som brygga.

När en försäljning registreras bokförs bruttobeloppet på Shopifys försäljningsinkomstkonto och på clearingkontot som en tillgång. När Shopify betalar ut nettoutbetalningen, tar clearingkontot emot avdragen (avgifter, återbetalningar, skatt) och töms till noll. Bankinsättningen matchar nettoutbetalningen exakt. Varje komponent hamnar på rätt konto.

Utan clearingkontot försöker du avstämma en bankinsättning som inte matchar något enskilt QBO-konto – för den ska inte matcha något enskilt konto. Det är en netto av fem finansiella händelser. Varje revisor som har tillbringat en kväll med en Shopify-avstämning utan ett vet exakt hur det känns.

Skapa ett clearingkonto per betalningsprocessor. Om din klient använder Shopify Payments och PayPal, är det två clearingkonton. Att blanda dem återskapar samma matchningsproblem på clearingnivå som du försöker lösa på inkomstnivå.

How these two decisions get enforced: product mappings.

Decisions 1 and 2 only hold if the software posting into QBO respects them, and mappings are where that happens. The sequencing rule comes straight from LedgerPort’s own setup docs: build the chart of accounts first, then map. LedgerPort maps to your existing QuickBooks accounts — it doesn’t create accounts behind your back — so the structure you design in this article is the structure the sync respects.

The mapping screen is also where you set revenue granularity. Every product maps to a QBO item, and every item carries an income account. Point many products at one item and you get the simple variant of this template — a single Shopify Sales account. Map products individually and you get per-SKU revenue, plus COGS posting on Inventory-type items. It’s the same decision as “one Sales account vs. per-line revenue accounts,” surfaced as a dropdown.

Two details make this workable in practice. First, the failure mode is safe: an order containing an unmapped product errors with a named status — “Product Not Mapped” — and holds instead of posting to a wrong account, so the template can’t be silently violated. Second, the setup isn’t a week of dropdown clicking: Auto-Map matches Shopify products to QBO items by SKU or name in one click, flags the results for review, and leaves only the misses for manual mapping.

Beslut 3 och 4: Avskiljning av avgifter och hantering av återbetalningar

Beslut 3: Shopify-avgifter är inte en enskild post.

Three distinct fee types appear in Shopify payouts. Collapsing them into one “Shopify Fees” account loses meaningful visibility into where margin is going:

En ren avgiftsstruktur i QBO:

• 6100 — Shopify Prenumeration
• 6110 — Shopify Transaktionsavgifter
• 6120 — Betalningsbehandlingsavgifter

Att klumpa ihop alla tre i ett konto är hur revisorer ärver böcker där en 3 % marginalerosion från betalningsbehandling är osynlig – tills någon frågar varför bruttomarginalen är lägre än vad prismodellen förutsäger. Att separera dem kostar inget vid installation och sparar tid vid varje granskning efteråt.

Beslut 4: Återbetalningar bokförs mot utbetalningen, inte den ursprungliga ordern.

När en kund returnerar en order drar Shopify av återbetalningen från nästa tillgängliga utbetalning. Det skapar ingen separat banktransaktion – det minskar nettobeloppet av utbetalningen. Motintäktskontot för Returer och Avdrag bör ta emot återbetalningsposten vid tidpunkten för utbetalningen som innehåller den, inte vid tidpunkten då returen behandlades.

Om en retur behandlades i mars men återbetalningen kom i aprilutbetalningen, hör motintäktsposten hemma i april. Att bokföra den i mars skapar en periodmässig mismatch: mars intäkter minskar, men mars bankavstämning balanseras fortfarande inte eftersom kasseffekten inte skedde i mars. Periodmässiga mismatches ackumuleras månad efter månad tills böckerna kräver en fullständig sanering för att reda ut.

Beslut 5: Moms som en skuld från dag ett

I de flesta amerikanska stater är Shopify en marknadsplatsfacilitator – vilket innebär att Shopify samlar in moms från kunder och betalar den direkt till delstatliga skattemyndigheter. Handlaren rör aldrig de pengarna. Handlaren är inte skyldig skatten; Shopify har redan betalat den.

Moms som Shopify samlar in visas i bruttoorderbelopp på Shopify-instrumentpanelen, men den flödar aldrig till handlarens bankkonto och är inte handlarens intäkt. Om ditt inkomstkonto registrerar bruttoorderbelopp inklusive moms, överdriver du intäkterna och bygger en spökande skuld på balansräkningen.

Korrekt installation kräver två skuld-/passivakonton:

• Moms att betala – för moms som handlaren samlar in och betalar in direkt (icke-marknadsplatskanaler som grossistförsäljning, eller stater där regler för marknadsplatsförmedlare inte gäller)
• Marknadsplatsskatt innehållen (eller ”Shopify-moms insamlad”) – för moms som Shopify samlar in och betalar in å handlarens vägnar; nollställs efter utbetalningscykeln eftersom skulden kvittas genom Shopifys inbetalning, inte handlarens

Om din klient säljer via flera kanaler – Shopify, direkt webbplats, grossistförsäljning – skiljer sig momshanteringen per kanal. Ett enda konto för ”Moms att betala” kan inte skilja mellan moms som hanteras av Shopify och moms som hanteras av handlaren, och den distinktionen är viktig vid skattetillfället.

In LedgerPort, Decision 5 ships as a setting rather than a monthly discipline. The Taxes tab of the sync configuration has a Line Item Tax option: platform-collected tax posts as its own line on the QuickBooks transaction, routed to a liability account you pick from a dropdown. “Tax is a liability, not income” stops being a rule someone has to remember and becomes the only way the sync can post.

The same tab holds the detail nobody explains: tax rounding. The platform’s tax math and QuickBooks’ tax math disagree by a cent or two on some orders, and without a home for those cents the books drift a few cents per order into an unreconcilable smear. The Tax Rounding setting adds a rounding-adjustment line item that absorbs the difference — which is why the books tie to the cent instead of “close enough.” Close enough doesn’t close.

Kontoplanen som stängs på en dag

När alla fem beslut är på plats, körs månadsavslutningen så här: varje Shopify-utbetalning passerar genom clearingkontot. Bruttobransch kredit in. Avgifter för betalningshantering, återbetalningar och marknadsplatsskatt debet ut. Netto bankinsättning bokförs. Clearingkontot stängs till noll. Bankavstämningen balanserar – genom konstruktion, inte genom utredning.

Det är en 20-minutersprocess. Skillnaden är inte arbetsvolymen – det är om kontoplanen utformades för att ta emot data korrekt.

Den initiala investeringen är verklig. Att bygga denna arkitektur korrekt för en ny klient tar två till tre timmar första gången – längre än att kopiera en generell mall. Men alternativet är att spendera de timmarna, eller mer, varje månad, på obestämd tid.

För redovisningskonsulter som hanterar fem eller tio Shopify-klienter är denna arkitektur grunden för en repeterbar mall. Samma fem beslut gäller för varje Shopify-butik i QBO. Bygg den korrekt en gång, och du tillämpar den i hela praktiken – inte att lära om problemet med varje nytt uppdrag.

One more decision: the sync method that will post into these accounts

A chart of accounts isn’t finished when the accounts exist. It’s finished when you’ve decided what kind of transaction will post into them. In a sync tool, that decision has a name: the sync method. In LedgerPort it’s one dropdown — Sync Config » Orders » Sync Method, reached from the left sidebar of the app — with five options, and each option asks something different of the chart you just built.

• Sales Receipt — one receipt per order, with line items, taxes, shipping, and discounts, posting into income and the clearing account. No receivables required.
• Invoice — two records per order: the Invoice when it’s placed, a Payment when Shopify marks it paid. Choose this and your chart needs open receivables.
• Estimate — a non-posted record; it touches nothing until converted. The docs are blunt about how rare this is: “If you are unsure whether you need it, you probably do not.”
• Daily Summary — one journal entry per day aggregating all of that day’s orders. Selecting it exposes account-mapping fields right below the dropdown.
• Tag-Based — Shopify order tags route orders to different transaction types (wholesale → Invoice, retail → Sales Receipt, do-not-sync → skipped), so a mixed retail/wholesale store may need both receivables and receipt-side accounts.

Look closely at what Daily Summary does: the moment you select it, the software asks you to name the accounts its daily journal entry will post to. Those mapping fields are this article’s five decisions, rendered as form fields — gross revenue, clearing, fees, refunds, tax. If you built the chart above, you fill them in one pass. If you didn’t, this is the screen where that becomes obvious.

The decision logic is short. Standard DTC store, paid at checkout: Sales Receipt — the docs’ own default, “the right starting point for most stores.” B2B or payment terms: Invoice. High volume — roughly 100 or more orders a day — with an accountant who works from totals: Daily Summary, which is how a 3,000-order month becomes ~30 journal entries instead of 3,000 records.

And the rule that makes this decision safe: changing the sync method never rewrites orders that have already synced. It applies going forward only. Pick a method, watch a payout cycle post through the clearing account, and revisit if the shape is wrong — the books you’ve already closed stay closed.

LedgerPort hanterar mappningen automatiskt – synkroniseringen bokför bruttoförsäljning, avgiftsrader, återbetalningar och marknadsplatsinsamlad moms till sina korrekta konton vid varje utbetalningscykel, så att clearingkontot stängs utan manuellt ingripande. Kontoplanen måste fortfarande struktureras korrekt för att ta emot den datan, men de fem ovanstående besluten ger dig exakt den strukturen.

Om du sätter upp en ny Shopify-klient i QBO — eller tar över en bokföring som inte stämmer — är detta de fem platserna att titta på först. Om något av besluten ovan inte fattades, är det där den fyra timmar långa avstämningen kommer ifrån. Att ha rätt kontoplan är också grunden för att ha skattefärdiga böcker när din CPA frågar efter dem — samma fem beslut som gör månadsavslutningen ren gör årsavslutet enkelt. Se hur LedgerPort hanterar mappningen i en praktik med flera klienter på ledgerport.com/cpas, eller kom igång gratis.