When a Saudi tech company reaches fifty or sixty paying subscribers, the billing process that worked in the first year starts to show cracks. At twenty customers, a finance or operations person can track subscription renewal dates in a spreadsheet, send invoices manually a few days before the renewal date, and reconcile payments in an afternoon. At one hundred customers, the same approach requires several people working in parallel, and the error rate rises to the point where revenue leaks and customer-experience problems become visible.
Subscription billing infrastructure is not glamorous. Most early-stage tech teams put it off until they have to deal with it, and then they deal with it under pressure during a growth period when the last thing anyone wants to spend engineering time on is billing logic. The decisions made under that pressure tend to be suboptimal, and they are often hard to undo once customers are set up on a particular system.
What follows is how we think about subscription billing architecture at the stage where it actually matters: when manual is no longer viable but complexity has not yet become your primary concern.
The Mechanics That Break First
The first thing that breaks in a manual subscription billing process is renewal date tracking. When customers sign up at irregular intervals, you end up with a renewal calendar that has something due on most business days of the month. The fifty-customer threshold is roughly where the renewal calendar stops being something one person can scan in a morning and starts being something that requires a dedicated process.
The second thing that breaks is proration. Customers who upgrade mid-cycle, pause their subscription, add a seat, or change their plan all generate billing states that are not cleanly handled by a single fixed invoice. For a SaaS product sold on a per-seat or tiered basis, these events happen frequently once the customer base reaches a certain size.
The third failure point is dunning. Subscription businesses have a recurring collections problem that one-time invoice businesses do not: a credit card or bank transfer that fails on renewal is a churned customer unless you catch it quickly and retry. Saudi B2B subscriptions often use direct bank transfer rather than card-on-file, which means failed payments may not fail with an error code. They simply do not arrive. Without a process to identify non-payments within a short window of the renewal date, you end up discovering overdue accounts weeks later.
Subscription Billing on Saudi Payment Rails
Saudi Arabia's payment infrastructure differs from the card-on-file ecosystem that most global SaaS billing tools assume. The dominant B2B payment rail is IBAN bank transfer, and many Saudi business customers prefer to pay by SADAD biller code, which allows them to initiate payment through their bank's corporate internet banking interface without manually entering your IBAN each time.
For subscription billing specifically, this means your renewal process cannot simply charge a stored card. The billing system needs to generate a ZATCA-compliant invoice, deliver it through the right channel, and then reconcile incoming bank payments against outstanding invoices. That reconciliation step is the piece most billing systems built for global card-based markets handle poorly for Saudi clients.
ZATCA's Fatoora e-invoicing mandate applies to VAT-registered businesses. For a Saudi tech company, this means your billing system needs to generate invoices with a UUID, a QR code, and the relevant VAT registration number, and retain the XML representation for audit purposes. Phase 2 of the mandate, which requires integration with ZATCA's portal for real-time or near-real-time invoice reporting, applies to larger taxpayers first. Early-stage companies below the Phase 2 threshold still need to issue compliant tax invoices, but the integration requirement may not yet apply.
Plan Architecture Before You Have One Hundred Customers
One of the highest-impact decisions in subscription billing is how you structure your plans before you have a complicated customer base. Plans that seem simple early on, with flat monthly pricing and one tier, tend to get patched with exceptions as the business grows: a customer who negotiated a discount, a customer on an older price point you grandfathered, a customer who pays quarterly instead of monthly. Each patch makes the billing system harder to manage.
A cleaner approach is to design your plan structure with two or three explicitly named tiers, a defined policy for grandfathering and discounts, and consistent billing cycle options rather than bespoke ones. Discounts should be expressed as percentage reductions on a named plan rather than as custom price overrides. Quarterly billing should be a configured option rather than a manual workaround.
The practical reason this matters is that every exception you encode as a manual process becomes a failure point when that process is not executed perfectly. A customer on a custom price that lives only in a spreadsheet is a customer who gets billed incorrectly when the person who manages that spreadsheet is unavailable.
The Reconciliation Problem
Subscription revenue reconciliation in a bank-transfer environment is more complex than it looks. A customer with two active seats who pays SAR 5,800 for a quarterly renewal does not include a reference to your invoice number unless you explicitly require it, and even then some corporate payers use their own payment reference instead. Matching incoming bank credits to outstanding invoices manually is feasible at twenty customers and unreliable at one hundred.
The structural solution is to assign a unique payment reference to each invoice and communicate it clearly in the payment instructions. SAR transfers through IBAN allow a 140-character payment reference field. If you include a reference like "Stream-INV-2026-0421" in the transfer instructions, and if most customers copy that reference into their transfer, the matching problem becomes substantially easier. Not every customer will do this, but the ones who do not are identifiable by exclusion and can be reconciled in a shorter focused effort.
SADAD integration simplifies this for customers who use it: each payment through SADAD is associated with your biller code and the customer's reference, giving you a cleaner automated match. The setup cost of SADAD integration is real, but for a subscription business with recurring payments from the same customers, the long-term reconciliation benefit is substantial.
Dunning Logic for B2B Subscriptions
A dunning sequence for a B2B subscription should be short, direct, and designed to surface the payment problem before the subscription date passes. Unlike tuition invoices where you might wait 7 to 14 days before the first overdue notice, subscription renewals often have a harder cutoff: access to the product may be suspended at a certain number of days overdue.
A practical sequence for a 30-day payment term subscription might look like this: a renewal notice 10 days before the due date (not immediately actionable, but primes the customer's accounts payable process), a payment confirmation request the day after the due date if no payment is detected, a first overdue notice at day 5 post-due, and an escalation to the customer's primary contact at day 15 if payment has still not arrived. Suspending access before the escalation stage tends to create more support burden than it resolves.
The tricky case is customers who have approved the payment internally but whose accounts payable team is running behind. A direct call or WhatsApp message from the account owner at day 7 or day 10 often resolves these faster than another automated email. Your dunning system should flag accounts at the day-7 mark for that manual outreach rather than relying on further automation.
What Not to Build Yourself
The argument for building subscription billing logic in-house is usually about control or cost. The control argument holds if your billing model has genuinely unusual requirements that no existing tool handles. The cost argument rarely survives a realistic accounting of engineering time. A subscription billing system that handles proration, dunning, ZATCA-compliant invoice generation, bank transfer reconciliation, and plan management correctly takes months to build and requires ongoing maintenance as Saudi regulatory requirements evolve.
We are not saying every company should use an external billing platform. There are cases where internal billing logic makes sense, particularly for companies with pricing models that cannot be expressed through standard billing primitives. But the decision to build should be based on a genuine requirement gap, not on the assumption that building is cheaper or faster than integrating.