We are using Magento CE 1.7 and have various rounding issues. In various calculations there is a 0,01 EUR difference.

The basic issue might be that the article-prices are incl. tax.

Co-programmers overwrote the Mage_Core_Model_Store::roundPrice() method to calculate with 4 digits precision. But this seems to cause issues with PayPal payments.

Is there a solution for those problems?


We actually tried an official core patch which basically adds 4-digit rounding to \Mage_Tax_Model_Sales_Total_Quote_Shipping::_round, \Mage_Tax_Model_Sales_Total_Quote_Subtotal::_deltaRound and \Mage_Tax_Model_Sales_Total_Quote_Tax::_deltaRound which fixes a coupon rounding issue but not the PayPal problem.

  • As far as I remember Magento stores prices with 4 decimal points. So if prices are input with 4 decimal points the calculation is correct. But I may be wrong. Commented Feb 19, 2013 at 10:01
  • 1
    What do you mean by "input with 4 dec. points"? But the Magento rounding works with 2 dec. points. Also I think the PayPal interface works with 2 dec. points - this seems where the problem starts.
    – Alex
    Commented Feb 19, 2013 at 10:07
  • If I recall correctly, if you input prices in admin with 4 decimal points it will be saved in db with 4 decimal points. Then it will be rounded to 2 point during output, but rounding will be correct as price with 4 decimal point will be rounded. Commented Feb 19, 2013 at 10:12
  • Sure - but we mainly have problems with total calculation, especially if percentage-based coupon codes are involved.
    – Alex
    Commented Feb 19, 2013 at 10:14
  • Oh, then I got your question wrong. Sorry. Commented Feb 19, 2013 at 10:15

4 Answers 4


We are aware of several rounding issues within the core Magento tax module that cover scenarios that have been described. Presently we're working on those issues for an upcoming 1.13 release. Those rounding issues are triggering a simple Paypal check that determines if the line items in the cart add up correctly. It looks like Fabian's patch takes care of the Paypal check in the short term.

If you have any questions, comments, or suggestions on how we can improve the Magento Tax module please don't hesitate to contact me as I'm the product manager responsible for taxes.

Regards, Chuck

  • Great! Is there some kind of test suite available to show which issues will be tackled?
    – Alex
    Commented Feb 21, 2013 at 16:45
  • 1
    Chuck, would you mind setting up your user info in order to verify?
    – benmarks
    Commented Feb 21, 2013 at 17:25
  • The tests are internal only. As far as more detail on known rounding issues - that's a little interesting. A customer would see them as being associated with certain tax configurations using specific combinations of price, tax rate, discounts, etc. Our approach for 1.13 has been to identify common tax configurations and ensure that # combinations will not mathematically produce rounding errors and tag certain configurations (small corner cases) as hazardous configurations that should be avoided.
    – Chuck
    Commented Feb 21, 2013 at 17:39
  • A little bit off-topic, but does it mean that there would be also CE 1.8 edition?
    – Sergei Guk
    Commented Feb 21, 2013 at 19:47
  • Yes - CE releases lag EE releases by about a month. 1.13 is the next EE release.
    – Chuck
    Commented Feb 22, 2013 at 18:46

Thanks to Andreas Vogt, I build a module to fix the Paypal round bug. Andreas gave me a few core hacked files and I made the module. It checks wether the sums are correct and if not, it is corrected.

