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

Этот процесс может включать множество вариаций, но обычно он предполагает часы, дни или недели работы с финансовым отделом для:

• Понимания, что должно быть включено в отчеты
• Моделирования этих отчетов
• Проверки этих отчетов
• Внесения корректировок в вашу модель
• Вопросов о своем существовании
• Повторной проверки этих отчетов

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

Я подробно расскажу, как вы можете использовать эти принципы, но прежде чем я начну, я должен упомянуть о dbt-пакетах, которые доступны для популярных источников финансовых данных и которые вы можете использовать! Если вы используете Fivetran и в настоящее время используете либо Netsuite, QuickBooks, Xero, либо Sage Intacct, то вы можете пропустить очередь и использовать готовые отчеты прямо из коробки. См. ниже ссылки на соответствующие пакеты:

• Netsuite dbt package
• QuickBooks dbt package
• Xero dbt package
• Sage Intacct dbt package

Эти пакеты генерируют три основных отчета финансовой отчетности (плюс несколько дополнительных моделей), которые понадобятся вашей финансовой команде:

• Главная книга/Детализация транзакций: книга всех проведенных транзакций в организации.
• Балансовый отчет: сводка финансовых балансов в организации. Классическое бухгалтерское уравнение (Активы = Обязательства + Капитал).
• Отчет о прибылях и убытках: отчет, детализирующий доходы и расходы в организации.

Просто установив пакет, вы можете получить эти отчеты в вашем за считанные минуты, что позволит вам обойти описанный ранее цикл. Однако, если вы не используете один из этих источников с Fivetran, не стоит бояться! Я подробно расскажу о принципах моделирования, используемых в каждом из этих пакетов.

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

Шаг 1: Понимание схемы источника

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

Таблица с одной транзакцией облегчает начало работы с финансовым моделированием и создание конечных отчетов. Однако она не дает хорошего представления о том, какие типы транзакций включены в таблицу. Чтобы понять типы транзакций, вам нужно будет потратить некоторое время на запросы к таблице, чтобы определить, какие транзакции включены (и не включены). См. ERD Fivetran Netsuite в качестве примера схемы таблицы с одной транзакцией.

Аналогично, версия схемы таблицы заголовков и деталей строк отлично подходит для понимания того, какие типы транзакций произошли в компании. Однако эта структура схемы довольно сложна, когда требуется проводить анализы на следующих этапах. Например, вам нужно объединить таблицы заголовков и деталей строк, прежде чем объединять их с другими объектами транзакций, чтобы целостно просмотреть все транзакции вместе. См. ERD Fivetran QuickBooks в качестве примера схемы таблицы заголовков и деталей строк.

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

Шаг 2: Создание отчета Главная книга/Детализация транзакций

Отчет Главная книга/Детализация транзакций является основой финансовой истории каждой компании. Этот отчет будет содержать каждую проверяемую транзакцию (поступление наличных, расходование наличных и т.д.), которая произошла в компании, но с интересным бухгалтерским поворотом!

Хорошо, это может быть не весело, или не поворот, но этот отчет будет включать важную часть бухгалтерской головоломки для каждой транзакции. Да, я собираюсь говорить о дебетах и кредитах (также известные как двойная запись в бухгалтерии).

Каждая транзакция будет детализировать, как запись влияет на итоговую строку, либо как дебет, либо как кредит на соответствующий счет. Это бесценно для нас для моделирования балансового отчета в частности. Метод бухгалтерии с дебетами и кредитами критически важен для принципа соответствия, где каждый элемент дохода должен соответствовать элементу расхода. Подумайте об этом как о том, что для каждой транзакции всегда должно быть компенсирующее действие. Если вы покупаете кофейные зерна для продажи клиентам, вы дебетуете кофейные зерна и кредитуете наличные. Это оказывает влияние, увеличивая ваш актив (кофейные зерна) и также уменьшая ваш актив (наличные). Идеально сбалансировано, как и должно быть.

Я настоятельно рекомендую найти уютное место на вашем диване и почитать о двойной записи в бухгалтерии перед моделированием вашей модели Главная книга/Детализация транзакций. К счастью, я обнаружил, что большинство источников финансовых данных, использующих таблицу с одной транзакцией, также обрабатывают двойную запись в бухгалтерии для вас в таблице (см. Sage Intacct в качестве примера). Однако, если ваш источник напоминает дизайн схемы заголовков и деталей строк, то вам, вероятно, нужно будет убедиться, что вы учитываете двойные записи в ваших моделях, прежде чем объединять все ваши транзакции в одну таблицу.

