Reworking the pricing engine in PrestaShop #41040

kpodemski · 2026-03-20T12:49:13Z

kpodemski
Mar 20, 2026
Maintainer

Price calculation has been one of the most discussed topics in the PrestaShop ecosystem for years. It consistently ranks among the top pain points reported by merchants and agencies, and we know many of you have run into issues. We're now starting a dedicated project to address this: a new pricing calculation system, built to be reliable, consistent, and properly tested.

What we're building

Instead of monolithic pricing logic, the new engine breaks computation into dedicated calculators, each responsible for a single domain:

ProductCalculator: base product price and combination impacts
TaxCalculator: tax rates and tax rule application
DiscountCalculator: specific prices, cart rules, and promotional reductions
ShippingCalculator: carrier rates and shipping cost computation
CartCalculator: full cart aggregation (products, quantities, totals)

Each calculator implements a shared interface and is orchestrated by a central component that runs them in sequence. This makes the pipeline extensible (adding a new pricing concern means adding a new calculator) and testable (each calculator can be unit-tested in isolation).

We're also standardizing rounding behavior across the entire pricing chain, so that a single, well-defined strategy applies everywhere, from the catalog to the order confirmation.

How we're rolling it out

The new system will be introduced gradually, behind a feature flag, and connected to the existing user journey step by step:

Products only (single currency, no taxes, no shipping, no discounts)
Adding shipping fees
Adding tax calculation
Adding discounts and specific prices
Multiple currencies

At each step, we validate the full order lifecycle before moving forward.

We need your input

We have a good picture of the issues tracked on GitHub, but we know that probably doesn't cover everything. We're especially interested in hearing about:

Tax calculation edge cases in specific countries or tax regimes
Reverse-charge scenarios (e.g. intra-EU VAT at 0%)
Rounding or display issues you've encountered that aren't already reported
Anything you consider critical that we should be aware of before we get deeper into development

If you've run into pricing problems that made you think "this absolutely needs to be fixed" now is the time to share them.

You can follow along and find all the tasks related to this project here on GitHub.

We'll share updates and individual stories as development progresses.

Hlavtox · 2026-03-20T13:16:14Z

Hlavtox
Mar 20, 2026
Collaborator

Scenario:

Czech company, VAT payer.
Czech tax is 21 %.
Selling to Slovakia in OSS mode, with 20 %.
Tax address set to invoice address.
Using FoP fork of vatnumber module or the native one.

Current status:

Invoice address	Delivery address	Correct VAT rate	Current VAT rate	Note
Czech customer with valid VAT	Czechia	21	21	✅ OK - standard scenario.
Czech customer with valid VAT	Slovakia	21	21	✅ OK - not an intracommunity delivery.
Czech customer normal	Czechia	21	21	✅ OK - standard scenario.
Czech customer normal	Slovakia	20	21	🔴 ERROR - must be 20% because of OSS mode. Limitation of core tax logic.
Slovak customer with valid VAT	Czechia	21	0	🔴 ERROR - must be 21% because the goods did not leave the country. Limitation of tax interface receiving only one address.
Slovak customer with valid VAT	Slovakia	0	0	✅ OK - intracommunity delivery.
Slovak customer normal	Czechia	21	20	🔴 ERROR - domestic delivery, must be 21%, OSS mode is not applied. Limitation of core tax logic.
Slovak customer normal	Slovakia	20	20	✅ OK - 20% due to OSS mode.

0 replies

mark-app · 2026-03-20T13:59:23Z

mark-app
Mar 20, 2026

Optional price on country level? This wil give a "nice" price in the country of choice including VAT, even when VAT rates changes by country.

0 replies

gennaris · 2026-03-20T14:01:43Z

gennaris
Mar 20, 2026

Here are a few common cases that currently require overrides due to missing native support:

UK VAT (£135 threshold): need to remove VAT based on cart total (no threshold-based tax rules available).
Northern Ireland (BTxxx postcodes from UK): need postcode-based logic to apply EU VAT rules (country-level logic is not enough).
Reverse charge (VIES): VAT exemption should depend on customer type + delivery country, but there’s no built-in conditional handling.

Native support for these cases would be great.

0 replies

matrixino · 2026-03-20T14:39:03Z

matrixino
Mar 20, 2026

