Reinstate Policy Transaction

Reinstates a cancelled policy as a REINSTATE transaction, back in force from the cancellation date with no gap in coverage. The server restores the premium, taxes and fees the policy carried before the cancellation, and you may add a reinstatement fee. To change the policy as well, reinstate it and then endorse it with Endorse Policy Transaction (endorsePolicyTransaction).

Value door (Invoicing a policy). The policy’s invoices change only as the request says: the invoicePlan you send voids the invoices it names and creates new ones, committed with the policy version, and without one every invoice stays as it is.

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.

Omit fullTermPricingInfo and the restored pricing contract is used. Billing is never restored: state it, or the reinstatement stores none.

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 cancel/reinstate 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-cancel-reinstate-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 term’s billing obligations per line item. The caller states this value, and leaving it out stores none. Stated billing must pass the receivable checksum and vocabulary checks.
• 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. invoicePlan is an invoice plan: nothing in it is defaulted or inferred. If reinstatement moves the billing an invoiced policy’s invoices add up to, a plan is required; without one it is refused with 422 finv2-policy-restates-invoices. A plan may credit a line the new billing drops, such as a paid tax on a flat cancellation (Credits).

Billing. Stores the caller’s billing as stated, without scaling, restoring or carrying billing from the policy: billing you leave out stores none. To keep a billed policy’s billing, state fullTermBillingInfo, at what the restored term owes. Kept and new invoices must still add up to the billing, as Invoice plans explains.

The policy’s layer. A policy sits at a layer of its pricing stack, read from its pricing, its billing and its active invoices. A reinstatement keeps the policy at its layer unless pricingStackLayerChange names the move it makes. Stating billing on a policy that has none, such as one whose cancellation dropped its billing, moves it from pricing to billing, and an invoicePlan that gives it its first invoices moves it up to invoicing. Leaving out fullTermBillingInfo on a billed policy drops its billing, a move from billing to pricing. A move the request does not name, or a named move it does not make, returns 422 policy-pricing-stack-layer-change and saves nothing; its message names the actual move and the exact pricingStackLayerChange that would name it. Billing that owes nothing sits at both billing and invoicing.

Required permission: policy.reinstate