Outgoing agency continues earning on the prior term
Prior-term premium collected after the renewal effective date earns to the outgoing agency, because they were producer of record on the term that generated it. Late installments, cured delinquencies, and audit premium flow to them for months.
ResponseAccept and communicate. The alternative takes commission earned on premium already collected. State in agency communications that the prior relationship pays out until that term's receivables close.
Underlying mechanism
- BillingCenter divides each charge's commission into item commissions, one per invoice item.
- Each item commission belongs to the policy period that produced it and carries that period's producer of record.
- A payment landing on a prior-term invoice item earns to that period's producer regardless of subsequent changes.
- There is no date at which a policy period's commission stops belonging to its producer.
Rate cutover keys on billing-request date, not effective date
No date attribute exists in availability criteria and plans have no versioning. For renewals, the billing-request date is one lead time earlier than the effective date.
ResponseAccept a timing-based cutover. Size an override pass into every rate change.
Underlying mechanism
- BillingCenter evaluates subplan availability criteria when it receives a policy period with a producer code.
- Subplans are evaluated in priority order, lowest to highest, and the first match is used.
- If none is true, it falls back to the Default subplan.
- That evaluation happens once, at receipt.
- The seven attributes are product type, policy term, assigned risk, account business segment, account evaluation, jurisdiction, and underwriting company.
Commission rate does not follow a BillingCenter transfer
BillingCenter moves commission on the original producer's plan and does not recalculate. The receiving agency earns at the outgoing agency's rate until the rate is changed on the transferred charges. Under on-payment-received the error surfaces slowly, over months.
ResponseAdd a required step to the transfer runbook. Build a standing query flagging transferred charges whose rate does not match the receiving producer's plan.
Underlying mechanism
- BillingCenter transfers commission based on the plan associated with the original producer code.
- It does not recalculate for the new producer code.
- The prescribed fix is two manual steps: transfer the policy, then change the commission rate on the transferred charges.
PolicyCenter and BillingCenter disagree after a transfer
In cases 2 through 4, PolicyCenter shows the outgoing agency as producer of record on the renewal term while BillingCenter pays the incoming one. Financially correct, structurally inconsistent.
ResponseAccept and document for reconciliation. The alternative is a PolicyCenter rewrite of the renewal, which is a cancel and rewrite, and heavier than the inconsistency warrants in most cases.
Underlying mechanism
- A PolicyCenter policy change can edit the producer of service but not the producer of record.
- Only a submission, issuance, rewrite, or renewal job can set producer of record.
- That is why a mid-term change requires a cancel and rewrite.
- The systems are decoupled by design. PolicyCenter owns producer identity, BillingCenter owns the commission.
Early premium narrows transfer options
Escrow, pay-in-full, and list-bill accounts routinely pay before the effective date. Once that premium distributes, commission earns and a point-in-time transfer can no longer move it.
ResponseConfirm the payment allocation plan uses Billed or Due eligibility rather than Next Planned Invoice. Consider shortening renewal invoice lead time, weighed against lapse risk from less time to pay.
Underlying mechanism
- All payments pass through an unapplied fund and distribute per the account's payment allocation plan.
- Billed or Due makes items on planned invoices ineligible, so money holds until the renewal invoice bills.
- Next Planned Invoice makes the next planned invoice eligible, so the payment distributes and commission earns immediately.
- The setting decides whether an account lands in case 2 or case 3.
Renewal lead time varies by policy
RenewalProcessLeadTime is a floor. Regulatory lead time, company practice, batch frequency, and concurrent transactions all push actual issuance later.
ResponseDo not set a date-based SLA. Intake reads two flags, renewal issued and premium received, and routes from those.
Underlying mechanism
- The renewal batch checks the expiration date against the configured lead time first.
- It then adds regulatory lead time, company practice, and a delay for concurrent policy transactions.
- No policy starts automatic renewal sooner than the configured lead time. Many start later.
- Batch frequency adds further variance. A renewal eligible on Wednesday waits for the next scheduled run.