Оплата по счёту и постоплата для юрлиц на 1С-Битрикс

В рознице покупатель платит картой и уходит с товаром — сделка закрывается за минуту. В B2B всё иначе: организация не достаёт корпоративную карту на кассе, а просит выставить счёт, передаёт его в свою бухгалтерию и оплачивает безналично платёжным поручением. Между «оформил заказ» и «деньги пришли» проходят дни, в игру вступают реквизиты, НДС, отсрочка платежа и сверка с банком. Если этот процесс на сайте не выстроен, менеджеры вручную готовят счета в Word, теряют реквизиты и путаются, кто оплатил, а кто нет.

Эта статья — практическое руководство по оплате по счёту в Битрикс и постоплате для юрлиц: как организации платят в B2B, как настроить способ оплаты «Счёт», сформировать счёт из заказа с корректными реквизитами и НДС, отдать PDF, подтвердить поступление денег через банк и 1С, и как аккуратно давать отсрочку с кредитным лимитом. Материал основан на нашей практике разработки B2B-сайтов на 1С-Битрикс. Дисклеймер: бухгалтерские и юридические нюансы (НДС, формы документов, условия отсрочки) всегда сверяйте с бухгалтером и юристом — здесь мы говорим о технической и процессной стороне.

Почему юрлица платят по счёту, а не картой

Чтобы правильно спроектировать оплату для B2B, нужно понять поведение корпоративного покупателя. Оно принципиально отличается от розничного, и попытка «натянуть» на юрлицо розничный сценарий с картой почти всегда буксует.

Вот почему организации выбирают безналичный расчёт по счёту:

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

Отсюда вывод: для B2B-магазина оплата по счёту — не дополнительная опция «на всякий случай», а основной способ расчёта. Онлайн-оплата картой и СБП при этом тоже может присутствовать — для мелких заказов, физлиц или срочных покупок, — но проектировать оплату начинают именно от безналичного счёта. Как подключить и онлайн-эквайринг для смешанной аудитории, мы разбирали в статье про подключение ЮKassa, СБП и Т-Кассы.

Как устроена оплата по счёту в 1С-Битрикс

Оплата по счёту в 1С-Битрикс собирается из тех же кирпичиков модуля «Интернет-магазин», что и любая другая оплата, но с важной спецификой B2B. Разберём сущности, которые в этом участвуют.

• Тип плательщика. В настройках магазина различают «Физическое лицо» и «Юридическое лицо». От типа зависят набор свойств заказа и доступные способы оплаты. Оплата по счёту привязывается к типу «Юрлицо».
• Свойства заказа. Поля, которые заполняет покупатель: для юрлица — наименование, ИНН, КПП, юридический адрес и т. д. Именно из них счёт берёт реквизиты плательщика.
• Платёжная система «Счёт». Способ оплаты с обработчиком безналичной оплаты. Он формирует печатную форму счёта из состава заказа и данных плательщика.
• Оплата заказа. Сущность «оплата» отражает поступление денег. Заказ может иметь одну или несколько оплат; он считается оплаченным, когда их сумма покрывает сумму заказа.
• Статусы заказа. Отражают этап: оформлен, выставлен счёт, оплачен, отгружен. Статусы удобно настроить под B2B-процесс.
• Обмен с 1С. Канал, по которому заказ уходит в учётную систему, а обратно приходят статус оплаты и документы. Для B2B это ключевой элемент.

Главное отличие от онлайн-оплаты: при оплате по счёту нет мгновенного подтверждения. Онлайн-эквайринг присылает колбэк за секунды, а безналичный платёж идёт банковскими днями, и «оплачен» ставится по факту поступления денег — из банковской выписки или через обмен с 1С. Поэтому центр тяжести настройки смещается с приёма колбэка на корректный счёт и надёжную сверку оплат.

Способ оплаты «Счёт» в модуле «Интернет-магазин»

