EWA для кадровых агентств и компаний по предоставлению заёмного труда: как учитывать отработанное время у нескольких клиентов?

Чтобы внедрить EWA в кадровом агентстве или компании по предоставлению заёмного труда, каждый работник должен быть точно связан с юридическим лицом-работодателем, клиентом, площадкой, договором/заданием, зарплатным периодом и данными об утверждённом времени. Компании нужно чётко определить, у какого клиента учитывается время, кто вправе его утверждать, когда время становится основанием для лимита и какая сторона отвечает за выплату, payroll и сверку. Когда работника переводят или его задание завершается, права на EWA должны меняться по дате вступления в силу, а не дожидаться конца месяца.

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

> Глоссарий: EWA (получение зарплаты за уже отработанные дни) · payroll (расчёт зарплаты) · assignment (задание/назначение у клиента) · SLA (соглашение об уровне сервиса) · HRIS (информационная система по персоналу) · ERP (планирование ресурсов предприятия) · cutoff (контрольная точка закрытия периода) · pilot (пилотное внедрение) · UAT (приёмочное тестирование) · KPI (ключевой показатель эффективности).

Почему модель с несколькими клиентами сложнее, чем один завод?

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

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

• получать смены и подтверждение присутствия от клиента;

• получать сводный учёт времени, расчёт и выплату зарплаты от кадрового агентства;

• переводиться между клиентами или площадками в пределах одного периода;

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

• завершить задание у клиента, но ещё не прекратить трудовые отношения;

• либо завершить и задание, и трудовые отношения в два разных момента.

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

1. Чётко разделите бизнес-модели до интеграции

Подбор/предоставление персонала

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

Предоставление заёмного труда

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

Аутсорсинг услуг с использованием труда

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

Почему классификация важна для EWA?

Она определяет:

• кто является работодателем;

• кто определяет и выплачивает зарплату;

• у кого есть достоверные данные об отработанном времени;

• кто вправе утверждать;

• кто предоставляет источник средств;

• с кем производится взаиморасчёт по транзакциям;

• кто является контролёром или обработчиком данных по фактической роли;

• кто рассматривает жалобы и споры.

Не следует использовать один и тот же процесс EWA для всех договоров лишь потому, что во всех случаях работники трудятся у клиента.

2. Архитектура данных при нескольких сторонах

(Требования к данным и интеграции: см. Интеграция EWA с учётом времени, payroll и ERP.)

flowchart TD
    A["HRIS кадрового агентства"] --> E["Слой эталонных данных"]
    B["График смен и учёт времени у клиента"] --> E
    C["Подтверждение супервайзера"] --> E
    D["Payroll и договоры"] --> E
    E --> F["Механизм лимитов EWA"]
    F --> G["Выплата"]
    G --> H["Сверка с payroll, ERP и клиентом"]

Принцип единого источника истины для каждого домена

3. Модель данных «человек — задание — клиент — зарплатный период»

Одного employee_id недостаточно. У одного человека может быть несколько назначений в одном периоде.

Ключевые идентификаторы

• employee_id: табельный номер работника;

• employerid или legalentity_id: юридическое лицо, заключившее трудовые отношения;

• client_id: клиент;

• site_id: место работы;

• assignment_id: конкретное задание/назначение;

• contract_id: договор об оказании услуг или необходимая ссылка;

• payroll_group: группа правил/зарплатного периода;

• payperiodid: зарплатный период;

• effectivefrom, effectiveto: даты вступления в силу;

• transaction_id: транзакция EWA;

• payment_reference: ссылка на платёж.

Почему `assignment_id` важен?

Если работник отработал 10 дней у Клиента A и 12 дней у Клиента B, система должна знать, к какому заданию относится каждая запись о времени, кто её утвердил и какие правила применяются. Не следует хранить в карточке работника только текущего клиента и затирать историю.

Пример данных о назначении

