Вот расскажите, при пересчете Вы печатаете расчетный лист заново?
Нет - что выдано, то выдано. Расчетный лист за предыдущие периоды с измененными данными перепечатываться не может. Только за текущий период.

Либо в вашей ЗАРПЛАТЕ при пересчете задним числом 'порождаются' именно отклонения начислений-удержаний и проводятся они уже в текущем периоде?
Угу - именно так и есть. Разница между тем, что было и тем что стало, при пересчетах закрытых прошлых расчетных периодов идет в текущий расчетный период.

Приходится рассчитывать заново конкретный вид начисления(удержания) по 'вновь уточненному' алгоритму
Я бы сказал правильнее - приходится пересчитывать все начисления изменившегося задним числом расчетного периода, так как например изменение оклада задним числом приведет к тому, что для всех сотрудников, которые на нем сидели, должны быть пересчитаны за каждый соотвествующий период, в котором для них оклад был актуален, не только нач. по окладу, но и премии, которые зависят от него, больничные, отпуска, сверхурочные, ночные и т.д.

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

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

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

Насчет реализации модели БД с поддержкой задних чисел:
Самый простой вариант - это ввести 2 даты, у меня условно они обозначены так:
CalcDate - на какой расчетный месяц информация
SaveDate - месяц выплаты, т.е. месяц, в котором был реально проведен расчет

Самый элементарный способ - это сделать в архиве начислений и удержаний поддержку такой модели и на основе новых данных входящей информации пересчитывать закрытые расчетные периоды, а разницу писать в текущий расчетный период, где SaveDate будет равно тек. расч. периоду, а CalcDate месяцу, который был пересчитан.

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

Более подробно про модели хранения и обработки информации задними числами можно поискать на SQL.RU - где то я видел обсуждения, возможно стоит покопать форум по MSSQL.

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

Результат последнего расчета хранить не надо. Для расчета задним числом закрытого периода он просто еще раз расчитываются начисления с учетом входящих данных того периода, но актуальных с точки зрения текущего расчетного периода. Разница между полученным результатом и архивными данными периода записывается в текущий расчет, с датой выплаты, равной текущему расчетному периоду и датой расчета пересчитываемого месяца. Данные же по расчету такого периода больше нигде не нужны и их смело можно удалять (тут уже зависит от модели БД, когда их лучше обнулять - у меня они например висят до операции "Закрытие текущего расчетного периода", чтобы их каждый раз не пересчитывать без надобности). В итоге по архиву начислений всегда можно получить начисления по 2 измерениям - или по дате выплаты или же по дате расчетного периода.

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