Home » Инженерные принципы построения финансовых систем

Инженерные принципы построения финансовых систем

Инженерные принципы построения финансовых систем

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

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

В этом посте будут рассмотрены следующие темы:

  1. Основные финансовые определения, имеющие отношение к должности

  2. Высокоуровневые цели системы бухгалтерского учета

  3. Инженерные принципы для достижения этих целей

  4. Лучшие практики

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

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

  • Финансовая отчетность: Это относится к главной книге и вспомогательным книгам.

  • Материал: Финансовое событие считается материал если это достаточно существенно, чтобы повлиять на решения заинтересованных сторон на основе финансовой отчетности. Обратите внимание, что это определение несколько двусмысленно по своей сути, поскольку разные предприятия имеют разные пороги существенности. Например, то, что может быть существенным для предприятия, получающего доход в 250 000 долларов в год, не будет существенным для предприятия, получающего доход в 1 миллиард долларов.

Три основные цели вашей системы бухгалтерского учета: (1) Точные, (2) Проверяемые и (3) Своевременные.

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

Если мы продаем 10 единиц продукта по цене $9,99, соответствующие финансовые записи должны составить $99,90. Это кажется очевидным, но когда вы объединяете тысячи (во многих случаях миллионы) транзакций, простые ошибки суммирования или округления между системами могут привести к существенным неточностям.

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

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

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

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

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

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

Примечание Уэйстмена: Люди часто теряются в разговорах о пакетных и потоковых системах в отношении своевременности. Я считаю, что это не столь важное различие. Пакетная обработка — это всего лишь частный случай потоковой передачи.Если ваши данные смоделированы правильно, переключаться между ними довольно просто, особенно с помощью унифицированных фреймворков, таких как Apache Луч.

Три основных инженерных принципа, которым должна соответствовать ваша система бухгалтерского учета:

  1. Неизменность и долговечность данных

  2. Данные должны быть представлены с наименьшей степенью детализации.

  3. Код должен быть идемпотентным

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

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

Это будет выглядеть примерно так:

Итак, вы можете видеть, что в финансовой записи есть доказательства того, что баланс счетов дебиторской задолженности (AR) и выручки составлял $1000 в какой-то момент, но был исправлен позже. Даже если этот баланс был неверным, мы хотим иметь аудиторский след того, каким был баланс в любой момент.

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

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

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

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

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

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

Степень детализации ваших финансовых сумм должна поддерживать конвертацию валют с минимальной потерей точности.. Если вы работаете только с долларами, представление значений в центах может быть достаточным. Если вы являетесь глобальным бизнесом, предпочитайте микро или DECIMAL(19, 4). Десятичный выбор довольно популярен среди финансовых систем, но микро был стандартом для рекламных финансовых систем. Это ограничивает потерю точности при конвертации между валютами

Примечание Уэйстмена: Микро валюты = наименьшая единица * 1 000 000. Например, $1,23 = 1 230 000 микро. Впервые я столкнулся с этим, работая с API метрик Google.

Используйте последовательные методы округления. В масштабе способ округления может создать существенные различия между ожидаемыми суммами. Например, одна из методик округления заключается в округлении всех значений от 5 и выше до следующей значащей цифры, а от 4 и ниже округляется в меньшую сторону. Другой допустимый способ — всегда округлять в большую сторону. Важно лишь, чтобы вы были последовательны по всем направлениям. Когда вы имеете дело с миллионами транзакций, отклонение на 1 цент за транзакцию может привести к существенным различиям. (10 миллионов транзакций с отклонением на 1 цент приводят к разнице в 100 тыс. долларов). Это может быть несущественно для вашего бизнеса в таком масштабе, но достаточно существенно, чтобы правительство привлекло вас к ответственности за недоплату налогов.

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

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

Используйте целочисленные представления времени. Это немного спорно, но я придерживаюсь этого. Существует так много библиотек в различных технологиях, которые анализируют временные метки в объекты, и все они делают это по-разному. Избегайте этой головной боли и просто используйте целые числа. Временные метки Unix или даже целочисленные даты и время UTC работают отлично. Чем меньше преобразований данных происходит между системами, тем лучше. (Читайте о собственных проблемах Etsy с типами временных меток здесь)

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

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

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

2024-07-11 01:47:46


1720677249
#Инженерные #принципы #построения #финансовых #систем

Read more:  Впервые в Ватикане за решеткой оказался кардинал финансовых махинаторов

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.