Afaik the core hack is tested in the wild. A lot of people asked for the module, but no onw gave me feedback wether it works. But it is unit tested! (only wether the rewrites work, because I had no idea, what the paypal problem is ;-))


  • 1
    Hm .. which bug exactly does it fix? Looks like the cart-line-items-transfer bug. We actually have switched the cart-transfer off. And is it to be applied with the 4-digits rounding patch?
    – Alex
    Commented Feb 19, 2013 at 10:35
  • Is there more than one problem? As I said, I have no idea, what exactly it fixes - if there is more than one problem :( Commented Feb 19, 2013 at 11:09

We are facing both, the paypal rounding bug and the issue with coupon codes of 100% discount. We only have problems on prices (like Eur 3,99 incl. tax), where the net price has on the 3rd digit a 5 (3,325). So also the tax (here with 20%) has on the 3rd digit a 5 (0,665). So if you round and add both prices (what paypal and magento does) the total is Eur 0,01 more than the base price (Eur 4,00).

The right caclulation should be Eur 3,32 net + Eur 0,67 tax = Eur 3,99

As we are also trying to find a general solution, we give the paypal rounding fix a try!

  • great, tell me if you have problems, I'm eager to help and see the Bugfix in the wild and debug it if needed! Commented Feb 20, 2013 at 11:01
  • 1
    FYI the issue you've described is fixed in our upcoming release ( 1.8 CE / 1.13 EE ).
    – Chuck
    Commented Mar 12, 2013 at 14:39
  • @Chuck I have just tested this scenario with Mage_Tax_Model_Sales_Total_Quote_Tax from and it does look to have resolved the issue as a drop-in replacement in a 1.12 project. Thanks very much. Is there an ETA for 1.8CE yet? Commented Jun 1, 2013 at 11:53

there is a general relationship between the prices, the quantity, discount, tax and their precisions.

x is the price
y is the percentage
s is the rounded sub-total

2 Directions
A) incl. Tax => excl. Tax => incl. Tax
B) excl. => incl. => excl.

The important issue is the rounded subtotal I am calculating with the max. Error. 2 fractional digits means 5*10^-3

A) x*10^2/(y+10^2) // s*(y+10^2)/10^2

B) x*(y+10^2)/10^2 // s*10^2/(10^2+y)

Subtotal precision 2 fractional digits:
5*10^-3*(y+10^2)/10^2 => (y+10^2)/10^2<1 => no y
3 fractional digits:
5*10^-4*(y+10^2)/10^2 => (y+10^2)/10^2<10 => y<900
4 fractional digits:
5*10^-5*(y+10^2)/10^2 => (y+10^2)/10^2<10^2 => y<90900
(must be a very bad country)


Subtotal precision 2 fractional digits:
(5*10^-3)*10^2/(10^2+y) => 10^2/(10^2+y)&lt;1 => every y

If you want to calculate with discounts or taxes and want to recalculate the price, the next explanation can be interesting for you. Please be aware since I don't know any case in the front-end, it is possible there is an intern calculation. A) Total => Tax/Discount =>Total B) Tax/Discount => Total => Tax/Discount

A) x*y/10^2 // s*10^2/y

B) x*10^2/y // s*y/10^2

A) Subtotal precision 2 fractional digits:
(5*10^-3)*10^2/y => 10^2/y < 1 => y>10^2
Subtotal precision 3 fractional digits:
(5*10^-4)*10^2/y => 10^2/y < 10 => y>10
Subtotal precision 4 fractional digits:
... 10^2/y < 10^2 => y>1

With a precision of 2 digits, you must have a rate with NO FRACTIONAL DIGITS. Example: Total: 15,15 tax-rate: 0,3% => tax 0,04545 => rounded 0,0455 tax: 0,0455 => total: 15,17

B) Subtotal precision 2 fractional digits:
(5*10^-3)*y/10^2 => y/10^2 &lt; 1 => y < 10^2

if a is the precision, than must be y less than a+2.

Please note if you handle quantities. The error will be multiplicated. So if you have a max of 10^5, you have to have a precision of 7. This is only worrying, if you are calculating with offset!

ADDITION (9.10.2013 Magento Version Brutto <=> Netto and Taxes // America <=> old Europe Sets are integers (Cents) and the mapping
f(x) = round(a*x) a>1 is not bijective. In my words: Not for every price incl. exists a price excl. or There are sometimes 2 prices incl. for one price excl. or You can get 2 different results depending how you calculate

Real-world-example from Germany:

You try to enter a price incl. taxes: 19,95 You get 16,76 (2 digits) as your prices excl. the taxes (19%). If you calculate the 19% taxes you get (16,76*0.19) 3,18. (Be aware: 19.95 * 019/1.19 ~ 3.19)

So there is 1 Cent difference. 16,76 => 19.94 16.77 => 19.96

There is no price 19,95 in america - land of netto.

So calculate with original prices as far as possible. For including prices use entered price and the taxes (broken number).

PayPal has this fraud check - now i'm not sure - but PayPal just adds the number magento gives it. see http://fabiankrueger.de/blog/magento-und-paypayl-rundungsfehler/ If this is not true and PayPal recalculate Tax or Total, this problem is not solvable, else the prices - wrong or right - are shown before in Magento. Solve it there. For me it seems to work.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.