Simplified Accounting Example

Overview

Here we show the accounting representation of a sequence of operations in Socotra:

  • A policy is issued with charges for $100 premium and $20 in tax.

  • Two installments are created, with the charges evenly split between them.

  • An invoice is issued for the first installment, for half the amounts ($50 premium and $10 tax.)

  • A payment is made for $30, which is applied to the invoice but not fully paying it.

  • A second payment is made for $60, which fully settles the invoice and leaves a credit left over for use later.

First we start with T-Accounts for the charges, an equity account and two asset accounts to hold the two charges:

../../_images/accounting_example_01.png

Then we post a transaction establishing the premium and tax charges:

../../_images/accounting_example_02.png

Note that the equity account is a “credit-side” account, and so it increases with the credit side of the transaction, and the “debit-side” asset accounts increase with the opposite, debit side of the transaction.

After charges are established, we create the first installment based on the charges. When we do this, the asset stored in the charge is transferred to the installment itself:

../../_images/accounting_example_03.png

We repeat this for the second installment:

../../_images/accounting_example_04.png

Note

The system actually will do the accounting at the installment item level, rather than the installment level as shown above. We’ve simplified the view to make the flow easier to understand.

It’s likely that the timing configured for invoicing will result in the first invoice being generated right away. To do this, all the installments that have reached their generateTime are grouped and put on an invoice. Here, there’s just one:

../../_images/accounting_example_05.png

When a payment is posted, it establishes a liability (because at the moment it is received, it is still the insured’s money), and this is balanced against the asset called Cash:

../../_images/accounting_example_06.png

The payment can then be applied, but this one isn’t sufficient to fully pay the open invoice:

../../_images/accounting_example_07.png

When a second payment comes in for $60, we post it as before:

../../_images/accounting_example_08.png

And pay off the invoice in full:

../../_images/accounting_example_09.png

Because there’s $30 remaining in the payment, we’ll store it in the insured’s credit balance, where it can be applied or disbursed later:

../../_images/accounting_example_10.png

Summary

After all the transactions are posted, we can examine the state of the policy as it stands:

../../_images/accounting_example_11.png

From this, we can prove that:

  • There are charges on the policy totalling $120, with $100 in premium and $20 in tax

  • This has been split evenly between two installments

  • One installment has been invoiced and fully paid

  • Another installment has yet to be invoiced

  • The insured has made payments totalling $90, of which $60 was used to pay the first invoice and $30 remains as a credit

Because accounting transactions also store the time they were created, we can determine the exact sequence of events and use this to explain the history of the policy.

See Also