Rekeningstelsel voor E-commerce: Hoe u slechte mappingbeslissingen kunt vermijden

U neemt een nieuwe Shopify-klant aan. U bouwt hun rekeningstelsel in QuickBooks Online — vijf categorieën, logische subrekeningen, rekeningnummers die de standaardconventie volgen. U koppelt de Shopify-integratie. Alles ziet er op papier correct uit.

Dan komt de eerste Shopify-uitbetaling binnen.

Shopify heeft € 14.200 op de bank gestort. QuickBooks toont € 15.800 aan Shopify-inkomsten. Het Shopify-dashboard rapporteert € 16.100 aan bruto verkopen. Drie verschillende cijfers, dezelfde maandactiviteit, geen enkele komt overeen. U besteedt vier uur aan het achterhalen van het verschil. Uiteindelijk vindt u het: kosten geregistreerd als bankoverschrijvingen, terugbetalingen die niet tegen de juiste rekeningen zijn geboekt, een btw-incassobedrag dat in de omzet staat in plaats van een verplichting. Het rekeningstelsel miste niets. Het was gewoon niet gebouwd voor hoe Shopify daadwerkelijk geld verplaatst.

Hier is de foute aanname waarop de meeste CoA-gidsen zijn gebaseerd: als u de juiste rekeningen in de juiste categorieën heeft, zal de reconciliatie werken — het is slechts een kwestie van het werk elke maand doen. Dat is niet waar voor Shopify. Rekeningnamen en nummering zijn basisvereisten. Wat bepaalt of uw Shopify-boekhouding reconcileert, is of het rekeningstelsel architectonisch compatibel is met hoe Shopify fondsen uitbetaalt — als netto uitbetaling, niet als bruto omzet. Vijf specifieke mappingbeslissingen bepalen of de maandafsluiting 30 minuten of het grootste deel van een middag duurt.

Het rekeningstelsel dat er goed uitziet tot de maandafsluiting

De meeste standaard templates voor rekeningstelsels — zelfs e-commerce-specifieke — zijn gebaseerd op de aanname dat inkomen als bruto omzet binnenkomt. Een verkoop van € 100 wordt geboekt als € 100 inkomen. Kosten worden geregistreerd wanneer u ze betaalt. Zo werken de meeste bedrijven.

Shopify werkt niet zo.

Shopify stuurt u geen € 100 wanneer een klant € 100 betaalt. Het stuurt u een netto uitbetaling — bruto verkopen minus betalingsverwerkingskosten, minus terugbetalingen, minus Shopify-transactiekosten, soms minus btw die namens u is geïnd, allemaal gebundeld in één bankoverschrijving die één tot veertien dagen aan bestellingen dekt. Tegen de tijd dat die uitbetaling op de bankrekening van uw klant staat, vertegenwoordigt het ten minste vijf verschillende financiële gebeurtenissen. Uw rekeningstelsel moet alle vijf ontvangen en ontleden, anders zal de reconciliatie elke maand mislukken.

De boekhoudingen zijn niet verkeerd. De architectuur wel.

Waarom Shopify's Netto Uitbetalingsstructuur het Architecturale Probleem is

Dit is wat een typische Shopify-uitbetaling daadwerkelijk bevat, uitgesplitst in posten:

• Brutoverkopen — omzet van alle bestellingen in de uitbetalingsperiode
• Betalingsverwerkingskosten — doorgaans 2,9% + € 0,30 per online transactie voor Shopify Payments (basisabonnement); afgetrokken vóór uitbetaling
• Shopify-transactiekosten — een extra 2% per transactie als de winkel Shopify Payments niet gebruikt; gebruikelijk bij oudere abonnementen
• Teruggaven verleend — bruto-teruggaven voor geretourneerde bestellingen in de uitbetalingsperiode
• Door marktplaats gefaciliteerde omzetbelasting — bedragen die Shopify heeft geïnd en rechtstreeks aan staatsautoriteiten zal afdragen namens de handelaar (in de meeste Amerikaanse staten is Shopify de marktplaatsfacilitator)

