Gain insight into overseeing a range of components, including customers, subscriptions, invoices, credit notes, quotes, payments, and more, along with their interconnected aspects throughout the Customer Transfer procedure.
Supervising Customer & Subscription, Status and IDs
Supervising Customer & Subscription, File Attachments and Comments
Supervising Customer, Additional Contacts
All additional contacts associated with the customer will be included in the transfer to the destination business entity. Nevertheless, it's essential for the user overseeing the customer transfer to review and validate these contacts, as some may not be relevant or necessary in the new business entity.
The user conducting the customer transfer may need to make adjustments or remove specific contacts to ensure that the data remains accurate and up-to-date. Furthermore, reaching out to the customer for confirmation regarding which contacts should be transferred to the new business entity can be beneficial.
Supervising Customer, Tax Registration Numbers
Customer's tax registration numbers associated with the customer will be included in the transfer to the destination business entity. However, it's essential to note that you are responsible for the accuracy of customer information, including their tax ID number, after the transfer. If required, tax registration numbers can be updated to comply with the destination business entity's regulatory requirements.
Supervising Subscription, Contract Terms
Each contract term is exclusively linked to a single subscription and a subscription can only have one active contract term. Contract terms that have ended, completed or been terminated / cancelled will not be transferred to the destination business entity alongside the subscription.
Supervising Customer, Consents
During the transfer to a new business entity, the consent information associated with customer profiles will also be migrated. Post-transfer, it is your obligation to ensure that all customer details, particularly consent fields, are kept up-to-date and accurate.
Supervising Invoice, Credit Notes, Quotes Status and IDs
Promotional / Account Credits
Promotional credits, such as referral bonuses and cashback, can be applied to invoices. These credits are seamlessly transferred when a customer is moved, ensuring their balance and credit history are preserved for use in the destination business entity.
Refundable Credits
Refundable Credits are subjected to validation as part of the customer transfer process.
Un-billed Charges
Un-billed Charges are subjected to validation as part of the customer transfer process.
Excess Payments / Unused Payments
Excess Payments are subjected to validation as part of the customer transfer process.
In Chargebee, you have the option to either issue a refund or record offline refunds. In both cases, Credit Notes are automatically generated for the refunded amount. However, it's important to note that Credit Notes are subject to validation as part of the customer transfer process.
Payment Methods
Payment methods, such as cards, that are currently linked to the customer in the source business entity will be duplicated and associated with the customer's record in the destination business entity.
If there are any outstanding or unpaid invoices in the source business entity, you can utilize the same card or payment method within the source entity to settle them.
Tokens
Given that the Payment Methods linked to the customer in the source business entity will be transferred to the destination business entity and associated with the customer's record there, it is appropriate to transfer tokens along with customer data.
Please be aware that the token ID will remain active and functional within the source (original) business entity even after the transfer, as well as in the destination business entity. This should be taken into account for continued operations and user access.
Auto-Collection (Setting)
In Chargebee, there is an important behavior regarding auto collection. When a new card is added, auto collection changes from Off to On, even for deprecated records (those transferred from the source business entity). Auto collection is turned Off when the card is deleted. To turn off auto collection in such cases, it's necessary to remove the card, but this should only be done after clearing all outstanding charges in the source business entity. This information is crucial for users to effectively manage auto collection in these situations.
To enable subscription Auto Collection when adding a payment method, set Auto Collection at the subscription level to "Use Customer's default." Otherwise, with "Always Off," you must manually charge customers.
Transactions
Events
As part of the customer transfer process, a new event named 'Customer Business Entity Change' will be created in both the source and destination entities. This event will include essential details such as the "from" and "to" entities, the reason code for the transfer and the transfer date.
Historical event data for customers who have been transferred to a different business entity will be retained in the source business entity. There will be no changes to the business entity name in historical events for customers who have moved out of that business entity. Any subsequent events related to the customer will be recorded within the new business entity following the transfer.
Email Logs
All historical email logs will be preserved in the source business entity for customers who have been transferred to a different business entity.
Understand the procedures for managing various workflows, particularly in the context of transferred customers or subscriptions. This pertains to operations within the source business entity and extends to subscriptions in the destination entity awaiting renewal and cloning. The full suite of processes becomes unrestricted post-transfer, following the successful cloning or migration of all customer and subscription information to the destination business entity.
Billing for Non-Metered and Metered Subscriptions During Customer Transfer
In this scenario, we have two types of subscriptions: non-metered and metered. The key difference is in how they are billed.
Let's break this down with an example:
August 7:
Entity E1:
Customer C1 was created
Subscription S1-I1 was created as non-metered
Subscription S1-I2 was created with metered components
Invoice V1 was generated
S1-I1 was billed the period from Aug 7 to Sept 7
S1-I2 no charges
Usage was added to S1-I2 during this time
August 21:
The transfer of Customer C1 from Entity E1 to E2 was initiated
Entity E1:
Customer C1 was cloned and its status was updated to "Transferred"
Subscription S1 (I1+I2) was active and waiting for the next renewal
Entity E2:
September 7:
Entity E1:
Customer C1 with the status "Transferred"
Subscription S1 (I1+I2) was cloned and its status was updated to "Transferred"
Entity E2:
Customer C1 and subscriptions S1(I1+I2) were active and renewed
Invoice V2 was generated
S1-I1 was billed for the period Sep 7 to Oct 7.
S1-I2 had usage and charges from Aug 7 to Sept 7, since the invoice was issued against E2. Revenue recognition would be under E2.
October 7:
Entity E2:
Customer C1 and subscriptions S1 (I1+I2) were active and renewed again.
Invoice V3 was generated.
S1-I1 was billed for the period Oct 7 to Nov 7.
S1-I2 had usage and charges from Sep 7 to Oct 7
In summary, this example demonstrates how billing and revenue recognition work for non-metered and metered subscriptions when a customer is transferred between different entities.
You cannot use Subscription Amendments and the MBE Customer Transfer feature at the same time.
Scenarios for merging customers when one is deprecated due to Business Entity Change and the other isn't, in the same business entity:
In summary, any operation involving a deprecated customer as either the source ('from') or the target ('to') customer is not allowed.
Deprecated resources such as Customers and Subscriptions that have already been transferred to another business entity will not appear in filters on the user interface. This is because we have provided an easier way to access these resources directly from the user interface, through the History tab of the Customer Details section once it's moved to the destination business entity. This ensures a streamlined and more user-friendly experience.
Manual designation of a customer as fraudulent is not possible until Chargebee's fraud detection system identifies the customer record as 'Suspicious.' When a customer is flagged as 'Suspicious' by Chargebee on the Customers page, such customers are not restricted from the transfer process. However, they will be clearly highlighted on the Transfer Customer page, and it is at your discretion whether to proceed with the transfer for these customers or not.
As mentioned in the previous section, customers who belong to an account hierarchy cannot be transferred across entities. It's important to note that transferred resources, specifically customers who have already been transferred to another business entity, cannot be included in the account hierarchy of the source business entity.
In situations where the site operates under one timezone and individual business entities have their specific overridden timezones, the timezone of the destination entity will be applied to transferred customers and their related resources. This aligns with the specific timezone settings of the applicable business entity.
Timezone Considerations in Transfer Process:
Initial:
Post-Transfer:
Dunning employs Chargebee's Smart Retry system to attempt payment collection on unpaid invoices at dynamically determined intervals. This process involves scheduled retries based on your configured settings.
Within the dunning settings, there is an option to define a final action if the last payment attempt fails. The choices include cancelling the subscription and marking the invoice as unpaid, or opting to keep the subscription active.
When dunning is active for a site and applicable to a customer who is being transferred between business entities, the configured final dunning action will occur after the subscription is renewed and cloned in the destination business entity.
It is important to note that if the dunning period configured is longer than the subscription renewal period, the timing of the final dunning action may be extended. For example, if the final dunning action would typically occur within one billing cycle, for a transferred customer, it might only take place after two billing cycles in the destination business entity post-transfer.
Chargebacks, which arise when customers contest a charge with their bank, can occur outside of your control. It's vital for you to have a strategy in place for addressing chargebacks, particularly when they involve your customers who have been moved to a different business entity. You may wonder how to proceed with chargebacks that occur post-transfer, considering that customers cannot retain an invoice in Entity A (the source) while having a corresponding credit note or refund transaction in either the same Entity A (the source) or in Entity B (the destination), particularly if the associated subscriptions have been transferred or are no longer active. To navigate these events, you need to follow some essential steps to manage these scenarios.
Here's what you should consider:
Important:
Adhering to these recommendations empowers you to adeptly navigate chargebacks that might surface post-customer transfer in the source business entity. This approach upholds transparency and accountability at every juncture.
It's important to emphasize that this is a consultative process integral to chargeback management throughout and after the customer transfer process in the source business entity. By adopting these practices, Chargebee effectively mitigates any potential liability, recognizing that we are offering a workflow within our product for the transfer process while acknowledging our limited control over chargeback events.
The Estimates API plays a crucial role in calculating the potential outcome of a purchase before finalization. This API provides important information such as anticipated invoice totals, the date of the next billing cycle, and any charges that have not yet been billed.
For instance, when you are planning to update an existing subscription, it is recommended to utilize the Estimates API beforehand to ascertain critical details. These include the charge amount expected for the customer and the resultant status of the subscription post-update or creation.
It is essential to note that the use of the Estimates API is not permitted in the following scenarios:
During the transfer workflow, we will limit the ability to reverse payments for invoices that have been paid and retained in the source business entity. This is done to maintain a clear record of all previous payment reversal transactions in the source business entity.
From Chargebee's perspective, we will restrict the ability to reverse payments on invoices that have been paid and retained in the source business entity. However, we want to provide some recommendations for you to manage such scenarios effectively:
This information will be valuable for you to efficiently manage the payment reversal process in case it becomes relevant during customer transfers to the source business entity.
Before initiating a customer transfer, it is advisable for you to ensure that partially paid invoices are fully paid and marked as "Paid" in the source business entity. This practice has several benefits:
Ensuring that partially paid invoices are settled before transferring customers enhances the overall efficiency of the customer transfer process and maintains the integrity of financial records. This practice can help you seamlessly transition your customers across entities with minimal complications.
When considering the deletion of a customer or subscription record within the context of customer transfer across entities, please be aware of the following guidelines:
When managing personal data during customer transfers between entities, adhere to these protocols:
In the Source Business Entity: Personal data clearance is permissible for customer records that remain in the source entity post-transfer, typically retained for auditing. This can be done even after the customer has been moved to the destination entity.
In the Destination Business Entity After Completion of Transfer: After a successful transfer, where customer and subscription records have been fully cloned or moved to the destination entity, you are authorized to clear personal data as needed
When considering bulk operations for the various Chargebee components within the context of customer transfer across entities, please keep the following guidelines in mind:
We encourage users to be mindful of these guidelines when executing bulk operations and to ensure that resources are in the desired state before initiating any bulk actions.
When utilizing the feature to backdate subscriptions and invoices on your MBE enabled Chargebee site, it is important to adhere to specific guidelines in the scenario of customer transfers between entities:
In the context of an MBE enabled Chargebee site, certain protocols must be followed for reactivating canceled subscriptions, especially when customers are being transferred between entities:
Regenerating invoices is subject to certain conditions in the context of customer transfers between business entities:
Remember, regeneration is intended for recurring invoices only. To add new charges, you should create a new invoice using the "Add Charge" feature rather than regenerating an existing one.
Upon the user's completion of a hosted page, and once processed by Chargebee, the page's status will update to 'succeeded'. To acknowledge a hosted page is to confirm the successful import of customer details from Chargebee into your own system, indicating readiness for order fulfillment. The acknowledgment API call is used to mark a hosted page in a 'succeeded' state as 'acknowledged'.
As this feature is infrequently used, it has been excluded from the customer transfer validation processes, thus permitting its use with resources in the source entity that are considered deprecated post-transfer.
It should be noted, however, that retrieving or listing hosted pages that remain in the source entity may not function as intended. This is because the hosted pages are designed to reference records in the destination entity due to their reliance on external IDs.
When preparing for customer transfers, it's essential to address the setup of offline payment methods:
Customization for Specific Business Entities: Offline payment methods can be tailored to each business entity. Ensure that the destination entity to which a customer is being transferred has suitable offline payment options set up if the originating entity uses them.
Ensuring Payment Continuity: Verify that the destination entity supports all offline payment methods utilized by the transferring customers. This may involve enabling specific payment options or updating customer payment preferences to align with the available methods in the new entity.
By ensuring these steps are taken, customers can continue to use their preferred offline payment methods without interruption following their transfer.
When sending manual emails to customers and related subscriptions that have been moved to a destination entity and now exist as deprecated resources in the source entity, be aware of ID changes:
ID Changes for Deprecated Resources: The original customer and subscription IDs assigned at creation will differ from those in the source entity. Post-transfer, these resources are linked to new, randomly generated IDs.
Reference IDs for Cloned Entities: The IDs used at the point of customer and subscription creation are retained by the cloned counterparts in the destination entity to ensure seamless continuity.
Note that for customers who have been transferred, the IDs referenced in emails originating from the source entity post-transfer will differ.