{
  "employee_id": "EMP-000123",
  "employer_id": "NK-DEMO",
  "client_id": "CLIENT-DEMO-B",
  "site_id": "SITE-B02",
  "assignment_id": "ASN-2026-00871",
  "payroll_group": "MONTHLY-B",
  "effective_from": "2026-08-12",
  "effective_to": null,
  "status": "ACTIVE",
  "record_version": 3
}

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

4. Кто учитывает время и кто его утверждает?

(Базовое понятие: см. Что такое утверждённое время?.)

Три роли могут различаться:

1. Тот, кто фиксирует: устройство учёта времени, приложение, табель или супервайзер на месте.

2. Тот, кто подтверждает присутствие/выполнение: бригадир или менеджер клиента.

3. Тот, кто утверждает к расчёту зарплаты: уполномоченный сотрудник кадрового агентства согласно процессу.

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

EWA должен использовать именно тот статус, который утверждён политикой. «Клиент просмотрел» ≠ «время утверждено к оплате».

5. SLA на утверждение времени нужно проектировать вместе с клиентом

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

Рекомендуемый KPI

Доля вовремя утверждённого времени (%) = Записи, утверждённые до контрольной точки ÷ Всего записей к утверждению × 100%

Отслеживать в разрезе:

• клиента;

• площадки;

• смены;

• утверждающего;

• типа исключения;

• «возраста» неутверждённого времени;

• причины задержки.

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

Механизм напоминаний и эскалации

• напоминания до и после контрольной точки;

• список исключений к обработке;

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

• эскалация по «возрасту» записи;

• предупреждение, когда по площадке нет данных;

• отчётность для контактных лиц клиента и агентства;

• фиксация причины при позднем утверждении.

6. Какие поля нужны для времени у клиента?

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

7. Перевод между клиентами в пределах одного периода

Это ситуация, в которой легко возникает дублирование или недоучёт времени.

Желательный процесс

1. закрыть прежнее назначение по дате/времени вступления в силу;

2. открыть новое назначение;

3. проверить отсутствие недопустимого перекрытия;

4. подтвердить «зависшее» время у прежнего клиента;

5. определить зарплатную группу и новую политику EWA;

6. пересчитать лимит, если правила изменились;

7. уведомить работника, если лимит затронут;

8. настроить права на управление/утверждение по новой площадке;

9. сопоставить уже возникшие транзакции с верным зарплатным периодом.

Не затирайте прежнего клиента

В карточке нужна история assignmentid. Если просто менять текущий clientid, ретроспективные отчёты могут отнести всё время и все транзакции к новому клиенту.

8. Завершение задания — это не увольнение

Человек может завершить работу у Клиента A, но ждать перевода к Клиенту B; либо уволиться совсем.

Компании нужны как минимум два независимых статуса:

• статус трудовых отношений;

• статус назначения/задания.

Справочная матрица обработки

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

9. Несколько зарплатных периодов и политик у разных клиентов

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

Таблица конфигурации, требующая версионирования

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

10. Сверхурочные и переменные виды дохода

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

Такие виды, как сменные надбавки, посещаемость, выработка или премии, могут определяться только в конце периода. Компания должна классифицировать:

• часть уже точную и утверждённую;

• часть предварительную, но с возможной корректировкой;

• часть, определяемую только в конце периода;

• часть, не включаемую в EWA.

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

11. Ответственность при позднем исправлении времени клиентом

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

1. в какой период клиент вправе вносить исправления;

2. кто утверждает изменение;

3. сохраняются ли значения «до/после»;

4. какие транзакции использовали прежнюю версию;

5. как пересчитывается текущий лимит;

6. в каком периоде обрабатывается разница;

7. кто связывается с работником;

8. как клиент и агентство проводят сверку;

9. как устраняются повторяющиеся ошибки.

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

12. Источник средств и денежный поток при нескольких сторонах

До внедрения нужно определить:

• какая сторона переводит деньги работнику;

