Проанализируем ситуацию, которая часто возникает во внешнеэкономической деятельности: расчеты по договору ведутся в китайских юанях (CNY), но банк фактически списывает или зачисляет рубли (RUB), конвертируя сумму по своему курсу. В результате в учете «разъезжаются» взаиморасчеты: часть суммы попадает на рублевые субсчета (например, 60.01/60.02), часть — на валютные (например, 60.21/60.22), и в оборотно-сальдовой ведомости появляются остатки «и там, и там». Разберем по шагам, как выстроить учет так, чтобы взаиморасчеты закрывались корректно, а курсовые разницы формировались там, где нужно. Для этой задачи есть исправление ошибок зачета авансов и красного сальдо.
Ключевой принцип: бухгалтерский учет ведется в рублях, но обязательства и расчеты, выраженные в иностранной валюте, отражаются с пересчетом по официальному курсу на даты операций, а возникающие разницы (в том числе из-за курса банка) учитываются как курсовые/суммовые или как прочие доходы/расходы в зависимости от ситуации и настройки учета. Этот базовый подход закреплен стандартом учета валютных операций (ПБУ 3/2006) и методологией учета валютных средств и обязательств.
Дальше важно не «угадывать проводки», а правильно смоделировать экономическую суть операции в 1С. Рассмотрим подробнее два типовых сценария и несколько рабочих решений для разных конфигураций 1С.
Перед настройкой документов в 1С давайте вместе ответим на два практических вопроса (именно они определяют правильный способ отражения):
Если у нас сценарий №1, то в учете почти всегда логичнее отражать две операции: отдельно конверсию и отдельно оплату поставщику в CNY. Если сценарий №2 — мы фактически платим рублями, но закрываем валютную задолженность, и тогда надо правильно «состыковать» рублевый платеж с валютным договором и корректно признать разницы.
Почему это важно: типовая 1С (особенно 1С:Бухгалтерия 3.0) не любит, когда по одному договору одновременно живут движения в разных валютах без понятного механизма связывания. В ряде случаев в типовой конфигурации прямо отмечают, что учет оплаты в валюте, отличной от валюты контракта, «из коробки» ограничен, и приходится применять обходные приемы.
Посмотрим на самый «чистый» вариант, когда поставщик получает именно CNY, а рубли используются только как валюта списания/покупки валюты. Тогда наша цель — сделать так, чтобы задолженность поставщику гасилась в валюте договора (CNY), а рублевые движения отражали банковскую конверсию и комиссии.
Логика учета:
Что делаем в 1С на практике (общая схема для типовых конфигураций):
Заведем договор с поставщиком в валюте CNY. Важно, чтобы валюта договора и валюта взаиморасчетов были CNY — тогда задолженность будет «жить» на валютных субсчетах (например, 60.21 для расчетов и 60.22 для авансов — конкретные субсчета зависят от плана счетов и настроек учета).
Отразим поступление товаров/услуг в той валюте, в которой выражена стоимость по документам поставщика (чаще всего это CNY). Если учетная политика требует вести поступление в рублях по курсу ЦБ на дату признания, 1С все равно будет хранить валютную сумму и рублевый эквивалент — так и должно быть.
Отразим покупку валюты/конверсию как отдельную операцию. Здесь цель — чтобы рубли уменьшились, а на валютном счете/валютной «позиции» появились юани. В некоторых конфигурациях это оформляется документами по банковским операциям (например, операции покупки валюты), а комиссии отражаются отдельной строкой выписки или отдельной операцией. По сути, мы показываем, что банк обменял рубли на CNY по своему курсу, и эта разница не должна «ломать» расчеты с поставщиком.
Отразим оплату поставщику в CNY отдельным документом оплаты (банковская операция «Оплата поставщику»/«Списание с расчетного счета» в валюте CNY). Здесь критически важно, чтобы документ оплаты был связан именно с валютным договором (CNY) и закрыл задолженность по 60.21/60.22, а не ушел на рублевые расчеты (60.01/60.02).
Закроем месяц с переоценкой. Переоценка валютных средств и обязательств нужна, чтобы остатки в валюте на счетах (например, 52, 57 и т. п.) и задолженность в валюте (60.21/62.21 и т. п.) были пересчитаны по курсу ЦБ на отчетную дату, а курсовые разницы отразились в прочих доходах/расходах.
Почему это решение обычно «лечит» зависания на 60.21 и 60.01:
Потому что рубли перестают «притворяться оплатой поставщику». Они становятся частью операции конвертации, а реальная оплата поставщику идет в валюте договора (CNY) и закрывает именно валютную задолженность. Это согласуется и с методологией учета валютных операций, и с практикой отражения банковских операций.
Проверка результата:
Откроем отчет по взаиморасчетам с поставщиком (например, анализ по контрагенту/договору) и посмотрим, что задолженность закрыта в ноль в разрезе документа расчетов.
Проверим, что рублевые суммы не «прилипли» к расчетам с поставщиком на 60.01/60.02.
Сформируем переоценку валютных средств/обязательств за месяц и убедимся, что курсовые разницы отражены в нужных статьях прочих доходов/расходов.
Теперь разберем сценарий, когда договор и взаиморасчеты выражены в CNY, но фактическая оплата идет рублями (например, по курсу банка или по курсу, зафиксированному в счете/инвойсе). Здесь задача — чтобы рублевый платеж корректно закрыл валютную задолженность и при этом разницы (между курсом ЦБ и курсом банка/счета) отразились правильно.
В 1С:ERP такой кейс поддерживается настройками правил оплаты «расчеты в валюте, оплата в рублях». В этом подходе вы храните взаиморасчеты в валюте (например, CNY), а документы оплаты отражаете в RUB, но система понимает, что оплата относится к валютной задолженности, и корректно формирует проводки и переоценку.
Что делаем пошагово (логика ERP, применимая как методология и для других конфигураций):
Настроим правила учета расчетов так, чтобы взаиморасчеты велись в валюте договора, а оплата допускалась в рублях. В ERP для этого используют специализированные настройки финансового учета расчетов (группы финансового учета), где задаются правила «расчеты в валюте, оплата в рублях» и счета учета (например, связка субсчетов для расчетов с покупателями/поставщиками).
Оформим реализацию/поступление в валюте договора (CNY) — это создаст валютную дебиторку/кредиторку.
Оформим оплату рублями и привяжем ее к документам расчетов в валюте. Здесь важно, чтобы документ оплаты был именно «оплата по валютным расчетам», а не рублевый платеж по рублевому договору.
Выполним переоценку и проверим, что разницы сформированы корректно, а остатки не разнесены по разным субсчетам без закрытия.
Если у нас 1С:Бухгалтерия 3.0, то прямой «кнопки» как в ERP может не быть для всех комбинаций валют, и многое зависит от того, как именно оформлена операция банком и какие валюты участвуют. В практике встречаются ситуации, когда типовая БП 3.0 не умеет держать в одном договоре «долг в CNY» и «платежи в RUB» без дополнительных действий, из-за чего и появляются «хвосты» на 60.21 и 60.01.
В таком случае переходим к решениям из следующего раздела: они как раз про то, как «свести» рублевые и валютные движения так, чтобы учет стал непротиворечивым.
Рассмотрим подробнее самый практичный обходной путь для типовых конфигураций, когда в учете возникает ограничение: валюта договора одна, а оплата фактически проходит в другой, и система не закрывает взаиморасчеты автоматически. В этом случае применяют двухдоговорную схему: заводят два договора с одним контрагентом — один в валюте контракта (CNY), другой в рублях (RUB), а затем переносят задолженность документом переноса/корректировки.
Такой подход прямо встречается в разборе внешнеторговых контрактов: для корректного отражения операций в двух валютах предлагают вести два договора и использовать стандартный документ «Перенос задолженности», чтобы «перекинуть» оплату на нужный контракт. Для этой задачи есть автоматизация переноса и корректировки остатков между счетами.
Когда это решение уместно:
Когда банк проводит платеж так, что в выписке он выглядит как рублевый платеж поставщику, и 1С уверенно относит его на рублевые расчеты — в этом поможет автоматизация разнесения банковской выписки по операциям и договорам.
Когда нам важно сохранить «юаневую» задолженность по поставкам (CNY), но оплату физически приходится отражать как RUB (из-за банковских ограничений, санкций, посредников и т. п.).
Когда типовая автоматом не закрывает 60.21 через рублевую оплату и оставляет остатки на 60.01/60.02.
Разберем по шагам:
Создадим договор №1 (CNY) — для поступлений товаров/услуг и формирования кредиторской задолженности в валюте.
Создадим договор №2 (RUB) — для отражения фактических рублевых списаний/зачислений из банка (чтобы выписка «легла» без ручных правок в валюту документа).
Оформим поступление товаров/услуг по договору CNY — задолженность появится на валютном субсчете (например, 60.21).
Оформим оплату по выписке банка по договору RUB — она попадет на рублевые расчеты (например, 60.01/60.02), и это нормально в рамках данной схемы.
Выполним документ «Перенос задолженности»: перенесем сумму оплаты (или задолженности) с рублевого договора на валютный договор так, чтобы в итоге закрылась задолженность по договору CNY. Именно на этом шаге мы «состыковываем» экономический смысл: рублевая оплата погашает юаневую задолженность.
Отразим разницы (если они возникли): при переносе и пересчетах могут появиться суммы, связанные с разным курсом (ЦБ vs банк). Их обычно относят на прочие доходы/расходы, а затем выполняют переоценку валютных остатков и обязательств в конце месяца.
Чем хороша двухдоговорная схема:
Она снимает конфликт «в одном договоре две валюты» и позволяет типовой 1С закрывать взаиморасчеты стандартными документами, без «магии» и без постоянных ручных правок выписки. Плюс, документ «Перенос задолженности» — типовой, его проще контролировать в отчетах и при проверках.
На что обратить внимание:
Перенос лучше делать в разрезе конкретных документов расчетов (если учет ведется по документам) — так вы избежите «смешивания» оплат и поступлений.
После переноса обязательно проверим аналитику по счетам 60.* (в разрезе контрагента, договора и документа расчетов) и убедимся, что по каждому договору остатки логичны.
Иногда нам нужно быстро и прозрачно привести учет в порядок, особенно если документы уже введены «как получилось», и остатки на 60.21 и 60.01 уже образовались. Тогда применяют точечную корректировку — чтобы закрыть взаиморасчеты и правильно показать разницы.
В практических консультациях по ситуациям «оплата и поступление в разных валютах» встречается рекомендация использовать ручную операцию или корректировку для отражения курсовых разниц и закрытия расчетов, когда типовой механизм не дал желаемого результата.
Как действовать аккуратно:
Сначала восстановим правильную картину взаиморасчетов: определим, какая сумма реально должна закрыть задолженность в валюте (CNY) и какой рублевый эквивалент по курсу ЦБ должен быть признан на дату операции.
Затем оформим корректировку так, чтобы остаток с рублевого субсчета (например, 60.01/60.02) был перенесен на валютный (60.21/60.22) или наоборот — в зависимости от того, где «висит» лишнее. Цель — чтобы по контрагенту/договору не оставалось двойного сальдо.
Разницу между курсом банка и курсом ЦБ отнесем на прочие доходы/расходы (91.*) — так, чтобы экономический смысл был прозрачен: банк конвертировал по своему курсу, а бухгалтерский учет ведется по курсу ЦБ на дату операции, и разница должна быть показана как финансовый результат периода.
После этого выполним переоценку в закрытии месяца и проверим, что не появилось повторных разниц или «качелей» на счетах.
Когда выбирать это решение:
Когда документов немного и нужно быстро исправить учет без перестроения схемы договоров.
Когда ситуация нестандартная (посредники, частичные оплаты, смешанные курсы, нетипичная выписка), и типовые инструменты закрытия в разных валютах не дают чистого результата.
Когда нужно обеспечить максимальную понятность для аудитора/проверяющего: ручная операция с грамотным описанием иногда читается проще, чем цепочка «нестандартных» документов.
Давайте посмотрим на прикладной прием, который часто применяют именно в 1С:Бухгалтерия (в том числе на УСН), когда закупка/поступление оформлены в одной валюте, а оплата — в другой. В разборе подобного вопроса рекомендуют после отражения операций обязательно проверять закрытие расчетов по отчету анализа субконто по контрагенту и договору, чтобы убедиться, что все «сошлось в ноль» в нужном разрезе.
Что делаем:
Оформим документы так, чтобы каждый «жил» в своей логике: поступление — по валютному договору (CNY), оплата — так, как приходит из банка (иногда RUB), не пытаясь «натянуть» валюту туда, где ее фактически нет.
Сведем расчеты выбранным способом: либо через перенос задолженности (двухдоговорная схема), либо через корректировку долга/ручную операцию, если перенос не подходит.
Проверим, что расчеты закрылись не «в целом по 60 счету», а в правильной аналитике: контрагент → договор → документ расчетов. Это принципиально важно, потому что «висеть» могут не только суммы, но и разрезы аналитики.
Как проверяем:
Сформируем отчет «Анализ субконто» по контрагенту с детализацией по договору и документу расчетов и убедимся, что итоговый остаток равен нулю (или равен ожидаемому, если есть непогашенная задолженность).
Сформируем оборотно-сальдовую ведомость по счетам расчетов (60.*) и посмотрим, не осталось ли «дубля» между 60.21 и 60.01.
Проверим переоценку валютных средств/обязательств по итогам месяца и убедимся, что курсовые разницы отражены один раз и в нужном периоде.
Давайте разложим по полочкам типичную причину путаницы, которая описывается в похожих вопросах: поступление/учет товара ведется «в рублях», а расчеты с поставщиком «в юанях», и в итоге часть операций отражается на валютных субсчетах, а часть — на рублевых, без механизма связывания. Именно так в практических обсуждениях и формулируют проблему: «оплата в юанях, а поступление в рублях — происходит путаница».
Что в этот момент делает система:
Документ поступления создает задолженность по одному договору/валюте (например, CNY) и кладет ее на 60.21.
Документ оплаты, если он оформлен как рублевый платеж по рублевому договору или без привязки к валютному договору, закрывает другую аналитику и уходит на 60.01/60.02.
Итог: задолженность по поставке остается на 60.21, а рублевая «оплата» висит как отдельное движение на 60.01/60.02, не закрывая валютный долг.
Значит, лечим не проводки, а причину: добиваемся, чтобы оплата была связана с валютной задолженностью либо через корректное оформление валютной оплаты (Решение 1), либо через правила «валюта/рубли» (Решение 2), либо через перенос/корректировку (Решения 3–4).
Чтобы не сомневаться, давайте зафиксируем простой алгоритм выбора:
Если поставщик получает CNY (банк конвертирует и отправляет юани) — выбираем Решение 1 и отражаем конверсию отдельно от оплаты.
Если договор в CNY, но платим рублями по правилам «оплата в рублях» и конфигурация это поддерживает (особенно 1С:ERP) — выбираем Решение 2.
Если типовая 1С:Бухгалтерия не закрывает расчеты в разных валютах по одному договору — выбираем Решение 3 (два договора + перенос задолженности) как самый стабильный вариант.
Если нужно быстро исправить уже введенные документы — применяем Решение 4 (корректировка/ручная операция) и затем выстраиваем правильную схему на будущее.
Давайте закрепим: после любого выбранного решения обязательно делаем контроль, чтобы проблема не всплыла снова при закрытии месяца или при следующей поставке.
Проверим закрытие по аналитике: контрагент → договор → документ расчетов. Даже если по счету 60 «в целом» ноль, в разрезе документов может остаться хвост, который позже превратится в курсовые разницы «не там» или в неверное сальдо.
Проверим, где сидит задолженность: если договор валютный, то задолженность должна жить на валютных субсчетах (например, 60.21/60.22), а не «расползаться» на 60.01/60.02 без причины.
Сделаем переоценку валютных средств/обязательств и убедимся, что курсовые разницы отражаются корректно и однократно.
Проверим комиссии банка: комиссии не должны попадать в расчеты с поставщиком. Они учитываются отдельно как банковские расходы, чтобы не ломать взаиморасчеты.
Чтобы закрепить материал, перечислим самые частые ошибки и сразу договоримся, как их обходить:
Ошибка: вводим оплату рублями по валютному договору как «обычную оплату поставщику» без привязки к валютным расчетам.
Как исправляем: либо отражаем оплату в валюте (через конверсию — Решение 1), либо применяем правило «расчеты в валюте, оплата в рублях» там, где оно поддерживается (Решение 2), либо уходим в перенос задолженности (Решение 3).
Ошибка: пытаемся «подогнать» поступление товара под рубли, когда договор валютный (или наоборот — подгоняем оплату под валюту, которой фактически не было).
Как исправляем: отражаем хозяйственную операцию по ее сути: поступление — по документу поставщика (валюта договора), оплата — как в выписке банка, а связываем их корректным механизмом (перенос/правила/двухоперационная схема).
Ошибка: не выполняем переоценку и не проверяем курсовые разницы.
Как исправляем: закрываем месяц с переоценкой валютных средств и обязательств и анализируем справку-расчет/результат, чтобы понять, где и почему возникла разница.
Давайте подытожим совместную работу. Проблема «оплата в юанях, поступление/списание в рублях» почти всегда сводится к тому, что 1С видит две разные истории: валютную задолженность и рублевую оплату, которые не связаны между собой. Наша задача — выбрать подход, который создаст эту связь:
Лучший универсальный вариант — разнести конверсию и оплату (Решение 1): тогда расчеты с поставщиком закрываются в валюте договора, а рубли остаются в конверсии и комиссиях.
Если конфигурация поддерживает — настроить «расчеты в валюте, оплата в рублях» (Решение 2), чтобы система сама понимала соответствие RUB-платежа валютной задолженности.
Если типовая не стыкует валюты — применить двухдоговорную схему и «Перенос задолженности» (Решение 3) как надежный способ «свести» оплаты и поставки.
Для исправления уже введенного учета — использовать точечную корректировку (Решение 4) и затем закрепить правильную схему на будущее.
Информация носит справочный характер и предназначена для методической помощи при настройке учета; при внедрении в конкретной базе учитывайте вашу конфигурацию 1С, план счетов, учетную политику и условия договора/банковской выписки.