Decide access timing and billing timing separately
An annual SaaS customer adding seats creates two decisions: when the extra people can use the product, and when the customer pays for them. Those dates can match, but they do not have to. A renewal adjustment can allow access now under an agreed policy; an immediate charge can leave the new seats pending until payment is confirmed.
Choose the policy that matches the customer contract, merchant capability and operational capacity. Immediate proration can collect money for the remaining term. Renewal billing can make the current period predictable. Approval can accommodate procurement or risk checks. None automatically proves fairness, reduces churn or establishes how revenue should be recognised in your accounts.
The practical output below is a seat-change billing policy brief. It makes effective dates, invoice behaviour, access conditions and recovery actions explicit before a customer adds users. The examples are fictional design choices, not Symaxx client results or provider defaults.
Option 1: immediate prorated additions
Under this proposed option, the customer sees a quote for the remaining subscription term and approves it before the product commits the change. Decide whether the invoice is collected immediately, becomes payable on agreed terms, or follows a different verified collection procedure. A calculated proration is not proof of payment.
Stripe documents quantity changes, previewing prorations and configurable billing behaviour. By default its calculation uses seconds; positive prorations are not automatically billed immediately, and negative prorations are not automatically refunded. An unpaid current invoice can also cause a credit for time not yet paid for. Stripe proration behaviour
For an eligible integration, preview the actual update and deliberately choose its invoicing and payment behaviour. Record the quoted effective date and relevant subscription version. If those change before confirmation, recompute the quote or ask for confirmation again rather than applying a stale amount silently.
The benefit is a defined charge for the remaining term. The cost is more state to manage: pending quotes, payment authentication, failed collection, corrections and access recovery. Test those paths before presenting an instant seat-add promise.
Option 2: change billing at renewal
A renewal policy needs a clear access rule. One possible policy allows approved additions immediately without charging for the current remainder, then prices the next full year at the new seat count. Another keeps additions pending until renewal. These are different promises and should not share the same vague label.
If additions receive current-term access without an extra charge, the business intentionally absorbs that remainder under the contract. The next annual invoice is not a backdated charge for those free months unless a separately disclosed agreement says otherwise. Store the scheduled seat count and renewal quote so the customer can review the next commitment.
Removing seats also needs a decision. You might reduce active access immediately while keeping the committed annual quantity until renewal, or approve a credit under a different contract. Do not assume that disabling a user entitles the customer to an automatic cash refund. Explain access, committed quantity and future billing separately.
Option 3: require approval
Approval can be useful when an enterprise customer needs a purchase order, a requested increase exceeds an agreed spending limit or the subscription has unresolved billing. Specify who may approve, what they approve and how long the quote stays valid. Approval is evidence of consent; it does not prove that payment completed.
Use a pending state while the request is reviewed. Tell the customer whether the existing seats remain usable and what happens if approval is declined or delayed. Define an escalation route rather than silently granting extra access when the reviewer is unavailable.
A proposed threshold such as a 20% increase is an example business rule, not a provider standard. Compare the requested amount and customer agreement rather than treating a percentage as a complete fraud test. Reviewers should see the old quantity, proposed quantity, effective dates and price impact before deciding.
Verify the actual merchant product
Stripe lists South Africa through its extended network and links Paystack. That is not evidence that a South African Paystack merchant has direct Stripe Billing, Connect or Stripe subscription APIs. Verify the legal entity, account and actual product contract before relying on the Stripe example above. Stripe country and extended-network availability
Payfast advertises subscriptions, flexible recurring schedules and subscription management controls. That page alone does not establish the exact seat-proration, invoice-preview or notification behaviour needed here. It also does not prove that those capabilities are absent. Verify the current merchant integration and test the operation you intend to offer. Payfast subscriptions
If the merchant product cannot support the chosen procedure, redesign the billing policy or verify another supported invoicing approach. Do not describe custom logic as a native provider feature, and do not switch providers merely because a feature page omits implementation details.
Practical output: seat-change billing policy brief
Use this proposed template to make the decision reviewable. Choose one approved policy for each event rather than implementing all alternatives automatically.
| Event | Effective access | Billing decision | Customer confirmation | Recovery rule |
|---|---|---|---|---|
| Add seats with immediate charge | New seats pending until the agreed payment or credit condition is confirmed | Preview the remainder charge and deliberately invoice/collect | Quantity, amount, date and renewal total | Preserve existing seats if the new charge fails |
| Add seats under renewal policy | Immediate approved access or pending until renewal, as explicitly selected | Record next-term quantity; disclose current-term treatment | Access start and next annual total | Reconcile scheduled quantity before renewal |
| Remove seats | Disable nominated users at the approved date | Apply agreed credit or renewal-only reduction | Which users lose access and any credit/refund terms | Retain audit history and correct accidental removals |
| Current invoice unpaid | Existing policy continues; request may need review | Resolve the unpaid-period and credit rule first | Explain why the quote is pending | Avoid issuing unearned credit or collecting the same obligation twice |
| Approval required | Pending proposed change | Store approved quote and conditions | Authorised approver accepts the exact request | Expire/requote stale approvals |
| Payment authentication or collection fails | Follow the approved extra-seat grace policy | Record the unresolved attempt | Explain action needed without claiming success | Reconcile the original charge before retrying |
The brief should also identify the policy owner, supported merchant procedure, active pricing version, rounding convention, currency and tax treatment, any grace period, approval validity and refund authority. Record which rules were tested and which still need verification.
Worked calculation: two added seats
Suppose a fictional annual plan costs R1,200 for ten seats, or R120 per seat for a full year. Two seats are added after 100 complete days of an assumed 365-day term. A proposed daily policy leaves 265 days:
2 × R120 × 265 ÷ 365 = R174.246575…, rounded once at the end to R174.25.
Do not round R120/365 to R0.33 first; that changes the result. This example assumes the stated day boundary, currency rounding and no tax or discount adjustments. A provider using exact timestamps may return a different preview. Compare that actual preview with the policy rather than forcing the illustrative amount onto an invoice.
Under a proposed renewal policy that gives the remainder free, no R174.25 charge is made now. If twelve seats remain for the next full year at the same unit price, the next annual base amount is R1,440. The R240 increase describes that next full term, not a retroactive charge for the current remainder.
Worked hypothetical implementation: three added seats
Imagine a South African SaaS company whose customer adds three seats after 150 complete days of the same assumed 365-day term. The provider is intentionally unspecified until merchant eligibility and the exact billing integration are verified. The proposed daily charge is:
3 × R120 × 215 ÷ 365 = R212.054794…, rounded once to R212.05 before any separately applicable adjustments.
- A permitted account administrator requests the new quantity. The server checks the customer workspace and current subscription version.
- The system calculates or obtains the verified provider preview, including effective time and required adjustments. It shows the customer the amount and next renewal total.
- The customer approves the exact quote. A stable change ID prevents two clicks or workers from creating two intended changes.
- The billing integration performs the supported update and chosen invoice/collection procedure. The application records each confirmed result rather than treating the API request as success.
- Extra seats are granted only when the agreed payment or approved credit condition is satisfied. The original seats follow their existing entitlement policy.
- Support can inspect the approved quote, provider invoice and entitlement history if the customer reports a mismatch.
Stripe's subscription events describe invoice and subscription activity; a subscription update does not itself prove that an added-seat invoice was paid. Map the applicable documented event or confirmed readback to the approved access rule. Stripe subscription webhooks
If the gateway accepted a change but the local response was lost, reconcile that original change and invoice before repeating the operation. If the invoice is paid but provisioning failed, repair the entitlement using the existing paid-period evidence instead of issuing another charge.
Acceptance and recovery worksheet
| Test | Expected result | Evidence retained |
|---|---|---|
| Duplicate request or concurrent workers | One intended change and one charging identity | Stable change ID and enforced unique record |
| Quote becomes stale before approval | Requote or explicitly confirm the changed amount | Original/current subscription versions |
| New charge fails | Existing paid seats follow policy; added seats follow the disclosed pending/grace rule | Invoice state and access decision |
| Payment succeeds but worker crashes | Recover the existing change without charging again | Provider invoice and processing record |
| Customer removes seats after an unpaid invoice | Approved unpaid-period/credit rule is applied | Reviewed invoice and policy version |
| Two additions occur before renewal | Final quantity and charges reconcile without losing one request | Ordered change history and confirmed totals |
| Customer changes a trial or discount | Quote is verified for that combination | Provider preview and approved terms |
| Removal would disable the account owner | Require an appropriate alternative administrator or review | Authorised account decision |
Do not assume that ending every trial creates a credit or that a credit means a cash refund. Test the actual trial, discount and unpaid-invoice combinations supported by your merchant product. Local arithmetic tests validate the example calculation; provider readback and entitlement tests validate the integration.
Make the customer decision understandable
Show current seats, proposed seats, access timing, today's charge and the next renewal amount together. Explain any approval or payment condition before confirmation. Avoid presenting a success screen while the gateway operation is still unresolved. A pending screen should show the next action and a support route.
Use the user journey glossary to map request, consent, payment and access. The CMS vs custom development guide helps scope custom account behaviour, and the website maintenance cost guide helps plan ongoing billing support and reconciliation.
If your business needs help choosing and verifying a seat-change policy, explore SaaS pricing models and SaaS development services. To turn the brief into a tested account workflow, get in touch.
Frequently asked questions
Must extra seats be charged immediately?
No. Select an approved policy that states both access and billing dates. Immediate collection, next-term billing and approval can each work when the customer promise and integration support them.
Does changing the subscription quantity prove the customer paid?
No. Confirm the applicable invoice/payment condition before granting access that your policy ties to payment. Keep billing and entitlement records separate.
Can we promise a refund whenever seats are removed?
Only if the approved terms and verified operation support that promise. A credit, a future reduction and a cash refund are different outcomes.