Účtová osnova pro e-commerce: Jak se vyhnout špatným rozhodnutím při mapování

Převezmete nového klienta Shopify. Vytvoříte jeho účetní osnovu v QuickBooks Online — pět kategorií, rozumné podúčty, číslování účtů podle standardní konvence. Připojíte integraci Shopify. Všechno vypadá na papíře správně.

Pak přijde první platba od Shopify.

Shopify uložilo na účet 14 200 $. QuickBooks ukazuje 15 800 $ příjmů od Shopify. Dashboard Shopify hlásí 16 100 $ hrubých prodejů. Tři různá čísla, stejná měsíční aktivita, žádné z nich nesouhlasí. Strávíte čtyři hodiny hledáním rozdílu. Nakonec ho najdete: poplatky zaznamenané jako bankovní převody, vrácení peněz, které se nepromítly do správných účtů, částka daně vybraná místo závazku. Účetní osnova nic nepostrádala. Jen nebyla postavena na tom, jak Shopify skutečně pohybuje penězi.

Zde je falešný předpoklad, na kterém staví většina průvodců účetní osnovou: pokud máte správné účty ve správných kategoriích, vyrovnání bude fungovat — je to jen otázka práce každý měsíc. To pro Shopify neplatí. Názvy účtů a číslování jsou základní požadavky. To, co rozhoduje o tom, zda se vaše účetnictví Shopify vyrovná, je, zda je účetní osnova architektonicky kompatibilní s tím, jak Shopify vyplácí prostředky — jako čistou platbu, nikoli jako hrubé příjmy. Pět konkrétních rozhodnutí o mapování určuje, zda měsíční uzávěrka trvá 30 minut nebo většinu odpoledne.

Účetní osnova, která vypadá správně až do uzávěrky měsíce

Většina standardních šablon účetních osnov — dokonce i ty specifické pro e-commerce — je postavena na předpokladu, že příjem přichází jako hrubý příjem. Prodej za 100 $ se zaúčtuje jako 100 $ příjmu. Poplatky se zaznamenávají, když je platíte. Tak funguje většina podniků.

Shopify tak nefunguje.

Shopify vám nepošle 100 $, když zákazník zaplatí 100 $. Pošle vám čistou platbu — hrubé prodeje mínus poplatky za zpracování platby, mínus vrácení peněz, mínus transakční poplatky Shopify, někdy mínus daň z prodeje vybraná vaším jménem, vše zabalené do jednoho bankovního převodu pokrývajícího jeden až čtrnáct dní objednávek. V době, kdy tato platba dorazí na bankovní účet vašeho klienta, představuje nejméně pět různých finančních událostí. Vaše účetní osnova musí všech pět přijmout a rozdělit, jinak bude vyrovnání každý měsíc selhávat.

Účty nejsou špatné. Architektura je.

Proč je struktura čistých plateb Shopify architektonickým problémem

Zde je to, co typická platba od Shopify skutečně obsahuje, rozděleno jako položky:

• Hrubé tržby — celkové příjmy ze všech objednávek v zúčtovacím období
• Poplatky za zpracování plateb — obvykle 2,9 % + 0,30 USD za online transakci pro Shopify Payments (základní plán); odečteno před výplatou
• Transakční poplatky Shopify — dodatečných 2 % za transakci, pokud obchod nepoužívá Shopify Payments; běžné u starších plánů
• Vydané refundace — hrubé refundace za vrácené objednávky v zúčtovacím období
• Daň z obratu zprostředkovaná tržištěm — částky, které Shopify shromáždil a které přímo odvede státním orgánům jménem obchodníka (ve většině států USA je Shopify zprostředkovatelem tržiště)

Když vaše integrace mapuje vklad přímo na účet příjmů „Tržby Shopify“, zmenšujete všech pět událostí na jedno číslo. Příjmy jsou podhodnoceny, protože poplatky již byly odečteny. Náklady na poplatky jsou neviditelné. Rozvaha nese fiktivní daňovou povinnost, protože jste výběr daní zaznamenali jako příjem.

Náprava nespočívá v úklidu zpětně měsíc co měsíc. Je to vytvoření účtové osnovy tak, aby každá složka automaticky směřovala na správný účet — a zúčtovací účet je propojuje zpět s bankovním vkladem. To vyžaduje pět konkrétních rozhodnutí. Následné náklady na jejich špatné nastavení jsou čas, který vaše firma odepíše z angažmá v oblasti e-commerce.

Rozhodnutí 1 a 2: Účty hrubých příjmů a zúčtovací účet

Rozhodnutí 1: Zaznamenávejte hrubé tržby jako příjem, nikoli jako částku vkladu.

