Что такое двойная бухгалтерия
Двойная бухгалтерия: понятие, значение и возникновение
По иронии судьбы у «двойной бухгалтерии» значение также неординарное. Наверняка многие сталкивались с таким выражением и в литературе, и в СМИ, и в жизни. Как правило, оно ассоциируется с какими-то не совсем чистыми делами. Однако такое толкование касается только случаев, когда это словосочетание употребляется в переносном смысле.
Но есть у него и другой смысл, первоначальный. А он чаще всего известен лишь специалистам – экономистам, налоговым инспекторам, юристам. О том, какие значения имеет фразеологизм «двойная бухгалтерия», а также о его происхождении, можно узнать из статьи.
Разбор первой составляющей
Вам будет интересно: О полезных ископаемых загадки, повсеместно добываемых, ребятки
Чтобы понять значение фразеологизма «двойная бухгалтерия», целесообразным будет для начала рассмотреть каждую из его составляющих в отдельности. Начнем с главного слова в изучаемом словосочетании. С существительного «бухгалтерия». В словаре оно представлено в трех вариантах.
Вам будет интересно: «Благодарствую!»: значение и происхождение слова
В русский язык это слово пришло из немецкого, где оно выглядит, как Buchhalterei. Оно содержит в себе две части. Первая – Buch, что значит «книга», а вторая – halter, в переводе – «держать».
Продолжая рассматривать, какое значение имеет фразеологизм «двойная бухгалтерия», перейдем к еще одной его части.
Другая составляющая
Вам будет интересно: «Благодарствую!»: значение и происхождение слова
Прилагательное «двойной» также имеет несколько значений. Среди них находятся следующие.
Образовано от числительного два, которое, в свою очередь, происходит из праславянского языка, где имеется форма dva в том же значении.
Кроме изучаемого, эта лексемы входит в состав и других устойчивых словосочетаний, среди которых двойное/двойной:
Далее перейдем к непосредственному рассмотрению вопроса о том, какое значение имеет «двойная бухгалтерия» в прямом и в переносном смысле.
В прямом смысле
Значение фразеологизма «двойная бухгалтерия» в словаре имеет несколько толкований. Как уже говорилось выше, это выражение употребляется и в прямом, и в переносном смысле.
В первом случае – это традиционный метод, применяемый при ведении бухгалтерского учета. Его изобретение приписывается Луке Пачоли, итальянскому математику. Его суть состоит в том, что каждая хозяйственно-финансовая операция записывается дважды в разных регистрах. Он носит название «двойной записи».
Вам будет интересно: «Благодарствую!»: значение и происхождение слова
Далее будет рассмотрено и употребление и в переносном смысле.
В переносном значении
В нем изучаемое выражение употребляется в разговорной речи, когда имеются в виду чьи-либо лицемерные, двурушнические действия.
Также в переносном смысле, имеющем криминальный оттенок, рассматриваемое словосочетание употребляется в разговорной речи для обозначения распространенного способа уклонения от налогов. Он заключается в том, что ведется два бухгалтерских учета, один фиктивный, для проверки со стороны соответствующих органов, другой реальный.
Для лучшего понимания рассматриваемого словосочетания приведем близкие ему по смыслу выражения.
Синонимы
К ним относятся такие, как:
Далее будет рассказано о возникновении двойной бухгалтерии как метода.
Самое раннее использование
Первое ее применение, зафиксированное в истории человечества, обнаруживается у инков в кипу. Речь идет об универсальном и всеобъемлющем способе передачи, а также анализа статистических данных. А еще на ее основе принимались решения. Эта система охватывала всю их империю под названием Тауантинсуйу. Независимым образом принцип двойной записи был изобретен в Корее при правлении династии Коре либо в 11, либо в 12 столетии.
Возникновение в Европе
Первым человеком, о котором стало известно, что он использовал этот метод на европейском континенте, был флорентийский купец по имени Аматино Мануччи. Существуют отдельные записи, сделанные в 1299-1300 гг., которые он вел в городе Салон-де-Прованс. Они касаются подразделения компании, принадлежавшей Джованни Фарольфи.
Самые старые бухгалтерские книги, сохранившиеся в Европе, где применен метод двойной записи, велись в 1340 г. Это были счета, относившиеся к казначейству Генуэзской республики. К концу 15 в. данный метод широко использовался банкирами и торговцами таких городов, как Флоренция, Генуя, Венеция, Любек.
А вот его систематическое изложение связывается с именем Луки Пачоли, годы жизни которого 1445-1517. Он был итальянским монахом и математиком и описал двойную запись в своей книге в 1494 г. Затем этот принцип в 16-17 вв. развили в своих трудах Джероламо Кардано, итальянский математик, и Симон Стевин, фламандский математик и механик.
Принцип применения
Двойная запись в бухгалтерском учете состоит в том, что любое изменение в состоянии принадлежащих предприятию средств отражается на двух счетах и обеспечивает общий баланс.
Каждый из счетов, на котором ведется учет состоит из двух частей. Первая называется дебетовой, это левая сторона, а вторая – кредитовой – правая сторона. Баланс состоит из активов и пассивов, которые в любой момент времени должны быть равны друг другу. При этом последние равняются сумме капитала и обязательств.
В активах отражается информация о составе и стоимости имущества, а также об имущественных правах организации, определяемых на соответствующую дату. Пассивы являются указанием на источники, из которых возникают активы.
Бухгалтерские проводки
Каждая из двойных записей называется проводкой, она изменяет и актив, и пассив и при этом сохраняет баланс. Когда увеличиваются активы, это отражают по дебету счетов. А, когда возрастают пассивы – по кредиту. Наблюдается действие закона сохранения: все суммы по дебету всегда равняются суммам по кредиту, тем самым обеспечивается общий нулевой остаток. Это дает возможность контроля за правильностью учета – если баланс отсутствует, значит, в нем допущена ошибка.
Например, если учредитель вносит 10 000 руб. в уставный капитал фирмы, это значит, что у нее возникает актив в виде денежных средств. В то же время у предприятия появляется обязательство перед учредителем. При этом делается двойная запись:
Дебет по счету денежных средств (касса или банк) – Кредит по уставному капиталу – 10 000 руб.
Главным в методе двойной бухгалтерии является то, что с ее помощью можно отслеживать, из каких источников получаются средства и куда они направляются. Например, когда расходуются денежные средства, это отражается по кредиту счета «Банк» или «Касса». Но при этом делается запись по дебету, которая показывает, куда они ушли. Это может быть погашение задолженности или выдача налички по авансовому отчету. А также эти записи позволяют через бухгалтерский баланс увидеть общее финансовое положение в организации.
Проблема принципа
Она заключается в том, что финансовые результаты, которые отражаются в учете, искажаются инфляционными процессами, происходящими в экономике. Как считают специалисты, это является большим недостатком метода двойной записи. При этом существует международная система отчетности. Некоторые ее стандарты позволяют решать указанную проблему, применяя методы переоценки. Но в этом случае допускаются различные варианты учета, что влечет за собой неоднозначность при интерпретации отчетности.
Двойная запись в бухгалтерском учете
Всем, кто сталкивается с бухучетом в первый раз, например студентам, в первую очередь рассказывают про принципы его ведения. И в числе главных принципов первым называют то, что любая цифра записывается дважды:
А сами эти дебет и кредит также имеют закодированные значения, и чтобы их расшифровать, нужен план счетов. Задача же бухгалтера состоит в том, чтобы провести все цифры по этому плану так, чтобы дебет и кредит всегда оставались равны друг другу и ни одна из цифр не потерялась. Все это и есть двойная запись в бухгалтерском учете. Рассмотрим подробнее, как с ней обращаться.
Двоичная система и сущность двойной записи
На первый взгляд, такие понятия, как двоичная система и бухгалтерия связаны мало. Конечно, именно на двоичной системе основано программирование, благодаря чему мы имеем возможность пользоваться компьютерами, а на двойной записи основаны принципы учета, которые не меняются вот уже 5 веков. Но все же, что общего между всего двумя цифрами «0» и «1» и миллионами, и даже миллиардами, которые проводит по счетам среднестатистический бухгалтер? Все просто — незыблемость принципов. Многие считают, что принцип двойной записи в бухгалтерском учете уже давно себя изжил, критикуют сложность этого процесса для человека, не имеющего специальных знаний, и говорят о том, что необходимо изменить сложившуюся систему. Но ничего другого равноценного предложить не могут.
Как, например, можно еще объемно показать, что 500 000 рублей, которые компания перечислила со своего расчетного счета поставщику, являются авансом, не прибегая к длинным текстовым пояснениям? И как разобраться в этих пояснениях, если операций не одна и не 10, а тысячи? И как найти ошибку, если вдруг она случится? А главное, сколько времени на это потребуется? А бухгалтер запишет такую операцию очень лаконично и просто:
И любой человек, знакомый с этими понятиями, сразу же поймет, о чем речь. Более того, если поставщик начнет отгружать материалы частями, тоже ничего не потеряется, ведь каждая такая разовая поставка будет оформлена так:
И это мы еще не разобрали ситуацию, когда в цене этих материалов скрыт НДС, который также нужно указывать отдельно. Конечно, современные технологии позволили бы упорядочить эти операции и другим способом, но ведь всего каких-то 20 лет назад таких возможностей еще не было, а вот двойная запись уже давно обеспечивала порядок в расчетах.
Счета и проводки
Итак, мы увидели, что двойная запись обеспечивает взаимосвязь между двумя неразрывно связанными частями одной операции: «приход — расход», «было — стало». В примере с авансом мы видим, что компания отдала 500 000 рублей другой организации, и это очевидный расход, то есть кредит. Но организация-поставщик не просто получила эти деньги, но и стала на определенный промежуток времени их должна, то есть возник приход долга — дебет. Примечательно, что у фирмы-поставщика ситуация будет прямо противоположная: она оприходует деньги и получит обязательство перед их отправителем. В проводках это будет выглядеть так:
Всего из этих строчек можно понять, что компания еще не выполнила свои обязательства перед покупателем на сумму 400 000 рублей. Таким образом, двойная запись — это способ отражения хозяйственных операций, позволяющий видеть объемную картину операций и их связь между собой. Ведь хозяйственная жизнь любой организации очень многообразна и включает в себя не только финансовые, но и другие операции. И именно за счет метода двойной записи можно существенно повысить информативность. Главное, соблюдать равенство числовых значений, как его называют, по модулю числа. Именно этим методом достигается баланс, который даже дал название главному финансовому отчету любой организации.
А для того чтобы сгруппировать однородные операции, как раз и применяются счета бухучета, которые, по сути, раскрывают квалификационные признаки любой суммы. Все они собраны в план счетов и имеют индивидуальные номер и название. Например:
Действующий план утвержден приказом Минфина РФ от 31.10.2000 № 94н (в редакции от 08.11.2010). Его должны применять все компании, за исключением кредитных организаций и государственных (муниципальных) учреждений. Для последних утверждены отдельные планы, учитывающие их специфику. Благодаря общему плану, компаниям легко взаимодействовать, проводить сверки и учитывать общие операции.
Все счета, входящие в план, являются синтетическими, то есть по ним учитываются только финансовые признаки операций. Каждый из них обязательно имеет:
В зависимости от того, к какой категории относится счет, обороты могут иметь разное значение в дебетовом и кредитовом выражениях. Для более подробного раскрытия операции используют субсчета, а также аналитические данные. Все вместе это создает современную многомерную систему бухучета, но все же именно метод двойной записи в бухгалтерском учете означает полноту отражения всех процессов.
Двойная бухгалтерская запись в реляционной БД
От переводчика: в ходе моей работы в нигерийском финтехе пришлось мне создавать с нуля одну платежную систему. Я тогда ничего толком не понимал в вопросах бухгалтерии, в том как именно лучше хранить платежи и балансы. Но было подозрение, что примитивный вариант с одной циферкой баланса в аккаунте пользователя слишком прост, чтобы быть правильным.
Разобраться и избежать кучи граблей в этом деле мне помогла данная статья. При этом информации по теме «как сделать свою платежную систему» довольно мало, а в учебниках по бухучету программисту сходу разобраться не так просто (и очень нудно). Надеюсь, этот материал окажется полезным тем, кто только собирается что-то такое делать.
Сразу извиняюсь за возможные неточности в русскоязычных финансовых терминах — я все-таки программист, а не бухгалтер, и с русской терминологией в этой сфере недостаточно знаком.
Введение
Многие компьютерные системы, использующие реляционные БД, хранят в них какую-то финансовую информацию о балансах и транзакциях. При этом при проектировании и разработке такой БД часто встает вопрос, а как именно хранить эту информацию. Обычно выбор стоит между дешевой «простой записью» и более сложной «двойной записью».
Лука Пачоли, автор самой старой (15 век) дошедшей до нас книги с описанием принципов двойной записи
В системе с «простой записью» числовые значения записываются только один раз. В системе с «двойной записью» каждое значение записывается дважды, как кредит (положительное значение) и как дебет (отрицательное значение). При этом есть набор правил, определяющих связь между этими значениями. Эти правила вам легко опишет любой опытный бухгалтер, хотя он может и не представлять, как именно они могут быть представлены в реляционной БД.
Основные правила таковы:
Применимость двойной бухгалтерии
На старте проекта низкая цена простой записи всегда искушает, а стоимость реализации и сложность полноценной двойной записи кажется излишней. Однако в действительности часто использование простой записи оказывается ложной экономией.
Если бухгалтерская информация в ИТ системе лишь копирует существующую бумажную отчетность, хранящуюся вне разрабатываемой БД, тогда простая запись еще имеет право на жизнь. Однако если хотя бы один из перечисленных ниже фактов о системе правдив, то с самого начала стоит использовать двойную запись:
Пример двойной записи
Ключевой идеей двойной записи является существование особого «cash book» аккаунта (прим. перев.: не нашел как это адекватно назвать по-русски, может кто подскажет?). Этот аккаунт содержит записи, сделанные когда ценности (например, деньги) вносятся или выводятся из нашей бухгалтерской системы. Таким образом, текущий баланс этого аккаунта отражает общее количество ценностей в системе.
Дальше показан простой пример с двумя аккаунтами, «cash book» и «Смит».
(а) £300 вводится в систему и кладется на счет Смита. Создается кредит на £300 в аккаунте Смита (кредит справа, дебет слева). Чтобы уровнять эту сумму, создается дебет на £300 в аккаунте cash book.
(b) Затем Смит выводит £50 из системы. Создаем дебет на эту сумму в аккаунте Смита и кредит в cash book.
(c ) Добавим еще один аккаунт Паттел и переведем 100£ ему от Смита. Для этого нам понадобится создать дебет на эту сумму у Смита и кредит у Паттела.
(d) В качестве завершающего штриха пусть теперь Паттел выведет из системы 60£. Мы создаем дебет в его аккаунте и кредит в Cash book.
Модель данных
Структура простой модели данных, которая может использоваться для представления всей этой информации:
Таблица POSTING содержит сами двойные записи. Хранение всех цифр в одной таблице сильно упрощает все вычисления. В качестве первичного ключа стоит использовать монотонно возрастающий счетчик. Значения при этом должны идти подряд, в таком случае по номеру всегда можно будет убедиться, что ни одна запись не была удалена. Таблицы BATCH и JOURNAL используются для контроля и ввода данных в эту таблицу POSTING.
Каждая запись в таблице JOURNAL представляет транзакцию (с точки зрения бизнеса), которая генерирует двойные записи. Такая транзакция — это завершенная единица работы или какого-либо бизнес-процесса. Либо все POSTING записи, ассоциированные с JOURNAL записью должны быть успешно завершены, либо ни одна из них. Сумма всех POSTING записей в рамках одной транзакции должна давать ноль. Каждая операция по переводу средств из примера выше представляется своей записью в таблице JOURNAL
Запись в таблице BATCH сделана для удобства ввода данных. Она используется для группировки записей JOURNAL в удобные пакеты, например набор чеков для ввода в систему, какой-то глобальный бизнес-процесс вроде начисления процентов сразу всем пользователям и т.п.
Таблица ACCOUNT хранит данные о владельцах ценностей в системе.
Таблица ASSET TYPE содержит информацию о типах ценностей, использующихся в системе. Добавив тип ценности в первичный ключ таблицы POSTING можно сделать систему, оперирующую сразу несколькими видами ценностей (например, обработку нескольких валют).
Вот как может выглядеть такая БД для примера выше в максимально упрощенном виде:
Баланс столбца Amount в таблице POSTING всегда равен нулю после завершения любой транзакции из JOURNAL (ПО должно гарантировать отсутствие записи незавершенных транзакций в БД).
Для демонстрации работы с многовалютностью был добавлен новый вид ценности. Если Смит хочет поменять 20 фунтов на доллары по курсу 1 за 1.5, транзакция будет проведена через Cash Book таким образом:
Расчетные периоды
Модель, которую мы получили, отлично выглядит, но в реальности очень быстро сломается под высокой нагрузкой из-за того, что мы не можем ничего удалять и вынуждены постоянно пересчитывать все возрастающее количество записей в POSTING.
Большинство систем бухучета имеют понятие расчетного периода — обычно это месяц, три месяца или год. Такой период подсказывает удобные моменты для разделения потока данных. Обычно удобной точкой является конец года, календарного или финансового.
Мы можем добавить столбец с индикатором периода к таблице POSTING и к ее первичному ключу, разбив данные на группы, которые могут обрабатываться независимо. Если бы в примере выше часть записей попала на новый расчетный период, балансы аккаунтов были бы перенесены следующим образом.
Сперва были бы очищены балансы предыдущего периода.
А затем они были бы перенесены в новый период
После определенного времени все записи периода YEAR 1 могут быть отправлены в архив и удалены из системы без потери ее целостности.
Агрегирование транзакций
Некоторые операции в бухгалтерской системе могут затрагивать сразу многих, или вообще всех пользователей. Например, выплата процентов всем пользователям в виде доли от их текущего баланса.
Такие операции могут быть обработаны в рамках одной транзакции в таблице JOURNAL и можно агрегировать все операции с Cash Book в одну общую запись в таблице POSTING (вместо создания отдельной операции для каждого аккаунта). Это позволит соблюсти все перечисленные выше правила бухгалтерского учета и при этом сократить в два раза количество записей в БД. При использовании такого подхода конец года в БД будет выглядеть так:
Пакетная обработка
Пакетная обработка часто используется для упрощения ввода данных в бухгалтерскую систему.
Исторически так работала обработка чеков. Бухгалтеру выдавалась пачка из десяти чеков, номер пачки и общая сумма всех чеков. На первом этапе чеки вносятся в систему в виде «неавторизованных» записей. При этом через таблицу BATCH проверяется их количество и общая сумма, и только если они совпадают с правильным значением пользователю позволяется закоммитить пачку. После того как это сделано, пачка отправляется другому сотруднику, который проверяет ее на валидность и затем «авторизует» если все введено верно.
Такой процесс называется «maker/checker» и может использоваться для ввода любых значимых данных в систему.
Правильным при этом будет хранить «неавторизованные» записи в отдельной таблице от основного набора двойных записей в таблице POSTING. Также можно иметь целый ряд таких таблиц для разных бизнес-процессов. Например, в случае с чеками, через которые осуществляется ввод или вывод денег из системы, бухгалтеру надо будет проверить только один аккаунт. Так как второй, Cash Book, в таких операциях всегда подразумевается неявно. В таком случае в таблице CHEQUE можно будет обойтись только одним столбцом с аккаунтом, в то время как в гипотетической таблице FUND TRANSFER нужно будет два столбца: «отправитель» и «получатель».
Именно тут возникает основное непонимание принципов двойной записи. Большинство людей в обычной жизни встречают только простые бумажные книги учета. В такой бумажной книге, например для учета финансов какого-то клуба по интересам, нужна только одна запись для каждой операции. Однако в ней по-прежнему есть неявная двойная запись, так как всегда неявно присутствует Cash Book аккаунт (в данном случае — этот самый клуб), ведь все движения средств это всегда или ввод (оплата взносов участниками), или вывод денег из системы (траты клуба).
Вторая причина заблуждений — то что в личных выписках по счету деньги, положенные на счет будут считаться «кредитом», потому что человек по сути кредитует банк, который получает его деньги. Хотя если бы этот человек вел свою бухгалтерскую книгу, эта запись была бы в ней учтена как «дебет» — так как банк должен эти деньги своему клиенту. Эти деньги выводятся из «платежной системы» пользователя и вводятся в систему банка.
Архитектура программной части
ПО, реализующее такую бухгалтерскую систему с двойной записью, лучше всего разрабатывать с помощью ООП и многоуровневого подхода. Уровни получаются такими:
Конечно, архитектура системы будет зависеть от того, что именно эта система должна делать, однако можно предположить наличие в ней следующих модулей:
PostEntry: модуль, который управляет созданием двойных записей в таблице POSTING. Он отвечает за вставку записей, присвоение ID и таймстампов. Модуль не может удалять или изменять записи и никакой другой модуль не должен удалять или изменять эти записи, за исключением возможного удаления старых архивированных записей для уже неактуальных расчетных периодов. Таблица POSTING должна быть доступна только на чтение для всех других модулей.
MakeDeposit, MakeWithdrawal, MakeTransfer: эти модули реализуют базовую бизнес-логику для операций переводов средств. Они будут использовать модуль PostEntry для занесения своих результатов в БД
ChequeEntry и ChequeAuthorisation, ReceiveBACS (прим перев: BACS — система межбанковских платежей): эти модули будут связывать систему с внешним миром и предоставят высокоуровневый интерфейс. Они будут использовать модули бизнес-слоя для выполнения своих функций. В таком случае можно гарантировать правильность процессинга вне зависимости от метода ввода данных, так как и ChequeEntry и ReceiveBACS будут работать через тот же самый MakeDeposit
Эту методологию разделения слоев можно применять в большей или меньшей степени, в зависимости от сложности системы и желаемой чистоты использования принципов объектного дизайна. При этом может иметь смысл, например, разрешить модулю генерации отчетов (например TestTrialBalance) прямой доступ к БД с уровня интерфейса — вместо того чтобы создавать промежуточные модули на бизнес и БД слоях.
Пробный баланс
«Пробный баланс» — главный способ проверки целостности бухгалтерской системы. Если все записи вносились в систему по правилам двойной записи и не было никаких ошибок, в таком случае сумма всех записей должна давать ноль. Вероятность того, что несколько отдельных ошибок сложатся в и сумме дадут ноль на невалидной базе обычно настолько мала, что ей пренебрегают.
Лучшим способом проверки является последовательное движение от верхнего уровня к нижнему. Проверки имеет смысл выполнять в таком порядке:
Типы записей в JOURNAL
Таблица JOURNAL содержит простое представление сущностей, которые однако часто оказываются на деле более сложными и вовлеченными в различные отношения.
Иногда имеет смысл разбить одну таблицу на несколько. Например на MATERIALISED и DEMATERIALISED, которые могут иметь различный набор столбцов, например для материальных сущностей могут потребоваться данные об их текущем местоположении.
Или же в одной таблице могут храниться различные подтипы ценностей, такие как валюта или ценные бумаги, у каждого подтипа при этом может быть свой набор свойств и атрибутов.
Сущности, имеющие как под- так и надтипы могут организовываться в БД одним из четырех способов (это довольно стандартная ситуация для любой БД):