Transactions

Transactions are the heart of commissions. The transaction flow will vary by industry, but will typically take the form of a monthly transaction per customer (exception being the Retail industry). These monthly transactions represent the paid premiums associated with the customers’ policies or coverage. While the way transactions are managed will vary depending on the needs of the business, the most commonly defined activity is a monthly paid premium for each active customer that may include premiums, eligible counts, claims expense or other data that is eligible for commission.

Before we go into the process flow for importing and posting transactions, let’s review the key transaction tables. For more detail, see Lesson 1 of the Appendix to the course.

As we saw in the unit on data integration, TranHead records are imported via an import table called InTranHead. However, the transaction posting process does much more. It is during the posting process that the calculation takes place.

During the Transaction posting process, InTranHead records are converted to TranHead records and a broker specific TranHis record is created for every broker found during the Broker Detail lookup process. TranHis records are also updated with additional information derived or computed as part of the payout process.

After computation is complete, a BrokerHistory record is created for every TranHis record that was computed for the first time or recomputed and an adjustment was created from the Computation task in Payout. Additional BrokerHistory records can be created without a TranHis or TranHead through Bonus Calculations or Manual Adjustments being created as part of the payout.

BrokerHistory records are the final payment records created by the payout process, and are locked once the payout has been finalized.

When a transaction enters the APM system, it contains minimal detail. Before it can be posted, we need a process to populate the transaction with necessary data from the policy, customer and broker records. This is done using a Global Transaction Default.

Typically, a transaction would include the following information:

• CustomerID
• PremiumDueDate
• Financial Entity
• Transaction Type (INCOME, COUNTS, etc.)
• Product
• PremiumReceived/Member Counts

However, this isn’t enough detail to calculate the commission. We need to ensure that the correct producer is paid, that they are paid the right amount, and the ERP extract is distributing the payment across the correct Lines of Business. Therefore, at a minimum, the system also needs the following information:

• Broker Number
• Broker Detail Number
• Vendor Number
• Broker/Vendor relationship
• Schedule
• Schedule Grid
• Formula

Global Transaction Defaults allow us to populate data on the transaction that’s needed for calculating commissions, reporting, AP extracts and other output. Data can be populated directly, or it can be derived or modified though the use of expressions.

Let’s look at an example.

A transaction comes in for a policy sold to Page Mortgage Group with the following information:

• Customer ID: AF2005 – Page Mortgage Group
• Premium Due Date: January 20, 2022
• Transaction Type: Income
• Product: Group Term Life Insurance
• Amount: US$2500

This isn’t enough to calculate the commission. For example, we don’t know who the writing agent or agency is, the location, policy age, and other information that tells us what the commission rate will be. The Global Transaction Default tells the system how to pull this information and add it to the transaction

Now that we have configured the Global Transaction Default, we can import and post our transactions. As we saw earlier, posting transactions uses the Global Transaction Default settings to populate the Transation Detail with data from other tables; then, the commission is calculated from a Schedule.

Once the Post process is complete, the transactions will be visible in the Manager portal under Inquiry – Transaction Search.