Unfotunately rounding differences cannot be avoided completely.
Since Rel. 4.5 wage types are genereated with an accuracy of 4 decimal
places, but the storage in cluster B2 is done with 2 decimal places, as
the payroll only deals with this accuracy.

Please note, that the standard-schemas and -rules are only patterns,
which have to be customized to the respective requirements.
For rounding problems the operations ROUND, RNDOT, ADDOT and ADDZL with
paramenters '*E' and '*B' can be used and should cover most of the
requirements.
Generally there are no standard rules for rounding, as there are
different requirements on customer side. The appropriate rounding has tobe performed before function CUMBT, but the concrete implementation has
to be done on your side.

Here is a statement from the development about this issue:

"The described situation is not caused by a program error, but are a
result of the data model. Internally, time accounts and time wage types
in time evaluation have an accuracy of 4 decimal places, as the
generated time types can appear several times in table TIP and out of
several different TIP-entries the same time wage type can be generated
respectively.
Unfortunately the number of decimal places in the cluster tables ZES,
SALDO and ZL are limited to 2. This does not lead to big rounding
differences in most of the cases (daily basis).
In some cases, when accumulating time accounts of several days, the
rounding effect may become an issue.
Depending on the underlying regulations it is possible to minimize
rounding differences by using special calculation rules or technical
time types. When e.g. calculating weekly summations with a higher
accuracy, the relevant time account could be saved into a technical
time type, which will not appear on the form, with factor 100. These
accounts can be used for the summation on the end of the week, which arethen divided by 100, so that the rounding only takes place once."