Recurring subscriptions sound simple until they cross borders. A customer in Malaysia upgrades mid-cycle; your platform prorates the charge. But which tax rate applies—the old plan's or the new one's? Do you invoice the delta as a separate line item, or fold it into the next billing cycle? And when a Singapore customer requests a refund for unused time, do you reverse the GST on a partial month, or issue a credit note? These aren't edge cases. They're core to any subscription business operating in Malaysia, Singapore, and Indonesia. The problem: most billing platforms (Stripe, Paddle, Zoho Billing) handle proration and tax separately, leaving you to stitch the logic together. Add regional SST/GST rules, exemption thresholds, and e-invoicing requirements, and most teams end up with either incorrect line-item tax coding or reconciliation chaos. This guide walks through the actual math, platform capabilities, and compliance checkpoints. SST, GST, and the threshold trap Malaysia's Service and Sales Tax (SST) applies to B2B and B2C services, but only above RM5,000 annual turnover per service category. Singapore's Goods and Services Tax (GST) kicks in at SGD1 million revenue annually per supplier. Indonesia's Value Added Tax (PPN) applies to most services, with exemptions for certain categories. On paper, it's clear. In practice, a SaaS vendor tracking multiple customers across jurisdictions faces a moving target. For recurring billing, the trigger is when the invoice is issued, not when payment clears . If you're billing monthly, each invoice gets the tax rate that applies on that invoice date. A Malaysian customer might fall below the SST threshold in January but cross it in February—and your invoices must reflect that shift on the February line items. The compliance requirement is stricter than the math: every invoice line must show: The base amount (pre-tax) The tax code and rate applied The total tax amount The line-item total When you prorate a mid-cycle change, you're creating a partial line item. That partial must carry the same tax coding discipline as a full month. Most platforms fail here because they treat proration as a discount or credit, not as a taxable line-item event. Proration logic: when and how to split the math A customer on a RM300/month plan upgrades to RM500/month on day 15 of a 30-day cycle. The proration delta is RM200 for 15 days = RM100. That RM100 is taxable as a separate service delivery—it's not a discount, it's a charge for the incremental service from day 15 to day 30. Here's the correct structure: Original line item: RM300 base, 6% SST, RM18 tax, total RM318 (covers the full month, but you issue a credit for the unused days) Proration credit: RM100 credit (15 days unused), 6% SST credit RM6, total credit RM106 Upgrade line item: RM100 base (15 days at new rate), 6% SST RM6, total RM106 Invoice total: RM318 − RM106 + RM106 = RM318 (no net charge if you're pro-rating fairly) The catch: some platforms (Stripe, for instance) calculate proration as a single line-item discount, not as separate credit and charge. That works for net cash flow, but your tax reporting and e-invoicing will show misaligned line items. Paddle handles this more cleanly with itemized credits and charges. Zoho Billing requires manual line-item adjustment if you want full separation. Pro tip: If your platform doesn't support split proration line items, issue the prorated charge as a separate invoice line on the next billing cycle, not mid-cycle. It's easier to reconcile and harder to dispute. Mid-cycle downgrades and refund tax reversal A Singapore customer on a SGD100/month plan downgrades to SGD50/month on day 10, then cancels entirely on day 20. You owe them a refund for the unused portion (days 20-30). That refund must reverse not just the cash, but also the GST. The math: Original invoice: SGD100 base, 9% GST SGD9, total SGD109 (issued day 1) Downgrade day 10: RM50 base, 9% GST SGD4.50, total SGD54.50 for the remainder (days 10-30) Refund day 20: SGD50 (10 days unused) base, GST reversal SGD4.50, net refund SGD54.50 The compliance issue: the original invoice already posted GST to your tax account. When you issue a refund, you must issue a credit note , not a simple refund. The credit note reverses the tax line-by-line. Your accounting software (Xero, QuickBooks, Zoho Books) must code the reversal correctly, or your GST reconciliation will show an imbalance on your next quarterly return. If you use Orin's invoicing module , you can track credit notes separately and flag them for tax reversal. Most SaaS platforms don't surface this distinction—they treat refunds as cash adjustments, not tax adjustments. That gap kills your compliance. Key takeaway: Refunds are not refunds—they're tax-reversing credit notes. Issue them on the same platform that generated the original invoice, and code them explicitly as credits, not discounts. Platform capability gap: Stripe vs. Paddle vs. Zoho Billing Stripe: Handles proratio