Vaše příjmové účty by měly odrážet to, co zákazníci skutečně zaplatili – než Shopify cokoli odečte. Vytvořte si samostatné příjmové účty pro každý prodejní kanál (prodeje Shopify, prodeje WooCommerce, velkoobchodní příjmy) namísto jediného „příjmy z e-commerce“. Jakmile zkombinujete příjmy ze Shopify a Amazonu do jednoho účtu, ztratíte přehled o marži na kanál a neexistuje žádný praktický způsob, jak ji obnovit bez přepracování účetnictví.

Přehledná sekce příjmů pro klienta pouze se Shopify vypadá takto:

• 4100 — Tržby Shopify (hrubé, před odečtením)
• 4110 — Příjmy z dopravy Shopify (pokud jsou poplatky za dopravu účtovány zákazníkům)
• 4200 — Vrácení a slevy (kontra-příjem)

Příjmové účty zaznamenávají, co bylo prodáno. Bankovní vklad odráží to, co bylo vyplaceno po odečtení. Tato dvě čísla jsou strukturálně odlišná a vaše účtová osnova potřebuje účet, který je propojuje.

Rozhodnutí 2: Použijte zúčtovací účet jako propojení.

Když je zaznamenána tržba, hrubá částka se zaúčtuje na příjmový účet Tržby Shopify a na zúčtovací účet jako aktivum. Když Shopify vyplatí čistou částku, zúčtovací účet obdrží odečtené položky (poplatky, refundace, daně) a vyrovná se na nulu. Bankovní vklad přesně odpovídá čisté výplatě. Každá složka je zaúčtována na správný účet.

Bez zúčtovacího účtu se snažíte spárovat bankovní vklad, který neodpovídá žádnému jednotlivému účtu QBO – protože nemá odpovídat žádnému jednotlivému účtu. Jedná se o čistý součet pěti finančních událostí. Každý účetní, který strávil večer nad vypořádáním Shopify bez něj, přesně ví, jaký to je pocit.

Vytvořte jeden zúčtovací účet na zpracovatele plateb. Pokud váš klient používá Shopify Payments a PayPal, jedná se o dva zúčtovací účty. Jejich smícháním se na úrovni zúčtování obnoví stejný problém s nesouladem, který se snažíte vyřešit na úrovni příjmů.

Jak se tato dvě rozhodnutí vynucují: mapování produktů.

Rozhodnutí 1 a 2 platí pouze v případě, že software odesílající do QBO je respektuje, a mapování je to, kde se to děje. Pravidlo sekvencování pochází přímo z vlastní dokumentace nastavení LedgerPort: nejprve vytvořte účtovou osnovu, poté mapujte. LedgerPort mapuje na vaše *existující* účty QuickBooks – nevytváří účty za vašimi zády – takže struktura, kterou navrhnete v tomto článku, je struktura, kterou synchronizace respektuje.

Obrazovka mapování je také místem, kde nastavujete podrobnost příjmů. Každý produkt se mapuje na položku QBO a každá položka nese příjmový účet. Pokud nasměrujete mnoho produktů na jednu položku, získáte jednoduchou variantu této šablony – jediný účet prodeje Shopify. Pokud mapujete produkty jednotlivě, získáte příjmy na SKU a také náklady na prodané zboží u položek typu skladem. Je to stejné rozhodnutí jako „jeden účet prodeje vs. účty pro jednotlivé řádky příjmů“, prezentované jako rozbalovací nabídka.

Dva detaily činí toto řešení prakticky proveditelným. Zaprvé, režim selhání je bezpečný: objednávka obsahující nemapovaný produkt vygeneruje chybu s pojmenovaným stavem – „Produkt není namapován“ – a pozastaví se místo odeslání na nesprávný účet, takže šablonu nelze tiše porušit. Zadruhé, nastavení nezabere týden klikání na rozbalovací nabídky: Auto-Map spáruje produkty Shopify s položkami QBO podle SKU nebo názvu jedním kliknutím, označí výsledky k revizi a ponechá pouze chybějící položky k ručnímu mapování.

Rozhodnutí 3 a 4: Oddělení poplatků a zpracování vrácení peněz

Rozhodnutí 3: Poplatky Shopify nejsou jediná položka.

Tři odlišné typy poplatků se objevují ve výplatách Shopify. Jejich sloučení do jednoho účtu „Poplatky Shopify“ ztrácí smysluplný přehled o tom, kam směřuje marže:

Přehledná struktura poplatků v QBO:

• 6100 — Předplatné Shopify
• 6110 — Transakční poplatky Shopify
• 6120 — Poplatky za zpracování plateb

Sloučení všech tří do jednoho účtu je důvodem, proč účetní dědí knihy, kde je 3% eroze marže z platebních transakcí neviditelná – dokud se někdo nezeptá, proč je hrubá marže nižší, než předpokládá cenový model. Jejich oddělení nestojí při nastavení nic a šetří čas při každé následné kontrole.

