Мультиаккаунтинг для бухгалтеров и юристов: кабинеты клиентов

Редакция GetAntik · 4 октября 2026 г. · 9 минут чтения

Как бухгалтерские и юридические фирмы ведут десятки клиентских кабинетов в банках, налоговых и госпорталах без потери доступов и путаницы.

Почему это вообще проблема

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

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

Проблема в том, что так устроено не везде. Часть банков не даёт одному логину одновременно работать с кабинетами десяти разных юрлиц — система заточена под один браузер на одного пользователя и постоянно переключает контекст, путая cookies и сессии. Часть сервисов вообще не имеет ролевой модели «бухгалтер + клиент», только логин-пароль самого клиента, который он передал сотруднику фирмы напрямую. А ещё есть ситуации, когда у клиента нет цифровой подписи или возможности зайти самому и выдать делегирование — проще зайти под его данными напрямую, с его согласия.

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

Что идёт не так при ручной организации

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

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

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

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

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

Подход через изолированные профили

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

Практическая схема выглядит так:

1. Один профиль — один клиент. Банк, налоговая, ЭДО этого клиента открываются в его профиле. Сессии не пересекаются с другими клиентами, даже если открыто двадцать профилей одновременно.
2. Прокси под геолокацию клиента. Если у клиента юрлицо зарегистрировано в определённом регионе, профилю назначается прокси с подходящим выходным IP — часовой пояс и язык интерфейса подтягиваются автоматически от прокси, а не выдают, что вход идёт из другого города. Это снижает число ложных срабатываний антифрода банка, которые реагируют на нетипичную геолокацию входа.
3. Хранилище 2FA в самом профиле. Если клиент передал фирме секретный ключ для одноразовых кодов (а не просто пароль), ключ хранится в привязке к профилю, а не в телефоне конкретного сотрудника — код генерируется там же, где открыт кабинет.

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

О том, как вообще устроены закладки, прогрев cookies и шаблоны профилей на старте работы с новым аккаунтом, подробнее написано в материале про прогрев аккаунтов и подготовку профилей — логика переносится и сюда, просто вместо рекламного кабинета это кабинет клиента.

Командная работа и передача клиентов

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

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

• Владелец видит весь пул клиентских профилей фирмы и может переназначить любой из них.
• Администратор (например, старший бухгалтер) управляет своей командой и лимитами профилей на человека.
• Рядовой сотрудник видит только те профили клиентов, которые ему назначены, и не может экспортировать из них пароли или ключи 2FA на сторону.

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

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

Безопасность и ответственность за чужие данные

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

Практический минимум для такой схемы:

• Шифрование данных профиля на устройстве, а не только на сервере. Если данные профиля зашифрованы паролем аккаунта на самом устройстве, а сервер хранит только зашифрованную копию, взлом или утечка на стороне сервера не дают доступа к паролям клиентов в читаемом виде.
• Журнал активности — кто, когда и в каком профиле работал. Это не только про контроль сотрудников, но и про возможность быстро ответить клиенту на вопрос «кто заходил в мой кабинет в четверг в 15:00».
• Отдельный пароль на профиль для особо чувствительных кабинетов — например, доступ к банк-клиенту с правом подписи платежей стоит закрывать дополнительным паролем даже внутри своей команды, чтобы случайный клик не привёл к отправке платёжки не тем сотрудником.

Подробный разбор шифрования, хранилища 2FA и восстановления доступа при потере устройства — в статье про безопасность профилей и шифрование данных. Общее описание механизма можно посмотреть на странице безопасности GetAntik.

Частые ошибки фирм, которые только выстраивают процесс

Хранить пароли клиентов в общей таблице Excel на диске. Это работает, пока в фирме три человека и десять клиентов. На пятидесяти клиентах таблица превращается в риск: она расшаривается шире, чем нужно, версии расходятся, никто не помнит, какая правильная.

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

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

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

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

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

Сравнение подходов

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

Как посчитать, сколько профилей нужно

Для небольшой бухгалтерской фирмы расчёт простой: один профиль на юрлицо клиента плюс пара служебных профилей на внутренние сервисы самой фирмы (бухгалтерская программа, внутренний портал). Фирма на 25 клиентов укладывается в план на 100 профилей с запасом на новых клиентов и тестовые окружения; фирма на 150–200 клиентов обычно переходит на план побольше. Актуальные лимиты и цены — на странице тарифов, начать можно с бесплатного плана на 3 профиля, чтобы опробовать схему на нескольких клиентах перед полным переходом.

FAQ

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

Банк может заблокировать кабинет клиента, если видит вход с IP бухгалтерской фирмы, а не из региона клиента? Такое бывает, особенно у банков с жёстким антифродом. Решение — использовать прокси с выходом в регионе клиента для его профиля, чтобы часовой пояс, язык и геолокация в браузере соответствовали ожиданиям банка. Подробнее о выборе типа прокси под задачу — в статье про прокси для мультиаккаунтинга.

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

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

бухгалтерияюридические услугимультиаккаунтингантидетект-браузерклиентские кабинеты