Завести дополнительное поле - дата поступления в вашу базу. Оно никак не будет связано с датой отчета и проще, если оно будет заполняться триггером.

Зависит от написанного кода. Простейший пример:

insert into ...
select * from ...

После настройки merge репликации select * вполне может выглядеть по-другому. Тогда все сломается. Так что не торопитесь убеждать клиентов, что все будет в порядке. Если есть возможность, то поставьте продукт на отдельную тестовую машину, настройте репликацию и проверьте жизнеспособность такого варианта. Боюсь, что процентов 90 за то, что это не заработает.

Это не только к merge относится.

Зависит от содержания триггера. Запросто может.

Если написать в вашем триггере что-то вроде

insert into t2 (col1, col2, ...) select col1, col2, ... from inserted

то, ВРОДЕ БЫ, ничего испортиться не должно. Но, с другой стороны, представим ситуацию, когда в триггере, который изначально висел на вашей таблице, формировались некоторые поля. Тогда они могут не попасть в ваш лог, поскольку SQL не гарантирует порядок срабатывания триггеров. Да, есть возможность назначить первый и последний триггер с помощью процедуры sp_settriggerorder, но ведь вполне возможно, что эти позиции уже заняты разработчиком. В общем, это все очень отвлеченные рассуждения, не имеющие особой ценности без приложения к вашему КОНКРЕТНОМУ случаю. Без исходного кода вашего приложения ничего определенного сказать нельзя.