Events API Case settled event

Support

This event is supported by both CORE, HUB and ClaimShop.

Description

Scalepoint supports sending events when the case is settled or partial settled (only for CORE & HUB). A settlement is the approval of one or more expenses from service partners or the approval of payout of some compensation to the customer. The resulting event contains detailed information of which expenses were settled and, maybe more importaint, how they were settled, resulting in a list of payments to be issued by the backend system.

The details can be found on the documentation page.

Settlement logic

To understand the contents of the event, one must understand a little bit about what goes on under the hood of CORE & HUB and ClaimShop.

One claim usually involves several parties all having some stake in it. These can be:

All of these parties can, when a claim is settled, owe each other money, for instance:

• Claimant owes insurance company or the service partners some deductible/depreciation/vat.
• Insurance company owes service partners some compensation regarding invoices, or the claiment some cash compensation.
• Service partners owes some money to the insurance company in form of a credit note.

Everytime some party owe another some money, the settlment logic lists this as an obligation, which can be though of as a money transaction. It would not be feasible to execute all of these, so therefore the output of a settlement is a list of all these unoptimized transactions (obligations), then a list of optimized, or collapsed transatctions, which is the actual payments.

Examples

The settlment logic has over the years been tailored to the different insurance companies policy. This entails a lot of insurance company specific settings which will alter the way the settlement looks. Some insurance companies will have the service partner collect the deductible, and some will collect the deductible them selves.

Following is a list of examples and then a collection of common uses for this data.. The examples use abrevations for the different parties listed in the table in section Settlement Logic.

Simple Property claim

A usual HUB Property claim will have one claimant/policy holder, one or several service provider and the insurance company.

The service provides will do some work and file the claimant some invoices which needs to be paid, but the claimant only need to pay an amount equal to his deductible, the rest will be covered by the insurance company.

Claim information:

Expenses:

Two invoices from one service partner

Obligations:

Obligation #1 states that the claimant owes the Service partner 1000 because of deductible in regards of invoice #1. Obligation #2 states that the IC then compensates invoice #1 minus the deductible already subtracted in obligation #1. And lastly obligation #3 states that the insurance company should compensate the full amount of invoice #2.

This can be translated directly to double entry bookkeeping t-accounts as illustrated in following table:

Payments:

This yields two payments, as the payment between Claimant and Service partner is not listed (can be turned on by setthing though). Payments are usually not collapsed between expenses, which in this case would yield only one payment to service partner of 7000, but can be turned on via setting if wanted.

claimant own work and repair

Claim information:

Expenses:

Here we have the same schenario as the Simple Property claim example, but this time the claimant has also done some work on his own for which he should be compensated.

Obligations:

Here the settlement engine decides that the deductible should be taken from the Claimants own work expense. Since an claimant own work expense is the claimant invoicing the insurance company, and deductible is some share of the claim which the claimant should pay, the claimant in this case reduces the claimant own work expense with the deductible, hense the from claimant to claimant obligation #1.

Some money should still be payed to the claimant which yields obligation #4.

The two repair invoices are paid in full by the IC.

The obligations illustrated as double-entry bookkeeping t-accounts:

Payments:

Extra payment is added for the IC to pay some compensation to the claimant.

Repair and credit note

This next example, the craftsman files an invoice, but then sends a credit note for some of the amount. Deductible and depreciation are applied as well.

Claim information:

Expenses:

Obligations:

In this example, the depreciation is collected by the craftsman, but the deductible is handled by the insurance company. The credit note is deducted from the expense.

The obligations illustrated as double-entry bookkeeping t-accounts:

Payments:

The payment of 4000 in depreciation from the claimant to service provider is omitted here, and the deductible and compensation from insurance company are collapsed into one payment to the service partner.

The last payment is deductible to the insurance company.

Common questions

Here is a list of common uses of obligations. The examples are given in sql/linq like psudo code.

Deducted from expense

When the amount to be payed on an invoice does not match the amount on the invoice, it's usually because the claimant should pay part of it, either in deductible, depretiation or vat.

How much deductible was applied to a given expense, can be extracted like:

From
    obligations
where
    expense = {expense} AND
    type = 'deductible' AND
    from = 'CL'
select sum(amount)

We find all obligations related to one expense which has type deductible and are payed by the claimant, and then sum them together.

This is equivalent of asking, how much of this expense should the claimant pay in regards to deductible.

type can be substituted with:

• Deductible
• Depreciation
• Vat (HUB Property only)
• Manual reduction (ClaimShop only)

JSON Schema of case_settled

• Please refer to the JSON Schema

JSON examples of case_settled

• Please refer to the JSON Example of case_settled