Бухгалтерский учет WooCommerce для фирм: Руководство для первого клиента

Бухгалтерский учет WooCommerce для фирм — это в основном ваш чек-лист для Shopify, который переживает переход без изменений. Три аспекта, в которых он не работает, — это именно те моменты, когда стоимость услуг превышает смету.

---

Реферальное письмо лежит в вашем почтовом ящике. Один из ваших клиентов Shopify имеет друга, который «управляет своим магазином на WordPress — WooCommerce, кажется?» — и поскольку вы закрывали его книги к 10-му числу каждого месяца в этом году, он сказал ей, что вы — фирма, которая занимается электронной коммерцией.

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

Вместо этого вы обнаруживаете: Stripe *и* PayPal *и* платежный шлюз «купи сейчас — плати потом», который вы никогда не сверяли. Нет магазина приложений — страница плагинов с 31 записью, четыре из которых требуют обновлений. И нет никакой платформенной компании, которая бы это хостила — клиент арендует сервер у хостинговой компании, о которой вы тоже никогда не слышали, а ее племянник «занимается веб-сайтом».

Заманчивый вывод — тот, который большинство фирм тихо принимают: *клиенты WooCommerce — это просто клиенты Shopify с дополнительными шагами — тот же чек-лист, больше терпения.* Это ложь, и она дорого обходится, потому что это означает, что каждая специфическая для Woo неожиданность возникает в середине проекта, а не в смете. Правда в том, что WooCommerce отличается для бухгалтерских фирм тремя конкретными структурными способами — и каждый из них имеет стандартный ответ, который вы можете установить в качестве политики до установочного звонка.

Почему бухгалтерский учет WooCommerce для фирм — это другая работа

Ни одно из трех отличий не касается бухгалтерии. Доходы, сборы, контр-счета возвратов, налоговые обязательства — идентичны вашим клиентам Shopify. Меняется то, откуда поступают данные и кто контролирует машину, которая их производит.

1. Нет единого платежного канала

Типичный клиент Shopify использует Shopify Payments, и большая часть их денег поступает через один поток выплат с одной логикой комиссий. Ваша мышечная память для сверки построена на этом.

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

Ответ со стороны фирмы: клиринг по каждому шлюзу, заявленный как постоянная политика. Один клиринговый счет и одна статья расходов на комиссию для каждого активного шлюза в магазине, созданного до синхронизации первой транзакции — никогда не общий «пул комиссий продавца». Это та же архитектура клиринга, которой вы уже доверяете; отличие Woo заключается в том, что вы запускаете ее параллельно, по нескольким каналам одновременно. Подробнее о политике ниже.

2. Клиент владеет инфраструктурой

Shopify — это хостинговая платформа: время безотказной работы, безопасность и база данных продаж — проблемы Shopify. Магазин WooCommerce — это программное обеспечение, которое клиент запускает на выбранном им хостинге. Ядро WordPress, WooCommerce, версии PHP, SSL-сертификаты и 30 других плагинов работают на инфраструктуре, в которую ваша фирма не имеет никакого представления — и все это находится выше вашего исходного источника данных.

Это не делает вас их IT-отделом. Это делает инфраструктуру вопросом для оценки объема работ, так же, как «это QuickBooks Online или Desktop?» является вопросом для оценки объема работ для клиентов Shopify.

Ответ со стороны фирмы: проверка доступа и обновление данных должны быть в вашем электронном письме для приема, а не через три месяца. Добавьте четыре вопроса в чек-лист перед звонком: Кто размещает сайт и кто его обслуживает? Включен ли HTTPS? (Инструменты синхронизации не будут подключаться без него.) Соответствует ли валюта магазина основной валюте компании QuickBooks? И кто имеет доступ к wp-администратору с правами на установку плагина? Пять минут на прием; это исключает всю категорию неожиданностей типа «сайт был недоступен / истек срок действия сертификата / племянник что-то обновил».

3. Уровень синхронизации — это плагин, который устанавливает клиент

Для клиентов Shopify инструменты синхронизации — это установка из магазина приложений на платформе, которая гарантирует среду. Для WooCommerce инструмент синхронизации — это плагин WordPress, установленный в wp-администраторе клиента, взаимодействующий с REST API магазина. Соединение, на которое вы полагаетесь для чистых книг, находится внутри системы из отличия № 2.

Ответ со стороны фирмы: ваш чек-лист по онбордингу включает их wp-администратор. Не как бремя — а как десятиминутный управляемый шаг, который вы выполняете во время стартового звонка, с клиентом (или кем-либо, кто имеет права администратора) в качестве ведущего. Процесс установки и подключения короткий и стандартный, и совместное прохождение означает, что вы точно знаете, что работает в их магазине. Следующий раздел охватывает это.

Дельта при онбординге: Что меняется по сравнению с вашим чек-листом для Shopify

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

Подготовка перед звонком включает вопросы по инфраструктуре. Хостинг, HTTPS, соответствие валют, доступ к wp-администратору — четыре из вышеперечисленных. Все остальное в письме перед звонком (приглашение бухгалтера QBO, какая компания QuickBooks, диапазон дат подгрузки данных) остается без изменений.

Этап подключения перемещается в wp-администратор. Вместо рукопожатия URL и установки приложения на хостинговой платформе клиент устанавливает плагин. С LedgerPort последовательность звонка выглядит следующим образом:

1. Установка. В админ-панели WordPress клиента: Плагины » Добавить новый плагин, найдите LedgerPort, Установить сейчас, Активировать. Мастер настройки автоматически откроется как полноэкранное окно.

