PolicyCenter · Learn-PnC

Account, policy, policy period

PolicyCenter's core structure has three levels. Getting them straight is the single most useful thing in this module.

Account: The customer relationship: a person or company holding one or more policies. Account-level contacts, documents and notes live here.
Policy: One insurance contract over its whole life, across all terms. Identified by its policy number.
PolicyPeriod: One version of the policy for one term. Every job creates a new PolicyPeriod (a "branch") that starts as a draft copy of the previous one; binding makes it the current truth.
Lines & coverables: Inside the period: policy lines (e.g. PersonalAutoLine), the insured objects or coverables (vehicle, dwelling, location), and their coverages and coverage terms.
Contact roles: Who plays which part: primary named insured, drivers, and additional interests such as a leasing company or mortgage lender (panthaver) who must be notified if the policy is cancelled.

Jobs: the policy lifecycle in PolicyCenter

Every lifecycle transaction from module 03 is a job in PolicyCenter:

Job	Business meaning	Danish
`Submission`	New business: quote and bind a new policy	nytegning / tilbud
`Issuance`	Issue a policy that was bound without being issued	—
`PolicyChange`	Mid-term change (endorsement)	ændring
`Renewal`	New term at expiration	fornyelse (hovedforfald)
`Cancellation`	End the policy before expiration	opsigelse / ophør
`Reinstatement`	Bring back a cancelled policy	genoptagelse
`Rewrite` / `RewriteNewAccount`	Replace the policy with a new term or move it to another account	—
`Audit`	Recalculate premium from actual exposure (e.g. real payroll on a workers' policy)	efterregulering

A typical job moves through Draft → Quoted → Bound, and for a new submission, on to issued. Along the way the job is validated, rated, and checked for underwriting issues. A job can also be withdrawn or declined.

Effective dating, out-of-sequence and preemptionA PolicyChange has its own effective date inside the term, and PolicyCenter stores values per date range ("slices"), so the period can answer what was true on any date. If a change is back-dated before an already-bound change, PolicyCenter handles it as an out-of-sequence change and asks how to apply it to the later versions. If two jobs are open on the same version and one binds first, the other is preempted and must take in the first job's changes before it can bind.

The product model

Products are defined as metadata, not code. The hierarchy:

Product, e.g. "Bilforsikring privat". Contains one or more…
Policy line patterns, e.g. personal auto. Each has…
Coverage patterns, e.g. Ansvar, Kasko, Vejhjælp, Glas, each attached to the line or to a coverable (the vehicle). Each coverage has…
Coverage term patterns: option terms (selvrisiko 3,000/5,000/10,000), direct terms (sum insured), typekey or package terms.
Exclusions, conditions and question sets (underwriting questions).

Each element has availability (from which date, under which conditions it can be selected) and can be required, suggested or electable. On modern versions, Advanced Product Designer (APD) lets analysts design products visually and generates the underlying model and screens.

Rating

PolicyCenter calculates premium with its rating management components:

Rate book: A versioned package of rating content for a line, with effective dates and a status lifecycle (draft → approved → active), so new prices can be prepared ahead and switched on at a date.
Rate table: Lookup tables of factors: zone by postcode, vehicle group, bonus step factor, deductible factor.
Rate routine: The step-by-step calculation: look up the base, multiply by factors, add flat amounts, round. It encodes exactly the ordered tariff from module 04.
Costs & transactions: Rating produces cost records (premium per coverage, taxes, fees) and, on bind, transactions: the change in premium versus the previous version. Transactions are what get sent to billing.

Danish twistThe bonus step lives as an extension field on the vehicle or line (e.g. BonusStep_Ext). It's recalculated at renewal from claims data, using a ClaimCenter integration or a claims-history service. State and Naturskade levies are separate cost types so BillingCenter can bill them as tax/fee charges, not premium.

Underwriting issues and authority

Underwriting rules (written in Gosu) run at defined checkpoints. When a rule fires, it raises an underwriting issue, the PolicyCenter word for a referral. Each issue type defines what it blocks: quoting, binding, issuance or renewal.

Users have authority profiles (tegningsfuldmagt) that say which issues, up to which values, they may approve. A junior underwriter might approve car values up to DKK 600,000; above that the issue is referred to a senior. Approved issues are recorded with who approved what, which matters for audit and Finanstilsynet's governance expectations.

Forms, documents and renewals

Forms inference decides which forms and clauses belong on a policy from its data: the right terms version for the product and date, plus clause C12 if a basement theft condition applies. A document-production integration then renders the Danish schedule and letters.

Renewals are mostly automatic: a batch process starts Renewal jobs a set number of days before expiry, applies indexation and new rate books, re-runs underwriting rules and produces renewal notices. Policies the insurer doesn't want to keep can be routed to an underwriter or set to non-renew.

Integrations

Direction	What flows
PolicyCenter → BillingCenter	Billing instructions on bind (new policy, change, renewal, cancellation) with charges and payment plan choice
BillingCenter → PolicyCenter	Cancellation requests for non-payment; reinstatement on late payment
ClaimCenter → PolicyCenter	Policy search and retrieval at FNOL, for the version in force on the loss date
Registers → PolicyCenter	Vehicle (DMR), building (BBR), address (DAR) and company (CVR) prefill
Portals → PolicyCenter	Quote-and-buy and self-service changes through the Cloud API

Walkthrough — Mette buys car insurance online

Mette logs in to the web shop with MitID and enters her registration number. The portal calls the Cloud API to create a Submission on her account.
A DMR integration prefills make, model and weight; a DAR lookup validates her address and sets the postcode zone.
She picks Ansvar + Kasko with selvrisiko DKK 10,000 and Vejhjælp. Rating runs the rate routine: DKK 3,690.75 plus taxes as separate costs.
No underwriting issues fire, so the job quotes and binds. The policy period becomes the bound version from her chosen start date.
On bind, PolicyCenter sends a billing instruction to BillingCenter with her quarterly Betalingsservice plan, and sends the insurance status to the Motor Register.
Forms inference picks the schedule and terms; documents go to her Digital Post.

Key takeaways

Account → Policy → PolicyPeriod; every job creates a new period branch that becomes current on bind.
Jobs: Submission, Issuance, PolicyChange, Renewal, Cancellation, Reinstatement, Rewrite, Audit.
Effective-dated slices give the full history; out-of-sequence and preemption handle overlapping changes.
Product model: product → line → coverage → coverage terms, with availability; APD for visual design.
Rating: rate books, rate tables, rate routines → costs and transactions; underwriting issues block jobs until approved within authority.