Other than what already said above, please stop using 6 decimals to store price data. There are lots or rounding error in final prices, no matter if set per product/line/total. There will always be discrepancies.
Also please let user decide if they want to apply discounts before or after VAT. Mathematically there is no difference, in reality if you round 6 decimals before or after there will be huge differencies.

0 replies

Mieces · 2026-03-20T14:53:48Z

Mieces
Mar 20, 2026

Does this mean that it will be released as a whole new upgrade version? Or will it be module only based to where any version of PrestaShop 9.x can use it?

Also, please make sure you fix the issues with the Shipping Price Ranges for USD as mentioned in my post here.
#41035

Thank you!

2 replies

matrixino Mar 20, 2026

Does this mean that it will be released as a whole new upgrade version? Or will it be module only based to where any version of PrestaShop 9.x can use it?

Also, please make sure you fix the issues with the Shipping Price Ranges for USD as mentioned in my post here. #41035

Thank you!

No it will replace the current system in future versions. No module.

Mieces Mar 20, 2026

Ok, thank you. I will prepare for a near future upgrade when it is released.

Codencode · 2026-03-20T16:20:43Z

Codencode
Mar 20, 2026
Collaborator

We would also need to consider Norway, which has the VOEC system, similar to the OSS system for Europe.

3 replies

kpodemski Mar 20, 2026
Maintainer Author

Just to be clear, we won't - probably - implement every single detail, but the architecture should allow developers to do everything what's needed.

Hlavtox Mar 20, 2026
Collaborator

@kpodemski That's perfectly fine. :-) All we want it is hookGiveMeTaxRate with all the params like $customer, $invoiceAddress, $deliveryAddress, $products. Or a new tax interface that will be instantiated with more data.

Plus, it would be good to easily report back to the core, what is happening. So after removing the VAT, it shows VAT removed due to intracommunity delivery instead of tax incl.

Codencode Mar 20, 2026
Collaborator

@kpodemski
Yes, of course, that's clear. I just said it to have a more complete picture.

Then, as @Hlavtox rightly said, the important thing is to have the parameters we can work with.

ChillCode · 2026-03-20T20:25:03Z

ChillCode
Mar 20, 2026

If PrestaShop wants to follow EN-16931 this is the correct way to do the math:

First we have to take in mind that we can use as many decimals as we need, but the price should be shown with the total number of decimals in every place, here resides many of the rounding issues PrestaShop have, so if we set 0.012581€ we must show that price on the invoice and FO, I explained this before.

The math is as follows if we want to use 6 decimals:

	Compliant Approach (EN 16931)	Bad Approach (Early Rounding)
Unit Price	0.012581 €	0.01 € (Rounded to 2)
Quantity	4,759	4,759
Gross Subtotal	59.872979 €	47.59 €
Line Discount (10%)	5.9872979 €	4.759 €
Line Net (Pre-round)	53.8856811 €	42.831 €
Total Line (Final)	53.89 €	42.83 €
Discrepancy	Reference Value	-11.06 € (20.5% Error)

There is a huge difference as we can see doing it in one way or another.

19 replies

Eolia Mar 21, 2026

Some currencies have 3 decimal places.
https://docs.adyen.com/development-resources/currency-codes

matrixino Mar 21, 2026

Some currencies have 3 decimal places. https://docs.adyen.com/development-resources/currency-codes

true, some have none too.
you can use 4 decimals for those.

Eolia Mar 21, 2026

Yes, but 3, 4, or 12 makes no difference. There are 3 problems with PrestaShop regarding rounding:

It's important to understand that the sum of the rounded values has NEVER been equal to the sum of the rounded values (the strange added option allows you to choose between rounding by line or rounding the total).
NOTHING should be rounded before the display. What you show the customer must be exactly what they will pay.
If you are displaying prices excluding tax (B2B), never round the unit prices! (0.1537 excl. VAT * 500 = 76.85, which is different from 0.15 * 500 = 75)

matrixino Mar 21, 2026

Yes, but 3, 4, or 12 makes no difference. There are 3 problems with PrestaShop regarding rounding:

It's important to understand that the sum of the rounded values has NEVER been equal to the sum of the rounded values (the strange added option allows you to choose between rounding by line or rounding the total).

NOTHING should be rounded before the display. What you show the customer must be exactly what they will pay.

If you are displaying prices excluding tax (B2B), never round the unit prices! (0.1537 excl. VAT * 500 = 76.85, which is different from 0.15 * 500 = 75)

