# Simplified Accounting Example



import Image from 'next/image';

Overview [#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:

<Image src="/images/accounting_example/accounting_example_01.png" alt="accounting example 01" width={600} height={173} unoptimized />

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

<Image src="/images/accounting_example/accounting_example_02.png" alt="accounting example 02" width={600} height={200} unoptimized />

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:

<Image src="/images/accounting_example/accounting_example_03.png" alt="accounting example 03" width={700} height={178} unoptimized />

We repeat this for the second installment:

<Image src="/images/accounting_example/accounting_example_04.png" alt="accounting example 04" width={700} height={140} unoptimized />

<Callout>
  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.
</Callout>

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:

<Image src="/images/accounting_example/accounting_example_05.png" alt="accounting example 05" width={700} height={275} unoptimized />

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*:

<Image src="/images/accounting_example/accounting_example_06.png" alt="accounting example 06" width={700} height={280} unoptimized />

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

<Image src="/images/accounting_example/accounting_example_07.png" alt="accounting example 07" width={700} height={280} unoptimized />

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

<Image src="/images/accounting_example/accounting_example_08.png" alt="accounting example 08" width={700} height={292} unoptimized />

And pay off the invoice in full:

<Image src="/images/accounting_example/accounting_example_09.png" alt="accounting example 09" width={700} height={280} unoptimized />

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:

<Image src="/images/accounting_example/accounting_example_10.png" alt="accounting example 10" width={700} height={288} unoptimized />

Summary [#summary]

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

<Image src="/images/accounting_example/accounting_example_11.png" alt="accounting example 11" width={700} height={287} unoptimized />

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 [#see-also]

* [Basic Double-Entry Accounting Primer](/features/financials/accounting-primer)