Технически оплата по счёту — это платёжная система с соответствующим обработчиком в разделе «Магазин → Платёжные системы». Она включается для типа плательщика «Юридическое лицо» и показывается таким покупателям на шаге оформления заказа.

Что делает эта платёжная система:

• Формирует печатную форму счёта. На основе состава заказа, сумм, ставок НДС и реквизитов плательщика/получателя выводит готовый счёт, который можно распечатать или сохранить.
• Показывает счёт покупателю. Ссылку на счёт дают на странице «Спасибо за заказ» и в личном кабинете, а также отправляют письмом.
• Не переводит заказ в «оплачен» автоматически. В отличие от эквайринга, обработчик счёта не получает подтверждение оплаты сам — статус ставится по факту поступления денег (вручную или через 1С).

Обработчик счёта в базовой поставке даёт шаблон печатной формы, который настраивается под ваши реквизиты и оформление. В реальных проектах шаблон почти всегда дорабатывают: добавляют логотип, подпись и печать, корректные формулировки, разбивку НДС, а иногда полностью переносят генерацию счёта в 1С (об этом ниже). Для розничного магазина такой способ оплаты обычно скрывают от физлиц и показывают только юрлицам — чтобы не путать аудитории.

Реквизиты покупателя: свойства заказа для юрлиц

Корректный счёт невозможен без корректных реквизитов плательщика, а они берутся из свойств заказа для типа «Юридическое лицо». Это фундамент всей схемы, поэтому набор свойств продумывают заранее.

Минимальный набор реквизитов юрлица

• Наименование организации — как в учредительных документах.
• ИНН — идентификатор налогоплательщика, ключевое поле для сверки и автозаполнения.
• КПП — код причины постановки на учёт (у ИП его нет).
• Юридический адрес — для счёта и документов.
• Контактное лицо и телефон — для связи по заказу.

Дополнительные поля, которые часто нужны

• Расчётный счёт, банк, БИК, корр. счёт — если вы указываете реквизиты плательщика в документах.
• Фактический адрес доставки — если отличается от юридического.
• ОГРН / ОГРНИП — для отдельных документов.
• Признак работы с НДС — упрощёнка без НДС меняет формулировки счёта.

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

Валидация реквизитов

Чтобы в счёт не попадал мусор, поля стоит валидировать: ИНН — по длине и контрольным цифрам (10 знаков у юрлица, 12 у ИП), КПП — по формату, расчётный счёт — по длине. Это ловит явные опечатки до того, как менеджер отправит некорректный счёт. Полная проверка «существует ли такая организация» решается уже автозаполнением по ИНН — о нём следующий раздел.

Автозаполнение реквизитов по ИНН

Ручной ввод реквизитов — источник ошибок: перепутанные цифры ИНН, лишний пробел, неверный КПП. Каждая такая опечатка = некорректный счёт и переделка. Автозаполнение по ИНН решает проблему в корне.

Как это работает:

1. Покупатель вводит ИНН в поле реквизитов при оформлении заказа.
2. Сайт отправляет запрос к внешнему справочнику контрагентов (сервис по данным реестров).
3. Сервис возвращает данные организации: полное и краткое наименование, КПП, юридический адрес, иногда ОГРН и статус.
4. Поля подставляются автоматически. Покупатель проверяет и при необходимости корректирует адрес доставки и контакты.
5. Реквизиты сохраняются в свойствах заказа и профиле для повторных покупок.

Выгода очевидна: быстрее оформление, меньше ошибок, чище счета. Но есть нюансы, которые важно учесть при внедрении:

• Источник данных. Автозаполнение требует подключения внешнего сервиса. У таких сервисов есть свои условия использования, лимиты запросов и, как правило, тарификация — это учитывают на старте.
• Данные могут устаревать. Организация могла сменить адрес; поэтому подставленные значения всегда дают покупателю на проверку, а не «зашивают намертво».
• Не только сайт. Часто справочник контрагентов уже есть в 1С или CRM — тогда автозаполнение логично строить на связке с учётной системой, а не отдельным сервисом.