Nothing new there.
You also forgot the problem with discounts, which is similar to your last point with vat.
Also some gateways if you pass the product list make their own math and round at different stages, so the grand total may differ. This is why PayPal for example forces you to setup line rounding.

Mieces Mar 21, 2026

It seems to me, that if they were to rewrite the pricing part to use the normal 2 decimal rounding method that is compliant within most payment methods, this would then allow devs to create modules to apply the extra decimals per country/currency that uses the extra decimals. This way, it would cover the majority of the problems over a good amount of the world and those in Europe and a few other countries can possibly have a free/low cost addon to fix their own decimal problems.

Another idea, is to have the PrestaShop Devs themselves create a linked pricing module to be loaded per country selected rather than per continent. The businesses really shouldn't allow other currencies than their own to be used. If a person from the USA wants to buy something from Europe, they usually have to pay a higher price in Euros instead of their own currency. PayPal and other payment methods usually do this conversion for us on the payment side. All we have to do on the shopping cart side is to get the payment total between the cost of the products, taxes, shipping and any VATs that might be included.

I don't know which versions each of you are using, but I'm using 9.0.0 and I have no problems with totals coming out right except for the shipping price ranges not calculating properly when reaching closer to the maximum part of each range. I'm using USD and it's somehow messed up between Euros and some other problem. I know this isn't the related problem here, but I'm trying to point out that I've seen no problems with this version calculating the totals on my end.

Jeremie-Kiwik · 2026-03-23T08:14:52Z

Jeremie-Kiwik
Mar 23, 2026

Great idea, and congratulations on the planned redesign!
Here are some issues we’ve encountered, which become especially significant in B2B contexts with very large carts of over 100 or 200 lines.

Keep a no-rounding system throughout the entire process, and only apply rounding at the very end
Cache the cart total amount to avoid recalculating it at every step of the checkout (in B2B contexts with very large carts, pages become too slow otherwise)
Cart rules: introduce 'incompatible' rules instead of 'compatible' ones (otherwise the cart_rules tables become extremely large with big catalogs, which slows-down price calculation)

6 replies

matrixino Mar 23, 2026

Cart rules: introduce 'incompatible' rules instead of 'compatible' ones (otherwise the cart_rules tables become extremely large with big catalogs, which slows-down price calculation)

This is a very discussed problem before and I hope it's already part of the discounts changes\redesign coming with 9.1. I didn't have the time to check the source code yet.
At the moment the only options are a Cron that deletes expired\used rules every night or an addon modules which changes the discounts system altogether (the 3x2 one).
But if have lots of active rules and use exclusions it's really a pain. You need to manually invert the logic in the core code to make it work to use cart_rule_combination in the opposite way.

Hlavtox Mar 23, 2026
Collaborator

@matrixino @Jeremie-Kiwik Good thing is that you don't have to worry about this anymore, because they decided to remove this completely with the discounts "redesign". 😄 /s

matrixino Mar 23, 2026

@matrixino @Jeremie-Kiwik Good thing is that you don't have to worry about this anymore, because they decided to remove this completely with the discounts "redesign". 😄 /s

@Hlavtox Did they remove the possibility to allow/deny rule combinations altogether? As I said I didn't have the time to check sources yet (lots of work + a toddler around :)). You know what? If they did I'm not even against it, at least we can implement our own solutions with hooks without touching the core.

Jeremie-Kiwik Mar 23, 2026

To my mind, your approach for the rouding system can introduce significant cumulative errors on large carts.
When discounts or unit prices are rounded early, and then multiplied by large quantities (e.g. ×400), the rounding error is also multiplied. This can easily result in diff greater than 0.01 € at the cart level.

That’s why keeping full precision during the entire calculation process, and only rounding at the very end, helps ensure better overall accuracy.

matrixino Mar 23, 2026

To my mind, your approach for the rouding system can introduce significant cumulative errors on large carts. When discounts or unit prices are rounded early, and then multiplied by large quantities (e.g. ×400), the rounding error is also multiplied. This can easily result in diff greater than 0.01 € at the cart level.

That’s why keeping full precision during the entire calculation process, and only rounding at the very end, helps ensure better overall accuracy.

You can't do that. First because payment gateway will throw an error if you round only the total since they work per line. Second because you must show the correct price by law to final users. Also legally and for e-invoicing there are specific fiscal rules, one of which is to round per line (this may differ by country but I believe it's the standard everyone is using nowdays, hence why also the gateways use that).

