Accounting Setup

Introduction

Insureflow's acocunting model is inspired by Martin Fowler's "Accounting Patterns" paper.

The accounting system is designed to work in an event-based manner, the event that occurs is always a source (such as binding a risk). This means that no matter what you trigger, the same thing happens and rules for the event source are what governs the accounting action.

Rules - What postings should be created for the source? What numbers should be used for this posting?

Validation - There is primary and secondary validation, see Accounting Validation

Example Walkthrough

The following video runs through how an event works, along with some raw data examples and backend information.

https://gaveaonline-my.sharepoint.com/personal/afoot_insureflow_co_uk/_layouts/15/stream.aspx?id=%2Fpersonal%2Fafoot%5Finsureflow%5Fco%5Fuk%2FDocuments%2FRecordings%2FMeeting%2D20240521%5F103109%2DMeeting%20Recording%2Emp4&referrer=StreamWebApp%2EWeb&referrerScenario=AddressBarCopied%2Eview%2Eb33e9a5e%2D2966%2D48d6%2Dac0c%2Dfdcb6e9c331f&ga=1

Accounting Events

There are 3 levels of events in Insureflow accounting:

  • Business Event - Any single button click that creates the financial movement

  • Accounting Event - A more discrete level of grouping, eg. a single premium row in an overall risk

  • Posting - Individual accounting entries linked to specific data

Order of events: A Business Event triggers one or more Accounting Events and they create two or more Postings.

Example: A risk with 5 premium sections would have 1 bind event, and 5 accounting events (one for each premium), creating a number of postings, determined by the configuration and context.

Triggering an Event

An event is triggered in the UI based on certian actions:

  • For bind actions, it is configured as an action button through Umbraco. Use the "execute" action with function "CORE_CREATE_POSTINGS"

  • Contra actions use the "CORE_CONTRA_POSTINGS" function, through the same "execute" action

  • Core events (create cash, allocate cash, declarations, reserve movements and claim payments) require no configuration and will automatically run the configured business events in Umbraco.

Posting Rules

These rules are configured through Umbraco, in the "Credit Control" folder.

Property
Description

Business Event Name

Business Event Description

Business Event Type

High level categorisation of the type of event running

Business Event Source

Defines the level at which the business event runs and its type of source.

Replacement Business Event

*Depricated*

Business Event Is Contra

*Depricated*

Accounting Events

A container of accounting events. See Accounting Specification Table

Accounting Specification Table

Property
Description

Accounting Event Name

Accounting Event Description

Accounting Event Category

Defines the level at which the accounting event runs and its type of source. Eg. When binding the premium, source = premium

Accounting Event Postings

These are the debits and credits and the data associated to them. See Postings Specification Table

Postings Specification Table

Property
Description

Posting Name

Posting Description

Posting Account

The posting account

Posting Type

The type of posting/data going into the account

Posting Category

Only applicable for bank account or tax, this is used which bank account or tax the posting is for

Settlement Posting

Defines whether the posting will be settled as a recievable or as a payable

Posting DRCR

This determines whether the posting is Debit/Credit by default

Function

Posting functions contains the rules for the specific posting

Posting Secondary Validation

If enabled, secondary validation will run

Posting Include Binder Data

If enabled, the binder data will be included in the posting entry, so that it can be used to distribute funds to carries at the correct proportions

Accounting Validation

The primary validation for accounting makes sure that the credits and debits add up to 0. This only validates the final number (overall posting).

There is also the option to add secondary validation on a per-posting basis, it will run subset validation for all postings that have it enabled, making sure the subsets add up to 0.

Script: CORE_CREATE_POSTINGS

  • Gets a load of data from the risk

  • Sets some values

  • Creates the business events based on the Umbraco configuration and inputs context-related data

  • Creates the accounting events based on the Umbraco configuration and inputs context-related data

  • Creates the postings based on the Umbraco configuration and inputs context-related data

  • All events are marked with a status of "invalid" to begin with, this is modified later on in the script

  • After creating all of the postings, script will entries in to database tables "postings" or "postings-invalid" depending on the status

MongoDB: Postings

There are 3 database tables for postings: "postings-staging", "postings" and "postings-invalid". All postings start in "postings-staging". If there are no issues they get placed into the "postings" table, if not then they go into "postings-invalid".

Statements

Config for creating Broker Statements.

  • Create the Broker Statement Document on VS and publish on SourceTree

  • Add the BrokerStatement Document under the Document Vault Configuration of Broker Statement document on Doc Vault

  • Document Type = Statement

  • Function = UI_Data_Statements

  • Priority = Low

Top Level Product setup

  • Top Level Product > Brands > Brand Statement Template > Choose the Broker Document added in the Doc Vault

User Permissions

  • Access_Accounting

  • Access_Accounting_Statements

Last updated