Каталог решений - Ведение взаиморасчетов в конфигурациях «Комплексная автоматизация 1.1» и «Управление производственным предприятием 1.3» — часть 2

Здесь следует отметить следующее. В действующей нормативной базе в области учета взаиморасчетов (НК РФ, ПБУ, 402-ФЗ) не прописана аналитика раздельного ведения взаиморасчетов, это является элементом учетной политики. Однако, имеются требования к формированию показателей «Дебиторская задолженность», «Кредиторская задолженность» в бухгалтерской отчетности (не допускается их искусственное взаимное завышение, как и зачет между ними), а также есть ограничения в смежных участках учета, связанные с понятием сделки на стыке ГК РФ и НК РФ, например — в НДС с авансов, в валютных расчетах и расчетах в условных единицах.

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

Любые дополнительные углубления детализации взаиморасчетов, приводящие к наличию «встречного» сальдо по одному договору, т.е. когда на какую-то отчетную дату по одному контрагенту и одному договору имеется и долг и аванс, требуют дополнительной расшифровки стандартных бухгалтерских регистров для обоснования:

• разделения на аванс и долг в разрезе заказов или счетов;
• возмещения ранее начисленного НДС с авансов, т. к. НК РФ содержит закрытый перечень ситуаций когда мы имеем право на возмещение, и отражаются эти ситуации в определенных строках декларации по НДС, а мы вдруг решим перекинуть деньги с заказа на заказ, выполнив зачет встречного аванс и долга, что логически должно привести к зачету НДС с аванса);
• расчета курсовых разниц и переоценки валютных остатков по каждому заказу раздельно.
• и др;

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

Поэтому, если в вашей информационной базе ведется два контура учета, и вы не можете (или не хотите) по вышеизложенным причинам включить разделитель учета по сделкам, чтобы он не влиял на авансы и долги в реальном бухучете, но вам при этом крайне важно понимание оплаченности каждого заказа, то есть два варианта:
а) вы можете совместно использовать регистры накопления «Заказы покупателей» и «Расчеты с контрагентами» (!!! НЕ взаиморасчеты, а имено "расчеты") в разрезе заказов чтобы определить отгруженность, оплаченность заказа, а разница между ними как раз будет виртуальной задолженностью (авансом) по заказу.
б) можно пойти другим путем, и доработать конфигурацию так, чтобы детализация по сделкам не выносилась в регламентированный учет, сохранившись чисто в управленческом (например, для менеджеров).