• кому принадлежит счёт-источник;

• когда транзакция считается обязательством между сторонами;

• когда кадровое агентство и клиент производят взаиморасчёт;

• какая сторона несёт комиссии;

• как обрабатываются неуспешные, неясные или возвратные транзакции;

• как соотносятся права работника и обязательства сторон, когда клиент платит с опозданием;

• по какому договору отражаются дебиторская задолженность и проводки.

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

13. Пятисторонняя сверка

(Подробнее о сверке: см. Сверка транзакций EWA с payroll и бухгалтерией.)

В модели с несколькими клиентами сверка может требовать пяти сторон:

1. подтверждённое/утверждённое время;

2. лимиты и транзакции EWA;

3. результат выплаты;

4. payroll/ERP;

5. документы подтверждения/взаиморасчёта с клиентом, когда это применимо.

flowchart TD
    A["Время у клиента"] --> F["Сверка"]
    B["Транзакции EWA"] --> F
    C["Результат выплаты"] --> F
    D["Payroll и ERP"] --> F
    E["Документы клиента"] --> F
    F --> G["Совпадение или кейс расхождения"]

Частые расхождения

• клиент подтвердил, но агентство ещё не утвердило;

• время на неверном assignment_id;

• у переведённого работника осталось время на прежней площадке;

• EWA прошёл успешно, но в payroll его нет;

• платёж успешен, но EWA не получил callback;

• транзакция попала в неверное юрлицо или период;

• клиент исправил время после cutoff;

• итог по клиенту сходится, но по работнику неверен;

• комиссия или взаиморасчётная сумма привязаны к неверному договору.

14. Разграничение доступа клиента без раскрытия лишних данных

(Рамка безопасности: см. Защита данных и конфиденциальность при внедрении EWA.)

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

• всю историю раннего получения зарплаты;

• суммы личных транзакций;

• данные по другому клиенту;

• полные банковские реквизиты;

• зарплатные данные вне зоны ответственности;

• детальные сигналы о мошенничестве;

• кадровые данные, не нужные для учёта времени.

Контроль прав

• права по clientid, siteid и роли;

• права с датой истечения;

• ревизия при смене договора или контактного лица;

• MFA для утверждающих;

• запрет общих учётных записей;

• логирование просмотра, изменения, утверждения и выгрузки данных;

• отдельное утверждение массовой выгрузки;

• немедленное уведомление и отзыв доступа при увольнении/переводе пользователя клиента.

15. Трёхсторонний канал поддержки

Работник не должен сам угадывать, на чьей стороне ошибка — клиента, кадрового агентства или поставщика EWA.

Маршрутизация по типу проблемы

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

16. KPI для кадрового агентства

Опережающие KPI

• доля работников с действительным assignment;

• доля времени, присланного клиентом вовремя;

• доля времени, утверждённого вовремя;

• среднее/медианное «время ожидания» неутверждённого времени;

• доля изменений assignment, обновлённых вовремя;

• актуальность данных для лимитов.

KPI опыта и операций

• доля активации по клиенту;

• доля успешных транзакций;

• время получения денег;

• тикетов на 1000 транзакций;

• доля автоматической обработки;

• доля автоматической сверки;

• расхождения по клиенту/причине;

• корректировки времени после cutoff.

Кадровые и коммерческие KPI

• доля выхода на работу и присутствия на начальном этапе;

• увольнения по когортам;

• доля закрытия потребности в персонале;

• запросы на ручной аванс;

• уровень осведомлённости и удовлетворённости;

• операционная нагрузка на одного клиента.

Не следует делать вывод, что EWA вызвал кадровые изменения, лишь из сравнения «до/после». Нужно учитывать сезонность, объём заказов, уровень зарплаты, руководство, площадку и прочие политики.

17. Каких клиентов выбрать для пилота?

(Стандартная дорожная карта: см. 90-дневный план пилота EWA для бизнеса.)

Подходящий клиент для пилота обычно имеет:

• чёткую потребность и согласие;

• уполномоченное контактное лицо;

• относительно стабильные данные о времени;

• репрезентативные процессы смен и сверхурочных;

• достаточно людей/транзакций для тестирования;

• готовность утверждать время вовремя;

• готовность взаимодействовать по коммуникации и поддержке;

• отсутствие одновременной замены крупной системы учёта времени.

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

Что должен охватить пилот

• один цикл онбординга/активации;

• обычные смены, сверхурочные и исключительное время;

• перевод или завершение assignment;

• успешные, неуспешные, неясные и возвратные транзакции;

• ежедневную сверку;

• один полный зарплатный период;

• подтверждение/взаиморасчёт с клиентом, если это в объёме;

• жалобы и инциденты.

18. Чек-лист UAT при нескольких клиентах

Работник и assignment

• [ ] У человека одно активное assignment.

• [ ] У человека два действительных assignment в периоде.

• [ ] Перевод между клиентами.

• [ ] Завершение задания без увольнения.

• [ ] Увольнение, но в файле клиента ещё есть время.

• [ ] Неверное юрлицо или код клиента.

Время и утверждение

• [ ] Клиент присылает время вовремя.

• [ ] Время в ожидании подтверждения и утверждённое время.

• [ ] Отклонённое время.

• [ ] Время, исправленное после утверждения.

• [ ] Дублирующий, отсутствующий или пришедший не по порядку файл.

• [ ] Утверждающий отсутствует, есть замещающие полномочия.

Лимиты и транзакции

• [ ] Лимит создаётся только по данным, дающим право.

• [ ] Изменение assignment применяется по верной дате.

• [ ] Повторная отправка с тем же ключом не создаёт дубль-транзакцию.

• [ ] Timeout создаёт неясный статус.

• [ ] Возвратная транзакция обрабатывается корректно.

Payroll и сверка

• [ ] Транзакция относится к верному человеку, юрлицу, клиенту и периоду.

• [ ] Payroll блокирует дубль-транзакции.

• [ ] Сверка по каждой транзакции, а не только по итогам.

• [ ] Расхождение создаёт кейс с ответственным.

• [ ] У корректировки есть значения «до/после» и утверждение.

Права и безопасность

• [ ] Пользователь клиента видит только свою зону.

• [ ] Клиент не видит лишнюю личную историю EWA.

• [ ] Права истекают и отзываются корректно.

• [ ] Выгрузка данных логируется.

• [ ] Сценарии утечки файла или захвата аккаунта отрабатываются на учениях.

19. Правовая рамка, которую следует учитывать

Трудовой кодекс № 45/2019/QH14 вступил в силу с 1 января 2021 года. Постановление № 145/2020/NĐ-CP вступило в силу с 1 февраля 2021 года и детализирует и разъясняет ряд статей Трудового кодекса об условиях труда и трудовых отношениях, в том числе положения о предоставлении заёмного труда.

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

Что касается данных, Закон о защите персональных данных № 91/2025/QH15 и Постановление № 356/2025/NĐ-CP вступили в силу с 1 января 2026 года. Обмен данными между кадровым агентством, клиентом, поставщиком EWA и платёжным партнёром следует проверить по роли, цели, объёму и фактическим мерам защиты.

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

Заключение

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

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

Источники

• Трудовой кодекс № 45/2019/QH14

• Постановление № 145/2020/NĐ-CP, разъясняющее Трудовой кодекс

• Закон о защите персональных данных № 91/2025/QH15

• Постановление № 356/2025/NĐ-CP, разъясняющее Закон о защите персональных данных

---

Автор: Nguyen Minh Khang — специалист отдела стратегии, Nhan Kiet Manpower Supply Co., Ltd.

Консультация по решению доступа к заработанной зарплате для бизнеса: Горячая линия 0937.022.655 · Email info@nhankiet.vn · доступ к заработанной зарплате для бизнеса