Wanneer uw integratie de storting rechtstreeks toewijst aan een 'Shopify Sales'-inkomstenrekening, voegt u alle vijf de gebeurtenissen samen tot één getal. De inkomsten worden te laag weergegeven omdat de kosten al zijn afgetrokken. De kosten voor de verwerking zijn onzichtbaar. De balans bevat een spookachtige belastingverplichting omdat u de inning van belastingen als inkomsten hebt geboekt.

De oplossing is niet om maand na maand achteraf op te ruimen. Het is het opbouwen van de rekeningschema zodat elk onderdeel automatisch naar de juiste rekening wordt gerouteerd — en een tussenrekening deze terugkoppelt naar de bankstorting. Dat vereist vijf specifieke beslissingen. De downstreamkosten van het verkeerd nemen ervan zijn de tijd die uw kantoor afschrijft op e-commerce-opdrachten.

Beslissingen 1 en 2: Bruto Omzetrekeningen en de Verrekenrekening

Beslissing 1: Brutoverkopen registreren als inkomsten, niet het stortingsbedrag.

Uw inkomstenaccounts moeten weergeven wat klanten daadwerkelijk hebben betaald — voordat Shopify iets aftrekt. Maak aparte inkomstenaccounts voor elk verkoopkanaal (Shopify-verkopen, WooCommerce-verkopen, groothandelsinkomsten) in plaats van één "e-commerce-verkopen"-categorie. Zodra u Shopify- en Amazon-inkomsten combineert in één account, verliest u de zichtbaarheid van de marge per kanaal, en er is geen praktische manier om deze te herstellen zonder de boekhouding opnieuw op te bouwen.

Een overzichtelijke inkomstensectie voor een klant die alleen Shopify gebruikt, ziet er als volgt uit:

• 4100 — Shopify-verkopen (bruto, vóór aftrek)
• 4110 — Shopify-verzendinkomsten (indien verzending aan klanten wordt gefactureerd)
• 4200 — Retouren en kortingen (contra-inkomsten)

De inkomstenrekeningen registreren wat er is verkocht. De bankstorting weerspiegelt wat er is uitbetaald na aftrek. Die twee getallen zijn structureel verschillend, en uw rekeningschema heeft een rekening nodig die ze overbrugt.

Beslissing 2: Gebruik een tussenrekening als brug.

Wanneer een verkoop wordt geregistreerd, wordt het bruto bedrag geboekt op de Shopify Sales inkomstenrekening en op de tussenrekening als een actief. Wanneer Shopify het netto uitbetalingsbedrag uitbetaalt, ontvangt de tussenrekening de aftrekkingen (kosten, terugbetalingen, belasting) en wordt deze nul. De bankstorting komt exact overeen met het netto uitbetalingsbedrag. Elk onderdeel komt op de juiste rekening terecht.

Zonder de tussenrekening probeer je een bankstorting te reconciliëren die niet overeenkomt met één enkele QBO-rekening - omdat deze niet bedoeld is om met één enkele rekening overeen te komen. Het is een netto van vijf financiële gebeurtenissen. Elke accountant die een avond heeft besteed aan een Shopify-reconciliatie zonder zo'n rekening, weet precies hoe dat voelt.

Maak één tussenrekening per betaalprovider. Als uw klant Shopify Payments en PayPal gebruikt, zijn dat twee tussenrekeningen. Het mengen ervan recreëert hetzelfde mismatch-probleem op het niveau van de tussenrekening dat u probeert op te lossen op het niveau van de inkomsten.

Hoe deze twee beslissingen worden afgedwongen: productkoppelingen.

Beslissingen 1 en 2 gelden alleen als de software die naar QBO post ze respecteert, en koppelingen zijn waar dat gebeurt. De volgorderegel komt rechtstreeks uit de eigen installatiedocumenten van LedgerPort: bouw eerst het rekeningschema op, koppel dan. LedgerPort koppelt aan uw *bestaande* QuickBooks-accounts — het maakt geen accounts achter uw rug om aan — dus de structuur die u in dit artikel ontwerpt, is de structuur die de synchronisatie respecteert.

