Скидка гостю, удержание ресторану: как проверить расчёты доставки до закрытия месяца

Скидка гостю, удержание ресторану: как проверить расчёты доставки до закрытия месяца

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

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

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

Из чего складывается сумма выплаты

Владелец часто сравнивает две цифры: сумму заказов в кабинете площадки и платёж в банковской выписке. Такой подход полезен как первичная проверка, но для полноценной сверки слишком груб. Между продажей и выплатой может находиться несколько разных по смыслу операций. Одни уменьшают сумму, которую ресторан получит по конкретному заказу; другие относятся к другой дате или к отдельному договорному периоду; третьи вообще не являются расходом ресторана.

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

Четыре суммы, которые нельзя смешивать

Для каждого заказа полезно различать как минимум четыре величины:

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

К ним добавляется пятая цифра — учётная сумма продажи, которая определяется правилами учёта и первичными документами, а не размером банковского перевода. Она может отличаться от чистого поступления, потому что комиссия и другие удержания обычно требуют отдельного отражения. Конкретный порядок зависит от договорной модели и применимых правил учёта; его следует согласовать с бухгалтером, а не выводить только из интерфейса площадки.

Например, заказ до скидки стоит 2 000 рублей. Гость получил скидку 300 рублей, из которых 200 финансирует платформа и 100 — ресторан. Если расчётная база комиссии — стоимость блюд до скидки, комиссия 25% составит 500 рублей. Если база — цена после скидки, это будет 425 рублей. В обоих случаях гость заплатил 1 700 рублей, но сумма, которую должны распределить между рестораном и платформой, зависит от договора. Поэтому нельзя автоматически считать, что площадка обязана перечислить ресторану 1 700 рублей за вычетом комиссии: часть скидки может быть возмещена платформой, а комиссия может рассчитываться по иной базе.

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

Какие удержания встречаются в расчётах

Набор строк зависит от договора и модели работы, но обычно проверяют следующие позиции:

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

Наличие строки ещё не доказывает, что она рассчитана верно. Проверьте её основание, период, ставку и объект, к которому она относится. Например, строка «продвижение» может быть начислена не на отдельный заказ, а за кампанию целиком. В таком случае попытка найти её в разбивке одного заказа даст ложное впечатление, что удержание лишнее. И наоборот, общая строка в недельном отчёте может скрывать двойное списание за одну услугу.

Удобно разделить все строки на четыре класса:

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

Скидка: кто её оплатил и на какой базе рассчитали комиссию

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

Для каждой кампании зафиксируйте до её запуска:

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

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

В каждой строке заказа должны быть видны по меньшей мере три элемента скидки: сумма выгоды гостя, часть за счёт ресторана и часть за счёт площадки. Если последняя не начисляется одновременно с продажей, добавьте поле «компенсация ожидается» и затем отслеживайте дату её появления. Так проще заметить не только неправильный расчёт, но и пропущенное возмещение.

Не стоит считать скидку площадки гарантированным доходом ресторана до проверки договора и документации. В интерфейсе она может называться компенсацией, бонусом или промоподдержкой, но экономический смысл и порядок оформления нужно подтвердить по условиям сотрудничества. Если терминология в отчёте не совпадает с договором, запросите официальное разъяснение и приложите его к регламенту сверки.

Комиссия: ставка без базы ничего не говорит

В договоре можно увидеть процент комиссии, но для контроля важна формула целиком. Нужно понять, от какой стоимости берётся процент: от цены до скидки, от цены после скидки, от суммы оплаченных гостем блюд, от суммы заказа с доставкой или от иной базы. Уточните также, включены ли в базу упаковка, модификаторы, сервисные сборы и компенсация скидки.

Если ставка меняется в зависимости от категории заказа, объёма, способа доставки, региона или условий акции, одного процента в справочнике недостаточно. Ставку надо сопоставлять с параметрами конкретной операции. У разных точек сети могут быть разные приложения к договору; даже в одной точке условия могли обновиться в середине периода.

Проверяйте следующие детали:

