If a menu shows a tax-inclusive price, checkout should not add the same tax on top again. The calculation is simple in isolation and easy to get wrong once discounts, rounding, and refunds share the path.
For a single tax rate r included in a gross price P, the pre-tax amount is P / (1 + r). The tax portion is P - P / (1 + r). For example, a gross price of ₹105 at 5% represents ₹100 before tax and ₹5 tax, before the system’s currency rounding rules are applied.
That formula is not a complete tax engine. Real invoices can involve different rates, exemptions, place-of-supply rules, tax-inclusive versus exclusive configuration, and jurisdiction-specific requirements. Software needs to make the branch’s regime explicit and use one consistent conversion point.
In OrderRestro, the server remains authoritative for pricing. The browser can show a responsive preview, but the API recalculates totals before accepting the order. That prevents a modified client from deciding what amount gets recorded. The project supports per-branch tax settings and documents India GST alongside other presets; operators still need to verify their configuration against the rules that apply to them.
When reviewing POS tax behavior, test more than a single item: add a discount, refund part of the order, and compare receipt totals with the system’s calculation. Money paths deserve explicit worked examples and automated checks.
The relevant implementation and product scope are in the OrderRestro repository. I write about building business software at RaktimRanjit.com.
Top comments (0)