Формирование счёта из заказа

Счёт — центральный документ оплаты по счёту, и он должен формироваться автоматически из заказа, без ручной сборки в Word. Разберём, из чего он собирается и на что обратить внимание.

Из каких данных состоит счёт

• Реквизиты получателя (продавца). Ваша организация: наименование, ИНН, КПП, расчётный счёт, банк, БИК, корр. счёт. Задаются один раз в настройках.
• Реквизиты плательщика (покупателя). Берутся из свойств заказа юрлица (см. раздел про реквизиты).
• Номер и дата счёта. Уникальный номер (лучше — из сквозной нумерации 1С) и дата выставления.
• Номенклатура. Позиции заказа: наименование, количество, единица измерения, цена, сумма — из состава корзины.
• НДС. Ставка и сумма налога по каждой позиции и итогом; либо пометка «Без НДС», если продавец не плательщик НДС.
• Итоги. Сумма без НДС, сумма НДС, всего к оплате, сумма прописью.

Аккуратность с НДС

НДС в счёте — частая точка ошибок. Ставки налога должны быть корректно заданы у товаров, иначе счёт выйдет с неверной суммой налога. Учитывают и режим налогообложения продавца: если вы на упрощёнке без НДС, в счёте пишут «Без НДС», а не нулевую ставку. Смешанные корзины (товары с разными ставками) тоже должны корректно разбиваться в итогах. Эти детали — совместная зона разработчика и бухгалтера.

Кто фактически рисует счёт — сайт или 1С — зависит от масштаба. В простых случаях достаточно печатной формы Битрикса. В зрелых B2B-проектах счёт формирует 1С (там же нумерация, договоры, спецификации), а сайт передаёт заказ и получает готовый документ. Второй вариант надёжнее для учёта, но требует настроенного обмена. Тесно связана с этим тема индивидуальных цен: если у клиента свой прайс, в счёт должны попасть именно его цены — как это устроить, мы разбираем в статье про индивидуальные прайс-листы для B2B.

PDF-счёт и отправка покупателю

Сформировать счёт мало — его нужно доставить покупателю в удобном виде. Стандарт де-факто в B2B — счёт в PDF: он одинаково выглядит на любом устройстве и в любом принтере, его удобно переслать в бухгалтерию.

Каналы доставки счёта покупателю:

• Страница «Спасибо за заказ». Сразу после оформления показывают ссылку «Скачать счёт» — покупатель получает документ, не выходя с сайта.
• Письмо на e-mail. Счёт прикрепляют к письму-подтверждению заказа. Это самый ожидаемый канал: бухгалтерия работает с почтой.
• Личный кабинет. В кабинете юрлица счета по всем заказам доступны для скачивания в любой момент — удобно, когда бухгалтер ищет документ по старому заказу.

Технически PDF генерируют либо на сайте (из печатной формы), либо берут готовый из 1С. Важные детали качественного счёта-PDF: корректная кодировка (без «кракозябр»), помещается на страницу, читается при печати, содержит все реквизиты и, если нужно, факсимиле подписи и печати. Проверьте, что при большом числе позиций счёт не «ломается» по вёрстке и корректно переносится на вторую страницу.

Подтверждение поступления оплаты

Это ключевой раздел, отличающий оплату по счёту от онлайн-эквайринга. Здесь нет мгновенного колбэка: деньги идут банковскими днями, и заказ переводят в «оплачен» по факту поступления. Вопрос — как это поступление зафиксировать надёжно.

Способ 1. Ручная сверка выписки

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

Способ 2. Обмен с 1С (рекомендуется)

Оплата фиксируется в 1С — там ведётся банк и учёт. Бухгалтер проводит поступление по нужному заказу (или оно подтягивается автоматически из банковского обмена), а при обмене с сайтом статус оплаты синхронизируется: заказ на сайте становится «оплачен», покупатель видит это в личном кабинете. Факт оплаты фиксируется один раз в учётной системе и отражается везде.

