The infamous one cent issue. The likely scenario is that there is some issues with the number of
significant figures after the decimal place during various calculations.
The best way I can illustrate this is using some math in an example:
A product that has a cost of 1.15 and has a tax rate applied at the single item level, for each of two items will be a penny different than the tax rate applied to the total of the product cost for two items.
While it seems like this is something that is rather obvious, what it has to do with is when and how rounding is handled. If I were to leave the decimals significance to 4 digits throughout the entire calculation, the solution will be the same at the very end for both scenarios. If I round to two digits before adding the cost of each item in the line total, then it may have a different result than if the two items were rounded to two digits after the summation of the line total.
Now, this can also occur when a single item is being taxed. It simply depends on what the cost of the item is at four decimal significance when tax is calculated.
If a product has a price of 2.8750, and were to be rounded to 2.88 before tax, we get two different answers.
If you are going to dispute the price inserted similar to the example above to 4 digits after the decimal, then here is where I suggest that this is common among 'catalog' discounts where a percentage is applied to matching products, and the price update results in a difference that would yield such a price to four digits.
I think (and welcome detailed corrections) that there have been some methods implemented to work with such issues in a more flexible way:
getFinalPrice(), if I am not mistaken produce a four-decimal and two-decimal result, respectively. The
getFinalPrice() method handle the calculations to two decimal places and depending on your settings is the price that would be used for tax calculations.
The reason I explain the scenarios is simply because it is possible that this is so unique to your situation that a fix cannot be found but the scenario can be debugged and resolved.
Combining both scenarios above, you are now even more hard-pressed to find the problem within the code.
Perhaps the solution would be best resolved to rewrite the output of the totals in the pdf methods, to obtain the calculated and stored values within the sales_flat_order table.