2. Подключение. Мастер предложит начать процесс подключения одним кликом.

3. Авторизация. Клиент перенаправляется на app.ledgerport.com, входит в систему, выбирает бизнес и авторизует — затем возвращается в свою админ-панель WordPress. Пароли не передаются, что стоит проговорить вслух во время звонка, точно так же, как вы бы сделали для предоставления доступа QuickBooks OAuth.

4. Подготовка выполняется автоматически. LedgerPort создает ключ WooCommerce REST API с доступом на чтение и регистрирует веб-хуки для заказов, возвратов, продуктов и клиентов. Если какой-либо шаг завершается неудачно, все автоматически откатывается — магазин никогда не остается частично настроенным. При успехе клиент попадает на подключенную панель управления.

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

Эта прозрачность — честный ответ на беспокойство о гигиене доступа из различия №2. Плагин имеет доступ на чтение, его следы можно проверить в wp-admin, а при отключении удаляется API-ключ и созданные им веб-хуки — в магазине клиента ничего не остается, если вы больше не обслуживаете его.

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

Чистая дельта для плана работ: четыре вводных вопроса и одна десятиминутная установка с инструктором. Это вся «дополнительные шаги» часть лжи — и это меньшая половина истории.

Сверка шлюзов как постоянная политика

Большая половина — это различие №1, потому что оно повторяется при каждом закрытии, а не только при онбординге. Запишите это как твердую политику — три строки:

Один клиринговый счет на шлюз, без исключений. Клиринговый счет Stripe, Клиринговый счет PayPal, один на дополнительный канал — каждый является другим текущим активом в файле QBO клиента, созданным при онбординге. Общий клиринговый счет для шлюзов воссоздает ту самую головоломку, которую вы были наняты решить.

Одна строка расходов на шлюз. Смешанные комиссии невозможно проверить. Раздельно, эффективная ставка каждого шлюза становится ежемесячным двухминутным обзором: Stripe обычно составляет около 3%, а в месяц, когда он показывает 4,1%, что-то произошло, стоящее двух минут.

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

Мы намеренно не пересматриваем здесь механику — архитектура ежедневных сводок и платежных журналов охвачена с проработанными цифрами в наших руководствах для владельцев магазинов по синхронизации WooCommerce с QuickBooks и структурам бухгалтерского учета WooCommerce. Эти два поста также полезны дословно в качестве образовательного материала для клиентов: отправьте их владельцу магазина перед началом работы, и разговор «почему вы не можете просто сопоставить депозиты?» уже будет пройден.

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

Недостаточно обслуживаемые и "липкие"

Теперь аргумент о построении практики, потому что он сильнее для WooCommerce, чем почти где-либо еще в электронной коммерции.

Большинство инструментов для бухгалтерского учета в электронной коммерции ориентированы на Shopify. Большинство контента, большая часть маркетинга для CPA, большая часть позиционирования «мы говорим на языке электронной коммерции» — ориентированы на Shopify. WooCommerce обслуживает сопоставимую долю мировых интернет-магазинов, но владелец магазина Woo, ищущий бухгалтера, который понимает выплаты по каждому шлюзу и синхронизацию на основе плагинов, почти никого не находит. Собственные инструменты Woo, которые существуют, в основном решают другую проблему — двустороннюю синхронизацию по каждому заказу для бизнесов, основанных на счетах-фактурах, которую MyWorks действительно хорошо решает — а не сверку на уровне выплат, от которой зависит ежемесячное закрытие.

Для фирмы такая нехватка делает две вещи. Это делает реферальный канал непропорционально щедрым: хорошо обслужите одного клиента WooCommerce, и вы станете «фирмой, которая может работать с магазинами на WordPress» в сообществах, где это предложение редко. И это делает клиентов «липкими» — владелец магазина, чьи книги наконец-то совпадают с банком, подготовленные фирмой, которая знала, о чем спросить о ее хостинге, прежде чем ее племянник сломал его, не будет искать специалиста, чтобы сэкономить 50 долларов в месяц.

Это тот же аргумент об инфраструктуре, который мы привели в почему клиенты электронной коммерции разрушают маржу фирмы — маржа определяется инструментами, а не типом клиента — с одним улучшением: в WooCommerce конкуренты не читали эту статью. И портфельный механизм переносится целиком: Программа CPA Partner Program применяет вашу конфигурацию диаграммы Master Template ко всем клиентам, независимо от того, используют ли они Shopify или WooCommerce, под одним входом фирмы, поэтому ваш шестой клиент Woo наследует решения, которые вы приняли по вашему первому.

Второе направление

Представьте себе следующий. Еще один магазин WordPress, еще одна собранная корзина — Stripe, PayPal и что-то скандинавское на этот раз. В вашем письме о приеме уже заданы четыре инфраструктурных вопроса. Ваш стартовый звонок включает десятиминутную установку плагина, которую вы уже проводили. Ваш шаблон сопоставления уже содержит строки для клиринга по каждому шлюзу, и закрытие месяца для этого клиента — это та же проверка, а не реконструкция, которую вы проводите для своих файлов Shopify.

В конце концов, тот же план — просто не тот, который обещала ложь. Три политики, принятые один раз, и разница в платформе перестает быть причиной для отказа от реферала.

У вас есть три различия и их стандартные ответы; самый быстрый способ проверить их — на реальном файле клиента. Запишитесь на звонок по настройке CPA →, и мы проведем вашего первого клиента WooCommerce вместе с вами — четыре вопроса при приеме, установка wp-admin, настройка клиринга по каждому шлюзу и первое закрытие, которое привязывается к каждому из этих потоков депозитов.