Het koppelingsscherm is ook waar u de granulariteit van de omzet instelt. Elk product wordt gekoppeld aan een QBO-artikel, en elk artikel bevat een inkomstenaccount. Wijs veel producten toe aan één artikel en u krijgt de eenvoudige variant van deze sjabloon — één Shopify Sales-account. Koppel producten individueel en u krijgt omzet per SKU, plus COGS-posting op artikelen van het type Inventaris. Het is dezelfde beslissing als "één Verkoopaccount versus inkomstenaccounts per regel", gepresenteerd als een dropdown.

Twee details maken dit in de praktijk werkbaar. Ten eerste is de faalmodus veilig: een bestelling met een niet-gekoppeld product genereert een fout met een benoemde status — "Product niet gekoppeld" — en wordt vastgehouden in plaats van naar een verkeerd account te worden gepost, zodat de sjabloon niet stilzwijgend kan worden geschonden. Ten tweede is de installatie geen week vol dropdown-klikken: Auto-Map koppelt Shopify-producten aan QBO-artikelen op basis van SKU of naam met één klik, markeert de resultaten voor beoordeling en laat alleen de missers over voor handmatige koppeling.

Beslissingen 3 en 4: Scheiding van Kosten en Afhandeling van Teruggaven

Beslissing 3: Shopify-kosten zijn geen enkele post.

Drie afzonderlijke soorten kosten verschijnen in Shopify-uitbetalingen. Deze samenvoegen in één "Shopify-kosten"-account verliest zinvolle zichtbaarheid van waar de marge naartoe gaat:

Een duidelijke kostenstructuur in QBO:

• 6100 — Shopify Abonnement
• 6110 — Shopify Transactiekosten
• 6120 — Betalingsverwerkingskosten

Het samenvoegen van deze drie in één rekening is hoe accountants boeken erven waarbij een marge-erosie van 3% door betalingsverwerking onzichtbaar is - totdat iemand vraagt waarom de brutomarge lager is dan het prijsmodel voorspelt. Het scheiden ervan kost niets bij de installatie en bespaart tijd bij elke volgende beoordeling.

Beslissing 4: Terugbetalingen worden geboekt tegen de uitbetaling, niet tegen de oorspronkelijke bestelling.

Wanneer een klant een bestelling retourneert, trekt Shopify de terugbetaling af van de volgende beschikbare uitbetaling. Het creëert geen aparte banktransactie - het vermindert het netto bedrag van de uitbetaling. De tegenrekening voor Retouren en Kortingen moet de terugbetalingsboeking ontvangen op het moment van de uitbetaling die deze bevat, niet op het moment dat de retour werd verwerkt.

Als een retour in maart werd verwerkt, maar de terugbetaling in de uitbetaling van april verscheen, hoort de tegenboeking bij de retour in april. Het boeken ervan in maart creëert een periode-mismatch: de omzet van maart daalt, maar de bankreconciliatie van maart klopt nog steeds niet omdat het effect op de kas niet in maart plaatsvond. Periode-mismatches stapelen zich maand na maand op totdat de boeken een volledige opschoning vereisen om te ontwarren.

Beslissing 5: Omzetbelasting als Verplichting Vanaf Dag Één

In de meeste Amerikaanse staten is Shopify een marktplaatsfacilitator - wat betekent dat Shopify de omzetbelasting van klanten int en deze rechtstreeks afdraagt aan de belastingautoriteiten van de staat. De verkoper raakt dat geld nooit aan. De verkoper is de belasting niet verschuldigd; Shopify heeft deze al betaald.

Omzetbelasting die Shopify int, verschijnt in de totale bruto orderbedragen op het Shopify-dashboard, maar vloeit nooit naar de bankrekening van de verkoper en is geen inkomsten van de verkoper. Als uw inkomstenrekening totale bruto orderbedragen inclusief belasting registreert, overdrijft u uw inkomsten en bouwt u een spookschuld op de balans op.

