Úč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.

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.

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ů.

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.

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

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

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

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é.

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.

Úč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.

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 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.