This article explains the correct way to enter policy-related dates in HawkSoft and offers guidelines on what to do with dates when renewing, remarketing, or performing an agent of record change on a policy.
As an agent, you understand the importance of clean data in producing accurate reports. If data isn’t entered into HawkSoft correctly or in a standardized fashion, your reports won’t be correct either. Did you know that this extends to the way you use policy date fields?
How policy dates are entered in HawkSoft affects the calculation of important Key Performance Indicators (KPIs) like policies added, retention, and other vital business metrics. While many aspects of HawkSoft are customizable to fit any desired workflow, policy dates must be entered in a standard fashion for Agency Intelligence and Sales & Retention reports to calculate correctly.
This article at a glance
What’s the correct way to enter policy date fields in HawkSoft? The table below lists important date fields for reporting, what date they describe, and when they should be updated. The most important thing to remember is that the Sold Date and Inception Date should never be changed on a policy after they are originally entered, while the Effective Date and Expiration Date will be updated every term.
| Date | Description |
When to Update |
| Sold Date | The date the sale for the policy was made by the agent/producer | Do not change after input |
| Inception Date | The date the policy’s coverages first become effective | Do not change after input |
| Effective Date | The most recent date the policy was made active or renewed | Update every term |
| Expiration Date | The date the policy will expire if it is not renewed or cancelled | Update every term |
See About Policy Dates in HawkSoft's help system to learn more about policy dates.
When renewing a policy, it's important to remember that you should not change the Sold Date and Inception Date. These will always remain the dates for the initial policy. However, you will update the Effective Date and Expiration Date every term to reflect the most recent dates for the renewed policy.
One instance where policy date confusion may occur is when a policy is rewritten. A risk may be remarketed with other carriers for a number of reasons. Perhaps the risk has changed and needs a different level of coverage, or maybe the renewal premium is too high. Whatever the reason, if the policy is being bound with a different carrier or if a new policy is being bound with the same carrier, you will use the Duplicate/Remarket feature to remarket, rewrite, and/or replace the policy.
The diagram below shows the Duplicate/Remarket process, and the steps to follow in CMS are listed underneath.
Duplicate the policy
Select Internal > Duplicate/Remarket from the Action Menu. A new prospective policy tab will be created with the same coverages and risks, and a policy source of Rewrite. Rate the policy and identify where to place the new risk. If in the end you decide to keep the original policy as is, simply archive the prospect policy via the Action Menu.
Rewrite the policy
Update the prospect policy to the applicable Active status. Because the rewrite is effectively a new policy, you’ll enter a new Sold Date (the date the updated policy was sold) and Inception Date (the date the updated policy first becomes effective). As with a new policy, these dates should not be changed after being entered initially.
You will notice a checkbox stating “Policy was rewritten from a prior policy.” This is a recent addition that ensures the rewrite policy will be reported correctly, so make sure this box remains checked.
Replace the original policy
Set the status on the original policy to Replaced. This will ensure the old policy is not included in applicable reporting.
Note: A commission override is automatically applied to the rewrite policy so that the commission will be paid on a renewal basis.
For more information on this process, see Rewriting/Remarketing a Policy in the HawkSoft help system.
Another time when there might be date confusion is when a policy is acquired by your agency that was written previously by a different producer. In this case you should enter the date your agency acquired the existing policy as the Sold Date, not the Inception Date (which should remain the original inception date for the policy). All other policy dates should remain the same as they were on the policy previously.
Sold Date: the date your agency acquired the existing policy
Inception Date: the original inception date for the policy
Effective Date: the current effective date (no change)
Expiration Date: the current expiration date (no change)
Using policy dates the way they’re described here may be an adjustment for your agency, but if you follow these guidelines your reports will be more accurate and you’ll get a better view of the number and type of policies you have within a given date range. Giving a little extra attention to entering dates accurately at the beginning of the process will pay major dividends in the quality of your reports down the road.