Я настоятельно рекомендую взглянуть на то, как это было смоделировано для каждого типа транзакции в dbt_quickbooks моделях двойной записи транзакций. Ниже приведен отличный фрагмент из папки двойной записи, который показывает, как метод двойной записи учитывается в модели с использованием объединения (обратите внимание на изменение account_id, чтобы отразить влияние транзакции на разные счета).

select
    transaction_id,
    transaction_date,
    customer_id,
    vendor_id,
    amount,
    payed_to_account_id as account_id,
    'debit' as transaction_type,
    'bill' as transaction_source
from bill_join
 
union all

select
    transaction_id,
    transaction_date,
    customer_id,
    vendor_id,
    amount,
    payable_account_id as account_id,
    'credit' as transaction_type,
    'bill' as transaction_source
from bill_join

Как только вы убедитесь, что правильно учитываете метод двойной записи в моделях отдельных типов транзакций, вы можете объединить все модели типов транзакций вместе, чтобы создать одну таблицу со всеми типами транзакций.

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

Шаг 3: Проверка классификаций счетов

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

Иногда вам повезет, и классификация счета будет предоставлена в таблице счетов (как в dbt_xero). Если это не так, то вам нужно будет добавить некоторую логику в вашу модель счетов, чтобы точно установить классификацию. Обычно логика включает в себя ссылку на тип счета для определения классификации (например, тип счета "Кредиторская задолженность" должен соответствовать классификации "Обязательство"). К счастью, это было применено в ряде проектов с открытым исходным кодом и может быть использовано вашей командой! Я рекомендую взглянуть на то, как пакеты dbt_quickbooks сопоставляют классификации. Аналогично, реализация dbt_sage_intacct следует той же логике, но вместо этого позволяет больше гибкости в форме переменных, которые могут быть изменены и отредактированы, если план счетов на стороне финансов изменится.

Как только вы проверите или создадите поле классификации счета, вы можете безопасно присоединить таблицы счетов (и другие измерительные таблицы) к вашей таблице Главной книги. Теперь, когда все объединено, вы начнете видеть полотно финансовой истории, разворачивающееся перед вашими глазами. Красиво, не правда ли. Время действительно летит, когда вы получаете удовольствие. На самом деле, теперь, когда я на тему времени, я не могу дождаться, чтобы поговорить о следующем шаге. Агрегирование данных Главной книги по периоду даты!

Шаг 4: Главная книга по периоду и временная ось

На данный момент ваша финансовая команда, вероятно, в восторге от того, что у них есть полностью функциональная (и, что самое важное, точная) Главная книга. Хотя это здорово, может быть довольно сложно создать окончательные финансовые отчеты с данными в этом формате. Будет намного проще управлять данными, если они агрегированы по периодам дат по счету. Хотя вы можете агрегировать по любому периоду, который вам нравится, я предлагаю агрегировать по месяцам, так как это позволяет вам и вашей финансовой команде разрезать и анализировать по месяцам/кварталам/годам по вашему усмотрению. Чтобы достичь этого, вы собираетесь использовать нашего лучшего друга - временную ось.

Используя комбинацию jinja и макросов временной оси, вы сможете создать таблицу, содержащую каждый месяц с начала финансовой истории компании. Хотя это может быть пугающим, я рекомендую взглянуть на то, как временная ось создается в модели dbt_quickbooks general_ledger_date_spine. Вы можете увидеть, как временная ось ссылается на модель Главной книги и находит минимальную и максимальную дату для создания полной оси. Это гарантирует, что вы не генерируете ни больше, ни меньше данных, чем необходимо для наших последующих анализов.

Как только временная ось создана, вы должны создать новую модель для агрегирования данных Главной книги по месяцам. В дополнение к простому агрегированию данных Главной книги по месяцам, вы захотите убедиться, что учитываете начальный, конечный и чистый изменения баланса счетов месяц за месяцем. Расчет этих дополнительных полей делает отчетность по балансу и отчету о прибылях и убытках более плавной.

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