• ставка указана в процентах или как фиксированная сумма;
• начисляется ли процент на заказ целиком или на отдельные составляющие;
• применяется ли минимум комиссии;
• как округляется результат — по каждой позиции или по заказу;
• как обрабатываются частичные возвраты;
• меняется ли база, если гость использовал баллы или сертификат;
• начисляется ли комиссия на доплату после оформления заказа;
• взимается ли отдельная плата за платёж, доставку или продвижение;
• не включён ли один и тот же расход одновременно в процент и отдельное удержание.

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

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

Платёж гостя и выплата ресторану могут относиться к разным датам

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

Для каждой операции полезно хранить несколько временных отметок:

• дата и время создания заказа;
• дата и время принятия кухней или подтверждения;
• дата выполнения или доставки;
• дата оплаты гостем;
• дата возврата, отмены или корректировки;
• дата включения в расчётный реестр площадки;
• дата фактической выплаты;
• дата зачисления по банковской выписке.

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

Если площадка перечисляет деньги пакетами, одна выплата может включать заказы за несколько дней, а один день продаж может попасть в несколько выплат из-за возвратов и корректировок. Не распределяйте пакетную выплату пропорционально обороту без подтверждения реестром: такой способ маскирует конкретные ошибки. Сначала найдите состав платежа, затем сверяйте составляющие.

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

Как построить сверку по заказам и выплатам

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

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

Три уровня контроля: заказ, расчётный реестр, банк

Сверку удобно вести в три прохода.

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

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

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

Эти три уровня отвечают на разные вопросы. Совпадение заказов не гарантирует правильной комиссии; корректная комиссия не гарантирует, что сумма попала в банковский перевод; совпадение перевода с реестром не доказывает, что в реестре учтены все заказы. Поэтому фиксируйте результат каждого уровня отдельно.

Начать можно с небольшой таблицы, где одна строка соответствует одной операции или заказу. Минимальный набор полей:

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

Сопоставление идентификаторов и устранение дублей

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

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

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

Отдельно ловите дубли. Это могут быть:

• повторно загруженная строка из-за повторной выгрузки файла;
• заказ, который отображается в отчёте и как продажа, и как отдельная корректировка;
• несколько платежей по одному заказу после частичного возврата;
• повторный заказ с новым номером после технического сбоя;
• один и тот же реестр, загруженный дважды.

Для защиты от повторной загрузки используйте составной ключ, например идентификатор площадки плюс тип операции и номер документа. Не удаляйте дубликаты автоматически только по одинаковым сумме и дате: легитимные операции могут совпадать. Сначала пометьте подозрительные строки и сохраните исходный файл.

Установите контроль полноты периода: число заказов по дням и точкам, число заказов, попавших в расчёт, число отмен, число выплат. Если в один день данные внезапно сократились вдвое, это может быть не падение продаж, а сбой выгрузки. Сравнивайте не только суммы, но и количество уникальных идентификаторов.

Формула ожидаемой суммы и порядок расчёта

Для внутреннего контроля можно задать упрощённую формулу, а затем расширить её в соответствии с договором. Например:

Ожидаемая сумма расчёта = сумма, относящаяся к ресторану по заказу + подтверждённые компенсации − скидка за счёт ресторана − комиссия − иные удержания ± корректировки.

Эта запись намеренно не определяет универсально, от какой суммы считать комиссию и кому принадлежит доставка. Эти параметры надо подставить из договора. Формула служит схемой: каждый элемент должен иметь собственное значение, источник данных и объяснимое правило.

Пусть блюдо и дополнения стоят 1 800 рублей, упаковка — 50 рублей, доставка оплачивается отдельно гостем и не относится к расчёту ресторана. Скидка для гостя — 250 рублей: 150 рублей финансирует ресторан и 100 рублей компенсирует площадка. По договору комиссия 22% начисляется на стоимость блюд после скидки ресторана, но до компенсации площадки; упаковка в базу не входит. Тогда сначала нужно определить договорную базу, затем рассчитать комиссию, после чего добавить или учесть компенсацию и удержать долю ресторана. Не следует просто умножать на 22% сумму, которую гость заплатил в приложении: она включает параметры, которые могут не входить в базу.

При фактической сверке лучше повторять порядок площадки, а не только итоговую арифметику. Если результат отличается, поэлементно проверяйте:

