План счетов для электронной коммерции: как не принимать плохих решений по сопоставлению

Вы берете нового клиента Shopify. Вы создаете его план счетов в QuickBooks Online — пять категорий, разумные субсчета, нумерация счетов, соответствующая стандартным соглашениям. Вы подключаете интеграцию Shopify. Все выглядит правильно на бумаге.

Затем поступает первая выплата от Shopify.

Shopify перевел 14 200 долларов США на банковский счет. QuickBooks показывает 15 800 долларов США дохода от Shopify. Панель управления Shopify сообщает о валовых продажах на сумму 16 100 долларов США. Три разных цифры, одна и та же месячная активность, ни одна из них не совпадает. Вы тратите четыре часа на поиск расхождений. В конце концов вы находите их: комиссии, учтенные как банковские переводы, возвраты, которые не были отнесены на правильные счета, сумма налога, собранная вместо дохода. В плане счетов ничего не было упущено. Он просто не был разработан для того, как Shopify фактически перемещает деньги.

Вот ложное предположение, на котором основано большинство руководств по плану счетов: если у вас есть правильные счета в правильных категориях, сверка будет работать — это просто вопрос выполнения работы каждый месяц. Это не относится к Shopify. Названия счетов и их нумерация — это базовые требования. То, что определяет, будет ли ваша бухгалтерия Shopify сверяться, — это архитектурная совместимость плана счетов с тем, как Shopify выплачивает средства — в виде чистой выплаты, а не валового дохода. Пять конкретных решений по сопоставлению определяют, займет ли закрытие месяца 30 минут или большую часть дня.

План счетов, который выглядит правильно до закрытия месяца

Большинство стандартных шаблонов плана счетов — даже специализированных для электронной коммерции — основаны на предположении, что доход поступает в виде валового дохода. Продажа на 100 долларов США отражается как доход в размере 100 долларов США. Комиссии учитываются при их оплате. Так работает большинство предприятий.

Shopify работает не так.

Shopify не отправляет вам 100 долларов США, когда клиент платит 100 долларов США. Он отправляет вам чистую выплату — валовые продажи минус комиссии за обработку платежей, минус возвраты, минус комиссии за транзакции Shopify, иногда минус налог с продаж, собранный от вашего имени, все это объединено в один банковский перевод, охватывающий от одного до четырнадцати дней заказов. К тому времени, когда эта выплата поступает на банковский счет вашего клиента, она представляет собой как минимум пять различных финансовых операций. Ваш план счетов должен получать и разделять все пять, иначе сверка будет ежемесячно давать сбой.

Счета не неверны. Неверна архитектура.

Почему структура чистых выплат Shopify является архитектурной проблемой

Вот что обычно входит в выплату Shopify, разбитое по статьям:

• Валовые продажи — общий доход от всех заказов за период выплаты
• Комиссии за обработку платежей — обычно 2,9% + 0,30 доллара США за онлайн-транзакцию для Shopify Payments (базовый план); вычитаются до перечисления
• Комиссии за транзакции Shopify — дополнительные 2% за транзакцию, если магазин не использует Shopify Payments; обычно для старых планов
• Выданные возвраты — валовые суммы возвратов за возвращенные заказы в период выплаты
• Налог с продаж, уплаченный маркетплейсом — суммы, которые Shopify собрал и напрямую перечислит государственным органам от имени продавца (в большинстве штатов США Shopify является маркетплейсом-фасилитатором)

Когда ваша интеграция напрямую сопоставляет депозит с учетной записью дохода «Продажи Shopify», вы объединяете все пять событий в одно число. Доход занижен, потому что комиссии уже были вычтены. Расходы на комиссии невидимы. Баланс отражает фантомное налоговое обязательство, потому что вы учли сбор налогов как доход.

Решение заключается не в том, чтобы исправлять ситуацию месяц за месяцем. Это создание плана счетов, чтобы каждый компонент автоматически направлялся в правильную учетную запись, а клиринговый счет связывал их с банковским депозитом. Для этого требуется пять конкретных решений. Последующие затраты на их неправильное принятие — это время, которое ваша фирма списывает на услуги электронной коммерции.

Решения 1 и 2: счета валового дохода и клиринговый счет

Решение 1: Учитывайте валовые продажи как доход, а не сумму депозита.

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.

Чистый раздел доходов для клиента, работающего только с Shopify, выглядит так:

• 4100 — Продажи Shopify (валовые, до вычетов)
• 4110 — Доход от доставки Shopify (если доставка взимается с клиентов)
• 4200 — Возвраты и скидки (контрдоход)

Доходные счета учитывают то, что было продано. Банковский депозит отражает то, что было выплачено после вычетов. Эти два числа структурно отличаются, и вашему плану счетов нужен счет, который их связывает.

Решение 2: Используйте клиринговый счет в качестве связующего звена.

При оформлении продажи валовая сумма зачисляется на счет доходов от продаж Shopify и на транзитный счет в качестве актива. Когда Shopify выплачивает чистую сумму, транзитный счет получает вычеты (комиссии, возвраты, налоги) и обнуляется. Банковский депозит точно соответствует чистой выплате. Каждый компонент попадает на правильный счет.

Без транзитного счета вы пытаетесь свести банковский депозит, который не соответствует ни одному счету QBO, потому что он и не должен соответствовать ни одному счету. Это чистая сумма пяти финансовых операций. Любой бухгалтер, который провел вечер, сверяя Shopify без него, точно знает, каково это.

