This page is part of the subscription pause recovery guide, which explains why a pause that collides with a prepaid renewal is worth documenting. Here the question is mechanical: which system holds what, and which identifier carries the case from one to the next.
Four systems, four owners: the map
Most subscription businesses split a pause recovery across four places. Each is usually run by a different team, which is why nobody holds the whole case by default.
| System | Record it holds | Linking key it carries | Usual owner |
|---|---|---|---|
| Subscription engine | Pause and resume events, skipped orders, contract date changes, who initiated each change | Subscription ID, customer ID | Ecommerce or retention operations |
| Billing | Invoices, charges, refunds, voided or uncollectible invoices | Invoice ID, subscription ID, customer ID | Finance |
| Support desk | Customer messages, agent notes, macros used, solved status | Ticket ID, requester email, order number field | Customer care |
| Fulfillment or order platform | Shipments sent, held or rescheduled | Order number, subscription ID where synced | Operations or the 3PL |
The map matters for an introduction because it shows who must be in the room. A retention lead can describe the engine; only finance can say whether voided invoices were kept, and only customer care knows whether agents typed the order number into a field or into free text.
The linking keys, ranked by how often they survive
Not every key is equally reliable. Rank them before describing the history, because the weakest required join sets the quality of the whole case.
- Subscription ID, engine to billing. Usually strong, because most billing tools create invoices against the subscription itself. It weakens after a platform migration if old and new IDs were not mapped.
- Order or invoice number, billing to support desk. Strong only when the ticket form has a dedicated field for it. When agents paste it into a comment, it exists but has to be found.
- Customer ID or email, support desk to engine. A common fallback. It links a ticket to a person, not to one subscription, so customers with two plans blur.
- Timestamps, all systems. Needed to prove order of events: did the refund come before or after the complaint? Time zones and batch jobs can shift them by hours, which matters when two events fall on the same day.
A fifth item is not a key but decides whether a case can be read: the initiator of each change. Some platforms let both sides act. Shopify's help center, for example, describes merchants pausing, skipping or resuming a contract on a customer's behalf, while customers can manage their own contracts when that setting is on. A staff-initiated pause usually has a ticket behind it; a self-service pause may not.
ShopifyOne pause case joined across all four (Illustrative)
A fictional 340-person pet supply company sells a six-month prepaid food plan. The identifiers below are invented to show how one case reads once every join holds.
| Step | System | Record | Key that links it to the next step |
|---|---|---|---|
| Customer pauses for two months from her account | Subscription engine | Pause event on SUB-4471, initiator: customer | Subscription ID SUB-4471 |
| Renewal invoice is created during the pause and charged | Billing | Invoice INV-90812 on SUB-4471, status paid | Invoice ID INV-90812 |
| Shipment for the paused month is held | Fulfillment | Order 55120 marked on hold | Order number 55120 |
| Customer writes in about the charge | Support desk | Ticket 77310 with order number 55120 in the order field | Order number 55120 |
| Agent refunds the charge and moves the renewal date | Support desk and billing | Internal note citing the pause policy; refund on INV-90812; new renewal date on SUB-4471 | Invoice ID and subscription ID |
| Next renewal charges and ships normally | Billing and fulfillment | Paid invoice on SUB-4471; order shipped | Subscription ID SUB-4471 |
Read across the right-hand column and the chain never breaks: every row hands a key to the next. That is what "fully joined" means. If ticket 77310 had held only the customer's email, the join to SUB-4471 would still be likely, but a reviewer could not be sure it was not her second subscription.
Where joins fail: voids, flat exports and silent pauses
Three documented behaviors explain most broken chains. A partner should ask how each was configured rather than assume.
- A voided invoice can leave nothing to join. Stripe's documentation on pausing payment collection says invoices for the paused period can be kept as drafts, marked uncollectible or voided, and that with the void option no record of charges is created for those periods. If a company chose void, billing has a gap exactly where the pause sits, and the engine events and tickets must carry the story.
- A flat ticket export drops the reasoning. Zendesk's export documentation says the CSV format leaves out ticket comments and descriptions, which appear in the JSON and XML formats, and that exports must first be enabled for the account. The agent's decision lives in those comments. Zendesk also keeps ticket audits, a read-only history of each update with its field changes and comments, which is where a changed order number or status would show.
- A self-service pause can have no ticket at all. When customers pause from their own account, the engine records the event but support may never hear about it until a charge goes wrong.
Stripe
ZendeskNone of these makes the history unusable. They change which system must carry which part of the case, and they belong in the brief as plain statements.
Questions that test the joins without touching a record
Ask the retention operations head and, where needed, finance and customer care. Every answer is metadata.
- Does the ticket form have a required field for order or subscription number, and since when?
- When a pause overlaps a scheduled renewal, which billing behavior is configured: draft, uncollectible or void?
- Does the engine record who initiated each pause, the customer or staff?
- Has the company changed subscription platform, and were old subscription IDs mapped to new ones?
- Are internal agent notes kept with tickets, and for how many years?
- Who could authorize a discussion about licensing these records?
The metadata-only Zendesk inventory template gives a format for the support desk line, and the referral brief template puts the answers on one page. If a platform change is planned, exporting data before cancelling SaaS covers the timing questions. For who should receive the brief, see who can license subscription pause records.
The introduced company needs 50+ full-time employees at peak (contractors excluded), documented operating history, rights to license and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 90% of the data is in English. Whether customer records can be licensed, which cases a buyer would want and whether an offer follows stay unknown until SourceX's review. More record types sit under ecommerce.
Next step
Refer a company. Earn up to $100,000. Default reward: 25% of Actual Supplier Payout, capped at $100,000 cumulatively per referred company. Eligibility and payment conditions apply, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.
If a subscription business can carry a pause case from engine to billing to ticket on shared keys, register as a partner, check it against who qualifies and read the program terms before introducing its retention operations head.