Billing and invoicing requests require action from our Billing/Accounts Receivable team.
The following information is helpful to provide to the AR team when transfering tickets, but not required.
Manage Purchases in
CustomersDotEdit tabEdit tabWhen a customer wants to change the contact for current and future purchases.
Note: Billing doesn't have a vetting process, so we need to vet the customer as far as possible before passing the request
Support::L&R::Zuora Contact Change macro to transfer the ticket to AR to
update the bill to and sold to contact in ZuoraSupport will still generate a manual license if new contact wants an updated license. Zuora update is primarily effective for future purchases.
NOTE: The Sold to contact in Zuora usually receives the license, renewal reminders and comms about changes to the subscription (e.g renewal success/fail). The Bill to contact in Zuora will receive invoices as well as renewal reminders.
When billing processes an entity change, billing creates a second Zuora account for the customer, with a different entity than the original.
To identify entity changes, check the Renewal subscription field in a Zuora subscription.
The original (and now cancelled) subscription will point at a Renewal subscription that can be used to search for the new Zuora account.
When an entity change happens at renewal, it can impact how licenses are generated. If you are troubleshooting a license issue, check Zuora to see if there are 2 accounts with different entities to confirm if an entity change took place.
The issue that we will see more often is the renewal license not generated with previous users or trueups. In the event of the license being impacted by the entity change, we can assist with a manual license.
As part of the entity change process,
the Billing team sets the new Zuora account to silent when creating the relevant quote, opportunity, and subscription from the previous account.
The silent account setting results in no Order being created in Customers Portal.
You can confirm that a Zuora account is silent by checking Billing and Payment Info -> Communication Profile.
NOTE: A subscription in the Customers Portal account may be visible but it would be impossible to link it to a group because of lack of an Order entry.
These situations are handled by following the steps in the Billing Entity Change: Associate Subscription issue template.
Console Hacks Deprecation Notice
Following the discussion and decision to be more pushy than hacky using console commands in CustomersDot, this workflow is documented as a temporary workaround only while the Fulfillment team works on integrating Billing entity changes in the product.
The progress on Fulfillment's work can be followed in these reported issues:
This workflow will be removed once the above issues are fixed.
When a Billing Entity Change occurs, there will be two Zuora accounts and two subscriptions; the old subscription would be on the canceled Zuora account, the new subscription would be on the active Zuora account. The newly created subscription will very possibly not have an Order object created for it, because the billing workflow sets the communication profile to silent during creation, which prevents Zuora from making callouts to CustomersDot. An Order is required to link a subscription to a namespace on GitLab, so you will need to create one.
To create an Order and link the namespace to the new subscription:
Zuora account IDMax seats used is reset to current seats in use count. If not, update it using the account_seats function.
Max seats used to their Seats currently in use, because this process does not automatically reset that like it normally would during a renewal. You may need to use discretion here if the customer's max historical seatcount is wildly different from what they are currently paying for.Examples of this workflow:
For the above workflow, you need to locate both of the Zuora accounts in question. The entity change results in a new billing account being created, and the SaaS subscription(s) being recreated on that account.
History tab and you can work from there.A000XXXXX. This can be searched directly in Zuora from the search page on Customer Accounts. Alternatively, the SFDC billing account shows a Zuora ID md5 hash, which you can supply to Zuora by editing this URL: https://www.zuora.com/apps/CustomerAccount.do?method=view&id=ZUORA-ID-MD5-HASH-GOES-HEREIf the above suggestions do not work, either use a different method for locating them, and/or see below on Finding subscriptions.
When creating an order for the new subscription, the create_order_from_zuora function will query the Customer object, look at their Zuora subscriptions, and create the order based on that, so the CustomersDot account must be pointing at the new Zuora account. If it is not, make sure you are looking at the right account, and if you are, then just update the Zuora account field to the correct ID. Billing team usually handles that, though.
Easily identify the old/cancelled subscription via console:
pp Order.find_by(subscription_name: "old-subscription-name")
id: 123456,
customer_id: 123456,
product_rate_plan_id: "2c92a00d76f0d5060176f2fb0a5029ff",
subscription_id: "MD5-HASH-HERE",
subscription_name: "old-subscription-name",
start_date: timestamp,
end_date: timestamp,
quantity: 216,
gl_namespace_id: "1234567",
gl_namespace_name: "group-name",
amendment_type: "RemoveProduct",
trial: false,
last_extra_ci_minutes_sync_at: nil,
zuora_account_id: "MD5-HASH-HERE",
You can also try just locating all subscriptions ever linked to the group namespace:
pp Order.where(gl_namespace_id: xxxxxx)
...
...
customer_id: 123456,
product_rate_plan_id: "2c92a00d76f0d5060176f2fb0a5029ff",
subscription_id: "MD5-HASH-HERE",
subscription_name: "old-subscription-name",
...
...
You may notice that the end_date is the renewed end_date, because it was renewed and then cancelled, so don't get tripped up by that. The important parts are the subscription_name, and if needed, the customer_id, subscription_id, and zuora_account_id.
Cancelled. You can use both of these to locate the Zuora accounts if you haven't already. Generally, the subscription with the higher ID number will be the new one. Alternatively if you can locate the relevant quotes in SFDC that have their status as Sent to Z-Billing, the quotes will have the Zuora Subscription ID md5 hash.Zuora Subscriptions tab. If not, either there exists another CustomersDot account (try searching by just contact email domain), or possibly the CustomersDot account wasn't updated.Once you locate a subscription_id you can directly access the subscription by editing this URL: https://www.zuora.com/apps/Subscription.do?method=view&id=ZUORA-ID-GOES-HERE.
In Zuora, the old / cancelled subscription may also have a field Renewal subscription, which lists the name of the newly created subscription.
When a customer wishes to cancel their subscription and they are not interested in waiting until the subscription expires.
General::Accounts Receivable macro to transfer the ticket to AR to
process the cancellation. They will reply to the customer once done and issue
a refund if applicable.There is currently no ability to downgrade a subscription from a self-service perspective.
Plan downgrades should only be done at renewal. However, if the customer purchased the wrong plan as a new subscription, send
the request to the AR team by selecting the Accounts Receivable macro and ask that the incorrect purchase be cancelled so that a new subscription can be purchased on the Premium plan.
If a SaaS Ultimate customer would like to renew for a Premium plan, advise them to purchase a Premium subscription and link their group to the new subscription. Ensure that they have set their Ultimate subscription to expire/cancel on the end date.
If a Self-managed Ultimate customer would like to renew for a Premium plan, refer them to Sales for assistance.
GitLab provides subscriptions on an annual basis which are not eligible for termination / refund for a customer's convenience. When a refund request is made, our billing team uses this internal guide (GitLab internal) to determine if a refund is appropriate.
General::Accounts Receivable macro to transfer the ticket to AR to advise and process if relevant. They will reply to the customer once done.Note: we cannot do partial refunds, so when a refund is requested, the whole subscription will have to be cancelled and refunded. See Renewal reversal for accidental renewal scenarios.
Check first if the invoice is available in CustomersDot.
General::Accounts Receivable macro to transfer the ticket to AR to
process the request. They will reply to the customer once done.When a customer wishes to modify their invoice for tax or administration purposes.
General::Accounts Receivable macro to transfer the ticket to AR to
process the request. They will reply to the customer once done.Use the General::Accounts Receivable macro to transfer the ticket to AR to
process the request. They will reply to the customer once done.
When a customer wishes to remove their credit card from their CustomersDot account.
General::Accounts Receivable macro to transfer the ticket to AR to
process the request. They will reply to the customer once done.When a customer has accidentally renewed twice or mistakenly.
General::Accounts Receivable macro to transfer the ticket to AR,
they will reverse the renewal so that the subscription is in the same state
as before the renewal and refund the renewal if applicableWhen a customer has a payment limit on their card, preventing a single payment for the full amount of their purchase, Billing is able to charge the card in "batches".
General::Accounts Receivable macro to transfer the ticket to AR to
process the request. They will reply to the customer once done.Note that in some cases, the total amount is too large to charge in 2 batches and Billing might request that a sales-assisted order is done instead. If you're unsure whether this would be the case, you can tag [at]Billing-ops in Chatter on the Account or Opportunity in SFDC to double-check with them.