Клиент: Я слышал об отличном сервисе! Туда можно всё загрузить и получать в любой момент всю управленку! Сколько на это понадобится времени?
Консультант: Я точно не скажу. Примерно через месяц вы получите отчёт о движении денежных средств и понимание по остальным отчётам. Может быстрей, всё будет зависеть от разных факторов.
Клиент: Даже если можно всё просто загрузить?!
Консультант: (про себя) Опять-двадцать пять!)))) (вслух) Да...
Клиент: ... (про себя) что-то он мне втирает (вслух) Очень интересно...
Я думаю, что многие узнали себя в первом или во втором персонаже. Этот диалог наверное самый распространённый сценарий старта проекта по оцифровке бизнеса.
А как часто звучит запрос на ВОЛШЕБНУЮ КНОПКУ!?
После того, как Клиент всё таки решается идти по дороге оцифровки финансов и внедрения управленческого учёта и отчётности, а деваться то ему прямо скажем некуда, начинает разбираться в цифрах, он конечно понимает, что алгоритм ЗАГРУЗИЛ, НАЖАЛ, ПОСМОТРЕЛ начинает работать не сразу и никогда не работает в автоматическом режиме. В полу-автоматическом, да, но не в автоматическом, и ни сразу.
Почему? Разберёмся с несколькими основными причинами, которые нельзя проигнорировать.
Идентификация плательщиков и сумм платежей по ним
Эта задача начинает становиться трудно решаемой когда в целях приёма платежей от клиентов используются платёжные сервисы такие как ЮКасса, CloudPayments, Тинькофф и другие. Они собирают платежи и отправляют их пакетом/реестром, одной суммой включающей несколько платежей за какой-то период.
Итак, мы имеем поступление на расчётный счёт от платёжного сервиса денег от клиентов за наши услуги. Кто клиент в транзакции? Правильно платёжный сервис. А где клиент? Нет клиента. В основании платежа только информация о номере и дате реестра.
Поэтому просто загрузкой выписок в сервис учётной системы, если мы хотим знать кто нам заплатил, а мы точно хотим, дело не обойдётся.
Информация о плательщиках и уплаченных ими суммах содержится внутри реестров платёжного сервиса. Вы их получаете на почту или в вашу CRM через API-интерфейс.
CRM
API-интерфейс
Как сделать так, чтобы в отчёты попала информация о платежах реальных плательщиков? Есть несколько вариантов решения этой задачи:
1-й вариант. Интеграция с платёжным сервисом.
Отличный вариант в целях автоматизации. Но, есть вопросы к безопасности такой интеграции. Как бы сервис ни уверял что у них всё с этим ОК, страх остаётся. То там, то тут всплывает информация об утечках сведений из самых защищённых систем. Если не боитесь, что ваши данные попадут не туда куда надо, пользуйтесь, это очень удобно. Главное чтобы учётный сервис поддерживал интеграцию с вашим платёжным сервисом.
2-й вариант. Интеграция с CRM.
Если есть возможность интеграции с CRM, то это удобно. Удобство этого варианта будет зависеть от гибкости интерфейса синхронизации систем.
3-й вариант. Загрузка реестров платёжных сервисов через электронные таблицы.
Рабочий вариант. Но о полной автоматизации речь не идёт. Надо понимать, что у платёжных сервисов есть свой формат реестров, а у сервисов управленческого учёта свой. Между ними нужен будет переходник и финансист который этот переходник обслуживает.
Не забудьте, какой бы вариант вы не выбрали, в системе управленческого учёта должна быть возможность учесть отдельно данные о пакетных транзакциях с расчётного счёта и данные о транзакциях отдельных покупателей. Иначе у вас эти суммы будут задваиваться в отчётах.
Идентификация продуктов (проектов)
Если у вас не монопродуктовый бизнес, а есть несколько продуктов - центров прибыли, естественно вам надо знать денежные потоки и финансовые результаты отдельно по каждому из них.
Без расщепления пакетных операций по транзакциям отдельных покупателей эта задача тоже не решается. В одном пакете платежей, присланных вам платёжным сервисом, наверняка окажутся платежи относящиеся к разным продуктам.
Это задача решается во-вторую очередь после идентификации плательщиков. Сложность зависит от того есть ли у вас в транзакции по отдельному покупателю информация достаточная для отнесения платежа к конкретному продукту.
Какие реквизиты транзакции из банковской выписки мы можем для этого использовать:
- - расчётный счёт - так же открывается для каждого продукта;
- - контрагент-плательщик - для точной идентификации продукта нужно создавать уникальных контрагентов для каждого продукта, даже если это одно юридическое лицо;
- - основание платежа - нужно проконтролировать, чтобы при оформлении платежа в платёжном сервисе информация об оплачиваемом продукте попадала в поле основания платежа платёжного поручения.
Выбор варианта может зависеть от причуд конкретного бизнеса, но мне нравиться больше всего последний.
Есть ещё одна проблема идентификации продуктов в платежах. CRM системы, подобные той что встроена в GetCourse, позволяют продавать клиенту несколько продуктов в одном комплексном продукте. В GetCourse это называется Предложением. В него может входить несколько продуктов. Разделить такой комплексный платёж в учёте будет уже сложнее. Коробочные учётные системы не позволят это сделать автоматически при загрузке информации. Придётся поработать руками после загрузки и поделить платёж между продуктами. Либо использовать переходник - электронную таблицу, где данные предварительно обрабатываются перед импортом в систему.
Дата отражения доходов и расходов
И третьей задачей о которой я хотел бы поговорить является самая неочевидная для НЕфинансистов проблема: дата отражения доходов и расходов в учёте.
В статье "Деньги под контролем. Часть 1. Денежная картина бизнеса" я указывал на проблему Капкана простоты учёта. Суть которой - чем проще регламентированный, обязательный в силу закона, учёт, тем менее развита культура управленческого учёта.
Но даже, если учёт ведётся, то при применении многих систем налогообложения, кроме общей - ОСНО (общая система налогообложения), отражать доходы и расходы предписано кассовым методом. То есть по дате совершения платежей. На графике это будет выглядеть так:
Прямые производственные, маркетинговые, коммерческие и остальные косвенные расходы признаются в том месяце в котором были совершены платежи.
Финансовый результат будет распределён во времени как на этом графике:
Такой метод искажает картину реального финансового результата. Доходы в марте на самом деле ещё не заработаны, пока что это авансы покупателей. И прямые затраты понесённые в январе-марте мы ещё не можем отнести на финансовый результат, они должны формировать незавершённое производство, так как оно будет завершено в момент окончания курса.
Можно пойти дальше и отделить затраты на создание курса и затраты на его проведение. Тогда можно расценивать первую стадию производства как процесс формирования нематериального актива и в дальнейшем часть его стоимости включать в расходы на второй стадии производства - его проведение через амортизацию.
Договор-оферта на оказание услуг который демонстрируется потенциальным покупателям на сайте проекта, должен включать пункт о моменте признания услуги оказанной. Для курсов это момент их завершения, если обучение не разделено на стадии (модули). Если в договоре прописана модульная структура курса и завершение каждого модуля признаётся моментом получения части дохода. Если признавать доходы и расходы не кассовым методом, а методом начислений, мы должны отразить доход в месяце когда услуга была фактически оказана - в нашем примере в Апреле, и расходы связанные с получением этого дохода (прямые расходы) отразить в месяце его признания, так же в Апреле. Косвенные управленческие расходы, отражаются в периодах фактического их возникновения. На графике это будет выглядеть так:
В этом случае, мы имеем более точное представление о финансовом результате продукта:
И проекта в целом:
Как видите финансовый результат и что самое главное, то какие решения будут приняты после анализа отчётов, очень сильно зависит от способа отражения доходов и расходов. Чем выше качество исходной информации, тем качественнее её анализ, и тем выше качество принимаемых решений. В одной из статей я подробнее раскрою тему признания доходов и расходов в образовательном онлайн-проекте.
Так в чём же проблема, связанная с загрузкой данных в учётную систему?
Проблема в дате, которая должна быть установлена при трансформации денежной операции в доходную или расходную. Как вы можете научить процедуру синхронизации проставлять нужные даты? Это можно делать руками и каждую операцию анализировать и проставлять нужную дату. Но это не эффективно, не оперативно и связано с большим риском ошибок от влияния человеческого фактора.
Самое простое решение третьей задачи использовать переходник - электронную таблицу, где данные предварительно обрабатываются перед импортом в систему.
Мы рассмотрели три наиболее острые проблемы связанные с трансформацией данных выписок по расчётным счетам в доходы и расходы в целях ведения управленческого учёта и составления отчётности позволяющей принимать качественные решения.
Очевидно, что добиться полной автоматизации от коробочного решения будет невозможно. Сколько не жми на волшебную кнопку ЗАГРУЗКА ДАННЫХ, получишь кривые отчёты.
У всех трёх решаемых задачах есть два общих универсальных решения:
1. Ручная обработка после синхронизации.
2. Предварительная обработка в электронной таблице - переходнике.
Более эффективным, относительно производительности и рисков человеческого фактора является второй вариант решения. При этом, дополнительно можно получить огромную пользу, если после загрузки из банк-клиента в электронную таблицу и перед выгрузкой в учётный сервис делать анализ данных, считать юнит-экономику и строить диаграммы.
ОСНО