About Resources and Managing Associated Workflow Processes 

Related Resources 

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.

Customer and Subscription 

Supervising Customer & Subscription, Status and IDs

• Customers designated for transfer must be in the 'Active' status by default.
• For subscriptions linked to the customer undergoing transfer, they should fall into one of the following categories:
  • Active: Active subscriptions will be cloned at their renewal time in the destination business entity, generating a new invoice for that term in the destination business entity.
  • Future: Future subscriptions will be cloned at the start of the subscription period in the destination business entity, creating a new invoice for that term in the destination business entity.
  • Pause: Paused subscriptions will be cloned in the destination business entity at their scheduled resumption date, resulting in a new invoice for that term in the destination business entity.
  • Metered: Metered subscriptions will be cloned at their renewal time in the destination business entity, leading to the creation of a new invoice for the previous term in the destination business entity. For metered subscriptions, charges are applied at the end of the billing term.
• Subscriptions in Non-Renewal, Cancelled and Inactive Status cannot be transferred across business entities.
• Subscriptions in In-Trial status are subjected to validation as part of the customer transfer process.
• Customer and Subscription IDs remain unaltered throughout the transfer process. This preserves data integrity and system continuity. Consistent IDs are maintained across entities, ensuring seamless data transitions. This approach avoids disruptions in reporting and downstream systems for both the source and destination entities. The technical implementation involves maintaining a mapping table that records the relationship between the original IDs (randomly generated) in the source business entity and their corresponding IDs (retained from the original) in the destination business entity.

Supervising Customer & Subscription, File Attachments and Comments

• By default, file attachments and comments at the customer and subscription level will remain in the source business entity where they were originally created. However, these attachments and comments will remain accessible to specific users within the source business entity after the transfer is completed.

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.

Invoices, Credit Notes and Quotes 

Supervising Invoice, Credit Notes, Quotes Status and IDs

• Please note that all financial records, including invoices, credit notes and quotes, are not part of the customer transfer process.
• Any 'Refund Due' credit notes will remain in the source business entity and can be applied to invoices within that same business entity. New credit notes will be generated after the transfer is complete and will be associated with the newly generated invoices in the destination business entity.
• Quotes marked as 'Open' and 'Accepted' are subjected to validation as part of the customer transfer process.
• Previously generated invoices, credit notes and quotes are not part of the customer transfer process, so their IDs remain unaffected. However, when a customer and its subscription are moved to a destination business entity, the destination business entity's sequence for generating new invoices, credit notes and quotes will be utilized.

Customer Balances 

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.

Unbilled Charges

Unbilled 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.

Refunds 

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.

Payments and Transactions 

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

• Authorization: These transactions are subjected to validation as part of the customer transfer process.
• Payment and Refund: These transactions will continue to reside in the source business entity. These transactions will remain accessible to users with appropriate permissions, including Site Admins, owners or Business Entity Admins who have access to both the source and destination entities.
• Verification: Similar to payments and refunds, verifications are treated as historical records. These verification transactions will be retained in the source business entity.

Events and Email Logs 

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.

Managing Associated Workflows Processes 

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.

Invoices With Metered Items 

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.

• Non-Metered Subscriptions:
  • With non-metered subscriptions, charges are invoiced in advance, typically at the beginning of each billing cycle.
• Metered Subscriptions:
  • Metered subscriptions work differently. Charges for these subscriptions are invoiced at the end of the billing term, in a postpaid manner.

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:

    • Customer C1 was active

• 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.

Amendments 

Merge Customer 

• Merging customers involves transferring various data from the source ('from') customer to the target ('to') customer. This includes payment methods, subscriptions, invoices, credit notes, transactions, unbilled charges and orders.
• Events and email logs will not be transferred as part of this process.
• The customer object returned after the merge will be the target ('to') customer object.
• It's important to note that the source customer record will still exist in Chargebee unless manually deleted.

Scenarios for merging customers when one is deprecated due to Business Entity Change and the other isn't, in the same business entity:

• Merging a deprecated customer (from) in the source with any other customer (to) in the source - Not Allowed.
• Merging any other customer (from) in the source with a deprecated customer (to) in the source - Not allowed, as there's no valid reason to move data from a deprecated customer to an active one.
• Merging a cloned customer (from) in the destination with a deprecated customer (to) in the source - Not allowed, as this would move data from the source customer to the target customer and may result in moving data from cloned to deprecated.
• Merging a cloned customer (from) in the destination with any other customer (to) in the destination - Allowed, as it follows normal business operations.
• Merging any other customer (from) in the destination with a cloned customer (to) in the destination - Allowed, as it also aligns with standard business procedures.

In summary, any operation involving a deprecated customer as either the source ('from') or the target ('to') customer is not allowed.

Filters On User Interface 

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.

Fraud 

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.

Account Hierarchy 

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.

Timezone 

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:

• Site Default Timezone: UTC
• Entity 1 Timezone: SST
  • Customer A and Subscription AB are set in Entity 1's timezone (SST).

Post-Transfer:

• Upon transfer to Entity 2, which operates under the LINT timezone:
  • Customer A and Subscription AB will adhere to Entity 2's timezone (LINT).

Dunning Management 

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 

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:

• Effective Dispute Resolution: You should have processes in place to promptly address customer concerns or billing disputes. Providing multiple ways for customers to reach out and resolve issues directly with their support, can help minimize chargebacks for transferred customers.
• Appropriate Actions: When chargebacks occur after your customer's business entity has changed, you must determine the right actions to take. This may involve issuing refunds or credits to affected customers in the destination business entity, ensuring proper accounting and record-keeping.
• Determining Responsibility: You need to decide which business entity is responsible for handling chargebacks related to historical invoices. It's crucial to establish clear protocols and responsibilities for managing chargeback resolutions between the source and destination entities.
• Reconciliation Process: You should create a process for reconciling chargebacks and related transactions between the source and destination entities. This may involve sharing information, coordinating efforts and ensuring accurate accounting across entities.
• Data Retention: Chargebee will retain the necessary data and documentation in the source business entity to support the resolution of any chargebacks that occur after the business entity change. This ensures an audit trail is available for reference.

Estimates API 

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:

• Within the original business entity concerning a customer or subscription that has been transferred to a new business entity.
• On any subscription in the destination business entity that is pending renewal and awaiting cloning.
  After the successful cloning or transfer of all customer and subscription data to the destination business entity, you are then able to employ the Estimates API without any limitations.

Payment Reversal for an Invoice 

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.

Credit Notes Linked to Partially Paid Invoices 

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:

• Accurate Financial Records: Completing payment for partially paid invoices ensures accurate financial records. It eliminates any outstanding balances associated with the customer, providing a cleaner transition in the customer's financial history.
• Simplified Transfer Process: By retaining fully paid invoices in the source business entity, the transfer process becomes simpler and more straightforward. It reduces the complexity of transferring partially paid invoices and their associated credit notes or adjustments to the destination business entity. This, in turn, helps avoid synchronization issues related to accounting.
• Enhanced Management: From your perspective, managing and tracking the status of fully paid invoices is often more manageable. Users can have a clearer understanding of the payment status, avoiding confusion when dealing with partially paid invoices during the customer movement process.

Deletion of Customer and Subscription Records 

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:

• Customer Records in Source Business Entity: If you intend to delete a customer record that has already been transferred to the destination business entity but a copy remains in the source business entity for audit purposes, please note that deletion of such records is currently not allowed. We are actively working on implementing a soft delete mechanism for these resources to preserve the audit trail.
• Subscription Records: Subscription records that have been either transferred to the destination business entity or are in a state where they are waiting for their next renewal to be cloned in the destination business entity cannot be deleted.
• Deletion Upon Full Transfer: Once all customer and subscription records have been successfully cloned or transferred to the destination business entity, deletion is possible. However, it's important to be aware that this deletion operation is irreversible. Deleting a customer or subscription record will result in the permanent removal of all associated data, including subscriptions and invoices.

Clear Personal Data 

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

Bulk Operations 

When considering bulk operations for the various Chargebee components within the context of customer transfer across entities, please keep the following guidelines in mind:

• Bulk Import and Export: You can also utilize the Bulk Operations feature to seamlessly import and export information between Chargebee and other applications.
• Action Restrictions on Transferred Resources: It's essential to be aware that performing actions on resources such as customers or subscriptions that have already been transferred to the destination business entity, or are in a state awaiting their next renewal to be cloned in the destination business entity, is restricted and not permitted.
• Bulk Actions Upon Full Transfer: Once all customer and subscription records have been successfully cloned or transferred to the destination business entity, you gain the ability to perform bulk actions without restrictions.

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.

Backdating Subscription and Invoices 

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:

• Limited Actions on Transferred Resources: Be aware that once customers or subscriptions have been transferred to the destination business entity, or if they are pending the next renewal before being cloned to the destination business entity, the ability to backdate certain actions related to subscriptions and invoices is restricted and generally not allowed.
• Permitted Actions After Complete Transfer: After the complete cloning or transfer of customer and subscription records to the destination business entity, the functionality to backdate certain subscription actions and invoices becomes available. However, this can only be performed within the confines of the same business entity; that is, backdating of subscriptions and invoices must occur in the business entity where they are currently housed.

Reactivating a Canceled Subscription 

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:

• Reactivation Constraints in Source Entities: If customers or their subscriptions have been moved to a new business entity, or if they are queued for cloning after their next renewal, it is not feasible to reactivate their canceled subscriptions within the original source business entity.
• Reactivation After Transfer is Complete: Only once the transfer and cloning of customer and subscription data to the destination business entity are fully completed can canceled subscriptions be reactivated. Importantly, the reactivation process must take place within the same business entity where the subscription cancellation occurred.

Regnerate Invoice 

Regenerating invoices is subject to certain conditions in the context of customer transfers between business entities:

• Historical Invoices: Regeneration of invoices designated as historical records within the original (source) business entity is not supported. It is essential to complete any necessary invoice regeneration for the customers in question before initiating their transfer.
• After Transfer Completion: Once the transfer to the destination business entity is finalized, you can regenerate invoices that originated there. The standard restrictions on invoice regeneration remain in effect, which means you cannot regenerate an invoice if:
  • It falls outside the current billing term.
  • It is a one-time invoice.
  • The invoice has already been regenerated or includes pro-rated unbilled charges.
  • An invoice was created with credits already applied.

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.

Acknowledge a Hosted Page 

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.

Offline Payment Methods 

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.

Sending Manual Emails 

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.