1. Верно ли прочитана исходная стоимость заказа и состав позиций?
2. Совпадает ли применённая скидка с условиями акции?
3. Правильно ли разделены доли ресторана и площадки?
4. Та ли ставка комиссии применена к этой точке и дате?
5. Совпадает ли расчётная база с договором?
6. Правильно ли учтены доставка, упаковка и дополнительные услуги?
7. Есть ли возврат, претензия, отмена или корректировка?
8. Не попала ли операция в другой реестр или период?
9. Совпадает ли округление с методикой площадки?
10. Перечислена ли сумма полностью и на правильный банковский счёт?

Эта последовательность уменьшает риск бессмысленной переписки, когда ресторан сообщает площадке только итоговую разницу, а не конкретный заказ и спорную формулу.

Для сети полезно закрепить версии тарифов и условий. Каждая ставка должна иметь период действия, канал, регион и точку, к которым она относится. Если тариф изменился в середине месяца, разделите расчёт на интервалы. Не применяйте текущую ставку задним числом к заказам прошлых дней, пока не подтверждено, что изменение действительно распространяется на них.

Автоматизация: что передать системе, а что оставить на проверку

Автоматизация полезна, когда объём строк уже не позволяет контролировать каждую операцию вручную. Но система не исправит неверно выбранную базу комиссии и не угадает, кто финансирует акцию. До настройки алгоритма ресторан должен описать правила расчёта человеческим языком и проверить их на нескольких реальных заказах.

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

Рутинные и однозначные проверки можно автоматизировать:

• отсутствие заказа в одной из систем;
• повтор одного и того же идентификатора;
• комиссия выше установленной ставки;
• скидка не соответствует подключённой кампании;
• отрицательная сумма без связанного возврата;
• сумма реестра не совпадает с выплатой;
• нераспределённый банковский перевод;
• превышение допустимого срока ожидания компенсации.

А вот спорные случаи лучше направлять на ручную проверку: частичная отмена, конфликт статусов, изменённые условия промо, корректировка после претензии, разная трактовка округления и неочевидные взаимозачёты. Автоматически закрытый случай без объяснения может быть опаснее, чем незакрытый: он создаёт видимость порядка, хотя сумма остаётся неверной.

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

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

Как разбирать расхождение, а не просто фиксировать его

Когда обнаружена разница, сначала установите её тип. Практически удобно использовать следующие категории:

• временная — операция ещё не вошла в выплату или относится к другому периоду;
• объяснимая договором — сумма удержана верно, но не была учтена во внутреннем прогнозе;
• ошибка данных — заказ потерян, задвоен, неверно отнесён к точке или каналу;
• ошибка расчёта — неправильная ставка, база, скидка или округление;
• спорная корректировка — возврат, претензия или удержание без достаточного основания;
• банковская — отличие связано с маршрутом платежа, реквизитами, датой или комиссией банка;
• невыясненная — данных пока недостаточно, требуется запрос.

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

Перед обращением к площадке соберите пакет доказательств:

1. номер заказа и реестра;
2. дату, точку, канал и статус;
3. сумму до скидки и сумму, уплаченную гостем;
4. разбивку скидки по источнику финансирования;
5. применённую ставку и вашу формулу расчёта;
6. фактическое удержание и ожидаемую сумму;
7. ссылку на условие договора или кампании;
8. банковский платёж, если спор связан с перечислением;
9. краткое описание требуемого исправления.

Сообщение «за месяц недоплатили 30 тысяч» сложно проверить, особенно если в нём соединены десятки разных причин. Начинайте с перечня конкретных операций и суммы по каждой. Если расхождения однотипные, приложите несколько примеров и отдельно обозначьте предполагаемое влияние на весь период. Сохраняйте ответ и номер обращения рядом с расчётной строкой.

Не меняйте исходные данные задним числом после ответа площадки. Если была корректировка, храните первоначальную запись, поправку, дату и причину изменения. Так можно увидеть, какая сумма была заявлена изначально и как вопрос закрыли. Это особенно важно при смене сотрудников и при подготовке подтверждений для финансовой службы.

Регламент до закрытия месяца: частота, роли и профилактика

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

