Сергеич (sergeich_vl) wrote,
Сергеич
sergeich_vl

Category:

Дебет слева, кредит справа

Выпускник Финансовой академии пошел работать в крупную компанию бухгалтером. У него появилась привычка с утра перед рабочим днем заглядывать в левый ящик стола. Затем он закрывал его на ключ и начинал работать. Через десять леть он стал старшим бухгалтером, еще через десять - главным бухгалтером. В 60 лет он ушел на пенсию, и на следующий день все побежали к ящику, чтобы узнать, на что бухгалтер смотрел там каждое утро. В столе лежала пожелтевшая бумажка, на которой было написано: «дебет слева, кредит справа».

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

Речь пойдёт о разных подходах к записи сложных проводок, то есть, проводок, затрагивающих более двух корреспондирующих счетов. Итак, представьте элементарную ситуацию: мы приходуем на склад товар стоимостью 118 руб. с НДС. В данном случае у нас задействованы три счёта: сырьё и материалы, налоги к получению и кредиторская задолженность. Как всё это отразить в учёте? Можно записать эту хозяйственную операцию в два приёма:

Д Сч. 10 «Сырьё и материалы» 100 руб. – К Сч. 60 «Кредиторская задолженность 100 руб.
Д Сч. 19 «НДС к получению» 18 руб. – К Сч. 60 «Кредиторская задолженность» 18 руб.

Эту же операцию, впрочем, можно записать и в один приём:

Д Сч. 10 «Сырьё и материалы» 100 руб
Д Сч. 19 «НДС к получению» 18 руб
К Сч. 60 «Кредиторская задолженность» 118 руб.

Видно, что в первом случае запись балансируется на уровне каждой строки, а во втором балансируется только вся запись целиком. Так вот, разница в подходах заключается в том, что для среднестатистического бухгалтера на постсоветском пространстве более естественным кажется первый вариант, тогда как на условном Западе более привычен скорее второй. На первый взгляд это кажется несущественным, однако на самом деле это имеет далеко идущие последствия. Привычные ко второму варианту западные специалисты соответственным образом спроектировали и свои учётные системы. Наиболее яркий пример тут – SAP. Каждая проводка там оформляется отдельным документом, где каждая строка относится только к одному счёту. Дебетовые строки записываются с плюсом, кредитовые – с минусом, так что итоговая сумма по каждому документу должна быть нулевой. Таким образом обеспечивается основной принцип двойной записи: итоговая сумма по дебету всегда должна быть равна итоговой сумме по кредиту. Однако, по причине того, что баланс обеспечивается не на уровне строки, а на уровне документа, в SAP в общем случае невозможно сделать такие привычные по 1С отчёты, как анализ счёта и шахматную ведомость. В самом деле, рассмотрим, например, проводку, которая делается при принятии к учёту лизингового актива и соответствующего обязательства. Допустим, мы берём в лизинг оборудование на восемь лет. Дисконтированная сумма всех лизинговых платежей равна $115000, что соответствует справедливой стоимости оборудования на сегодняшний день. Ежегодный лизинговый платёж при этом составляет $20199, из которых $19199 – это собственно погашение лизингового обязательства, а ещё $1000 – страхование объекта лизинга, стоимость которого мы возмещаем лизингодателю. Платить всегда надо в начале года. При постановке объекта лизинга на учёт нормальный бухгалтер сделает серию следующих проводок:

Dr Right-of-use asset $19199 – Cr Cash $19299 (на сумму первоначального платежа)
Dr Right-of-use asset $95801 – Cr Lease liability $95801 (на дисконтированную сумму невыплаченных лизинговых платежей)
Dr Prepaid insurance $1000 – Cr Cash $1000 (на сумму страховой премии, уплаченной за первый год)

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

Dr Right-of-use asset $115000
Dr Prepaid insurance $1000
Cr Lease liability $95801
Cr Cash $20199

И теперь система не знает, с кредита какого счёта приходит на Prepaid insurance эта $1000. Это мы с вами можем сказать, что эта $1000 приходит из кэша – исходя из содержания хозяйственной операции. Учётная система же не имеет о содержании хозяйственной операции никакого представления. Это просто база данных, которая не может сопоставить дебет по одному счёту с соответствующим кредитом по корреспондирующему счёту, если этот дебет и кредит не прописаны явно в одной строке. В результате мы не можем построить ни анализ счёта, ни шахматную ведомость, и в этом сразу проявляется вся ущербность SAP по сравнению с той же 1С, где эти отчёты получаются в два клика. Сначала я вообще думал, что это фундаментально неустранимое отличие 1С от SAP, но потом прочитал, что как раз 1С можно легко перевести на западный стандарт, достаточно лишь снять галку «Корреспонденция» в настройках регистра. А вот SAP перевести на российский стандарт без танцев с бубном фиг получится. Там надо настраивать подсистему корреспонденции и прописывать правила сопоставления строк в бухгалтерских документах. При этом рано или поздно попадается проводка, которая не укладывается в прописанные правила, и в этом случае система чаще всего определяет корреспонденцию неправильно.

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

Recent Posts from This Journal

  • Post a new comment

    Error

    default userpic
    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 6 comments