1. Деньги поступают на расчётный счёт от плательщика.
2. Поступление отражается в 1С — из банковской выписки, вручную или автозагрузкой.
3. Оплата сопоставляется с заказом по номеру счёта, сумме и контрагенту.
4. Обмен переносит статус оплаты на сайт.
5. Заказ становится «оплачен», покупатель и менеджер видят актуальный статус.

Второй способ — стандарт для B2B-магазина с заметным потоком счетов. Он снимает ручную рутину и убирает рассинхрон «в 1С оплачено, на сайте нет». Подробнее механику обмена заказами и статусами разбираем в разделе про интеграцию с 1С ниже.

Постоплата и отсрочка платежа

До сих пор мы говорили про схему «сначала оплата по счёту, потом отгрузка». Но в B2B нормальна и обратная последовательность — постоплата, когда товар отгружают до оплаты. Это мощный инструмент удержания клиентов, но требует аккуратности.

Постоплата

Постоплата — отгрузка с оплатой после получения товара. Клиент получает продукцию и оплачивает счёт в согласованный срок. На сайте это означает, что заказ можно оформить и провести в работу без предоплаты: способ оплаты «постоплата» разрешён для клиента, а статус оплаты закрывается позже, по факту поступления денег.

Отсрочка платежа

Отсрочка — это условие о сроке оплаты: заплатить в течение согласованного количества дней с даты отгрузки. Отсрочка превращает постоплату из «когда-нибудь» в конкретное обязательство с датой. Её фиксируют в договоре и учитывают при контроле задолженности.

Важный принцип: постоплату и отсрочку дают не всем подряд, а проверенным клиентам, и в рамках кредитного лимита. Технически на сайте это выражается так:

• Признак «доступна постоплата» у клиента (группа покупателей или свойство контрагента). Только таким клиентам показывают способ «постоплата».
• Срок отсрочки хранится в свойствах клиента или договора и используется для контроля просрочки.
• Кредитный лимит ограничивает суммарную задолженность (см. следующий раздел).

Кредитный лимит и дебиторка

Отсрочка без контроля превращается в неуправляемую дебиторскую задолженность. Два инструмента держат её в узде: кредитный лимит и мониторинг дебиторки.

Кредитный лимит

Кредитный лимит — максимальная сумма задолженности, которую вы готовы держать по конкретному клиенту. Пока текущий долг плюс новый заказ укладываются в лимит, клиент может оформить постоплату; если заказ выводит за лимит, система требует предоплату или согласование. Логика проверки лимита обычно живёт в 1С или CRM (там же полная картина отгрузок и оплат), а сайт запрашивает у учётной системы, доступна ли постоплата на текущую сумму.

Дебиторская задолженность

Дебиторка — деньги, которые клиенты должны вам за отгруженный товар. По каждому контрагенту важно видеть: сколько должен, по каким счетам, есть ли просрочка. Эта картина ведётся в учётной системе, а на сайте её полезно показывать клиенту в личном кабинете — список неоплаченных счетов и сумма к оплате дисциплинируют не хуже звонка менеджера.

• Текущая задолженность — сколько клиент должен прямо сейчас.
• Просроченная задолженность — по счетам, у которых вышел срок отсрочки.
• Доступный остаток лимита — сколько ещё можно отгрузить в кредит.
• Блокировка новых отгрузок при превышении лимита или наличии просрочки.

Для клиента прозрачность полезна: он видит свои долги и планирует оплаты. Для вас — это защита оборотных средств. Такой контроль естественно вписывается в личный кабинет дилера и тесно связан с документооборотом: список счетов, актов и накладных с их статусами оплаты. Тему закрывающих документов и сверки мы подробно разбираем в статье про документооборот B2B и ЭДО.

Смешанные способы: аванс плюс постоплата

Реальные сделки не всегда укладываются в чистую «предоплату» или «постоплату». Частый компромисс — смешанная схема: часть суммы авансом, остаток — после отгрузки. Она балансирует интересы сторон: продавец подстраховался авансом, покупатель не платит всё вперёд.

