Reinstate Policy Transaction

Reinstates a previously cancelled policy as of a given date via a REINSTATE transaction. The policy must be cancelled at the reinstatement date.

reinstatementDate (= the transaction effective date) is sugar the server expands into per-segment, segment-scoped deltas. policyStatus flips back to active from the reinstatement date through end of term, and cancellationEffectiveOnDate is cleared across the whole term — reinstatement removes the cancellation marker rather than recording a parallel reinstatement marker. There is no reinstatement date field.

A reinstate may not leave a coverage gap. A reinstate that would leave a cancelled window between two active periods (e.g. cancel Jun 15, reinstate Jul 1, leaving Jun 15–Jun 30 cancelled) is rejected with a 400 — the domain models that as a new policy term, not a reinstatement. A valid reinstate restores continuous coverage and fully clears the cancellation, so the segments return to their pre-cancellation state (and merge).

A reinstate never reprices — it RESTORES

The server computes what the reinstated term’s pricing contract must be: the pre-cancel version’s contract, verbatim. Every component comes back — premium, taxes, fees — at the value and earningSchedule the policy carried before the cancellation, so the reinstatement is the exact inverse of the cancel’s per-charge floor. Recognition follows: each charge picks its schedule back up from the reinstatement date, and the earned curve across cancel-then-reinstate is flat.

“Pre-cancel” is a VERSION, not a date — the version immediately before the CANCEL being undone. Since a reinstatement may not leave a coverage gap, its effective date is the cancellation date, so there is nothing to choose.

A bare { "reinstatementDate": ... } body is the normal request, and it always succeeds. Omit fullTermPricingInfo and the restored contract is used.

If you DO send fullTermPricingInfo, it is validated against that restored contract component by component, to the exact cent:

• every component of the pre-cancel contract must be present, at exactly its pre-cancel value and with its pre-cancel earningSchedule;
• an UNRECOGNIZED <classification, qualifier> pair is an addition — money the reinstatement itself creates, typically a reinstatement fee — and it MUST carry earningSchedule: "immediate", because it is recognized on the reinstatement date rather than scheduled over the restored term.

Companies that tax through InsCipher. Where the company’s InsCipher lifecycle tax sourcing is enabled, the server asks InsCipher what the state re-charges on this reinstatement and appends its answer to the restored contract as additions of its own — one immediate component per corrected tax, under that tax’s classification with a reserved qualifier of the form inscipher-RI v4 (a state suffix where the charge is split by state). A flat fee the state charged once and does not re-charge is netted to nothing this way. A supplied fullTermPricingInfo must include them, at the derived cents. If InsCipher cannot answer while tax money is at stake, the reinstatement is refused (502 inscipher-tax-calculation-failed, or 422 inscipher-lifecycle-tax-unpriceable naming the gap).

Re-valuing, re-basing or dropping a restored component is rejected with a 400 naming it. To reprice the restored term, book an endorsement at the same effective date after the reinstatement: transactions sharing an effective date are applied in booking order (ascending policyVersion), so reinstate-then-endorse restores the term and then reprices it prospectively.

Three optional derived channels are whole-object overwrites of a policy-root full-term container — necessarily whole-term, so none carries dates nor an element-level form:

• fullTermPricingInfo — the full-term pricing contract, validated as described above.
• fullTermBillingInfo — the Billing Aggregate, the term’s billing obligations per line item. Omit it and the platform derives it, restoring the pre-cancel lines verbatim, payable lines included — or, when InsCipher adjustments changed the restored total, scaling the receivable lines to it by largest remainder, as a cancellation does. State it explicitly to override that; either way a stated aggregate is checked against the receivable checksum and the per-line vocabulary rules.
• fullTermPolicyRatingResult — the canonical policy-level rating result. Unvalidated and unconstrained: it is the rater’s own output, not the money the platform books.

Policy invoices. Optionally send invoicePlan, a fully explicit keep/void/create plan. Nothing is defaulted or inferred. If reinstatement moves a billed policy’s pricing target, a conserving plan is required.

Required permission: policy.reinstate