• Агрегируйте данные Главной книги по месяцам
• Создайте накопительный баланс для счетов баланса
• Создайте начальный и конечный баланс для счетов баланса, используя накопительный баланс
• Объедините данные Главной книги с вашей временной осью
• Заполните пустые записи месяцев соответствующими данными, показывающими 0 в чистом изменении

Я рекомендую обратиться к модели dbt_quickbooks general_ledger_balances в качестве примера того, как лучше всего следовать вышеуказанным шагам. Как только эти шаги будут выполнены, у вас должна быть модель, которая включает запись для каждого месяца и каждого счета с начальным, конечным и чистым изменениями балансов.

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

Шаг 5: Нераспределенная прибыль / Скорректированный доход

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

К счастью, основная часть тяжелой работы уже была выполнена на Шаге 4, и вы можете использовать эту работу для генерации записей о нераспределенной прибыли/скорректированном доходе. Сначала взяв записи о доходах, а затем вычитая их из записей о расходах, вы можете достичь желаемого результата. Одно, что стоит отметить, это то, что вам нужно будет создать уникальные имена полей для этих записей, так как вы фактически генерируете новые данные. См. модель quickbooks_retained_earnings для того, как это было рассчитано.

С этим вы наконец-то находитесь на последнем этапе агрегирования Главной книги по периоду! Объединение модели Нераспределенной прибыли/Скорректированного дохода с моделью Главной книги по периоду.

Шаг 6: Завершение модели Главной книги по периоду

Объедините модель Главной книги по периоду с вашей моделью Нераспределенной прибыли/Скорректированного дохода. Вот и все, вы завершили самую сложную часть этого уравнения! Теперь у вас есть полностью используемая таблица, содержащая каждый месяц вашей финансовой истории, и вы можете видеть соответствующую запись счета за этот месяц. Бонусные баллы также за то, что не забыли о записях Нераспределенной прибыли/Скорректированного дохода, которые будут бесценны при расчетах баланса.

Теперь вы наконец-то можете перейти к последним шагам и создать отчеты о балансе и отчеты о прибылях и убытках.

Шаг 7: Создание отчета о балансе

Чтобы создать отчет о балансе, вы теперь можете просто ссылаться на вашу Главную книгу по периоду и фильтровать по классификациям счетов баланса. Бада Бинг... у вас есть ваш отчет о балансе, и вы можете разрезать и анализировать по периодам сколько угодно! ❤️ ⚖️

Вау, это было легко. Не может быть так просто создать отчет о прибылях и убытках, верно?

Шаг 8: Создание отчета о прибылях и убытках

Чтобы создать отчет о прибылях и убытках, вы теперь можете просто ссылаться на вашу Главную книгу по периоду и фильтровать по классификациям счетов отчета о прибылях и убытках. Бада Бум... у вас есть ваш отчет о прибылях и убытках, и вы можете разрезать и анализировать по периодам сколько угодно! ❤️ 💸

Боже, я не шутил. Это действительно так просто!

Вот и все!

Вы только что прошли быстрый 8-шаговый процесс, чтобы превратить ваши финансовые данные из необработанных в комплексные финансовые отчеты. У меня мало сомнений, что в данный момент ваша финансовая команда устраивает вам вечеринку с кальцоне за создание идеальных финансовых отчетов!

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

Важно отметить, что каждый бизнес может сильно отличаться друг от друга. Приведенные выше принципы могут не переводиться 1-к-1 точно, но они могут быть слегка изменены, чтобы соответствовать вашему бизнес-кейсу. Кроме того, dbt-пакеты также могут столкнуться с аналогичным сценарием "один размер не подходит всем". Тем не менее, dbt-пакеты поддерживаются увлеченными людьми, которые всегда рады и готовы развивать пакет. Если вы используете решение dbt-пакета и замечаете, что ваши цифры не сходятся, я бы рекомендовал открыть Issue, чтобы вступить в дискуссию с поддерживающими и сообществом. Возможно, есть обновление, которое можно применить, чтобы улучшить пакет и свести ваши финансовые отчеты. Dbt-пакеты - отличный пример сообщества аналитиков, работающих вместе для разработки готовых моделей данных, которые могут использовать другие.

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