After a subscription migration, identify the record that should continue billing before archiving any apparent duplicate. Match the customer, service and billing period, resolve the old record's invoices, and confirm that the previous system will not charge again. Two records with the same customer name are not enough evidence of duplication.
This guide is for billing administrators reviewing a completed import. Its survivor ledger is an original example, not an automatic deduplication feature or a tested customer migration.
Choose the Survivor by Service Identity
For every suspected pair, write down the source-system ID, PayRequest subscription ID, customer, product, actual service identifier, currency, billing interval and paid-through period. “Hosting monthly” can describe two legitimate websites. A matching email can also belong to an organization buying several services.
The survivor is the record you intend to manage and bill going forward. Preserve a reference to the other record so someone can reconstruct the decision later. Do not pick the survivor simply because its creation timestamp is newer.
Use a Three-Record Decision Ledger
Illustrative example: one customer has a managed website subscription. A repeated import appears to have created a second record, while another record covers a genuinely different website.
| Record | Service and period | Evidence | Decision |
|---|---|---|---|
| S-401 | Site A, October | Intended live record; next billing verified | Keep as survivor |
| S-402 | Site A, October | Same source service ID; duplicate import confirmed | Candidate for cancellation, then archive |
| S-403 | Site B, October | Different service ID and separate agreement | Keep; not a duplicate |
Add columns for open invoice IDs, provider subscription IDs, last successful payment and reviewer. If those fields conflict, stop the cleanup until the conflict has an owner and resolution. Do not merge payment histories or infer that two invoice numbers mean two valid charges.
Clear Three Separate Stop Conditions
- Record identity: the candidate truly represents the same service and obligation as the survivor. Confirm it with the source data and service owner.
- Billing authority: verify which system and provider can still create or collect the next payment. Archiving a PayRequest record is not evidence that an external legacy subscription was canceled.
- Invoice disposition: classify each open invoice as valid, duplicated or disputed. Record the approved billing correction separately. If a duplicate was paid, investigate the payment and refund decision; hiding the subscription does not return money.
An unresolved invoice is a reason to keep the cleanup pending, not to make the record harder for a customer to find. Explain the chosen continuing record to the customer when the migration changes what they see.
Cancel, Archive and Verify the Preserved Record
PayRequest's archiving documentation requires cancellation before archiving. An archived subscription moves to the Archived tab, disappears from the customer portal and retains linked invoices, transactions and history. Open invoices are not automatically canceled by the UI archive action.
After the three checks pass, tag the candidate with the migration reference, cancel it through the documented workflow and confirm its canceled status. Open its detail page, choose Archive Subscription and confirm. Verify it is in Archived, the preserved documents are still accessible to the administrator, and the survivor's next billing details match the handoff.
Then inspect the next expected billing cycle in both systems. A clean list is only one acceptance criterion; the other is that the intended obligation is collected once.
Keep Reactivation Out of Routine Cleanup
The documented recovery path is to open the archived record and reactivate it with billing details such as the next date and mandate. Review the survivor first. Reactivating the old duplicate without checking the continuing service can recreate the original problem.
Use PayRequest subscription archiving after the ledger is decision-ready. For migration planning before import, use the separate WHMCS migration checklist.
For temporary interruptions rather than duplicate cleanup, use the separate pause-and-resume checklist.
Ready to configure your workflow? Create a PayRequest account.
Prepared by the PayRequest Team with AI assistance. Documentation reviewed on 11 October 2026. Record IDs, service names and the ledger are illustrative; no customer test or financial result is claimed.