Как это устроено технически в 1С-Битрикс:

• Заказ поддерживает несколько оплат. Одна оплата — аванс, вторая — доплата. Заказ считается полностью оплаченным, когда сумма оплат покрывает сумму заказа.
• Частичная оплата — отдельный статус. Пока внесён только аванс, заказ в статусе «оплачен частично», а не «оплачен».
• Аванс может идти разными каналами. Например, аванс — онлайн-картой или по счёту, а остаток — по счёту после отгрузки.

Конкретные пропорции аванса и остатка (например, аванс и оставшаяся часть) — это коммерческое решение, а не техническое: система лишь должна корректно учитывать несколько оплат по заказу и правильно показывать статус «оплачен частично / полностью». Проверьте, что при доплате остатка заказ автоматически переходит в «оплачен», и что покупатель в кабинете видит, сколько уже внесено и сколько осталось.

Способы оплаты в B2B: сравнение

Чтобы собрать оплату для B2B-магазина осознанно, полезно видеть все способы рядом. У каждого своя роль: не нужно выбирать один — обычно их комбинируют под сегменты покупателей.

Логика показа способов: юрлицам с типом плательщика «Юрлицо» показывают безналичный счёт (и постоплату — если она им открыта), физлицам и на мелкие заказы — онлайн-оплату. Не стоит вываливать все способы всем: покупатель-организация не должна видеть «оплату картой» как единственный вариант, а розничный клиент — теряться в безналичном счёте. Привязка способов оплаты к типу плательщика и группе покупателя решает это чисто.

Закрывающие документы

Важно не путать счёт с закрывающими документами. Счёт на оплату — это основание для платежа, а не подтверждение сделки для учёта. Бухгалтерия клиента не сможет принять товар к учёту по одному счёту — ей нужны закрывающие документы.

• Накладная (ТОРГ-12) — подтверждает передачу товара покупателю.
• Универсальный передаточный документ (УПД) — объединяет функции накладной и счёта-фактуры; часто используется вместо связки «накладная + счёт-фактура».
• Акт — для услуг, подтверждает их оказание.
• Счёт-фактура — документ по НДС (для плательщиков НДС), если не используется УПД.

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

Интеграция с 1С: проведение оплаты и сверка

Практически всё, о чём мы говорили — нумерация счетов, подтверждение оплат, кредитный лимит, закрывающие документы — надёжно работает только при интеграции сайта с 1С. Для B2B-магазина обмен с учётной системой не роскошь, а фундамент.

Что даёт обмен с 1С для оплаты по счёту

• Единая нумерация счетов. Счета нумеруются в 1С, без дублей и расхождений с бухгалтерией.
• Проведение оплаты. Поступление денег отражается в 1С и синхронно переводит заказ на сайте в «оплачен».
• Актуальные реквизиты и договоры. Контрагенты, договоры и условия работы ведутся в 1С и подтягиваются на сайт.
• Контроль лимита и дебиторки. Задолженность и лимит считаются в 1С, где есть полная картина отгрузок и оплат.
• Закрывающие документы. Накладные и УПД формируются в 1С и отдаются в личный кабинет.

Сверка оплат

Сверка — регулярное сопоставление того, что оплачено, с тем, что отгружено, по каждому контрагенту. Её итог — акт сверки взаиморасчётов, который формируют в 1С и согласуют с клиентом. Правильно настроенный обмен делает сверку почти беспроблемной: оплаты и отгрузки уже связаны с заказами, и расхождения видны сразу. Без интеграции сверка превращается в ручное сопоставление таблиц — долго и с ошибками.

Типичные причины, по которым оплата «не подтягивается» к заказу даже при обмене:

• Не совпал номер счёта в назначении платежа — плательщик указал не тот номер или оплатил без ссылки на счёт.
• Частичная оплата — пришла не вся сумма, и система не закрывает заказ полностью.
• Оплата на другой договор — деньги пришли, но привязались к иному договору контрагента.
• Сбой или задержка обмена — оплата проведена в 1С, но не доехала до сайта из-за ошибки обмена.

