Enterprise Systems
Calculating GST from an inclusive MRP in a retail POS
A concrete pricing model from NodeDR POS: derive the tax portion from the shelf price, keep the server authoritative and test rounding at receipt level.
By Raktim Ranjit · Published · 5 min read

A retail shelf label gives the customer a price to pay. If that MRP already includes GST, adding a tax percentage at checkout changes the price. NodeDR POS treats the shelf price as the gross amount and derives the taxable value and tax portion from it.
The arithmetic
For a single rate, the tax contained in an inclusive price is gross × rate / (100 + rate). The taxable value is gross − tax. As an arithmetic illustration, a ₹118 item at an assumed 18% rate contains ₹18 of tax and ₹100 of taxable value. That illustration does not determine the correct rate for any real product; the configured rate must be verified separately.
The CGST Rules, Rule 35 gives the corresponding inclusive-value formula using the sum of the applicable tax rates. This distinction matters when tax components are displayed separately on an invoice.
Store money as exact values
A checkout cannot let binary floating-point decide the final paise. I model money as integer minor units or exact decimal values, define where rounding occurs and test the total against the printed receipt. The design has to choose whether tax is rounded per line or after aggregation and apply that choice consistently to invoices, returns and reports.
The server owns the result
The browser can preview a GST breakup for the cashier. The API recalculates the final amount from the stored product price, rate and quantity. It does not accept a client-submitted tax or total as the source of truth. That protects against accidental drift between versions of the interface and deliberate alteration of a request.
A return is part of the model
A return reverses more than a payment. It must carry the original price and tax treatment into the credit document and put the quantity back into stock. I test the sale and its return together, because a screen that shows the right checkout total can still leave the stock or reports wrong.
This is why tax calculation belongs next to inventory and receipt generation in the same business workflow. The rate tables and compliance rules can change, so the article explains the engineering model rather than giving tax advice for a specific sale.
References
Author
Raktim Ranjit is a software engineer and the founder of NodeDR Infotech. He builds and maintains the software described here.