Org label modifications in Multi-Org
This guide introduces the prerequisites and best practices for modifying an org label.
Modifying Org Labels is a significant operation that requires careful consideration due to its potential effects on data accuracy, compliance, and reporting across finance, revenue, and integrated systems. These changes are typically prompted by external business decisions like re-branding or organizational restructuring. To help ensure a smooth transition and minimize potential disruptions, we recommend avoiding Org Label modifications for any active products or accounts in your production environment.
Multi-Org configurations support business realignment by region or product category and adjustments to test organizations. Review and manage downstream effects before you update the configuration.
A parent-child hierarchy supports complex reporting and operational structures. Related organizations can inherit settings, including financial rules and reporting configurations.
- Evaluate the impact of reassigning an org to a different region or product category. The reassignment can affect reporting structures and product availability. Document the changes for audit purposes.
- Review and adjust the configuration of test orgs before you move them from a lower environment to production. Confirm that the data and settings meet production requirements.
Prerequisites for modifying org labels in a Multi-Org setup
Complete the following prerequisites before you modify an org label:
-
Verify that no active subscriptions reference the products or rate plans.
Do not modify org labels on products or rate plans that active subscriptions reference. These changes can affect renewals, amendments, pricing, product availability, and reporting accuracy. Complete or migrate active subscriptions before you make the change.
Product Rate Plan Charges (PRPCs) define billing rules for products and services. When you create a subscription, Zuora copies the PRPC configuration to Subscription Rate Plan Charges (SRPCs). The components of a PRPC determine charge calculation, billing, accounting, and tax treatment.
Changing an org label on a referenced product or product rate plan can cause the following issues:
- Disrupt the relationship between SRPCs and their source PRPCs, which can cause data inconsistencies.
- Cause invoice items to be generated or mapped incorrectly because billing requires a consistent org context.Because SRPCs inherit org context from PRPCs, changing the org label at the product or product rate plan level can affect subscription lifecycle processing.
-
Review the customer account configuration. Verify that the account org label matches the intended org structure. Confirm that the change will not affect existing transactions or user access.
- Review transactional data segmentation. Org labels identify the org that owns transactions such as subscriptions, invoices, and payments. Changing an account org label can cause existing data to appear in incorrect reports or become visible to unintended orgs.
- Review product catalog access. After an org label change, an account can lose access to required products or gain unintended access. These changes can affect subscription creation and amendments.
-
Review user access and permissions.
User permissions can depend on org labels. Changing an org label can change which users can view or edit an account. The account can become inaccessible or visible to unintended users.
-
Complete related bill runs and payment runs.
Verify that all related bill runs and payment runs are complete. Wait for ongoing runs to finish before you proceed. Bill runs and payment runs are filtered by org. Incorrect org labels can exclude accounts from runs or include accounts in multiple orgs, causing billing and payment errors.
Unlabeled runs include only transaction objects that do not have an assigned org label.
-
Validate the org assignment for journal runs.
Confirm that the account has the correct org assignment for journal runs. Journal runs create journal entries from invoices, payments, refunds, and credit memos.
Changing an org label affects journal entry segmentation. The change can affect integrations with ERP systems such as NetSuite or Workday. Update integration mappings when necessary to maintain data consistency.
-
Review finance behavior after an account org label change. An account org label change takes effect immediately for subsequent processing. Existing journal entries and trial balance data are not automatically modified or regenerated. If you must reprocess previously processed transactions, complete the following actions:
- Before you change the account org label, cancel the affected cancelable journal entries or journal runs.
- Change the account org label from the original org to the new org.
- Rerun the affected journal run for all impacted transactions. Include transactions associated with both the original org and the new org.
- Rerun trial balance for both the original org and the new org.
- If the accounting period is closed, reopen it before you rerun trial balance. Close the accounting period again after the rerun is complete. The journal run rerun is not limited to the relabeled account. A journal entry can contain transactions from multiple accounts. Review all impacted transactions when you determine which journal run to rerun. Changing an account org label does not automatically regenerate historical journal entries or trial balance data. Plan required historical reprocessing before you make the change.
-
Close open accounting periods.
Close all accounting periods in the org before you modify or delete org labels. Do not modify org labels while an accounting period is open.
-
Review integration mappings.
Review and update integration mappings that use org labels to identify business units or entities. If Workday or NetSuite relies on org labels, update the mappings after you modify the labels. Data synchronized with the old org labels might not update automatically and can cause reporting discrepancies.
-
Review currency conversion settings. Review currency conversion settings when you modify org labels, especially in a hierarchical org structure. The root org provides exchange rate settings, including the provider, date, and rounding mode. Child orgs inherit these settings unless they override them.
- Review root org settings that provide the default exchange rate configuration.
- Review child org settings that inherit or override the root org configuration. If you reassign a child org to a different parent, the child org inherits currency conversion settings from the new parent.
-
Update Zuora Revenue org mappings. Each organization in Zuora Revenue maps to a corresponding org in Zuora Billing. Update the Zuora Revenue mappings after you modify Zuora Billing org labels. These mappings support accurate billing, revenue recognition, and user access.
-
Update billing and order-to-revenue mappings. Review and update org label mappings for Order-to-Revenue (OTR) processes. OTR mappings are applied before transactional data is synchronized. If you modify org labels without updating the corresponding revenue mappings, Zuora Revenue data can be incomplete or incorrect.
Best practices for modifying org labels
Use the following practices to protect data integrity, regulatory compliance, and financial operations in a Multi-Org-enabled Zuora Billing tenant:
- Modify org labels for products and product rate plans before you activate related subscriptions. If a product has no org label, all orgs can view it, but only unlabeled accounts can subscribe to it.
- Change an account org label only as part of a data migration. The migration moves all account transactions to the target org. Review the impact on financial reporting before you proceed.
- Plan historical reprocessing when you change an account org label. Existing journal entries and trial balance data are not automatically modified or regenerated.
- Test org label changes in lower environments before you make changes in production.
- Back up your data with Data Query Exports or Zuora Reporting before you modify org labels.