В стране явно не хватает математиков. Бухгалтерия неправильно считает НДС #748278

Сдаем НДС, по-новому. Конкретно тут 10%, с 18% вроде сошлось до погрешности в рубль Книга продаж считает результат базы по каждой СФ, отлично Декларация считает от всей базы, тоже неплохо И вроде все хорошо, но эти разные способы различаются на 42 рубля Вот наша бухгалтерия и переживает. Я говорю Сдавайте как есть. Проблемы в законе. Но бухгалтера боятся, что проблемы у нас. Как быть? У Вас такое есть?

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

Налогооблагаемой базой является не сумма в целом по всем сделкам, а сумма по каждой строке документа ОТДЕЛЬНО. так что разбежка даже по документу уже будет. Но при большом колве строк/документов общий итог весьма близок. ркасхождение в десятки рублей возможно свидетельствует об искуственном "округлени", например когда булгахтера "бояться" то 4.232 в сумме НДС округляют до 4.24 (просят сделать такое округление), и тогда - в итоге да - могут быть существенные отклонентия типа как у вас.

не верю округление с одной с записи(с.ф.) не более полкопейки. Чтобы набрать 42 руб надо более 8000 округлений в одну сторону, это не учитывая округлений в другую сторону.

верь, округление в строке СФ, а не в СФ в целом. Я анализировал, есть СФ с забезом в 70 копеек

это все хорошо в теории, ты на вопрос ответь

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

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

тоже на статистику намекнул эти вообще ладно, продаю хрень по 0,01 рублю (без учета НДС цена), в течении месяца (30 дней), итоговый НДС вроде 0 илм 0.03?

какието кривые счф у вас У мея счф естьао нескольку сотен строк Расхождения мизерные

Ндс считается по строкам, потом пишется это всё дело в рн, а оттуда в декларацию

П.с. у вас есть цены в уе с ндс ?

да, устанавливаются в у.е., но в первичку они попадают в рублях

тогда где логика из 10 не работает ?

может у тебя НДС по курсу пересчитывается?

я проверял все ошибка округления именно из=за разной методики подсчета

тем по ставке 18% все сошлось

в каких местах она разная ?

Работаем с контрагентом, который учет в валюте ведет. - т.е. суммы и НДС считает в валюте (в САПе), а потом в рубли переводит - вот там по 50 копеек разница по НДС бывает на каждую строку сч/ф

поому что в сапе ндс равен сумма в уе по документу, умноженный на курс А не по строчный перевод ндс в рубли

не сходится именно по позициям. в целом по документу не проверял

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

перечитай

вся база о куда берётся - из рн ндс ?

еще раз: я сделаю 100 СФ по продаже 1 карандаша ценой без НДС 0,01 рубля (ставка 10%) в каждой отразится НДС = 0 вся же база равна 1.00 итого НДС = 0,10 не помню, это БП 2.0, в понедельник скажу

ой-ой-ой! вот есть у нас куча позиций - кабель. Цены у него за метр. В у.е. А продают его километрами. Бывает, что и по несколько сотен. А считают метрами, поскольку он на бобинах 306 +/- лапоть.

Не считают НДС "от всей базы". Только по позициям. В НК это четко написано.

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

ФНС надо ввести сертификацию учетных систем. Чтобы всякие САПы и прочие самоделки не писали, что "у нас все правильно, а ваша 1С не так считает".

нормальное явление. К сожалению, те бухгалтера, которые не верят на слово программе и перепроверяют 90 счет по ставкам - очень часто страдают перфекционизмом - и ошибка  округления в 10-20 рублей для них - из области фантастики. По сути - первичным документов является счетфактура - поэтому правильной является цифра которая попадает в книгу и декларацию. Цифра полученная расчетным способом является не более чем цифрой и к учету имеет слабое отношение. НО Бывают ситуации когда бухгалтера или специалисты допускают ошибки - поэтому если расчетная цифра существенно  отличается - целесообразно дополнительно проверить книгу - выгрузит ее в эксель и там сравнить расчетную цифру с сохраненной по каждой СФ если есть отклонения больше нескольких копеек по документу - желательно проверить такие СФ вручную. Правда имеет смысл соизмерять количество строк в СФ - если СФ содержит несколько тысяч наименований - то отклонения могут быть и по несколько рублей. В моем случае в квартале около 30-40 тыс счет фактур по 30-100 строк.  каждый месяц встречаются отклонения в 10-40 рублей.

переходи на 3.0

