Navigation
2.7. Merge a Client into a Parent as a Billing Profile
Preview and merge a client into another client, preserve billing profiles, review portal access, and complete accounting mapping follow-up.
An acquisition can leave an MSP supporting one organization through several client records. Merging brings the operational records under one client while retaining billing identities as profiles. For example, Harbor Clinic could become a billing profile of GreenLeaf Dental Group after their organizations combine.
Before you begin
You must be an MSP user with both client:update and client:delete permissions. Confirm which client will remain, how contacts should access profile tickets, how contracts should cross the transition, and who will review accounting mappings.
This operation is irreversible. The preview writes nothing, but the final merge moves records and retires the source client. If the organizations still require separate operational ownership, keep separate clients until that decision changes.
Choose the source and destination
- Open the client you intend to keep, such as GreenLeaf Dental Group, and select Merge in its header.
- In Merge a client into this one, choose Client to merge, such as Harbor Clinic.
- Check Destination client carefully. It starts with the client from which you opened the dialog, but you can change it.
- If a recorded parent is suggested, use Use it only when that is the intended destination. A previously recorded parent does not force your choice.
- Select Next to load the preview and continue through contacts, contracts, and options. Read any blocker shown before proceeding.
Review contacts, contracts, and access
For each contact, choose a Billing profile or No profile. Every source contact moves to the destination client, regardless of this profile assignment.
| Choice | Effect |
|---|---|
| Manager | Labels the contact who runs that profile; only one manager can be selected per profile. |
| Sees profile tickets | Separately grants the contact visibility of tickets attributed to that profile in the portal. |
| Keep portal users on their own billing segments | Preserves the segments currently available to affected unrestricted portal users instead of extending them across the destination. |
Manager status alone does not grant profile-ticket access. Leave Keep portal users on their own billing segments enabled when the aim is to preserve existing boundaries. The wizard shows the affected user count and any visibility-group renames needed to avoid a clash.
For each contract, choose Keep original dates or Cut over. Keeping dates moves the contract without changing its billing period. A cutover ends it on the old client and starts a copy on the destination from the selected Cutover date. Review these choices with the person responsible for the next invoice run.
Confirm what will move
- Review What will move and Billing profiles after the merge on the confirmation step.
- Check the record counts, resulting profile names, and your contact and contract decisions. Use Back to correct them.
- Enter the source client's name in Type "…" to confirm.
- Select Merge client only when the preview describes the intended result.
Tickets, contacts, assets, projects, and contracts move under the destination. Billing profiles move with their associated invoices, billing cycles, payment methods, and credits, keeping those financial records attributed to their profiles. The source becomes inactive and is marked as merged into the destination; it is not a second active operating client.
Afterwards, review contacts and their profile assignments under the destination. Check portal access separately from the contact's manager designation, and confirm that a clinic contact can see the intended segment's tickets.
Complete the accounting follow-up
When accounting mappings exist, the wizard offers a separate step after the merge. Select the mappings to redirect and choose Apply selected, or choose Skip for now and arrange manual relinking.
The merge itself does not automatically redirect these mappings. If the destination is already mapped for an integration, that source mapping requires manual review rather than overwriting the destination's mapping. A failed or skipped accounting remap does not reverse the completed client merge.
If a preview is blocked, resolve the displayed reason and preview again. If a remap cannot be applied, keep the destination client and billing-profile structure intact while the accounting administrator reconciles the external customer links.