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

1. Принять файл обмена штатным образом. Центральная база принимает обмен не быстро (как периферийная), а с принудительной задержкой - 1 объект в 10 сек. (или 5 - уже не помню, но все равно много). Убедиться в этом можно, открыв во время загрузки файл журнала (far`ом например).
Можно и убедиться, что загрузка продолжается, и когда-нибудь закончится. Суток через несколько
Потом тот же объем изменений будет раздаваться в другие периферийные, если таковые есть.

2. Отказаться от приема этого файла. Очистить в периферийной базе очередь обмена (1supdts), затем перезаписать все, что делали (создавали) бухгалтера нового, сверившись с журналом регистрации, и обменяться. Затем, возможно, восстановить периферийную по центральной, если прошлые итоги уже разошлись.

3.Если в обмене участвуют всего 2 базы - центральная и одна периферийная, можно на время подменить заголовки ЦБ, сделав ее периферийной (с префиксом центральной) и наоборот (периферийную центральной со старым ее префиксом), сделать выгрузку и загрузку. Времено объявленная периферийной, база примет тот же объем значительно быстрее.

Можно и другие варианты придумать - зависит от анализа произошедшего.