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

Вы берете нового клиента 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: Учитывайте валовые продажи как доход, а не сумму депозита.

Ваши доходные счета должны отражать то, что клиенты фактически заплатили — до вычета комиссий Shopify. Создайте отдельные доходные счета для каждого канала продаж (продажи Shopify, продажи WooCommerce, оптовый доход), а не единую категорию «доход от электронной коммерции». Как только вы объедините доход от Shopify и Amazon в одну учетную запись, вы потеряете видимость маржи по каждому каналу, и не будет практического способа восстановить ее без перестройки бухгалтерского учета.

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

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

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

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

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

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

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

Как эти два решения обеспечиваются: сопоставление продуктов.

Решения 1 и 2 действительны только в том случае, если программное обеспечение, публикующее данные в QBO, соблюдает их, и именно здесь происходит сопоставление. Правило последовательности взято непосредственно из собственной документации LedgerPort по настройке: сначала создайте план счетов, затем выполните сопоставление. LedgerPort сопоставляет ваши *существующие* учетные записи QuickBooks — он не создает учетные записи за вашей спиной — поэтому структура, которую вы разрабатываете в этой статье, — это структура, которую соблюдает синхронизация.

Экран сопоставления также позволяет установить детализацию дохода. Каждый продукт сопоставляется с элементом QBO, и каждый элемент несет доходную учетную запись. Направление многих продуктов на один элемент дает вам простую версию этого шаблона — единую учетную запись продаж Shopify. Сопоставление продуктов индивидуально дает доход по каждому SKU, а также проводку себестоимости проданных товаров по элементам типа «Запасы». Это то же самое решение, что и «одна учетная запись продаж против учетных записей доходов по позициям», представленное в виде раскрывающегося списка.

Две детали делают это практически осуществимым. Во-первых, режим отказа безопасен: заказ, содержащий несопоставленный продукт, выдает ошибку с именованным статусом — «Продукт не сопоставлен» — и останавливается вместо проводки на неправильную учетную запись, поэтому шаблон не может быть нарушен незаметно. Во-вторых, настройка занимает не неделю кликов по выпадающим спискам: Auto-Map сопоставляет продукты Shopify с элементами QBO по SKU или названию одним щелчком мыши, помечает результаты для проверки и оставляет только пропущенные для ручного сопоставления.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В LedgerPort Решение 5 поставляется как настройка, а не как ежемесячная дисциплина. Вкладка «Налоги» конфигурации синхронизации имеет опцию «Налог на позицию»: налог, собранный платформой, проводится как отдельная строка в транзакции QuickBooks, направляемой в учетную запись обязательств, которую вы выбираете из раскрывающегося списка. «Налог — это обязательство, а не доход» перестает быть правилом, которое кто-то должен помнить, и становится единственным способом, которым может проводиться синхронизация.

Та же вкладка содержит деталь, которую никто не объясняет: округление налогов. Налоговый расчет платформы и налоговый расчет QuickBooks расходятся на цент или два по некоторым заказам, и без места для этих цен книги расходятся на несколько центов за заказ, превращаясь в неустранимую кашу. Настройка «Округление налогов» добавляет позицию «Корректировка округления», которая поглощает разницу — вот почему книги сходятся до цента, а не «достаточно близко». Достаточно близко — не значит закрыто.

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

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

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

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

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

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

План счетов не завершен, когда счета существуют. Он завершен, когда вы решили, какой *тип* транзакции будет в них проводиться. В инструменте синхронизации это решение имеет название: метод синхронизации. В LedgerPort это один выпадающий список — Sync Config » Orders » Sync Method, доступный из боковой панели приложения — с пятью вариантами, и каждый вариант предъявляет разные требования к только что созданному вами плану счетов.

• Квитанция о продаже — одна квитанция на заказ, с позициями, налогами, доставкой и скидками, проводимая по доходам и клиринговому счету. Требуются никакие дебиторские задолженности.
• Счет-фактура — две записи на заказ: Счет-фактура при его размещении, Платеж при его оплате Shopify. Выберите это, и вашему плану потребуются открытые дебиторские задолженности.
• Предварительный счет — не проведенная запись; она ничего не затрагивает до преобразования. В документации прямо говорится, как редко это бывает: «Если вы не уверены, нужна ли она вам, скорее всего, нет».
• Ежедневное сводное резюме — одна бухгалтерская запись в день, агрегирующая все заказы за этот день. Выбор этого варианта открывает поля сопоставления счетов прямо под выпадающим списком.
• На основе тегов — теги заказов Shopify направляют заказы к различным типам транзакций (оптовая → Счет-фактура, розничная → Квитанция о продаже, не синхронизировать → пропущено), поэтому смешанный розничный/оптовый магазин может нуждаться как в счетах дебиторской задолженности, так и в счетах квитанций.

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

Логика принятия решений коротка. Стандартный магазин DTC, оплата при оформлении заказа: Квитанция о продаже — собственный вариант по умолчанию в документации, «правильная отправная точка для большинства магазинов». B2B или условия оплаты: Счет-фактура. Большой объем — примерно 100 или более заказов в день — с бухгалтером, который работает с итогами: Ежедневное сводное резюме, что является способом превратить 3000 заказов в месяц примерно в 30 бухгалтерских записей вместо 3000 записей.

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

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

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