Автоматизация сверки Booking и банка для PT на Бали

Автоматизация сверки бронирований и банковских счетов для PT на Бали нужна не из-за любви к таблицам. Она нужна, когда основной счёт Permata за июнь 2026 показывает ноль входящих, а выплаты Booking и Airbnb могли пройти через Danamon, счёт управляющей или старый маршрут площадки. В такой ситуации один красивый банковский экспорт легко превращает налоговую отчётность в документ с неверной картиной.

1 июля 2026 у Юрия Солара была именно такая сцена: нужно было проверить PT SOLAR PROPERTY BALI перед месячной налоговой подачей. Первый банк выглядел спокойно. Основной корпоративный счёт Permata за июнь 2026 дал ноль входящих операций. Но старые выгрузки Booking и Airbnb показывали другое: юрлицо PT SOLAR PROPERTY BALI, маршруты на счета с масками *1023 и *3484, gross за январь-июнь 429 млн IDR, а затем отдельный хвост Booking за сентябрь-февраль на 707 млн IDR. Нулевой отчёт по первому впечатлению был бы не аккуратностью, а ошибкой.

Почему главный счёт PT не равен всей выручке

У владельца PT на Бали часто есть удобная иллюзия: если основной корпоративный счёт пустой, значит за период нечего показывать. Банк выглядит официально, выписка скачана из кабинета, название компании совпадает. Проблема в том, что OTA-площадки, управляющая компания и платёжные шлюзы редко живут внутри такой аккуратной схемы. Booking мог платить на один счёт в 2025 году, Airbnb мог отправлять выплаты другим маршрутом, управляющая могла принимать часть денег на свой счёт и потом проводить расчёт с владельцем.

В кейсе PT SOLAR PROPERTY BALI первым источником была Permata. Июнь 2026: входящих ноль, исходящий перевод есть. Если смотреть только на этот фрагмент, картина простая: компания за месяц ничего не получила. Но этот вывод отвечал на узкий вопрос: были ли входящие на конкретном счёте Permata. Он не отвечал на вопрос, была ли выручка у компании.

Разница между этими двумя вопросами стоит отдельного процесса. Банк отвечает за банковские строки. OTA отвечает за бронирования и выплаты. Coretax принимает отчётность по компании. Между ними нет встроенного честного переводчика, который сам скажет: «ты смотришь не туда». Значит, переводчик нужен в операционной системе бизнеса.

Для PT на Бали это особенно заметно, потому что деньги от гостей часто двигаются по цепочке. Гость платит Booking или Airbnb. Площадка удерживает комиссии и отправляет выплату по реквизитам, которые были внесены в кабинете в конкретный период. Управляющая компания может получить часть оплат напрямую. Старый счёт мог остаться в профиле площадки дольше, чем в управленческих заметках владельца. Через год владелец открывает свежую выписку, видит ноль и делает быстрый вывод. Машина сверки нужна как раз против этого быстрого вывода.

Как Booking и Airbnb ломают ручную картину месяца

Booking и Airbnb не обязаны подстраиваться под внутреннюю бухгалтерскую карту владельца PT. У них есть свои кабинеты, payout-циклы, статусы бронирований, удержания, отмены, корректировки и банковские реквизиты. Внутри бизнеса может быть привычка считать Permata главным счётом, но площадка могла продолжать платить на Danamon, потому что этот счёт стоял в payout-настройках с 2025 года.

В разборе за 1 июля 2026 всплыл именно такой конфликт. В выгрузках площадок были указаны PT SOLAR PROPERTY BALI и банковские маски *1023 и *3484. Gross за январь-июнь был 429 млн IDR. Это не доказывало сразу, что вся сумма легла на конкретный банковский счёт в нужном месяце, но разрушало главный тезис «выручки нет». Если OTA показывает выплаты на компанию, следующий шаг не спорить с банковской выпиской Permata, а строить маршрут денег.

Ручной просмотр здесь быстро начинает врать. Человек берёт 20 строк, запоминает 3 суммы, прыгает между PDF, CSV и кабинетом Booking, теряет один перенос периода, устает и выбирает понятный вывод. Автоматизация должна забрать не решение, а механическую часть: вытащить номера броней, даты, суммы, валюту, банк, маску счёта, источник, статус выплаты и собрать кандидатов на совпадение.

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

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

Сверка по номерам броней как нормальный ключ

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

В кейсе PT SOLAR PROPERTY BALI эта логика нашла Danamon. Счёт был в старых заметках помечен как «не используется, исключить». Это удобная управленческая пометка, но она не является банковским фактом. Система пошла не от заметки, а от данных Booking: период сентябрь 2025 - февраль 2026, выплаты по броням, суммы и банк. После матчинга выяснилось, что через Danamon прошло 707 млн IDR Booking-выручки. 13 из 14 платежей сошлись до рупии.

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

Практически такой матчинг можно построить в обычной таблице, Python-скрипте или внутреннем агенте. Входные таблицы: выгрузка Booking, выгрузка Airbnb, выписка Permata, выписка Danamon, отчёт управляющей. Каждая строка получает нормализованные поля: дата операции, месяц отчёта, источник, номер брони, сумма gross, сумма net, валюта, банк, счёт, контрагент, уверенность совпадения и ссылка на исходный файл.

Дальше система делает несколько проходов. Первый проход ищет точное совпадение суммы и номера брони. Второй ищет совпадение суммы в окне нескольких дней, потому что дата payout и дата банковского поступления могут отличаться. Третий ищет пачки, где одна банковская строка закрывает несколько бронирований. Четвёртый оставляет ручной список: всё, что не сошлось, уходит человеку с исходниками, а не прячется в итоговой сумме.

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

Что проверять в Coretax до отправки