Все эти случаи решаемы, но требуют настроенных правил сопоставления и мониторинга обмена. Поэтому обмен с 1С проектируют вместе с оплатой, а не «прикручивают потом».

Безопасность и лимиты постоплаты

Оплата по счёту сама по себе безопаснее онлайн-эквайринга в части карточных данных (их просто нет), но у B2B-схемы свои риски — в основном финансовые и организационные.

• Лимит постоплаты — обязателен. Никогда не открывайте отсрочку без ограничения по сумме. Кредитный лимит на клиента — базовая защита оборотных средств.
• Проверка контрагента. Перед открытием отсрочки полезно проверить организацию (реквизиты, историю сделок). Автозаполнение по ИНН помогает, но решение об отсрочке — за ответственным менеджером.
• Блокировка при просрочке. Клиент с просроченной задолженностью не должен свободно оформлять новые заказы в постоплату — система блокирует или требует согласования.
• Права доступа к оплатам. Проводить оплату, менять лимиты и статусы должны только уполномоченные сотрудники — это защита от ошибок и злоупотреблений.
• Реквизиты — актуальные. Ваш расчётный счёт в счёте должен быть верным; смена реквизитов без обновления шаблона счёта ведёт к платежам «не туда».
• Логирование изменений. Кто и когда изменил статус оплаты или лимит — полезно фиксировать для разбора спорных ситуаций.

Общий принцип: постоплата — это доверие, подкреплённое лимитом и контролем. Технически несложно открыть отсрочку всем, но бизнес-риск при этом растёт. Правильная система делает злоупотребление трудным: лимит, блокировка просрочки и права доступа работают вместе.

Настройка оплаты по счёту: пошагово

Соберём практическую последовательность внедрения оплаты по счёту в 1С-Битрикс. Порядок может отличаться по проектам, но общая логика такая.

1. Настройте тип плательщика «Юрлицо». Убедитесь, что в магазине есть тип плательщика для организаций и он отделён от физлиц.
2. Задайте свойства заказа для юрлица. Наименование, ИНН, КПП, юр. адрес, контакты; обязательные пометьте обязательными, добавьте валидацию.
3. Включите платёжную систему «Счёт». Добавьте способ оплаты с обработчиком безналичной оплаты и привяжите его к типу «Юрлицо».
4. Настройте шаблон счёта. Впишите реквизиты продавца, логотип, разбивку НДС; сопоставьте поля плательщика со свойствами заказа.
5. Настройте выдачу PDF и отправку. Счёт на «Спасибо за заказ», в письме и в личном кабинете; проверьте кодировку и вёрстку.
6. Проверьте НДС. Убедитесь, что у товаров заданы верные ставки и итоги счёта считаются корректно.
7. Настройте обмен с 1С. Передача заказа, получение статуса оплаты и документов; сопоставление оплат с заказами.
8. Настройте статусы под B2B. «Выставлен счёт», «оплачен частично», «оплачен», «отгружен» — чтобы процесс читался в админке.
9. Добавьте постоплату для нужных клиентов. Признак доступности, срок отсрочки, кредитный лимит и блокировку при просрочке.
10. Настройте автозаполнение по ИНН (если нужно) — через справочник контрагентов или связку с 1С.
11. Прогоните сквозной сценарий. Оформите тестовый заказ юрлицом, получите счёт, проведите «оплату» в 1С, убедитесь, что статус встал.

Отдельно проговорите с бухгалтерией форму счёта, признаки НДС и нумерацию — это сэкономит переделки. И заложите время на обмен с 1С: именно он обычно занимает больше всего в проекте оплаты по счёту.

Частые ошибки

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