Создайте один транзитный счет для каждого платежного процессора. Если ваш клиент использует Shopify Payments и PayPal, это два транзитных счета. Их смешивание воссоздает ту же проблему несоответствия на уровне транзитного счета, которую вы пытаетесь решить на уровне доходов.

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.

Решения 3 и 4: разделение комиссий и обработка возвратов

Решение 3: Комиссии Shopify — это не одна строка.

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

Четкая структура комиссий в QBO:

• 6100 — Подписка Shopify
• 6110 — Комиссии за транзакции Shopify
• 6120 — Комиссии за обработку платежей

Объединение всех трех в один счет приводит к тому, что бухгалтеры наследуют учетные записи, в которых 3%-ное снижение маржи от обработки платежей остается незамеченным — до тех пор, пока кто-нибудь не спросит, почему валовая маржа ниже, чем предсказывает ценовая модель. Разделение их ничего не стоит при настройке и экономит время при каждом последующем обзоре.

Решение 4: Возвраты отражаются против выплаты, а не первоначального заказа.

Когда клиент возвращает заказ, Shopify вычитает сумму возврата из следующей доступной выплаты. Это не создает отдельной банковской транзакции — это уменьшает чистую сумму выплаты. Контр-ревеню счет для возвратов и скидок должен получать запись о возврате в момент выплаты, которая его содержит, а не в момент обработки возврата.

Если возврат был обработан в марте, а возмещение поступило в апреле, запись контр-ревеню относится к апрелю. Отражение ее в марте создает несоответствие периодов: доход марта падает, но сверка банковских операций марта по-прежнему не сходится, потому что денежный эффект не произошел в марте. Несоответствия периодов накапливаются месяц за месяцем, пока учетная документация не потребует полной очистки для распутывания.

Решение 5: налог с продаж как обязательство с первого дня

В большинстве штатов США Shopify является посредником маркетплейса — это означает, что Shopify собирает налог с продаж с покупателей и напрямую перечисляет его налоговым органам штата. Продавец никогда не прикасается к этим деньгам. Продавец не обязан платить налог; Shopify уже заплатил его.

Налог с продаж, который собирает Shopify, отображается в общих итогах заказов на панели управления Shopify, но он никогда не поступает на банковский счет продавца и не является его доходом. Если ваш счет доходов учитывает общие итоги заказов, включая налог, вы завышаете доход и создаете фиктивное обязательство в балансе.

Правильная настройка требует двух счетов обязательств:

• Налог с продаж к уплате — для налога, который продавец собирает и уплачивает напрямую (каналы не через маркетплейс, такие как оптовая торговля, или штаты, где не применяются правила посредника маркетплейса)
• Удержанный налог маркетплейса (или «Собранный Shopify налог») — для налога, который Shopify собирает и уплачивает от имени продавца; обнуляется после цикла выплат, поскольку обязательство погашается уплатой Shopify, а не продавца

Если ваш клиент продает через несколько каналов — Shopify, прямой веб-сайт, оптовая торговля — налогообложение различается в зависимости от канала. Единый счет «Налог с продаж к уплате» не может различать налог, обработанный Shopify, и налог, обработанный продавцом, а это различие имеет значение во время уплаты налогов.

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.

План счетов, который закрывается за один день

Когда все пять решений приняты, ежемесячные операции выполняются следующим образом: каждая выплата Shopify проходит через клиринговый счет. Кредит валовых продаж поступает. Комиссии за обработку платежей, возвраты и удержанный маркетплейсом налог списываются. Чистый банковский депозит зачисляется. Клиринговый счет закрывается с нулевым остатком. Сверка банковских счетов сходится — по построению, а не по расследованию.

Это 20-минутный процесс. Разница не в объеме работы — а в том, была ли структура счетов разработана для правильного приема данных.

Первоначальные инвестиции реальны. Правильное построение этой архитектуры для нового клиента занимает от двух до трех часов в первый раз — дольше, чем копирование общего шаблона. Но альтернатива — тратить эти часы или больше каждый месяц, неопределенно долго.

Для CPA, управляющих пятью или десятью клиентами Shopify, эта архитектура является основой для повторяемого шаблона. Те же пять решений применяются к каждому магазину Shopify в QBO. Постройте ее правильно один раз, и вы будете применять ее во всей практике — а не переучивать проблему при каждом новом взаимодействии.

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 автоматически обрабатывает сопоставление — синхронизация записывает валовые продажи, позиции строк комиссий, возвраты и налог, собранный маркетплейсом, на соответствующие счета при каждом цикле выплат, поэтому клиринговый счет закрывается без ручного вмешательства. Структура счетов по-прежнему должна быть правильно организована для приема этих данных, но пять вышеуказанных решений дают вам именно такую структуру.

Если вы настраиваете нового клиента Shopify в QBO — или наследуете книги, которые не сверяются — вот пять мест, на которые стоит обратить внимание в первую очередь. Если какое-либо из вышеуказанных решений не было принято, именно поэтому сверка занимает четыре часа. Правильный план счетов также является основой для подготовки налоговой отчетности, когда ваш CPA запрашивает ее — те же пять решений, которые обеспечивают чистоту в конце месяца, делают конец года простым. Узнайте, как LedgerPort обрабатывает сопоставление в практике с несколькими клиентами, на ledgerport.com/cpas, или начните бесплатно.