Rozhodnutí 4: Vrácení peněz se zaúčtuje proti výplatě, nikoli proti původní objednávce.

Když zákazník vrátí objednávku, Shopify odečte vrácenou částku z další dostupné výplaty. Nevytváří samostatnou bankovní transakci – snižuje čistou částku poukázané částky. Protikontokonto pro vrácení peněz a slevy by mělo přijmout záznam o vrácení peněz v době výplaty, která jej obsahuje, nikoli v době, kdy bylo vrácení zpracováno.

Pokud bylo vrácení zpracováno v březnu, ale vrácená částka se objevila ve výplatě v dubnu, záznam protikontokonta patří do dubna. Jeho zaúčtování do března vytváří časový nesoulad: březnové příjmy klesnou, ale březnové bankovní vypořádání stále nesouhlasí, protože peněžní efekt nenastal v březnu. Časové nesoulady se hromadí měsíc co měsíc, dokud knihy nevyžadují kompletní úklid k rozpletení.

Rozhodnutí 5: Daň z prodeje jako závazek od prvního dne

Ve většině států USA je Shopify zprostkovatelem tržiště – což znamená, že Shopify vybírá daň z prodeje od zákazníků a přímo ji odvádí státním daňovým úřadům. Obchodník s těmito penězi nikdy nemanipuluje. Obchodník daň nedluží; Shopify ji již zaplatil.

Daň z prodeje, kterou Shopify vybírá, se na řídicím panelu Shopify zobrazuje v hrubých celkových částkách objednávek, ale nikdy neprotéká na bankovní účet obchodníka a není příjmem obchodníka. Pokud váš příjmový účet zaznamenává hrubé celkové částky objednávek včetně daně, nadhodnocujete příjmy a vytváříte na rozvaze fiktivní závazek.

Správné nastavení vyžaduje dva závazkové účty:

• Daň z prodeje k úhradě – pro daň, kterou obchodník vybírá a odvádí přímo (kanály mimo tržiště, jako je velkoobchod, nebo státy, kde neplatí pravidla zprostředkovatele tržiště)
• Daň z tržiště zadržená (nebo „Daň vybraná Shopify“) – pro daň, kterou Shopify vybírá a odvádí jménem obchodníka; po zúčtovacím cyklu se vyrovná na nulu, protože závazek je uhrazen odvodem Shopify, nikoli obchodníka

Pokud váš klient prodává prostřednictvím více kanálů – Shopify, přímý web, velkoobchod – daňové zacházení se liší podle kanálu. Jediný účet „Daň z prodeje k úhradě“ nemůže rozlišovat mezi daní zpracovanou Shopify a daní zpracovanou obchodníkem, a toto rozlišení je v době daní důležité.

V LedgerPort je rozhodnutí 5 dodáváno jako nastavení spíše než jako měsíční disciplína. Karta Daně v konfiguraci synchronizace má možnost Položka daně: daň shromážděná platformou se odešle jako samostatný řádek v transakci QuickBooks, směrovaný na účet závazků, který vyberete z rozbalovací nabídky. „Daň je závazek, nikoli příjem“ přestává být pravidlem, které si někdo musí pamatovat, a stává se jediným způsobem, jak může synchronizace odesílat data.

Stejný list obsahuje detail, který nikdo nevysvětluje: zaokrouhlování daní. Daňová matematika platformy a daňová matematika QuickBooks se u některých objednávek liší o cent nebo dva a bez místa pro tyto centy se knihy odchylují o několik centů na objednávku do neslučitelného rozmazání. Nastavení zaokrouhlování daní přidává položku úpravy zaokrouhlení, která absorbuje rozdíl – proto se knihy shodují na cent místo „dostatečně blízko“. Dostatečně blízko neznamená uzavřeno.

Účetní osnova, která se uzavře za jeden den

Když jsou všechna tato pět rozhodnutí zavedena, měsíční uzávěrka probíhá takto: každá platba ze Shopify prochází zúčtovacím účtem. Hrubé tržby se připíší. Poplatky za zpracování plateb, vrácení peněz a daň z tržiště se odečtou. Čistý bankovní vklad se zaúčtuje. Zúčtovací účet se uzavře na nulu. Bankovní výpis se shoduje – konstrukcí, nikoli vyšetřováním.

To je 20minutový proces. Rozdíl není v objemu práce – je v tom, zda byl účetní rozvrh navržen tak, aby správně přijímal data.

Počáteční investice je reálná. Správné vybudování této architektury pro nového klienta trvá poprvé dvě až tři hodiny – déle než kopírování obecné šablony. Alternativou je však strávit tyto hodiny, nebo více, každý měsíc, neurčitě.

