Billing implications of audits

Under normal circumstances, BillingCenter closes a policy period if there are no outstanding charges, no outstanding balance, the expiration date passes, and all premium is earned. Basically, closing the period means that BillingCenter does not expect any more activity on that period.

If a policy is subject to a final audit, PolicyCenter tells BillingCenter to set the period status to OpenLocked while it creates the period. This prevents it from being closed before the final audit. When PolicyCenter sends the final audit billing instruction, BillingCenter sets the period back to Open. The batch process that closes periods soon closes the now-audited period.

For a policy originally subject to final audit, a PolicyCenter user can later decide to waive final audit. An insurer typically does not want the billing system to wait forever with the period in an open and locked status because it never got the final audit. Waiving the audit unlocks the policy. If you use the base configuration BillingCenter integration PolicyCenter notifies BillingCenter about waiving the audit and BillingCenter unlocks the policy period. This removes the OpenLocked status.

Less likely is that policy period might start out not subject to a final audit, but later the underwriter decides that an audit is appropriate. If you schedule a final audit in PolicyCenter, PolicyCenter notifies BillingCenter that the period must stay open for the audit.

A bill for an audit contains the following items that a policyholder must understand:

• The total audited premium for the period. This is basically a quote page from PolicyCenter.
• The amount due on their invoice

Insurers traditionally provide a bill that shows the value of total amount due, which is calculated from the following formula:

TOTAL_AMOUNT_DUE = TOTAL_AUDIT_PREMIUM - AMOUNT_PREVIOUSLY_BILLED_AND_COLLECTED

PolicyCenter cannot calculate the total amount due because PolicyCenter does not know the amount that the billing system already collected. PolicyCenter and BillingCenter do have the following information:

• PolicyCenter knows the difference between the audited premium and what was previously sent to billing in transactions that PolicyCenter already charged. Call this amount X.
• BillingCenter knows the value of currently uncollected amounts, including anything that might not yet have billed, if that is possible. Call this amount Y.

The total due is X+Y, just as it would be for any new charges. The package that the insurer sends to the policyholder typically includes the following:

• An invoice showing any open balance plus any new charges including audit amount X
• An audit report showing Total Audit Premiums and Change in Premiums. This is the data from the two tabs on the quote page in PolicyCenter that explains the value derived in the amount X.

An insurer can optionally add code to PolicyCenter to call out to a billing system to display difference between the final audit and the amount paid. This would not change what PolicyCenter must send to the billing system but it might amend what to print on the final audit statement.

Like any other policy transaction, PolicyCenter must send billing charges to the billing system to bill for premium changes resulting from an audit.

There are two ways to think about the results of an audit.

• Policy system sends total audit premiums to billing. In that case, the billing system must compare this to the amount previously billed. This would include any deposit but not include various fees on top of the charges sent from the policy system. The policy system explains this to the insured and bills the insured for the difference.
• Policy system sends incremental charges compared to what was previously sent to billing system as with other transactions.

The base configuration BillingCenter integration uses the second approach. The base configuration PolicyCenter behavior sends BillingCenter incremental charges only compared to what PolicyCenter previously sent to the billing system. PolicyCenter looks at transactions from previous versions of the policy to determine what PolicyCenter already sent to the billing system.

There are times that an audit must change. There are two basic situations:

• An audit revises, which causes PolicyCenter to send adjusting charges compared to the prior audit.
• The audit reverses, other changes may be made to the policy, and then a new audit happens. A variation of this is reversing the audit because the policy reinstates. There may then be many other transactions before a new audit is done months later.

For a revised audit, the PolicyCenter base configuration integration to BillingCenter creates another audit request with additional charges. BillingCenter creates an audit billing instruction to handle this request.

For an audit reversal, a few things happen:

• PolicyCenter sends a new Audit billing instruction with new charges. These reverse the prior audit. However, the total might be positive or negative, so PolicyCenter must tell BillingCenter that this is a reversal, not just a revised audit. BillingCenter cannot derive that information from the total charges.
• BillingCenter moves the policy period back to OpenLocked because the policy needs a new audit before it can finish. This can occur for a policy change after final audit or a reinstatement after final audit.