De juiste instelling vereist twee aansprakelijkheidsrekeningen:

• Te betalen omzetbelasting — voor belasting die de verkoper rechtstreeks int en afdraagt (niet-marktplaatskanalen zoals groothandel, of staten waar de regels voor marktplaatsfacilitators niet van toepassing zijn)
• Marktplaatsbelasting ingehouden (of "Shopify-belasting geïnd") — voor belasting die Shopify namens de verkoper int en afdraagt; wordt nul na de uitbetalingscyclus omdat de aansprakelijkheid wordt geëxtingueerd door de afdracht van Shopify, niet door de verkoper

Als uw klant via meerdere kanalen verkoopt — Shopify, directe website, groothandel — verschilt de belastingbehandeling per kanaal. Eén enkele "Te betalen omzetbelasting"-rekening kan geen onderscheid maken tussen door Shopify afgehandelde belasting en door de verkoper afgehandelde belasting, en dat onderscheid is belangrijk op belastingtijd.

In LedgerPort wordt Beslissing 5 geleverd als een instelling in plaats van een maandelijkse discipline. Het tabblad Belastingen van de synchronisatieconfiguratie heeft een optie voor regelitembelasting: door het platform geïnde belasting wordt als een aparte regel op de QuickBooks-transactie geboekt, gerouteerd naar een aansprakelijkheidsaccount dat u kiest uit een dropdown. "Belasting is een verplichting, geen inkomen" is niet langer een regel die iemand moet onthouden en wordt de enige manier waarop de synchronisatie kan posten.

Dezelfde tab bevat het detail dat niemand uitlegt: belastingafronding. De belastingberekeningen van het platform en die van QuickBooks verschillen per cent of twee bij sommige bestellingen, en zonder een plek voor die centen lopen de boekhoudingen per bestelling een paar centen uit elkaar in een onherstelbare smurrie. De instelling Belastingafronding voegt een afrondingscorrectie-regelitem toe dat het verschil absorbeert — daarom komen de boekhoudingen tot op de cent overeen in plaats van "dichtbij genoeg". Dichtbij genoeg is niet sluitend.

Het rekeningstelsel dat op één dag wordt afgesloten

Wanneer alle vijf beslissingen zijn genomen, verloopt het einde van de maand als volgt: elke Shopify-uitbetaling loopt via de tussenrekening. Bruto verkopen worden bijgeschreven. Verwerkingskosten, terugbetalingen en marktplaatsbelasting worden afgeschreven. De netto bankstorting wordt geboekt. De tussenrekening sluit op nul. De bankafstemming klopt — per constructie, niet per onderzoek.

Dat is een proces van 20 minuten. Het verschil zit niet in de hoeveelheid werk — maar of de rekeningschema is ontworpen om de gegevens correct te ontvangen.

De initiële investering is reëel. Het correct bouwen van deze architectuur voor een nieuwe klant duurt de eerste keer twee tot drie uur — langer dan het kopiëren van een generieke sjabloon. Maar het alternatief is die uren, of meer, elke maand, voor onbepaalde tijd, besteden.

Voor accountants die vijf of tien Shopify-klanten beheren, is deze architectuur de basis van een herhaalbare sjabloon. Dezelfde vijf beslissingen zijn van toepassing op elke Shopify-winkel in QBO. Bouw het één keer correct, en u past het toe in de hele praktijk — u leert het probleem niet opnieuw met elke nieuwe opdracht.

Nog een beslissing: de synchronisatiemethode die naar deze accounts wordt gepost

Een rekeningschema is niet voltooid als de rekeningen bestaan. Het is voltooid als je hebt bepaald welk *soort* transactie erin wordt geboekt. In een synchronisatietool heeft die beslissing een naam: de synchronisatiemethode. In LedgerPort is het één dropdown — Sync Config » Orders » Sync Method, bereikbaar vanuit de linkerzijbalk van de app — met vijf opties, en elke optie vraagt iets anders van het schema dat je net hebt opgebouwd.

