Point-of-sale packages written for other markets almost always assume a single sales tax applied once at the line or the invoice level. Sri Lankan retail does not work that way, and when a system cannot express the relationship between VAT and SSCL correctly, the difference has to be made up by hand.
In practice that means one of three workarounds. Cashiers adjust totals manually, which is slow and produces receipts that do not reconcile. Prices are entered pre-adjusted, which makes every price change a bulk data exercise. Or the tax is reconciled monthly by the accountant, which means the figure on the customer's receipt was never right in the first place.
All three are expensive, and the third carries real compliance risk. A receipt is a document, and a systematic discrepancy between what you charged and what your filings say is not the kind of problem you want to explain retroactively.
The fix is not complicated, but it has to be a requirement rather than a configuration afterthought. Tax should be a configurable engine applied in a defined sequence at both line and invoice level, with the receipt format and the period summary generated from the same calculation. When we specified this for a multi-outlet retail client, it was written into the requirements document before any code was written, precisely because retrofitting it is much harder than building it in.