Частота контроля зависит от масштаба. Небольшой ресторан может проверять заказы и выплаты несколько раз в неделю, а крупная сеть — ежедневно автоматически с ручным разбором исключений. Важен не календарный ритуал, а возможность найти причину, пока доступна информация, и успеть задать вопрос в срок, установленный договором или правилами взаимодействия.

Ежедневный контроль: поймать сбой, пока он свежий

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

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

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

Следите за показателями по каналам и точкам отдельно. Если у ресторана несколько площадок, общая сумма может выглядеть нормальной: переплата по одному каналу компенсирует недоплату по другому. Аналогично сводный отчёт по сети может скрыть неверное применение тарифа в одном регионе. Сверяйте сначала на уровне точки и канала, затем агрегируйте.

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

Еженедельная сверка: заказы, промо и ожидаемые компенсации

Раз в неделю полезно проверять не только уже выплаченные суммы, но и незавершённые цепочки. Например, заказ прошёл корректно, но обещанная компенсация за скидку ещё не появилась. Если ждать конца месяца, будет сложнее установить, в каком именно реестре она должна была появиться.

На недельной сверке ответьте на вопросы:

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

Недельный срез помогает заметить системную проблему. Если три дня подряд комиссия рассчитывается по повышенной ставке, ошибка может быть связана с изменённым тарифом или настройкой точки. Если задерживается только компенсация конкретной акции, возможно, она начисляется отдельным документом в конце кампании. Обе ситуации требуют действий, но разного типа.

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

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

Закрытие месяца: порядок действий и контрольная точка

За несколько рабочих дней до закрытия соберите все доступные отчёты, не дожидаясь последнего дня. Уточните, какие выплаты относятся к периоду, но будут фактически перечислены позднее. Зафиксируйте последний доступный реестр и список заказов, по которым расчёт ещё не завершён. Это не значит, что их нужно искусственно включать или исключать: период отражается по правилам учёта, согласованным с бухгалтером, а управленческий контроль показывает незавершённые суммы отдельно.

Практический порядок закрытия:

1. Зафиксировать исходные данные. Сохранить выгрузки заказов, реестров, корректировок, промо и банковских поступлений за период. Записать дату выгрузки и версию отчёта.
2. Проверить полноту. Сопоставить число уникальных заказов и общие суммы по дням, точкам и каналам. Отдельно проверить смену месяца и часовой пояс.
3. Сверить заказную детализацию. Найти заказы без расчётной строки, строки без заказа, повторы, отмены без обратной операции и частичные возвраты.
4. Пересчитать переменные удержания. Проверить ставки, базы, доли скидок, комиссии и правила округления на выборке и на всех выявленных исключениях.
5. Сопоставить периодические услуги. Проверить рекламные и иные начисления с договором, заказом услуги и документами за соответствующий период.
6. Свести реестры и банк. Убедиться, что выплаты зачислены, либо указать, какие суммы ожидаются и почему.
7. Разобрать существенные отклонения. Направить запросы до крайнего срока, установленного условиями сотрудничества, и приложить расчёт.
8. Сформировать список незакрытых позиций. Указать сумму, владельца вопроса, ожидаемый срок и влияние на отчётность.
9. Подписать результат сверки внутри компании. Ответственный подтверждает, что данные собраны, а руководитель видит существенные риски и нерешённые суммы.
10. Архивировать подтверждения. Сохранить договорные версии, условия акций, реестры, выписки, переписку и результаты расчёта в одной структуре.

Не используйте нулевое расхождение как единственный критерий закрытия. В реальном процессе могут оставаться суммы, которые будут выплачены позднее или оспариваются. Важно, чтобы они были объяснены, оценены, назначены ответственному и не исчезли в следующем периоде без следа.

Пример контрольного итога может выглядеть так: «Выполнено 4 820 заказов; 4 760 вошли в закрытые расчёты; 35 ожидают выплаты по графику; 12 связаны с открытыми возвратами; 8 имеют спор по комиссии; 5 не сопоставлены». Для каждой группы указывается сумма и следующий шаг. Такой отчёт информативнее общей строки «площадка должна 17 400 рублей», потому что показывает природу остатка.