Coretax в этой истории не был отдельной магической правдой. Его нужно было проверить как кабинет статусов и обязательств. В сессии 1 июля 2026 были просмотрены очереди Not Submitted, Submitted, Rejected, Waiting и Canceled. Annual CIT за 2023, 2024 и 2025 годы был в статусе submitted. Monthly 2026 не был закрыт подачами. Профиль обязательств PKP/PPN не был подтверждён как отдельный факт.

Это важно, потому что банковская сверка отвечает за деньги, а Coretax отвечает за статус отчётности. Ошибка может быть в любом слое. Можно правильно найти 707 млн IDR в Danamon и всё равно подать не тот период. Можно увидеть пустую очередь Not Submitted и пропустить, что нужный тип обязательства неактивен или настроен иначе. Можно принять annual CIT за месячную подачу. Поэтому автоматизация должна собирать не одну итоговую цифру, а пакет доказательств для конкретной кнопки.

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

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

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

Чек-лист владельца PT перед месячной подачей

Первый пункт: собрать все банковские счета PT, а не только тот, который считается основным. В список попадают Permata, Danamon и любые старые счета, которые когда-то были в payout-настройках Booking, Airbnb, Stripe, PayPal, Wise или местного шлюза. Старый статус «не используется» не удаляет счёт из проверки, пока нет свежего подтверждения из кабинетов площадок и банков.

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

Третий пункт: выгрузить Booking и Airbnb за период с детализацией по бронированиям. Нужны не только итоговые суммы. Нужны номера броней, даты проживания, даты payout, суммы, комиссии, валюта, статус отмены, получатель и банковская маска. Без этих полей невозможно объяснить, почему банковская строка включена в отчёт.

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

Пятый пункт: завести месячный архив доказательств. В архиве лежат исходные PDF/CSV, итоговая таблица, скрины кабинетов, статусы Coretax и короткий файл с решениями. Название папки лучше делать скучным: `2026-06-pt-spb-tax-pack`. Через год скучные имена выигрывают у творческих названий, потому что их можно найти.

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

Почему последняя кнопка остаётся за человеком

В операционной автоматизации есть соблазн довести всё до полной автономности. Банк скачан, Booking распарсен, Airbnb сопоставлен, Coretax открыт, черновик готов. Значит, можно нажимать отправку автоматически. Для налоговой отчётности это плохой дизайн. Не потому что машина слабая, а потому что ответственность живёт не в скрипте.

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

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

Правильная машина в этом сценарии похожа на штабного офицера, а не на пилота без тормозов. Она приносит папку: вот Permata, вот Danamon, вот Booking, вот Airbnb, вот 13 совпадений из 14, вот одно исключение, вот статусы Coretax, вот черновик. Последняя строка в папке: «подтвердить отправку». Владелец не тратит день на прыжки между кабинетами, но и не прячется за кнопку.

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

Как собрать такую сверку без героизма

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

Следующий слой - нормализация. Банки называют поля по-разному, Booking и Airbnb выгружают разные CSV, управляющая может прислать Excel с собственными колонками. Внутренний формат должен быть единым: `source`, `period`, `booking_id`, `bank_account`, `amount`, `currency`, `date`, `counterparty`, `match_status`, `evidence_link`. После этого уже можно делать правила матчинга, отчёты и черновики.

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

Четвёртый слой - месячный ритуал. Например: 1 числа скачать банки, 2 числа забрать OTA, 3 числа получить отчёт управляющей, 4 числа закрыть расхождения, 5 числа подготовить черновик Coretax, 6 числа подтвердить отправку. Даты могут быть другими, но порядок должен повторяться. Автоматизация любит повторяемость. Налоговая тоже любит документы, которые можно восстановить.

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

Что забрать в свою систему

Из этой истории не нужно забирать виллы, Бали или конкретный банк. Забрать нужно принцип: отчётность строится не по самому удобному источнику, а по полному маршруту денег. Если бизнес принимает деньги через 3 канала, налоговый черновик должен видеть 3 канала. Если старый счёт мог остаться в payout-настройках, он остаётся в проверке. Если управляющая принимает часть платежей, её отчёт становится источником, а не приложением к разговору.

Минимальный артефакт для владельца PT - таблица источников и таблица матчей. В первой строками идут банки, OTA, управляющая и Coretax. Во второй каждая выплата получает связь с бронированием, банком и периодом. Дальше можно наращивать автоматизацию: парсер CSV, загрузчик PDF, сверку сумм, генератор архива, подготовку черновика. Но начинать стоит не с интерфейса, а с полного списка мест, где могли оказаться деньги.

У меня это всё крутится 24/7 в более широком контуре: агенты читают источники, сверяют факты, собирают артефакты и останавливаются там, где нужен человек. Полный набор таких схем, AGENTS.md, промптов, чек-листов и рабочих шаблонов я складываю в клуб «Solar — внутрянка», от 2 500 ₽/мес. Бери и адаптируй: https://4bos.ru/inside/

Дополнительный разбор смежной архитектуры можно посмотреть в статье про AI-readiness сайта и машинно читаемые контуры. Там тот же принцип, только для публичных страниц: если систему должен читать не только человек, данные нужно раскладывать так, чтобы машина не додумывала за владельца. В налоговой сверке логика такая же. Машина получает факты, человек принимает решение, а между ними лежит архив, который можно поднять без археологии по чатам.

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

Для малого бизнеса это и есть нормальная автоматизация: не огромная ERP, а связка простых источников, которая каждый месяц задаёт одни и те же вопросы. Где деньги? На каком счёте? К какой брони относятся? Кто подтвердил исключение? Что ушло в Coretax? Ответы скучные, зато именно скука защищает отчётность от красивых, быстрых и неверных выводов.

Solar OS.