обновление выпущено 21.02

В любом случае надо будет массово поменять значения на новые в полях кадровой части.
Это будет проблемой?

все равно нужен ответ "какая форма квитка используется".
В зависимости от формы, зависят возможности настройки и/или доработки

"Клиент всегда прав", это же только красивая фраза.
При практическом применении превращается в:
1) или если это подкреплено законодательно
2) или если мы с клиентом нашли "взаимовыгодный вариант" (в общем смысле этой фразы.... это не обязательно деньги, выгода может быть в чем-то еще).
3) или если мы "единорожки". С голой задницей, зато сделали "мир лучше"(нет!): обеспечили за свой счет комфортную возможность заблуждающимся продолжать и дальше считать, что они вовсе не заблуждаются.

В обсуждаемом вопросе:
1) законодательного подкрепления этой хотелки нет

2) я пока не увидел в чем наша выгода

3) и я точно не сторонник потакать глупостям, если это не бесплатно для нас.
Нам было "бесплатно" (корректнее сказать, "расходы" на разъяснения почему люди заблуждаются превышали "расходы" на написание инструкции) в начале 2023 года обеспечить раздельный расчет ПФ, ФСС, ФОМС, не смотря на то, что законодательство требовало единый расчет: вот инструкция...
И нет резона оспаривать желание клиента убиться об стену за свой счет. Хотя, если честно, даже там исходно было проверено - при всем желании не убьются... если только пара ссадин в виде оплаты времени внедренцу за перенастройку.

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

Зачем вам сейчас в КЗ paymentMethod?

paymentMethod будет реализован тогда, когда будет выпущена версия в которой будут хранится 100 сообщения. Чтобы брать тот paymentMethod что стоит в 100.
До этого момента реализация paymentMethod влечет скорее негативные последствия.
Связано это с тем, что Контур.Экстерн при импорте ОЗНС при отсутствии paymentMethod СКОПИРУЕТ его из соответствующего 100, и это именно то, что надо. А если paymentMethod будет исходно в файле, Экстерн его копировать не будет.

Резюмируя: зачем заставлять вводить бухгалтера то, что должно быть "один в один" как в исходном запросе, если бухгалтер не может это сейчас посмотреть (а мы проверить) в программе? 
Как следствие получить в Экстерне ошибку из-за того что paymnetMethod который выбрал бухгалтер не соответствует методу, что был в исходном запросе (если такая проверка уже реализована). А если не реализована, то получить ошибку уже после отправки.

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

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

Если четко понимать свою роль в этом процессе, то не понятно откуда могут возникнуть "бредовые" (ну как минимум на первый взгляд) идеи вида:
- нам надо заранее знать сумму НДФЛ (чтобы что? Как это помогает исполнять обязанности налогового агента? Как мешает исполнять если не будете знать заранее?)
- сумма НДФЛ должна быть ровно 13% (у кого будут претензии и почему, если не будет равно ровно 13%? и какое отношение они имеют к контролю правильности выполнения обязанностей налогового агента?)