Pro účetní (CPA), kteří spravují pět nebo deset klientů Shopify, je tato architektura základem opakovaně použitelné šablony. Těchto pět stejných rozhodnutí platí pro každý obchod Shopify v QBO. Vybudujte to jednou správně a aplikujete to v celé praxi – nebudete se muset znovu učit problém s každým novým závazkem.

Další rozhodnutí: metoda synchronizace, která se odešle do těchto účtů

Účtová osnova není hotová, když účty existují. Je hotová, když jste se rozhodli, jaký typ transakce se do nich zaúčtuje. V synchronizačním nástroji se toto rozhodnutí jmenuje: metoda synchronizace. V LedgerPort je to jeden rozbalovací seznam – Sync Config » Orders » Sync Method, dosažitelný z levého postranního panelu aplikace – s pěti možnostmi a každá možnost vyžaduje něco jiného od účtové osnovy, kterou jste právě vytvořili.

• Prodejní doklad – jeden doklad na objednávku s položkami, daněmi, dopravou a slevami, zaúčtovaný do příjmů a zúčtovacího účtu. Nevyžaduje pohledávky.
• Faktura – dva záznamy na objednávku: faktura při jejím zadání, platba při označení Shopify jako zaplacené. Zvolte tuto možnost a vaše účtová osnova bude potřebovat otevřené pohledávky.
• Odhad – nezaúčtovaný záznam; nedotkne se ničeho, dokud nebude převeden. Dokumentace je o tom, jak vzácné to je, stručná: „Pokud si nejste jisti, zda jej potřebujete, pravděpodobně jej nepotřebujete.“
• Denní souhrn – jeden účetní zápis denně agregující všechny objednávky daného dne. Jeho výběr odhalí pole pro mapování účtů přímo pod rozbalovacím seznamem.
• Založeno na značkách – značky objednávek Shopify směrují objednávky do různých typů transakcí (wholesale → Faktura, retail → Prodejní doklad, do-not-sync → přeskočeno), takže smíšený velkoobchodní/maloobchodní obchod může potřebovat jak účty pohledávek, tak účty prodejních dokladů.

Podívejte se pozorně, co Denní souhrn dělá: v okamžiku, kdy jej vyberete, software vás požádá o pojmenování účtů, na které se jeho denní účetní zápis zaúčtuje. Tato pole pro mapování jsou pět rozhodnutí tohoto článku, vykreslená jako pole formuláře – hrubé příjmy, zúčtování, poplatky, vrácení peněz, daně. Pokud jste vytvořili výše uvedenou účtovou osnovu, vyplníte je v jednom průchodu. Pokud ne, je to obrazovka, kde se to stane zřejmým.

Logika rozhodování je krátká. Standardní DTC obchod, placeno při pokladně: Prodejní doklad – výchozí nastavení dokumentace, „správný výchozí bod pro většinu obchodů“. B2B nebo platební podmínky: Faktura. Vysoký objem – zhruba 100 nebo více objednávek denně – s účetním, který pracuje s celkovými částkami: Denní souhrn, což je jak se z 3 000 objednávek za měsíc stane ~30 účetních zápisů místo 3 000 záznamů.

A pravidlo, které činí toto rozhodnutí bezpečným: změna metody synchronizace nikdy nepřepisuje již synchronizované objednávky. Platí pouze pro budoucí transakce. Vyberte metodu, sledujte, jak se platba projde zúčtovacím účtem, a pokud tvar není správný, vraťte se k němu — knihy, které jste již uzavřeli, zůstanou uzavřené.

LedgerPort zpracovává mapování automaticky – synchronizace zaúčtuje hrubé tržby, položky poplatků, vrácení peněz a daň vybranou tržištěm na správné účty při každém zúčtovacím cyklu, takže se zúčtovací účet uzavře bez manuálního zásahu. Účetní rozvrh musí být stále správně strukturován, aby tato data přijal, ale pět výše uvedených rozhodnutí vám přesně tuto strukturu poskytne.

Pokud nastavujete nového klienta Shopify v QBO – nebo přebíráte účetnictví, které nesouhlasí – těchto pět míst je třeba zkontrolovat jako první. Pokud některé z výše uvedených rozhodnutí nebylo učiněno, právě proto trvá čtyřhodinová uzávěrka. Správné nastavení účetního rozvrhu je také základem pro připravenost účetnictví na daně, když o ně váš účetní požádá – stejných pět rozhodnutí, která zajišťují čistou měsíční uzávěrku, činí roční uzávěrku přímočarou. Podívejte se, jak LedgerPort zpracovává mapování napříč praxí s více klienty na ledgerport.com/cpas, nebo začněte zdarma.