luigimassa · 2026-03-23T13:02:02Z

luigimassa
Mar 23, 2026

Adding hooks to add one or more ad hoc amounts as additional expenses?

0 replies

cruftex · 2026-03-25T11:19:47Z

cruftex
Mar 25, 2026

Great to hear!

@kpodemski
Please mind that the "Feature Flag" approach will probably not work or it will get a whole problem and project on its own. Prices are a cross cutting concern.

PS is at the moment calculating with net (tax exclusive) prices. In many countries B2C requires prices to be tax inclusive. Then, to avoid rounding, all calculations have to be done on the tax inclusive prices.

If you want to have the current and the new calculations in parallel, you need to introduce new price properties in every data structure.

2 replies

matrixino Mar 25, 2026

In many countries B2C requires prices to be tax inclusive.

Can you name one? In front prices are always tax incl. AFAIK in case of invoices the calculation must be done on the net price (for example discounts) pretty much everywhere. The only case where discounts must be shown on gross price is in physical stores. Also keep in mind that adding vat or discount before/after doesn't really change the total if we are talking about % (rounding apart). They are only relevant for amount discounts.
Moving everything from using gross prices by default is a BIG change for PS. Even if you want to keep both and let it choose in the BO settings (maybe tied to B2B on/opff flag). Not saying it's not worth, but it's open to lots of troubles.

Hlavtox Mar 25, 2026
Collaborator

PS is at the moment calculating with net (tax exclusive) prices. In many countries B2C requires prices to be tax inclusive. Then, to avoid rounding, all calculations have to be done on the tax inclusive prices.

That's not true, check CartCalculator class and related code.

I would let @jolelievre do his job and you will see it will be correct. The new system design has all the right things it needs to have. The numbers are carried around both in rounded and not rounded form. It deals with calculation of VAT from bottom and from top etc. It will be good.

cruftex · 2026-03-25T13:24:28Z

cruftex
Mar 25, 2026

@Hlavtox

That's not true, check CartCalculator class and related code.

Thanks! I was incorrect. This one is calculating in parallel on tax inclusive and tax exclusive. The product price is always kept as tax exclusive price. I was analysing the code a while back.

Can you name one? In front prices are always tax incl. AFAIK in case of invoices the calculation must be done on the net price (for example discounts) pretty much everywhere.

The invoicing is done based on the price that is displayed with the prodcut. That can, depending on the country, be tax inclusive or tax exclusive. The majority of consumer prices is tax inclusive. Here is an overview:

Country / Region	Tax Included in Displayed Price	Notes
European Union (EU)	Yes	VAT must be included by law for consumers
United Kingdom	Yes	VAT included in retail prices
Australia	Yes	GST included
New Zealand	Yes	GST included
Japan	Yes (mostly)	Sometimes both tax-incl. and excl. shown
South Korea	Yes	VAT included
China	Yes (generally)	Standard consumer pricing includes tax
Brazil	Yes	Complex tax system but included
Mexico	Yes	VAT (IVA) included
Singapore	Yes	GST included
South Africa	Yes	VAT included
Switzerland	Yes (mostly)	Some variation in B2B contexts
India	Yes (MRP)	Retail MRP includes GST
UAE	Mixed	Often included, but not always clear
Saudi Arabia	Mixed	Increasingly tax-inclusive
United States	No	Sales tax added at checkout (varies by location)
Canada	No (mostly)	GST/HST/PST added at checkout

I just AI generated this. This is not to be meant as a reference just as an idea about that this is handled differently by country.

0 replies

matrixino · 2026-03-25T13:44:49Z

matrixino
Mar 25, 2026

@cruftex Displayed price is a different thing tho. Displaying rules differs from fiscal rules when invoicing. that's why sometimes you can find a rounding additional line at the end of invoces with (+- some cents) to make it even.

1 reply

Hlavtox Mar 25, 2026
Collaborator

You cannot calculate with some hidden price.

cruftex · 2026-03-25T13:57:16Z

cruftex
Mar 25, 2026

@cruftex Displayed price is a different thing tho.

No its not. If you buy something for 5 Euro (displayed price), the price on the invoice is the same. How would you otherwise know the invoice is correct?

I discussed that here: #32969

Here is the pseudo code:

for each distinctive VAT-rate:
  unit_price = inclusiveVat ? displayedVatInclusiveUnitPrice : displayedVatExclusiveUnitPrice
  position_total = qty * unit_price
  product_total = position_price1 + position_price2 + ...
  if (inclusveVat) {
     vat_inclusive_sum = product_total
     included_vat = round(product_total / (1 + vat_rate) * vat_rate)
    vat_exclusive_sum = vat_inclusive_sum - included_vat
  } else {
    vat_exclusive_sum = product_total
     included_vat =  round(product_total * vat_rate)
     vat_inclusive_price = vat_exclusive + included_vat
  }

9 replies

cruftex Mar 25, 2026

@matrixino

Oh. I assume now with "Final price" you meant the invoice total. When I write display price, I mean the price at which the product was offered (displayed) to the customer.

@matrixino Yes, that's why some shops display "approximate amount" next to Total (tax excl.) or Total (tax excl.), depending of which price they use as source of truth.

@Hlavtox wrote both times tax excl, but probably meant tax inclusive or tax exclusive. If you print both values on the invoice, one of it is approximate because you need to round when calculating the VAT. That is correct. But, the other one is accurate and not rounded. And nothing can ever be off by 2 cents.

If you have a final display price of 10€, and for rounding issue your invoice ends up with 9,98€ or 10,02€

I am happy to explain this more, if needed. However we need to define first what we are talking about and how we name things.
Can you give please a complete example for what you mean. What is the product price, vat rate and final total of the invoice? And who wants it to be rounded to 10 Euro?

Meanwhile I also checked the SAP documentation on that. They use the terms net price and gross price and not vat included and vat excluded. So I will switch to the obviously more common terminology now.

matrixino Mar 25, 2026

@cruftex Chekc this example. It's really just like Hvlatox wrote here #41027 (comment)
Doesn't matter how you want to call it: net price == price vat excl. (the one we currently save in db), gross price == price tax incl.

cruftex Mar 25, 2026

@matrixino

As stated there, you need to calculate your invoice with the displayed price. In his example 2.04 Euro.

When you calculate the final total, as long as you have no fractional quantities and no discounts, no rounding needs to happen. All numbers are decimals with two digits. So its an incorrect assumption that you need to round here.

From the final total you need to calculate the included VAT. That needs to be rounded.

I do not see where a line with rounding has to be added and why something can be off by 2 cents.

matrixino Mar 25, 2026

@cruftex Oops sorry, I forgot to say when discounts are involved. Especially on high quantities.

cruftex Mar 25, 2026

@matrixino :)

cruftex · 2026-03-25T13:59:22Z

cruftex
Mar 25, 2026

@Hlavtox @kpodemski

I don't see any PRs referenced. If I should have a look at a PR, can you please mention me there?
I am happy to have a look, if needed, but I don't have capacity to follow all the PRs.

2 replies

Hlavtox Mar 25, 2026
Collaborator

Here is all the info you need, check it out - #41027

cruftex Mar 25, 2026

@Hlavtox

Ok, I wrote comments there for the most relevant thing.

tswfi · 2026-03-31T13:27:46Z

tswfi
Mar 31, 2026

Didn't have time to read trough everything but at least in Finland there is one interesting edge case regarding bottle deposits. As the contents is usually "food item" it is using a different tax class than the deposit. Just wanted to high light a case where one product can actually contain multiple vat rates :)

0 replies

Reworking the pricing engine in PrestaShop #41040

Uh oh!

Uh oh!

kpodemski Mar 20, 2026 Maintainer

Replies: 15 comments · 44 replies

Uh oh!

Uh oh!

Hlavtox Mar 20, 2026 Collaborator

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Codencode Mar 20, 2026 Collaborator

Uh oh!

kpodemski Mar 20, 2026 Maintainer Author

Uh oh!

Hlavtox Mar 20, 2026 Collaborator

Uh oh!

Codencode Mar 20, 2026 Collaborator

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Hlavtox Mar 23, 2026 Collaborator

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Hlavtox Mar 25, 2026 Collaborator

Uh oh!

kpodemski
Mar 20, 2026
Maintainer

Replies: 15 comments 44 replies

Hlavtox
Mar 20, 2026
Collaborator

Codencode
Mar 20, 2026
Collaborator

kpodemski Mar 20, 2026
Maintainer Author

Hlavtox Mar 20, 2026
Collaborator

Codencode Mar 20, 2026
Collaborator

Hlavtox Mar 23, 2026
Collaborator

Hlavtox Mar 25, 2026
Collaborator