Using Financials as a broker ledger

Pay As Paid

Pay as Paid processing is required in a Broker ledger because the business entity is acting as an intermediary between two other parties. It is receiving funds from one party and then remitting these funds to a third party. In this situation it is vital that the funds have been received from one party before they are paid to the other party. For example, in a simple case the broker receives a premium from a client and then (and only then) pays this premium to the policy underwriter.

This means that the 'credit element' of a business transaction needs to be withheld until the associated 'debit element' has been received. In Financials terms, this means some transactions must be withheld from payment until the related transactions have been matched.

To facilitate pay as paid, Financials is able to:

• identify all of the ledger transactions that make up a 'business transaction'. For example it needs to be able to identify all of the postings relating to a premium or claim. It uses an intra-transaction link reference to do this.
• distinguish between the different parties involved in the transaction, that is the client and underwriter. This is determined by the Agency/Broker Account Type set on each account using Chart of Accounts (COA).
• distinguish between the cash and non-cash postings that are made to an account. This is identified by the Posting Type set on a journal type using Journal Types (JNT).

When Financials is operating as a Broker ledger, it performs many different processing tasks automatically to ensure that the pay as paid principles are always applied, unless they are overridden.

Many of these tasks are triggered by allocation codes that are set automatically when particular allocation actions are recognised by the particular system functions.

For example, when a premium journal enters Financials, Ledger Entry (LEN) or Ledger Import (LIM) automatically sets the allocation marker on the credit transactions to Withhold to ensure they are not paid until payment is received from the client for the credit transactions. This processing is triggered in Ledger Entry (LEN) and Ledger Import (LIM) by the Releasing Collectable allocation action. Then, when cash is received from the client and matched against the debit transactions, the Withhold indicator is automatically removed from the corresponding credit transactions to release them for payment to the underwriter. This release processing is triggered by the Releasing Payable allocation action.

Principal to Principal

The purpose of the principal to principal functionality is to enable the broker to easily identify:

• for each client, the underwriters that are underwriting the premiums and claims.
• for each underwriter, their position with each client.

On larger policies, the risk is often spread across a number of underwriters, in a hierarchical structure. There may be several levels in this structure and the same underwriter may appear at more than one level. This structure can be identified on the transactions in Financials, and used as the basis for inquiries and reports. In addition, transactions can be matched and settled at different levels within this hierarchy.

The principal to principal hierarchical information must be imported from an external system using Ledger Import (LIM) as it cannot be entered or maintained directly through SunSystems.

Principal to principal information can be viewed within SunSystems using filters and control desks.