где-то было на этот счёт письмо фнс

3.0 тут не причем - это чистая математика. Эта ошибка была в 7.7 и такая же сейчас у меня в 3.0

ужас

читай 26 и 10

дык я просто забыл "ошибку" в кавычки взять. Мне столько нервов этой "ошибкой" вымотали. "Не может быть ошибка округления такой большой" (С) ГБ "Округления же должны в разные стороны складываться" (С) ГБ

ты гб в нк отправляй

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

зачем книгу в эксель ?

Что бы доказать, что накопленная ошибка округления может быть больше 10 рублей. Потом уже написал отдельный отчет для анализа ошибок в разрезе ставок НДС - бесполезно - "а вдруг отчет не правильно считает" (С) - эксель то "надежнее" - там то сам ручкой формулу вбиваешь. В общем это неизлечимо - я уже смирился.

в книгах и так есть общие функции + есть сложение выделенных строк )))

Не. это не то. Берешь книгу и  сохраняешь в Эксель - потом берешь столбец сумма без НДС 18 и выкручиваешь из нее НДС - из полученной суммы вычитаешь сумму НДС по той же строке - получаешь ошибку округления по документу - в моем случае обычно  от -4 до +4 копеек. потом складываешь сумму ошибок округления по всем документам - по теории вероятности - ошибки округления должны схлопываться. Но на практике для 10-12 тысяч документов эти копейки в итоге частенько складываются в сумму 20-40 рублей.

нельзя так делать

почему?

В Excel зачем? Запросом в консоли отчетов всё замечательно проверяется. А так проблема старая и это косяк законодательства.

По привычке - потому что раньше это было в 7.7 и там консоли отчетов не было. Опять же консоль, отчет,  обработка - это все делает программист и может ошибиться и проверить его нельзя. А эксель как бы вот он - любую строку можно проверить и самому формулу скопировать. А в законодательстве никаких косяков как таковых нет - проблема в том, что расхождение между расчетной суммой НДС и фактической может свидетельствовать как об ошибке округления, так и о том, что где то ошибся человек, например вбив ставку 10, а сумму посчитав вручную по 18 (прецеденты бывали). Вопрос в том, что грань между двумя этими состояниями очень зыбкая.

Тебе сам запретил! Перестань ерепениться!

Эта проблема?

Да разве это какая-то сложная математика? Обычная "проблема копеек" которую либо законодательство, либо разработчики не учли.

Налицо очередной "честный" способ ухода от НДС - продажа товара "долями", таким образом, чтобы НДС от каждой доли округлялся в ноль. Особенно с услугами это просто сделать. Расценить например секунду консультации и оплачивать отдельно)

тут  запаришься этим дурам доказывать, 2х2 не равно 5, а ты о вечном...

А чему равно дважды два?

Еще один бухгалтер:))

+51 смотря какая система счисления и ваши кооординаты в пространстве. Наверняка они тебя спрашивают, а если это векторы?!!! И что ты им отвечаешь?

потому что никогда не сойдётся, если суммы с копейками

Я тебя умоляю...Если я им скажу про двоичное счисление или не лай бог шестнадцетиричное - я там и умру:-))

нет никакх проблем, есть тупые бухи

не прокатит

Это да. Готов давать медаль "Умный бух":-)

Свою отдашь?

Я ж не бух:-)  Так что при всем желании- нет

ты же как прог должен быть умнее буха

Кому? Вот сейчас было обидно..

Ну понятно, у Ходорковского тоже не прокатило. Но формально это дыра в законе. Могли бы написать в НК "НДС в счет-фактуре округляется до копеек, если не строго ноль - то минимальная сумма 1 копейка".

Потому и не разбрасываюсь направо- налево:-)

ты чётко знаешь, за что ходер сел ?

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

..>>формально букве закона не противоречащие ...блаженны верующие(С)Библия

дык в этом и смысл что бы не сходилось. На каждой счетфактуре может быть несколько копеек отклонений между фактическим НДС и расчетным, как в плюс, так и в минус. Потом эти копейки складываются и должна получиться некая сумма отклонения. Поскольку бухи искренне уверены в том, что по теории вероятности эти округления при сложении должны стремиться к нулю. Однако на практике теория вероятности действует не так однозначно и иногда эти копейки могут складываться в десятки рублей (на 12 тыс счет фактур - это в общем даже терверу не особо противоречит) - но на слово не верят - и каждый раз приходиться доказывать.

Внезапно возник какойто фактический ндс и расчетный ндс