• Счёт без нужных реквизитов. Самая частая беда: в счёте нет ИНН, КПП или наименования плательщика. Причина — незаполненные или несопоставленные свойства заказа юрлица. Делайте ключевые поля обязательными и проверяйте маппинг в шаблоне счёта.
• Оплата не подтянулась к заказу. Деньги пришли, но заказ висит неоплаченным: не совпал номер счёта, частичная оплата, оплата на другой договор или сбой обмена. Настройте правила сопоставления и мониторинг обмена.
• Неверный НДС в счёте. Ставки у товаров заданы неправильно или не учтён режим «без НДС» — счёт уходит с ошибочной суммой налога. Согласуйте НДС с бухгалтером и проверьте на тестовом счёте.
• Расхождение нумерации счетов. Сайт и 1С нумеруют счета независимо — возникают дубли и путаница. Определите единый источник нумерации (обычно 1С).
• Постоплата всем без лимита. Отсрочку открыли по умолчанию — растёт неуправляемая дебиторка. Всегда ограничивайте лимитом и открывайте отсрочку осознанно.
• Счёт только в письме. Письмо ушло в спам — клиент без документа. Дублируйте счёт в личном кабинете и на странице заказа.
• Способ «счёт» показан физлицам. Розничный покупатель видит безналичный счёт и теряется. Привязывайте способ к типу «Юрлицо».
• Нет обмена с 1С. Всё держится на ручной сверке выписки — медленно и с ошибками при росте потока. Для заметного объёма счетов настраивайте обмен.
• «Битый» PDF. Счёт с кривой кодировкой или ломающейся вёрсткой при многих позициях. Проверяйте PDF на реальных больших заказах.
• Смешение счёта и закрывающих документов. Клиенту дают только счёт и не отдают накладную/УПД — у него не закрыт учёт. Показывайте оба типа документов.

Чек-лист запуска

Короткий список для сверки перед запуском оплаты по счёту в B2B-магазине:

1. Тип плательщика «Юрлицо» настроен, отделён от физлиц.
2. Свойства заказа юрлица заданы, ключевые обязательны, есть валидация ИНН/КПП.
3. Платёжная система «Счёт» включена и привязана к типу «Юрлицо».
4. Шаблон счёта с верными реквизитами продавца, НДС и разбивкой итогов.
5. PDF-счёт отдаётся на странице заказа, в письме и в личном кабинете; кодировка и вёрстка проверены.
6. НДС корректен: ставки товаров заданы, итоги считаются верно, учтён режим «без НДС».
7. Обмен с 1С настроен: заказ уходит, статус оплаты и документы приходят, оплаты сопоставляются.
8. Статусы под B2B настроены: выставлен счёт, оплачен частично, оплачен, отгружен.
9. Постоплата и отсрочка заданы для нужных клиентов с кредитным лимитом и блокировкой просрочки.
10. Автозаполнение по ИНН подключено (если требуется) и оставляет поля редактируемыми.
11. Закрывающие документы (накладная/УПД) доступны в личном кабинете после отгрузки.
12. Сквозной сценарий пройден: заказ → счёт → оплата в 1С → статус «оплачен» на сайте.

Вывод

Оплата по счёту — это не «ещё один способ оплаты», а полноценный B2B-процесс: юрлицо оформляет заказ, получает счёт с корректными реквизитами и НДС, оплачивает его безналично, а заказ переходит в «оплачен» по факту поступления денег из банка через 1С. Ключевые узлы — правильные свойства заказа для юрлица, аккуратный счёт (лучше с нумерацией в 1С), надёжное подтверждение оплаты через обмен и разумная политика постоплаты с кредитным лимитом.

Стройте оплату по счёту от учётной системы: 1С даёт нумерацию, проведение оплат, контроль дебиторки и закрывающие документы, а сайт показывает счёт и статусы покупателю в личном кабинете. Тогда менеджеры перестают вручную собирать счета и гадать, кто оплатил, а клиенты получают прозрачную и привычную для B2B оплату. Другие сценарии оплаты и доставки — от онлайн-эквайринга до отгрузки — мы разбираем в рубрике «Оплата и доставка».