Running a subscription business across Malaysia, Singapore, and Indonesia on one customer record breaks most billing systems. Each territory taxes differently—SST in Malaysia, GST in Singapore, PPN in Indonesia—and they don't align to calendar months. Mid-cycle changes, prorations, and currency swings create GL splits that either reconcile perfectly or leave you chasing ₹5K phantom differences for weeks. This playbook shows you how to build recurring billing that handles all three regimes, prorates correctly, calculates tax at invoice time, and produces audit-ready GL entries that your accountant won't question. Why standard recurring billing fails across three tax zones Most SaaS billing platforms assume one tax rate per customer. They apply tax to the full billing period upfront, then struggle when: A customer in Malaysia signs on the 15th; you need to prorate from day 15 to month-end, then apply SST only to that prorated amount. Mid-cycle, the customer adds a second product. Now one invoice has two line items at different tax rates, both prorated, both calculated at invoice time. The customer pays in USD but operates in MYR. Exchange rate moves 2% overnight; tax recalculates on the converted amount, not the original. Your GL needs to split the invoice into revenue, SST payable (Malaysia), GST payable (Singapore), and PPN payable (Indonesia)—not a single tax line. Each of these is solvable, but only if you build the logic layer yourself or use a platform that lets you define regional tax rules without writing code. Step 1: Define tax rules by territory and invoice date Start by codifying your tax rules as configuration, not code. Store them in a structured format that your billing engine can read at invoice time: Malaysia SST: 6% on services, effective from invoice date. No reduced rates for early-stage companies (unless your agreement carves one out). Singapore GST: 9% on all supplies, exempt only if customer holds a valid GST exemption certificate on file. Indonesia PPN: 12% standard rate. Calculate on the net amount before any discounts, prorated to the day. Store these as a rule table, indexed by territory and invoice month: Tax rules must lock to invoice date, not billing date. If a customer's invoice triggers on the 1st of the month but the rule changes on the 15th, only invoices dated the 15th onward use the new rate. In Orin's billing module , you can define custom tax profiles per customer and region. At invoice generation, the system reads the customer's territory and invoice date, retrieves the matching rule, and applies it to the prorated base amount. Step 2: Calculate the prorated base before tax Prorating is not a linear division. You must: Count billable days. From subscription start (or the billing period start) to the end of the period. Use calendar days, not business days. If a customer signs on March 15, 2025, and you bill monthly on the 1st, proration runs from March 15 to March 31 = 17 days. Divide the monthly price by the month's total days. For March (31 days), the daily rate is price ÷ 31. Multiply by billable days. 17 × (price ÷ 31). Round to two decimals. Use banker's rounding (round half to even) to avoid systematic bias over thousands of invoices. Example: A ₹30,000/month subscription starts on March 15 (17 billable days in March). Daily rate: ₹30,000 ÷ 31 = ₹967.74 (rounded) Prorated base: ₹967.74 × 17 = ₹16,451.58 This prorated base is what tax applies to, not the full monthly price. When a customer adds or removes a service mid-cycle, calculate a separate prorated line for the change. Invoice shows: Original service, prorated for full month: ₹16,451.58 Add-on service, prorated from day 20 to 31: ₹5,200.00 Subtotal: ₹21,651.58 Tax then applies to the subtotal, not each line separately (unless your contract specifies otherwise). Step 3: Apply tax rules at invoice time, not at quote time The moment you generate an invoice, you must: Read the customer's current territory from their contact record. (This can change if they move or relocate operations.) Look up the tax rule for that territory on the invoice date. Retrieve the customer's tax exemption status (GST exempt in Singapore, SST exemption in Malaysia, etc.). Apply the rule to the prorated subtotal. Calculate tax amount: subtotal × rate (if not exempt). Round tax to two decimals using the same rounding method as proration. This logic must run every time an invoice generates—not once at contract signature. If a tax rate changes, old invoices don't recalculate; new invoices use the new rate. In Orin's built-in AI automation , you can define a recurring billing rule that fires on a schedule (e.g., the 1st of each month) and uses conditional logic to look up the tax rule, prorate the amount, and apply tax—all without touching a spreadsheet or manual calculation. Step 4: Map invoice lines to GL accounts by tax territory This is where most billing systems fail audits. A single invoice across three territories must split into mult