Роли и ответственность: кто должен видеть какую часть

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

Обычно в процессе участвуют:

• управляющий или руководитель точки — подтверждает операционные статусы, причины отмен, фактические условия работы;
• ответственный за канал доставки — контролирует настройки, промо и доступность выгрузок;
• финансовый специалист или бухгалтер — определяет правила отражения операций, проверяет первичные документы и банковские поступления;
• центральный офис — сравнивает точки, следит за едиными условиями и эскалирует системные расхождения;
• ИТ-специалист или интегратор — отвечает за передачу данных и стабильность обмена, но не подменяет финансовую проверку.

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

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

Метрики, которые помогают увидеть проблему раньше

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

• доля заказов, автоматически сопоставленных без ручной проверки;
• доля заказов без расчётной строки;
• сумма и количество открытых расхождений по возрасту;
• средний срок между выполнением заказа и выплатой;
• доля скидок, по которым подтверждена компенсация;
• фактическая комиссия как процент от согласованной базы;
• среднее удержание на заказ по каналу и точке;
• частота отмен, возвратов и претензий;
• число повторных ошибок по одному правилу;
• доля выплат, для которых найдена полная расшифровка.

Сравнивайте метрики по сопоставимым периодам и условиям. Рост удержаний может быть вызван изменением состава заказов, запуском кампании или сезонным сдвигом, а не ошибкой. Поэтому полезно показывать и абсолютную сумму, и процент, и количество заказов. Если поменялась ставка, отметьте дату и не сравнивайте два периода без поправки на условия.

Не превращайте метрики в рейтинг сотрудников без контекста. Высокая доля возвратов может объясняться сложной логистикой или проблемой меню, а не работой одного человека. Цель показателей — обнаружить причину и скорректировать процесс, а не найти виноватого по одному графику.

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

Типичные ошибки и способы их предотвратить

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

Считать любую скидку расходом ресторана. В акции могут участвовать несколько сторон. Разбивайте скидку на доли и подтверждайте начисление части площадки.

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

Применять одну ставку ко всем заказам. Условия могут зависеть от точки, канала, даты и типа заказа. Храните версии тарифов с периодом действия.

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

Игнорировать мелкие повторяющиеся отклонения. Копейки или несколько рублей на заказ превращаются в заметную сумму при большом потоке. Проверяйте системность и округление.

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

Сверять данные только вручную в кабинете. Экран может показывать текущую версию без полной истории. Сохраняйте детальные выгрузки и фиксируйте момент получения.

Не учитывать доступы и изменения. Если никто не знает, кто включил кампанию и какую долю финансирования выбрал, спор затянется. Утвердите роли, журнал изменений и порядок согласования.

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

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

Короткий чек-лист перед подтверждением расчёта

Перед тем как считать период проверенным, ответьте «да» на вопросы:

• Есть ли выгрузка всех заказов и всех расчётных операций за нужный период?
• Совпадают ли идентификаторы или существует таблица их соответствия?
• Проверены ли границы периода, даты выполнения и даты выплаты?
• Разделена ли скидка на выгоду гостя, долю ресторана и долю площадки?
• Для каждой ставки известны база и срок её действия?
• Отдельно ли учтены комиссия, доставка, продвижение, возвраты и иные услуги?
• Все ли отмены и возвраты связаны с исходными заказами?
• Нет ли необъяснённых дублей, потерянных заказов и нераспределённых выплат?
• Сходятся ли суммы реестров с банковскими поступлениями или отмечены как ожидаемые?
• Есть ли список открытых вопросов с ответственными и сроками?
• Сохранены ли условия кампаний, версии договоров и исходные отчёты?
• Уточнены ли с бухгалтером правила отражения валовых продаж, удержаний и корректировок?

Если хотя бы на один ключевой вопрос ответ отрицательный, обозначьте конкретный пробел и назначьте действие. Не обязательно задерживать всю внутреннюю отчётность из-за одной ожидаемой выплаты, но нельзя и маскировать её под подтверждённую сумму. Разделение закрытых, ожидаемых и спорных операций делает картину честнее и облегчает дальнейшее закрытие.

Что сделать в ближайшие две недели

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

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

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

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

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