• Verkoopbon — één bon per bestelling, met regelitems, belastingen, verzending en kortingen, geboekt in inkomen en de verrekeningsrekening. Geen vorderingen vereist.
• Factuur — twee records per bestelling: de Factuur wanneer deze wordt geplaatst, een Betaling wanneer Shopify deze als betaald markeert. Kies deze en je schema heeft openstaande vorderingen nodig.
• Offerte — een niet-geboekt record; het raakt niets aan totdat het wordt geconverteerd. De documentatie is bot over hoe zeldzaam dit is: "Als je niet zeker weet of je het nodig hebt, heb je het waarschijnlijk niet nodig."
• Dagelijkse Samenvatting — één journaalpost per dag die alle bestellingen van die dag aggregeert. Als je deze selecteert, verschijnen er direct onder de dropdown accounttoewijzingsvelden.
• Tag-Gebaseerd — Shopify order tags routeren bestellingen naar verschillende transactietypes (wholesale → Factuur, retail → Verkoopbon, do-not-sync → overgeslagen), dus een gemengde retail/wholesale winkel kan zowel vorderingen als bon-gerelateerde rekeningen nodig hebben.

Kijk goed naar wat Dagelijkse Samenvatting doet: op het moment dat je het selecteert, vraagt de software je de rekeningen te benoemen waarnaar de dagelijkse journaalpost zal worden geboekt. Die toewijzingsvelden zijn de vijf beslissingen van dit artikel, weergegeven als formuliervelden — bruto-inkomsten, verrekening, kosten, terugbetalingen, belasting. Als je het bovenstaande schema hebt opgebouwd, vul je ze in één keer in. Als je dat niet hebt gedaan, is dit het scherm waar dat duidelijk wordt.

De beslissingslogica is kort. Standaard DTC-winkel, betaald bij het afrekenen: Verkoopbon — de standaard van de documentatie zelf, "het juiste startpunt voor de meeste winkels". B2B of betalingstermijnen: Factuur. Hoog volume — ongeveer 100 of meer bestellingen per dag — met een accountant die werkt met totalen: Dagelijkse Samenvatting, wat is hoe een maand met 3.000 bestellingen ~30 journaalposten wordt in plaats van 3.000 records.

En de regel die deze beslissing veilig maakt: het wijzigen van de synchronisatiemethode herschrijft nooit orders die al zijn gesynchroniseerd. Het geldt alleen voor de toekomst. Kies een methode, bekijk een uitbetalingscyclus die via de tussenrekening wordt verwerkt en ga opnieuw na of de vorm verkeerd is - de boekingen die je al hebt gesloten, blijven gesloten.

LedgerPort regelt de mapping automatisch — de synchronisatie boekt bruto verkopen, fee-regels, terugbetalingen en door de marktplaats geïnde belasting naar de juiste rekeningen bij elke uitbetalingscyclus, zodat de tussenrekening zonder handmatige tussenkomst sluit. Het rekeningschema moet nog steeds correct gestructureerd zijn om die gegevens te ontvangen, maar de bovenstaande vijf beslissingen geven u precies die structuur.

Als u een nieuwe Shopify-klant in QBO instelt - of een boekhouding overneemt die niet wordt afgestemd - zijn dit de vijf plaatsen waar u eerst moet kijken. Als een van de bovenstaande beslissingen niet is genomen, is dat de reden waarom de reconciliatie van vier uur nodig is. Het correct krijgen van de grootboekrekeningschema is ook de basis voor het hebben van belastingklare boeken wanneer uw CPA ze opvraagt - dezelfde vijf beslissingen die maandafsluiting schoon maken, maken jaarafsluiting eenvoudig. Zie hoe LedgerPort de mapping beheert voor een praktijk met meerdere klanten op ledgerport.com/cpas, of begin gratis.