Overview of FS-CD Master Data - SAP Collections and Disbursements (FS-CD)

SAP Collections and Disbursements (FS-CD)

Overview of FS-CD Master Data

© SAP SE, 2015, Jochem Schueltke

1. SAP Collections and Disbursements (FS-CD)

The SAP for Insurance software application ‘Collections and Disbursements (FS-CD)’ provides proven functions to insurance companies and re-insurers for automated cash relevant posting and payment processing, in particular

• posting all to-be-paid receivables and payables that are insurance related,
• processing customer-initiated incoming payments (e.g. cheque, incoming bank transfer, or electronic fund transfer),
• creating insurer-initiated incoming payments (e.g. direct debit, debit memo procedure, credit card collection, or deposit account withdrawal),
• creating outgoing payments (e.g. outgoing bank transfer, electronic fund transfer, or money transfer to credit card),
• balancing (offsetting) receivables with payables through automatic account maintenance,
• managing deposit accounts, including automated withdrawal,
• posting and settling coinsurance premium shares, related commissions, and charges,
• posting and settling incoming or outgoing payments with third parties, which do collections or disbursements on behalf (e.g. Broker Collections and Submitting Receivables to Collection Agencies),
• creating and issuing correspondence that is related to postings (e.g., invoice, account statement), payments (e.g. payment form, payment note, receipt, outgoing cheque, outgoing payment advice, direct debit notification), or to exceptions (e.g. reminder, dunning letter, return notice, deferral and installment plan agreement), and
• Updating general ledger, based on summarized documents as well as reconciliation with financial accounting, considering all cash flow relevant insurance related receivables and payables as well as associated revenues (profits) and expenses (losses).

SAP Collections and Disbursements supports various lines of insurance business, insurances types, currencies, incoming and outgoing payment methods within one system. On the one hand it is designed for automated billing and payment handling, especially regarding high volume of transactions. On the other hand all master data and transactional (posting) data contain detailed attributes, especially to apply different legal and business rules. These rules can be configured customer-specific, utilizing reasoned SAP Customizing in combination with robust enhancement possibilities, if required.

2. FS-CD Master Data ensure fast and accurate high-volume processing

Different policy management systems, claims systems, commission systems, re-insurance systems and other calculating as well as operationally leading insurance systems can be integrated into one SAP Collections and Disbursement instance. For example different policy administration systems, claims management systems, commission systems, or re-insurance systems - used within a group of affiliated insurance companies - can be integrated into one and the same SAP FS-CD system and client.

Any feeder system can collaborate real-time (online) with FS-CD, mainly depending on its capabilities. Therefore SAP offers appropriate eSOA Enterprise Services for Insurance Billing and Payment, or alternatively classical Business Application Programming Interfaces (BAPIs), exposing Remote-Function-Call-enabled Function Modules (RFC). In addition these RFC Function Modules can be encapsulated into Web Services and exposed through Web Service Technologies in the Application Server (please see also ABAP Web Services).

In addition FS-CD includes powerful outbound interfaces named ‘Information Containers’, which can send structured information to different external systems, primarily for submitting FS-CD process results. These Information Containers are intended to transfer data back towards various feeder systems - either near-time, or scheduled automatically at a later point in time. FS-CD can also trigger external functions, which are provided by these feeder systems, if they are able to be ‘controlled remotely’ (e.g. they provide RFC Function Modules that can be called out of FS-CD).

But real-time integration and operation is not mandatory, but strongly recommended. Over and above FS-CD provides ‘traditional’ methods to transfer data, especially through file transfer via Direct Input.

Also mixed scenarios are broadly supported, which combine for example [A] real-time creation and maintenance of FS-CD Master Data, utilizing Enterprise Services or RFC Function Modules together with [B] classical file transfer, utilizing Direct Input for high-volume transactional data (so-called ‘Payment Plan Items’, please see Interface and Data Transfer Tools and Payment Plan Interface).

Overall SAP Collections and Disbursements comprises high-performance in mass processing. To guarantee extensive automation, while taking detailed legal and business rules into account, FS-CD provides meaningful Master Data, as follows:

1. Business Partner
2. FS-CD Contract Account with its relationship to Business Partner
3. FS-CD Insurance Object with its relationship to Business Partner
4. FS-CD Payment Plan assigned to an InsuranceObject-BusinessPartner-Relationship

On the strength of these Master Data FS-CD is able to process Transactional Data (Payment Plan Items) ‘autonomously’; presupposed that a feeder system delivered these Master Data and the Transactional Data (Payment Plan Items). Thereafter FS-CD doesn’t need to permanently call the relevant feeder system, or to be called from a feeder system for executing each and every transaction. Altogether these Master Data and Transactional Data guarantee self-reliant billing and payment processing in FS-CD, while minimizing data exchange with various feeder systems, and avoiding back and forth for business process control. Because of these Master Data hold powerful attributes to control FS-CD processes and transactions, they are named ‘Control Parameters’.

With respect to these control parameters FS-CD can handle transactional data accurately without ‘asking’ a feeder system over and over again, or without ‘getting told’ from a feeder system what and how to do for each and every transaction in particular.

When an FS-CD Document is processed in any transaction or mass activity, the control parameters of the relevant ContractAccount-BusinessPartner-Relationship, InsuranceObject-BusinessPartner-Relationship, and – optionally – Payment Plan are considered on principle. The direct impact of Master Data is already evident, when one or multiple Payment Plan Items are transformed into a posted Document.

Based on my experiences many consultants and customers have often underestimated the power and flexibility of FS-CD Master Data. They have tried to control billing and payment processes primarily by Transaction Data; means through Payment Plan and Payment Plan Item attributes, which are persisted in each Open Item – means a Business Partner Line Item (within an FS-CD Document). In a couple of implementation projects this approach caused disproportional extra implementation effort as well as unnecessary complexity.

Thus being said, studying FS-CD Master Data including all Control Parameters is a valuable exercise, which pays off shortly.

3. FS-CD Master Data

3.1. Business Partner

Each posting and transaction in FS-CD is related to a particular Business Partner. Moreover the ID of a Business Partner is the primary key in almost all FS-CD tables, not only for Master Data, but also for Transaction Data (Postings / Open Items / FS-CD Documents). In terms of data modeling a ‘Business Partner’ is a business object that belongs to the SAP software component with the same name ‘SAP Business Partner’.

In context of FS-CD all Business Partners are relevant that act as insurance-related debtors, creditors, payers, payees, or correspondence recipients with regards to billing, payments, collections, or disbursements. In insurance terms these Business Partners are for example: policyholders, alternative premium payers, insured, beneficiaries, group or collective insurance parties (e.g. employers, employees, or associations), agents, brokers, claimants, injured parties, service partners, doctors, hospitals, appraisers, adjusters, repair shops, rental car companies, towing services, partner insurers in co-insurance, re-insurers, and other payers or payees.

SAP Business Partner Master Data is essential from a business or legal perspective as well as from a technical point of view in FS-CD. All Business Partner data, which are utilized in any context of Collections and Disbursements, have to be persisted in the SAP component named SAP Business Partner. SAP Business Partner is a basic software application that is seamlessly integrated into all SAP for Insurance software components. SAP Business Partner must be installed as a software application, configured and used operationally within one and the same SAP System where SAP Collections and Disbursements (FS-CD) is also running.

The SAP Business Partner is the central SAP software application for saving and managing all customer information. Any Business Partner can be created using the regular SAP User Interface (e.g. SAPgui, SAP NetWeaver Business Client, please see Processing Business Partner Data), as well as through different interfaces (please see Maintaining SAP Business Partner Data, Replication and Synchronization of Business Partners, and SAP for Insurance - SAP ERP Central Component - Release 6.0 - Release Notes).

Thus being said, all required business partners and their attributes can be created and completely maintained ‘remotely’ from any external system or software application, which has appropriate capabilities. Overall it’s possible to operate SAP Business Partner in ‘slave’ mode, including entire data creation and maintenance; means controlled by an external Non-SAP system, please see General Introduction to BAPIs (CA-BFA) and SAP Enterprise Services WIKI - Business Partner. In addition these ‘traditional’ BAPIs can be wrapped into Web Services and exposed through Web Service Technologies in the Application Server (please see also ABAP Web Services).

SAP delivers three different predefined Business Partner Categories: (A) ‘Person’, (B) ‘Organization’, and (C) ‘Group’. In general a Business Partner can only be created in one of these three Categories. Subsequent Change - after creation - of an initially selected Category is not supported in standard.

Business Partner data include name and address, payment transaction data (e.g. bank details, payment or credit cards), supplementary data depending on the Business Partner Category (e.g. date of birth as personal data for a natural person, or legal form as company data for an organization), Business Partner Roles, legitimation data, creditworthiness, ratings, fiscal year information, partner numbers in external systems,and Business Partner Relationship (for example husband and wife, parent and child, father and son, company holding and subordinated subsidiary, company and contact person).

A Business Partner can have multiple Business Partner Roles in parallel. With other words: you can assign different roles in parallel to a Business Partner. Each Role can be time-independent, or time-dependent; means autonomously per Business Partner Role.

For technical reasons the role ‘Contract Partner (MKK)’ needs to be assigned to all Business Partners, which are relevant for FS-CD in general – independent from the fact whether they are debtors, creditors, payers, payees, or correspondence recipients. This can be done via default assignment, which is applied automatically, when a Business Partner is created.

Every Business Partner can have multiple Addresses in parallel, if required. Each address can have its own valid from date and valid to date. At least one address has to be maintained. If several valid addresses exist in parallel, only one of them can be marked and used as the Standard Address at a certain point in time. An explicit move regarding the Standard Address is supported out of the box.

You can allocate a specific Address-Usage to an address, which can be configured project-specific. The assignment of an Address to a particular Address-Usage provides a valid from date and valid to date; means the usage can be made time-dependent.

A Business Partner of Category ‘Organization’ can be assigned to multiple Industries in parallel, but just one as the Standard Industry. It is possible to configure a customer-specific Industry System (catalog).

Cross all Categories a Business Partner can be identified by one or different several Identification Numbers (Identifiers) in parallel. SAP delivers several proposals of ID Types (e.g. passport), which can be configured and enhanced customer-specific. Per ID Type a dedicated validation check can be implemented. Therefore, SAP delivers sample validation checks.

You can assign a Tax Number, or - if required - several Tax Numbers in parallel to a certain Business Partner. Therefore SAP delivers some country-specific Tax Number Categories that provide appropriate validation checks accordingly, which can be enhanced customer-specific.

Furthermore, SAP provides also a ‘Where-used List’ for business partners. It gives an overview where a Business Partner is used, in relation to other business objects (e.g. policy, claim, commission contract, contract account, re-insurance treaty) cross software components. The ‘Where-used List’ can be accessed either from the business partner master data, or using the SAPphone functions. From the list, one can branch to the various related business objects, to which the business partner is linked. It is possible to add customer-specific where-used relations and attributes without modification.

All Bank Details of a Business Partner (e.g. payer, payee, policyholder, premium payer, beneficiary, and claimant) are persisted within the Master Data of this partner. With other words: if a Business Partner holds several banking accounts in parallel, all of them are stored within his or her ‘Payment Transactions’ data (that are an essential part of Business Partner Master Data). Thus, the technical reference that points to a certain banking account of a particular business partner consists of both, the ID of this Business Partner and the ID of his or her Bank Detail.

The same principle applies to payment cards or credit cards; means all payment cards of a Business Partner are also stored within his or her Payment Transactions Master Data.

In general, Bank Details and Payment Cards (Credit Cards) belong to a certain Business Partner, which shall be the holder of each bank account or credit card that is persisted within his or her Business Partner Master Data. For example: if a husband is the policyholder - Business Partner ‘A’ - related to a certain policy, but his wife pays the premiums via direct debit (using her bank account), you must not store her (Premium Payer) bank details within his (Policyholder) Business Partner Master Data. Instead, the wife has to be reflected as a separate Business Partner ‘B’, maybe with an appropriate Business Partner Relationship (e.g. has husband) to Business Partner ‘A’. Moreover, this Business Partner ‘B’ (Premium Payer) must be assigned and utilized as an alternative Payer (e.g. Business Partner Number ‘100293787’), together with the reference that points to her Bank Account (e.g. Bank Details ‘0001’).

In this regard SAP provides a central data structure named ‘BUS_DI (Business Partner: Transfer structure)’ that contains all Business Partner related attributes. It corresponds to the RFC Function Module ‘ISCD_PARTNER_MAINTAIN’ to create and maintain Business Partner Master Data from any external system or software application. Please consider also the Business Partner Interface for Direct Input, which provides you with an overview.

3.2.  Contract Account with Relationship to Business Partner (ContractAccount-BusinessPartner-Relationship)

The central place regarding all postings in FS-CD is the Contract Account; means all to be paid receivables and payables are posted on a Contract Account. It acts as a container for all FS-CD Documents. A Contract Account is the ‘hub’ to manage billing (invoicing), payment and clearing (offsetting) transactions, controlled by general Master Data attributes. In terms of data modeling a Contract Account is a business object that belongs to the SAP software component SAP Collection and Disbursements (FS-CD).

From a business perspective an FS-CD Contract Account is a universal ‘subledger account’ to post all cash flow relevant receivables, payables, incoming payments, outgoing payments, clearings, resets, and cancellations, represented through FS-CD Documents. In this context ‘universal’ means that an FS-CD Contract Account can be used for all categories and lines of insurance business, and for all types of receivables, payables, incoming payments, or outgoing payments – such as premiums, deposits, commission payables, claims payables, benefit payables, claw backs, subrogations, charges, taxes, or interests among others. Moreover, it can be linked to all business partner categories, which are debtors, creditors, payers, or payees related to the entire insurance business.

In general a Contract Account can’t be created autonomously, but must have a relationship to at least a Business Partner (ContractAccount-BusinessPartner-Relationship).

SAP provides several attributes within the Master Data on level of a Contract Account itself; means these control parameters are partner-independent (see cross-partner Control Parameters on Contract Account level). Technically these attributes are persisted in table ‘FKKVK - Contract Account Header’. Among other control parameters these are: Contract Account Category, Outside Account View, and Account Management.

The Contract Account Category is a control parameter that belongs to the cross-partner Contract Account Master Data (Contract Account Header), affecting all ContractAccount-BusinessPartner-Relationships, not only to the Account Holder (Owner), but also to all other Business Partner that are eventually related to the Contract Account. The Contract Account Category defines contract accounts, which shall have the same fundamental characteristics. When a Contract Account is created, a Contract Account Category has to be specified. This can be done automatically (by default values). You can’t assign another Contract Account Category to an existing Contract Account after it has been created.

The Outside Account View is a different control parameter that belongs to the cross-partner Contract Account Master Data (Contract Account Header). It is a criteria to group items for Invoicing, and for the Payment Program. Following two view types are supported:

• Individual view
  If Individual View is set as ‘Outside Account View’ the items that are posted on a Contract Account are grouped by each Insurance Object, so that an own invoice (using the Invoicing function) or direct debit, debit memo, and outgoing bank transfer (using the Payment Program) is created separately per Insurance Object with its Relationship to Business Partner. Thus, the Insurance Invoicing as well as the payment program considers the Insurance Object as a key differentiator.
  
  This principle can be strengthened and applied also to other FS-CD transactions and further mass activities. Within Master Data of all InsuranceObject-BusinessPartner-Relationships, which are assigned to one and the same Contract Account, you can set the collections and disbursements parameters as well as the correspondence parameters ‘active’ on level of the Insurance Object. In this case the control parameters, which belong to the Master Data of an InsuranceObject-BusinessPartner-Relationship are decisive for steering FS-CD transactions and mass activities. Thus, the Insurance Invoicing as well as the Payment Program considers the Insurance Object (with its relationship to a Business Partner) as a key differentiator.
  
  
• Collective view
  If Collective View is set as ‘Outside Account View’ all items that belong to a Contract Account are grouped on level of the Contract Account itself; means cross different Insurance Objects. Even if several Insurance Objects (with their Relationships to a Business Partner) are assigned to one Contract Account, you can create an invoice, direct debit, debit memo, or outgoing bank transfer that includes all items that are existing on this account. Thus, the Insurance Invoicing as well as the Payment Program considers the Contract Account (with its relationship to a Business Partner) as one unit.
  
  Within Master Data of all InsuranceObject-BusinessPartner-Relationships, which are assigned to one and the same Contract Account, you can set the collections and disbursements parameters as well as the correspondence parameters ‘active’ on level of the Contract Account. In this case the control parameters, which belong to the Master Data of a Contract Account (Header, cross-partner) or a ContractAccount-BusinessPartner-Relationship are decisive for steering FS-CD transactions and mass activities.

In general each Contract Account must have a Contract Account Relationship with at least one Business Partner, which is the Holder of this Account. The appropriate Relationship Category ‘is Holder’ is intended for this case. Except Deposit Accounts you can assign several different Business Partners in parallel to one and the same Contract Account. That means multiple further Contract Account Relationships can exist with different other Business Partners in parallel, but these are based on the Relationship Category ‘is other Partner’.

Only one Business Partner can be the Holder of a Contract Account (Relationship Category). Of course the Holder of a Contract Account can change over time; means that the Contract Account Relationship ‘is Holder’ for this Contract Account can be switched to the ‘is other Partner’ Relationship Category regarding Business Partner ‘A’, if another Business Partner ‘B’ assumes the Contract Account Relationship ‘is Holder’ at the same time.

Thus being said, SAP provides various control parameters within the Master Data on level of a ContractAccount-BusinessPartner-Relationship; means differentiated per Business Partner that is related to a Contract Account.

Technically these attributes are persisted in table ‘FKKVKP - Contract Account Partner-Specific’. Among other control parameters these are <excerpt>: Company Code Group, Standard Company Code, Incoming Payment Method, Alternative Payer, Bank Details ID for Incoming Payments, Outgoing Payment Methods, Alternative Payee, Bank Details ID for Outgoing Payments, Own Bank Details, Alternative contract account for collective bills, Dunning Procedure, Dunning Strategy, Contract Account used for Payment Transactions, Authorization Group, Tolerance Group for Contract Account, Clearing Category for Clearing Postings, Clearing Restriction, and Correspondence Variant.

In this regard SAP provides a central data structure named ‘FKKVK_DI (Contract Account: Transfer Structure)’ that contains all General Data on level of a Contract Account itself (Header, cross-partner) as well as all attributes on level of its Relationship to a certain Business Partner. This structure corresponds to the RFC Function Module named ‘ISCD_ACCOUNT_MAINTAIN’ to create and maintain Contract Accounts with their Relationships to Business Partners from any external system or software application. Please see also the Contract Account Interface for Direct Input, which gives an overview.

Considering these different attributes and their impact on controlling FS-CD transactions and mass activities, it’s obvious that the more detailed control parameters belong to the ContractAccount-BusinessPartner-Relationship Master Data (not to the cross-partner Contract Account Master Data).

Master Data of a ContractAccount-BusinessPartner-Relationship can be changed automatically by certain business transactions. In this way, for example, a return (refusal) subsequent to a faulty direct debit or a faulty debit memo procedure can result in a temporary payment lock being set within this Master Data - to avoid processing of the next insurer-initiated incoming payment too soon, for instance when a payment run is scheduled on daily basis or twice a week. That’s a matter of FS-CD Customizing, which can be decided and implemented customer-specific.

3.3.  Modelling Contract Accounts and Relationships

From an FS-CD perspective a Contract Account is the entity to post and balance (offset) all open items, aggregate invoices or process payments that are initiated by the insurer (e.g. direct debit, outgoing bank transfer), or by the customer.

On the one hand it’s theoretically possible to clear open debit and credit items with each other automatically (based on detailed rules), which are posted on different Contract Accounts, if these open items belong at least to one and the same Business Partner.

On the other hand several fundamental prerequisites have to be fulfilled for supporting this approach, and also relevant control parameters must be identical within the ContractAccount-BusinessPartner-Relationship Master Data and within the InsuranceObject-BusinessPartner-Relationship Master Data. For example, the Clearing Variant must not contain the Contract Account as a grouping or as a selection criteria, and the Business Partner has to be the decisive Parallelization Object. That’s very unusual in practice and unrealistic.

Leveraging FS-CD basic features you can control balancing (clearing, offsetting) of open items, invoicing, creation of correspondence, and payments (by payment program) straightforward within a Contract Account, in particular if the items are related to one and the same Business Partner. Therefore no extra Customizing or configuration effort is required.

In this regard modelling of Contract Accounts has high importance and impact on FS-CD transactions as well as on mass activities. Under this view angle one has to consider various aspects to decide for an appropriate Contract Account structure, such as:

• If a group of affiliated insurance companies consists of several legal entities (Company Codes) that could process collections and disbursements jointly: what aggregation is permitted cross companies? What separation is mandatory? Moreover, can one insurance company act on behalf of one or several other companies in collections and disbursements (e.g. the life insurance company ‘A’ collects also premium on behalf of the property and casualty insurance company ‘B’)?
• How does an insurer – a single legal entity (Company Code) – organize its billing and payment processes overall, for instance strictly divided per category of insurance business (e.g. separated in Life Insurance, Property and Casualty Insurance, and Health Insurance - if operated by one insurer), alternatively per individual insurance business versus group (collective) insurance business, or per customer segments (differentiated by customer target groups)?
• What types / categories of insurance related debits (receivables) and credits (payables) can be posted on one and the same Contract Account, based on legal and business rules? For instance: premium receivables, discount payables, charge receivables, commission payables, indemnity payables, claim expense payables, or benefit payables. What receivable types and payable types must not be posted on one and the same Contract Account in general?
• Which receivable and payable types / categories can be balanced (cleared, offset) automatically with each other, of course considering detailed clearing rules? In contrast, which of these receivables and payables must not be balanced with each other, in general?
• How does an insurer want to aggregate invoices (bills), which are created based on posted open items in FS-CD, as far as allowed?
• How does an insurer want to summarize incoming payments or outgoing payments, which are initiated by the insurance company (e.g. direct debit, debit memo procedure, credit card collection, outgoing bank transfer / electronic fund transfer), presupposed aggregation is legally permitted?
• How does an insurer receive payments, which are initiated by policyholders, premium payers, or other payers (e.g. by cheque, incoming bank transfer, or cash)? How are the bank accounts that the insurer holds are structured in this context?
• On what - segregated or aggregated - level does an insurer want to create invoices, payment notes, notes to payers, and other billing or payment relevant outbound correspondence in FS-CD?
• Does the insurer manage policies, which can contain several different subordinated contracts per policy, including different characteristics per contract regarding collections or disbursements (e.g. dunning)?
• Is it possible that a certain Business Partner is the policyholder of several polices in parallel, which are all based on the same (sales) insurance product? If yes, is it mandatory to keep invoicing, clearing, and payment processing strictly separated by policy? Or is aggregation cross policies even welcome in such a case?
• What is the legally relevant Dunning level, if overdue premium receivables are not paid, or just partially paid (e.g. Business Partner, Policy, or Contract)? What is the maximum allowed ‘superordinated’ dunning level (e.g. all items for the combination of one Business Partner and one line of insurance business)?
• What is the link (reference) between a policy, or a contract and an associated claim?
• On what level an open premium receivable could be balanced automatically - based on rules - with a to-be-paid indemnity, benefit, or claim payable (that refer to the same policy or contract), if permitted? Or in which cases an automated clearing (offsetting) isn’t allowed, but could be processed manually?

All these aspects need to be considered, before FS-CD Master Data are modeled. Furthermore the capabilities of all feeder systems and data quality play a very important role in these regards. Accurate data is essential and required to derive suitable Contract Account Variants, even for scenarios that appear simple at first glance.

Structure and differentiation of Contract Accounts can deviate between several countries significantly, mainly according to law and justice. Furthermore, it depends on customer-specific contractually agreements with policyholders (premium payers, insured, beneficiaries, claimants, etc.) as well as General or Special Terms and Conditions, if either more detailed segregated Contract Accounts, or more aggregated Contract Accounts are advisable.

For instance separate Contract Accounts per customer segment (e.g. private clients, small and medium enterprises, large enterprises), or insurance business categories could be adequate (e.g. divided into Life Insurance, Property & Casualty Insurance, and Health Insurance), if items have to be managed strictly separated - maybe per legal entity (different insurance companies). It could be also the case that a particular insurer, which is a member of an affiliated group of insurance companies, is responsible only for one insurance business category. But: the group of these companies may share one and the same Business Partner data commonly (cross legal entities). If these insurers process billing and payments independent from each other, separate Contract Accounts are strongly recommended.

Furthermore it can make sense to specify different Contract Accounts with separate Contract Account Categories, in terms of business purposes or legal insurance relationships, for instance:

• (1) A ‘Premium Contract Account’ with relationship to a policyholder, an alternative premium payer, a collecting third party (e.g. agent, broker, or employer); It is intended only for premium receivables and payables (e.g. discounts, refunds, paybacks).
• (2) A ‘Commission Contract Account’ with relationship to an intermediary (e.g. captive agent, independent agent, broker, affiliate, or affinity); It is intended only for commission and compensations payables.
• (3) A 'Claim Contract Account’ with relationship to a policyholder, claimant, beneficiary, an injured party, a lawyer, a hospital, a clearinghouse, an accounting center, or a claim service partner; It is intended for claim, indemnity, or benefit payables as well as for reclaim or claw-back receivables (e.g. deductibles, retentions, franchises).
• (4) A combined ‘Premium and Claim Contract Account’ with relationships to all relevant business partners mentioned before. In this context ‘combined’ means that one and the same Contract Account is used for premium receivables as well as for claims payables.

For instance there is a particular Contract Account mapped 1:1 to an FS-PM Policy and vice versa. This FS-PM Policy contains three subordinated FS-PM Contracts. Each of these three Contracts is reflected as an Insurance Object in FS-CD. Thus, there are three InsuranceObject-BusinessPartner-Relationships of type 'FS-PM Contract’, which come from SAP Policy Management (FS-PM), assigned to that Contract Account.
In addition there are two Claims in FS-CM. Each of these two Claims is reflected as an Insurance Object in FS-CD. Thus, there are two further InsuranceObject-BusinessPartner-Relationships, which come from SAP Claims Management (FS-CM). They are also assigned to this Contract Account. Maybe the first Claim belongs to Contract ‘#2’, and the second Claim belongs to Contract ‘#3’. Finally all these five InsuranceObject-BusinessPartner-Relationships are assigned to one and the same Contract Account.
Since all these five InsuranceObject-BusinessPartner-Relationships belong to one Policy, it’s possible to clear all debit and credit items with each other - automatically - according to legal and business rules, based on accurate FS-CD Clearing Control (if permitted). If some of these debit and credit entries must not be balanced with each other, one can consider precise rules per Clearing Step, considering the ContractAccount-BusinessPartner-Relationship specific Clearing Category, the predefined Clearing Type and the Clearing Variant on line item level, if necessary. Please be aware that the Clearing Variant is an attribute of the Master Data within the ContractAccount-BusinessPartner-Relationship. Thus, one can set a specific Clearing Variant per type of a policy (e.g. according to a Sales Product, or to a line of business).

Optionally such a Contract Account can be arranged on level of the Business Partner that is the Holder of this Account. In this case it’s a ‘Business Partner Contract Account’ for all policies and claims, cross lines of business (e.g. for ‘Pooling and Netting’).

• (5) A ‘Third Party Collection Settlement Contract Account’ with relationship to a third party that collects premiums on behalf of the insurer (e.g. collecting captive agent, independent agent, broker, collection agency, or employer); It is intended for aggregated settlement of summarized receivables and payables as a result of third party collection, using FS-CD features and functions for Broker Collection or for Submitting Receivables to Collection Agencies.
  
  
• (6) A ‘Co-Insurance Settlement Contract Account’ with relationship to other insurers that are partners in active or passive co-insurance; It is intended for co-insurance premium shares, claims or benefit shares, commission shares, and charges or expenses.

Usually the business object Contract Account is not known on part of feeder systems, not even the concept of a cash-flow oriented subledger account, including its relationship to a Business Partner.

Very often it’s challenging to convince the sovereigns of policy systems, claim systems, or commission systems to enhance their data model and processes accordingly, especially for seamless data exchange and bi-directional integration with FS-CD – even the entire organization will benefit from these adjustments.

Moreover it takes considerable extra effort to ‘carve out’ billing or collection and disbursement functions, which are inbuilt within home-made ‘monolithic’ policy systems, claim systems, or commission systems that maybe were developed many years ago. This exercise starts always with Master Data. Thus being said, the modelling of Contract Account needs to be done thoughtfully, and is not just an unimportant auxiliary implementation project task.

3.4.  Insurance Object with Relationship to Business Partner (InsuranceObject-BusinessPartner-Relationship)

From a business and legal point of view the Insurance Object– together with the InsuranceObject-BusinessPartner-Relationship– is the most important reference in insurance business regarding billing and payments. An Insurance Object is also the ‘anchor’ for administering and controlling billing (invoicing), payment and clearing (offsetting) transactions on detailed Master Data level. In terms of data modelling an Insurance Object is a business object that belongs to the SAP software component SAP Collections and Disbursements (FS-CD).

From a business and technical perspective an FS-CD Insurance Object is a lean ‘proxy object’. It reflects and persists an extract of all billing and payment relevant attributes, which are created and maintained within an original business object of type insurance policy, insurance contract, claim case, benefit case, commission contract, re-insurance treaty, deposit agreement, or third party collection contract (e.g. collection agreement with a broker, an agent or another third party that collects premiums on behalf of the insurer). With other words: different feeder systems manage polices, contracts, claims, benefit cases, commission contracts, or re-insurance treaties. These original business objects contain – among other data – also billing and payment relevant attributes or basic characteristics, which are mirrored on part of FS-CD by an appropriate Insurance Object as a ‘slave proxy object’; means it represents a subset (extract) of the genuine business object for billing and payment purposes.

Therefore FS-CD provides in standard five predefined internalInsurance Object Categories, as follows:

1. 10 – Insurance contract (policy)
2. 20 – Broker contract (third-party collection agreement)
3. 30 – Commission contract
4. 40 – Claim number
5. 50 – Deposit contract

The first internal Insurance Object Category ’10 - Insurance Contract (Policy)’ characterizes an insurance policy or insurance contract in FS-CD, which is originally managed in a policy in-force business / administration system like SAP Policy Management (FS-PM) for instance. In SAP Policy Management (FS-PM) the original business object is either an FS-PM Policy, or a subordinated FS-PM Contract (that is configurable per Sales Product).

The second internal Insurance Object Category ’20 - Broker Contract (third-party collection agreement)’ describes an agreement between an insurance company and a third party (e.g. broker, agent, employer, affiliate, or association) that collects premiums from the policyholder or premium payer on behalf of the insurer. Such an agreement is usually managed by another in-force business administration system, often including a link to a commission agreement (contract) or to a claim settlement agreement and authorities (e.g. power of attorney for paying specified claims). If, and only if the legal and business content of such an agreement is very simple and restricted, it could be an option to implement it inside FS-CD; means as the leading and maintaining system. Otherwise FS-CD provides a proxy to represent such an agreement through an Insurance Object of Category ’20 - Broker Contract’, which is originally created and administered by a specific feeder system.

The third internal Insurance Object Category ’30 - Commission Contract’ characterizes an agreement between the insurer and an intermediary (e.g. broker, agent, financial service advisor, bank advisor, or affiliate) regarding commissions and incentives related to insurance business. Such a commission contract is usually administered by a commission system, like SAP for Incentive and Commission Management (FS-ICM) for instance. In SAP for Incentive and Commission Management (FS-ICM) the original business object has the same name ‘Commission Contract’ as its proxy in FS-CD.

The fourth internal Insurance Object Category ’40 - Claim Number’ describes a claim or benefit case, which is created and handled in an appropriate claims or benefits management system, like SAP Claims Management (FS-CM) for example. In SAP Claims Management (FS-CM) the original business object is a ‘Claim’, which is represented in FS-CD by its proxy ‘Claim Number’.

The fifth internal Insurance Object Category ’50 - Deposit Contract’ characterizes an agreement between an insurer and a policyholder, premium payer, or other party about payments, interest and withdrawal of a credit balance that is assigned to a specific Contract Account (Deposit Account). This Deposit Account is managed by the insurer. Regularly it’s used to consider advance payments for ‘financing’ upcoming recurring premiums, while granting interests on the remaining money (credit) - until it is consumed, or increased with another / additional advance payment. Such a Deposit Account is always directly linked to an Insurance Object of Type ‘Deposit Contract’. FS-CD provides comprehensive features and functions to maintain Deposit Contracts in conjunction with Deposit Accounts. In addition, FS-CD provides the Payment Method ‘Internal Clearing / Deposit Account’ out of the box for incoming payments and outgoing payments. Overall FS-CD can be utilized as the leading system for managing Deposit Contracts and Deposit Accounts.

From a technical perspective the crucial table on level of the Insurance Object itself is ‘DIMAIOB (IO: Header Data for Insurance Object in FS-CD)’. Amongst other attributes it contains the External Insurance Object Category.

An Insurance Object can’t be created autonomously, it must have a Relationship with at least one Business Partner (InsuranceObject-BusinessPartner-Relationship). The Relationship itself doesn’t have a particular category or another differentiation characteristic in standard.

If an Insurance Object is linked in parallel to two or more Business Partners, all relationships are equivalent to each other; means they are not distinguished into ‘is Holder’ versus ‘is other Partner’ in standard.

FS-CD fully supports external number ranges to identify any Insurance Object. If an insurer has non-overlapping number ranges for different business object types (e.g. Business Partner, Policy, Contract, Commission Contract, Claim, etc.), then the original number can be used – and shall be used – as the ID of the Insurance Object. For example: the original Policy Number of a policy, which is managed for instance in SAP Policy Management (FS-PM), can be utilized 1:1 as the identifier for the Insurance Object that represents this original policy as a proxy in FS-CD; means without prefix or suffix. Of course SAP strongly recommends to keep number ranges disjunctive, regarding all identifiers that are assigned to different business object types – especially if they will be represented by a proxy Insurance Object in FS-CD.

Regarding the InsuranceObject-BusinessPartner-Relationship one of the fundamental tables is ‘DIMAIOBPAR (IO: InsuranceObject-BusinessPartner-Relationship in FS-CD)’. Almost all control parameters are persisted in this table like (excerpt): Dunning Variant, Correspondence Variant, Invoicing Type, Base Date for Invoicing Frequency, Payment Plan Key, Payment Option Key, Alternative Payer, Address Number for Alternative Payer, Incoming Payment Method, Bank Details ID for Incoming Payments, Alternative Payee, Address Number for Alternative Payee, Outgoing Payment Methods, Bank Details ID for Outgoing Payments, Clearing Account, Payment Card ID for Incoming Payments, or Payment Card ID for Outgoing Payments.

• In general an Insurance Object can have multiple relationships to various Business Partners in parallel. With other words: multiple relationships can exist between several different Business Partners and one and the same Insurance Object.
• Various InsuranceObject-BusinessPartner-Relationships (between one Insurance Object and different Business Partners) can be assigned to one Contract Account. At least one of these Business Partners (e.g. policyholder) must be linked to this Contract Account as its Holder, whereas each other Business Partner is just linked as other Partner.
• Alternatively, you can assign each InsuranceObject-BusinessPartner-Relationship to a separate Contract Account. This assignment doesn’t depend on the fact, whether the linked Business Partner is the Holder or just another Partner related to the Contract Account.

Thus, you can assign the Relationship between Insurance Object ‘IO-1’ and Business Partner ‘BP-1’ to the Contract Account ‘CA-2’, which has the Holder Business Partner ‘BP-2’. Then Business Partner ‘BP-1’ must be linked to the Contract Account ‘CA-2’ as other Partner (Contract Account Relationship Category).

Moreover you can allocate the Relationship Insurance Object ‘IO-1’ ↔ Business Partner ‘BP-1’ to the Contract Account ‘CA-1’ and the second – parallel – Relationship between this Insurance and Business Partner ‘BP-2’ to the Contract Account ‘CA-2’.

In this context SAP provides a central data structure named ‘DIMA_A_DI (Structure for Insurance Object)’ that contains all general data on level of the Insurance Object itself (Header, cross-partner) as well as all attributes on level of its Relationship to a certain Business Partner. This structure corresponds to the RFC Function Module named ‘FSCD_INSOBJECT_MAINTAIN’ to create and maintain Insurance Objects with their Relationships to Business Partners from any external system or software application.

3.5.  Modelling Insurance Objects and Relationships

In addition to the five predefined internal Insurance Object Categories you can define various meaningful external Insurance Object Categories customer-specific. Each of them has to be mapped to a dedicated internal Insurance Object Category in FS-CD Customizing. The internal Insurance Object Categories are predefined by SAP and fixed, please see paragraph “3.4 Insurance Object with Relationship to Business Partner (InsuranceObject-BusinessPartner-Relationship)”. When initially creating an Insurance Object (with its relation to a Business Partner), an external Insurance Object has to be assigned. This assignment can’t be touched afterwards; means you can’t change or delete the external Insurance Object Category assignment within a particular existing Insurance Object.

At the latest when specifying external Insurance Object Categories you should also give attention to appropriate Contract Account Creation Rules. A Contract Account Creation Rule determines the way how a Contract Account is going to be created automatically by FS-CD itself, when an Insurance Object (with its relationship to a certain Business Partner) is created - whereas the creation of the Insurance Object is usually triggered by a feeder system. Overall, Contract Account Creation Rules provide different approaches how Contract Accounts are structured, especially for assigning Insurance Objects either to different Contract Accounts, or to one and the same Contract Account (for example: all FS-PM Contracts that are mapped 1:1 as Insurance Objects in FS-CD, which belong to one super-ordinated FS-PM Policy that is mapped 1:1 as a Contract Account in FS-CD). Therefore several Contract Account Creation Rules consider the Contract Account Category or the external Insurance Object Category.

Segregation or aggregation of external Insurance Object Categories depend mainly on fundamental characteristics of the genuine business objects. Following two examples should illustrated this interdependency:

• First Example: direct distinction between different business object types

For instance a policy is created on part of an in-force business administration system initially as a ‘Homeowners Insurance Policy’ (as an instance of a defined insurance product). Subsequently it’s not possible to change the ‘type’ of this existing policy into ‘Private Auto Insurance Policy’ or ‘Accident Insurance Policy’ for instance, while keeping the identical policy number as before.

If this restriction is applicable in general, you can define a separate external Insurance Object Category in FS-CD Customizing per type of insurance product; means it reflects the original product differentiation, for example ‘HO - Homeowners Insurance Policy’, ‘PA - Private Auto Insurance Policy’, and ‘AI - Accident Insurance Policy’. Each of these external Insurance Object Categories have to be mapped to the internal Insurance Object Category ’10 - Insurance contract’.

• Second Example: superordinated distinction between different business object types

For instance a policy is created on part of an in-force business administration system initially as an ‘Endowment Life Insurance Policy’ (as an instance of a defined insurance product). Subsequently it is possible to change the ‘type’ of this existing policy into ‘Term Life Insurance Policy’, while keeping one and the same policy number as before. Thus, an important characteristic of the policy can be changed on part of the policy system, despite one and the same policy number is used after this endorsement. Here, the initially underwritten policy isn’t terminated, but changed substantially and continued in a different shape.

In this case the highest level of - disjunctive - consistency at the policy system (and product definition) must be utilized for defining suitable external Insurance Object Categories in FS-CD. Of course they should be meaningful. If the highest level is ‘Life Insurance Policy’ for instance (where a change can be made in the policy system, while keeping the identical policy number as previously), then also for example ‘LI – Life Insurance Policy’ has to be defined and utilized as an external Insurance Object Category in FS-CD Customizing.

In this case ‘Life Insurance’ is the compatible super-ordinated term and also the appropriate external Insurance Object Category in FS-CD. It contains the two subordinated exchangeable products ‘Endowment Insurance’ and ‘Term Life Insurance’, and maybe further life insurance products. Under this prerequisite it doesn’t matter on part of FS-CD, if the policy is changed at the in-force business administration system basically - but carries on the same policy number as before. Considering a thoughtful mapping the external Insurance Object Category doesn’t need to be changed within the existing Insurance Object. (Otherwise this would harm SAP standard.)

Overall, it’s valuable to define well thought external Insurance Object Categories, because they can be used to differentiate control parameters in each and every InsuranceObject-BusinessPartner-Relationship easily, and to populate them automatically when an Insurance Object is created (for instance: Dunning Variant, Correspondence Variant, Invoicing Type, Payment Plan Key, or Payment Option Key).

In many scenarios there is just one relationship required between an Insurance Object and a Business Partner. Depending on legal and business rules there is maybe just one policyholder that is identical to the premium payer; means only one Business Partner is assigned to a policy in all billing and payment relevant roles. In such a case one InsuranceObject-BusinessPartner-Relationship is sufficient.

In contrast to such an elementary scenario you can model complex scenarios differently, by leveraging the option to create and maintain multiple InsuranceObject-BusinessPartner-Relationships in parallel.

• First Example: One Policy is linked to two Business Partners (Debtors, Payers) in parallel

Imagine there is a Professional Liability Insurance Policy, reflected as an Insurance Object in FS-CD (e.g. using the external Insurance Object Category ‘Professional Liability Insurance Policy’.

It has a policyholder in form of a commercial partnership as one unit, represented by a specific Business Partner ‘A’ of Category ‘Group’. Additionally ‘A’ has Business Partner Relationships to two Business Partners ‘B’ and ‘C’ with Category ‘Person’.

Each recurring premium receivable shall be paid by these two different Business Partners ‘B’ and ‘C’ separately, divided by 70 : 30. The Policyholder - Business Partner ‘A’ - doesn’t pay premiums. The first premium payer - Business Partner ‘B’ - gives the permission for Direct Debit (Debit Memo Procedure), and the second premium payer - Business Partner ‘C’ - provides his Credit Card details for insurer-initiated collection.

Both Premium Payers ‘B’ and ‘C’ are responsible for their premium shares on their own. Moreover they request billing and other correspondence separately (maybe by tax law reasons). Overall both Business Partners ‘B’ and ‘C’ are not just alternative Payers in parallel, but also debtors regarding their premium receivables. Let us assume that the policy admin system is able to manage these relationships and the percentage premium shares, like SAP Policy Management (FS-PM). Thus, it is easy to create and maintain three appropriate relationships in FS-CD for all Business Partners ‘A’, ‘B’ and ‘C’, of course linked to one and the same Insurance Object.

Consequently both Business Partners ‘B’ and ‘C’ will get their own invoices as well as other correspondences created out of FS-CD. And every payment run will separate all items (premium receivables) by different Business Partners, different Payment Methods for Incoming Payments, and Bank Detail for Business Partner ‘B’ (Direct Debit) as well as Credit Card for Business Partner ‘C’ (Automated Payment Card debiting).

In such a case it could make sense that each of these three InsuranceObject-BusinessPartner-Relationships is assigned to one and the same Contract Account. The Holder of this Contract Account ‘CA-1’ is Business Partner ‘A’ (policyholder). In parallel both Business Partners ‘B’ as first premium payer and ‘C’ as second premium payer are attached to it each as ‘other Partner‘. Under this preconditions all documents are posted on one and the same Contract Account, but they are strictly distinguished by each Business Partner. Since the policyholder doesn’t pay premiums at all, there are no documents related to Business Partner ‘A’ in this case.

In contrast the Business Partner itself could be the decisive key for modelling separate Contract Accounts, depending on the perspective of the insurer. If you implement such an alternative approach, the result would look totally different: each of these three Business Partners will have its own Contract Account ‘CA-A’, ‘CA-B’, and ‘CA-C’ with each of these Business Partners as the ‘Holder‘.

Moreover each of the three InsuranceObject-BusinessPartner-Relationships is assigned separately to one associated Contract Account (CA); means ‘IO-PLI’ ↔‘BP-A’ is assigned to ‘CA-A’, ‘IO-PLI’ ↔‘BP-B’ is assigned to ‘CA-B’, and ‘IO-PLI’ ↔‘BP-C’ is assigned to ‘CA-C’. Therefore all items that belong to Business Partner ‘B’ as the first premium payer are posted on Contract Account ‘CA-B’, and all other items that belong to Business Partner ‘C’ as the second premium payer are posted on Contract Account ‘CA-C’. As long as the policyholder doesn’t pay premiums Contract Account ‘CA-A’ will be empty, means there are no open items (FS-CD Documents) posted.

This example illustrates the flexibility of InsuranceObject-BusinessPartner-Relationships. The implemented model depends mainly on legal and business requirements, while considering the mapping of Business Partners (for instance: is a Business Partner ‘A’ created as a Group that represents the commercial partnership, including two Business Partner Relationships to ‘B’ and ‘C’, or not?). From this point of view the capabilities of the feeder system have also high impact. SAP Policy Management (FS-PM) supports both approaches, which are described in this first example.

• Second Example: One claim is linked to multiple Business Partners in parallel

In FS-CD a claim is represented by an Insurance Object of Category ’40 - Claim Number’, often with multiple relationships to different Business Partners. Maybe there are several claim participants involved in parallel. Each of them could receive a benefit-, a claim- or an indemnity-payment. From a legal perspective such a particular Business Partner (e.g. claimant) is in many cases not just a Payee, but also a Creditor with its own entitlements.

Usually the insurer submits separate documents to these different payees, considering partner-specific postal or email addresses, when the claim is settled. On top of that each Business Partner may have its own preference how to get paid (e.g. outgoing Cheque, Bank Transfer / Electronic Fund Transfer, or credit transfer to a Payment Card). Even if all of them chose the same Payment Method ‘Bank Transfer’ (Electronic Fund Transfer), every Partner has of course his own bank details.

Thus, you will create one Insurance Object ‘IO-CLAIM1’ with a meaningful external Insurance Object Category that reflects the claim in FS-CD, including appropriate relationships to all relevant Business Partners.

It could be wise to create always a basic InsuranceObject-BusinessPartner-Relationship between the claim and the policyholder (here: Business Partner ‘H’) - independent from the fact, whether this Business Partner ‘H’ will receive a payment or not. This InsuranceObject-BusinessPartner-Relationship ‘IO-CLAIM1 ↔ BP-H' can be utilized to determine the correct ContractAccount-BusinessPartner-Relationship, which will be created automatically if it hasn't existed yet.

An insurer may prefer a separate ‘Claim Contract Account’, which is created and managed independent from a ‘Policy Contract Account’ that is intended to process just premium payments. If such an extra ‘Claim Contract Account’ shall contain only all claim-related credit (or debit) items referencing to a particular policy, then Business Partner ‘H’ who is the policyholder is meant to be also the ‘Holder‘ of this specific Claim Contract Account ‘CA-CLAIM’. All further Business Partners, which are linked to the representing Insurance Object ‘IO-CLAIM1’ as Creditors (Payees), will get

a) their own relationship to the same Contract Account ‘CA-CLAIM’ as ‘other Partners‘, and

b) their own relationship to the Insurance Object ‘IO-CLAIM1’, which will be assigned to the Claim Contract Account ‘CA-CLAIM’ according to a).

As a result, all claim payables will be posted on one and the same Contract Account ‘CA-CLAIM’, but strictly separated by different Business Partners. Each InsuranceObject-BusinessPartner-Relationship will hold its specific control parameters and can steer FS-CD transactions and mass activities accordingly. In particular different Outgoing Payment Methods and Bank Details or Credit Cards will be considered in FS-CD carefully, of course separated per InsuranceObject-BusinessPartner-Relationship.

In contrast, an insurer may opt for a universal mixed ‘Premiums and Claims Contract Account’, with the policyholder - Business Partner ‘H’ - as the ‘Holder‘. In this case an appropriate Contract Account will already exist, originally created for handling policy-related premium receivables and payments. As a consequence, this existing Account can also be utilized for postings and payments related to all associated claims.

Thus, every InsuranceObject-BusinessPartner-Relationship “IO-CLAIM1 ↔ BP-x” will be assigned to this existing Contract Account. BP-x means any Business Partner that is linked to this claim, such as policyholder, claimant, and further Creditors or Payees (Claims Participants). In total, all postings are strictly differentiated by Business Partner as well as by Insurance Object, even they are processed on one and the same Contract Account. Please be aware that each and every open it could be strictly separated regarding all FS-CD processes and transactions by the relevant Business Partner as well as the relevant Insurance Object. Even if there are many claims over time, each of them will be represented by its own Insurance Object. Usually, it doesn’t cause any negative impact, when assigning all these claim-specific Insurance Objects to one and the same Contract Account.

Additionally, an extra Contract Account for ‘special’ Business Partners could be implemented as well, without interfering the regular model. For instance there are agents or brokers, which are mandated from an insurer to handle and settle claims on its behalf. They focus on claim settlement in advance; means prior to a comprehensive claim handling on part of the insurer (e.g. by a professional claim handler). It could be wise to define a particular Contract Account Category for this special purpose and to set a specific number range for those Contract Accounts, which are dedicated to third party claims payments (and further processing).

Of course, various legal and business restrictions have to be considered for modelling Contract Accounts and Open Item Management (especially regarding Clearing Control). For example: a broker ‘D’ is permitted to handle claims only for a specific insurance business category or only for a particular line of business, if the policyholder is identical with the claimant and also with the payee, and no third-party indemnities are affected (e.g. like in liability insurance).

Therefore, a dedicated ‘Settlement Contract Account’ could be appropriate for such a broker, which contains all InsuranceObject-BusinessPartner-Relationships between all relevant claims – reflected as Insurance Objects “IO-CLAIM-x” in conjunction with this Business Partner ‘D’ (broker with power of attorney to settle claims upfront). Consequently, a different Contract Account Creation Rule with a specific Clearing Category as default comes into consideration, if a claim or an indemnity payable should be processed in FS-CD that refers to Business Partner ‘D’, where this broker is entitled to settle such a claim on behalf of the insurer.

Thus, the InsuranceObject-BusinessPartner-Relationship ‘IO-CLAIM-x↔ BP-D’ will be assigned to a specific Contract Account ‘CA-SZ’ with the broker as the Holder. It doesn’t matter, whether there are additional Business Partners linked to this claim or not, because each of them will have its separate InsuranceObject-BusinessPartner-Relationship “IO-CLAIM-x↔ BP-y” in parallel. All these Relationships can be assigned to the usual Contract Account based on the regular scheme, just this exception for the broker with a claim settlement mandate is administered differently on purpose via Settlement Contract Account ‘CA-SZ’. Holder of this Contract Account is the broker (Business Partner ‘D’).

Considering the impact of these different models, a thorough evaluation of legal and business consequences is required, upfront to the implementation. Depending on the line of business, the insurance product as well as law and justice, the last proposal could be efficient … but in other scenarios it wouldn’t. There is no ‘golden rule’ that fits for all scenarios. SAP Claims Management (FS-CM) supports all variants that are mention in this second example.

• Third Example: A policy has an alternative Premium Payer (instead of the Policyholder)

Depending on the country, the insurance business category, or the line of business, an alternative Payer can pay all premiums instead of the Policyholder, which is contractually agreed explicitly. At the same time, the Payer (Business Partner ‘P’) doesn’t replace the Policyholder (Business Partner ‘H’) as a Debtor regarding premium receivables. ‘P’ is just paying, usually via Direct Debit (Debit Memo Procedure) or via Credit Card. Although these payments are initiated by the insurer, and ‘P’ is the relevant Business Partner for collecting premiums, ‘H’ keeps still being responsible overall as the policyholder and debtor; means he will receive reminders or formal dunning notices (dunning letters) from the insurer, if premiums were not paid by the alternative Payer. Overall, in this case the Premium Payer does not play a major legal role.

Therefore, the insurer has to create a Business Partner that represents the alternative Payer, especially based on law and justice in all countries that belong to the Single Euro Payments Area (SEPA) for Direct Debit.

In many countries it’s not permitted to add just another Bank Detail or Payment Card under the section ‘Payment Transactions’ of the policyholder’s Business Partner Master Data (by capturing the first name and family name of the alternative Payer in the field ‘Account Holder’ for a certain Bank Account, or in the field ‘Description’ for a certain Payment Card). Instead, it is mandatory to create and maintain a separate Business Partner that reflects the alternative Premium Payer. Thus, the alternative Premium Payer is represented by its own Business Partner ID (e.g. Business Partner Number).

If just one alternative Premium Payer can be assigned to a policy (instead of the policyholder) as a general rule at a particular point in time, and this Business Partner ‘P’ is not a separate debtor, an extra Relationship between him and the Insurance Object that reflects the policy is not required in parallel to the InsuranceObject-BusinessPartner-Relationship with the Policyholder. This restriction is decisive from a legal, business and technical perspective, if you want to implement such a scenario.

Instead, the Relationship between the Business Partner ‘H’ (Policyholder) and the Insurance Object ‘IO-POLICY’ will be sufficient. SAP Collections and Disbursements (FS-CD) provides all necessary parameters to support this scenario. Within the Relationship ‘IO-POLICY ↔ BP-H’ you can specify:

• An Alternative Payer (Business Partner ID; here ‘P’ for instance)
• An Address Number of this Alternative Payer
• The Incoming Payment Method and
  the Bank Details ID, or the Payment Card ID for Incoming Payments
  of this Alternative Payer

Furthermore the Alternative Payer can be assigned as an Additional Recipient regarding one or several selected Correspondence Types (e.g. Invoice, Dunning Notice, or Account Statement) under the section ‘Correspondence’ within the InsuranceObject-BusinessPartner-Relationship ‘IO-POLICY – BP-H’. Thereupon, the alternative Premium Payer – Business Partner ‘P’ – will get the same correspondence in copy as the Policyholder, of course only for the selected correspondence types.

These powerful control parameters are supported throughout all FS-CD transactions and mass activities. Please keep in mind that they support just one Business Partner as an Alternative Payer, which replaces the ‘original’ Partner only with regard to this function.

Analog control parameters are also available in standard for an alternative Payee, which can be specified within an InsuranceObject-BusinessPartner-Relationship, as follows:

• An Alternative Payee (Business Partner ID)
• An Address Number of this Alternative Payee
• The Outgoing Payment Methods and
  the Bank Details ID, or the Payment Card ID for Outgoing Payments
  of this Alternative Payee

In contrast to the scenario mentioned above, SAP Policy Management (FS-PM) focuses in general on Premium Payers for Payment Processes. The singular scenario regarding one Alternative Payer or one Alternative Payee - mentioned above - isn’t supported by FS-PM in standard, as soon as there is any different Payer. SAP Policy Management (FS-PM) creates always a separate InsuranceObject-BusinessPartner-Relationship per Premium Payer. This approach is much more flexible, considering backdated (retroactive) as well as to future changes of any Premium Payer, or multiple Premium Payers in parallel.

There are cases in practice, when another Premium Payer has to be assigned with a valid from date in the past. For instance: a return occurred subsequently to a direct debit, maybe because the previous premium payer diseased. Alternatively, you want to schedule a switch from the current Premium Payer ‘A’ to another Payer ‘B’ in future, effective from a certain date, but considering existing FS-CD Documents. These cases cannot be reflected as such by changing the attributes within one existing InsuranceObject-BusinessPartner-Relationship itself historically. Please keep in mind that FS-CD Master Data are not based on a two-dimensional history concept like the Master Data within SAP Policy Management (FS-PM). All FS-CD attributes and control parameters are valid according to the date (actual), which controls a certain FS-CD transaction or mass activity. Regarding FS-CD Master Data there is almost no time-dependency. It’s neither possible to change them with an effective date in the past, nor in the future, including automated reverse or cancellation of posted items (FS-CD Documents) and automated creation of corrected new items.

Therefore, it’s more generic to create an InsuranceObject-BusinessPartner-Relationship per Premium Payer. If a switch from a previous Payer (Business Partner ‘P1’) to a new Payer (Business Partner ‘P2’) must be reflected accurately in FS-CD, all original debit line items can be neutralized through posting ‘mirror’ credit line items related to Business Partner ‘P1’ with inversed minus or plus sign, and - additionally - by posting new appropriate line items related to Business Partner ‘P2’. If this method is applied, it doesn’t matter whether some items have already been paid or not, in either case correct debit as well as credit line items are posted toward the relevant Business Partner. SAP Policy Management (FS-PM) is doing that fully automated.

Depending on the technical capabilities of the feeder (administrative) system as well as on the integration platform, a ‘hand-in-hand approach’ can be implemented, which is fully supported on part of FS-CD. In this scenario the feeder system doesn’t persist any billing or payment relevant data. Instead, it creates real-time an FS-CD Insurance Object with relationship to the respective Business Partner, and also maintains real-time all control parameters within this InsuranceObject-BusinessPartner-Relationship. Thus, there are no redundant Master Data that have to be replicated and kept in sync from the feeder system towards FS-CD. Overall, the feeder system creates and maintains all InsuranceObject-BusinessPartner-Relationship Master Data, and doesn’t persist these attributes at its own. In addition, the feeder systems reads all FS-CD Insurance Object attributes - real-time - for displaying them to a user on request (e.g. inquiry or change). In some implementation projects extra navigation, specific dialogues and screens have been developed customer- on part of the feeder system, for providing users with a unique and homogeneous user interface in Non-SAP environment.

Alternatively a ‘redundant approach’ is fully supported as well. In this common scenario the feeder system persists all data that are relevant for billing or payments at its own, as a part of the genuine business object (e.g. policy, claim, commission contract, treaty, etc.). Additionally, all these attributes are mapped, transferred, and synchronized to an adequate FS-CD Insurance Object, including its relationship to the respective Business Partner; overall, the relevant characteristics that exist in the leading administration system are replicated from this feeder system towards FS-CD, and the feeder system keeps them in sync. Replication and synchronization can be implemented selectively in real-time mode or in batch-mode (e.g. Direct Input), depending on the capabilities of the feeder system and the integration environment.

3.6.  Payment Plan assigned to an InsuranceObject-BusinessPartner-Relationship

SAP Collections and Disbursements (FS-CD) facilitates functions to convert a total amount, which is valid for a specific period (e.g. premium receivable for a year), into partitioned payment plan items that are finally transformed into posted FS-CD Documents. Rules and options for scheduling and distributing the initial amount are controlled by a Payment Plan. A Payment Plan and Payment Plan Items belong to the Master Data of an InsuranceObject-BusinessPartner-Relationship.

As an additional option a Payment Plan can be used to create equal repetitive (recurring) Payment Plan Items, which are based on a specific Payment Plan Item as a ‘template’ and will recur per defined period repetitively (e.g. monthly, quarterly, or semiannually); means reproduced periodically with updated dates automatically and autonomously in FS-CD. Moreover, you can also specify a deferral agreement to shift the due dates, which are provided by the feeder system for the original receivables or payables, according to an individually configured scheme that recurs each period.

These FS-CD capabilities can be used from any feeder system. For example a policy administration system calculates only yearly premium receivables, but customers (policyholders) ask for monthly, quarterly, or semiannually payment frequency. Or a claim system delivers just yearly annuity payables, but the outgoing payments should be distributed monthly, or quarterly.

A Payment Plan holds several control parameters. One of the basic characteristic is the Payment Plan Key, which determines

• how amounts set by payment plan items for an insurance relationship are distributed,
• how changes to payment plan items are to be processed,
• whether charges are to be posted, and
• which additional activities are to be executed when posting or changing payment plan items.

A second control parameter is the Payment Option. A Payment Option represents a set of Payment Plan Keys that can consist of just one Payment Plan Key, or of multiple different Keys in parallel. Thus, a Payment Option specifies, which Payment Plan Keys are permitted overall and can be switched from one to another. Furthermore it determines one or several activities that are triggered, when the Payment Plan Key is changed.

It’s not mandatory to make use of the FS-CD Payment Plan features and functions, but a valuable option. If this option is used, the control parameters of an InsuranceObject-BusinessPartner-Relationship specific Payment Plan are applied to all relevant Payment Plan Items. Thus, each Payment Plan Item that belong to this InsuranceObject-BusinessPartner-Relationship is subject to the rules of a particular Payment Plan, which are mainly steered by the Payment Plan Key and the Payment Option mentioned above.

But: every Payment Plan Item that is indicated as ‘One-time payment’ is not subject to any Payment Plan. Here the field ‘PSNGL (Checkbox: One-time payment)’ is set with the value ‘X’. Such a Payment Plan Item is not controlled by a Payment Plan Key or a Payment Option. Nevertheless, these Payment Plan Items of type ‘One-time payments’ are subject to Item Grouping and Item Summarization.

In this regard SAP provides a central data structure named ‘SVVSCPOS_B (Direct Input Structure of Payment Plans and Payment Plan Items)’ that contains all Data on level of a Payment Plan and on level of a Payment Plan Item. Thus, it’s a combined structure that includes all Payment Plan attributes as well as all Payment Plan Item attributes. This structure corresponds to the RFC Function Module named ‘ISCD_SCPOS_MAINTAIN’ to create and maintain Contract Accounts with their Relationships to Business Partners from any external system or software application. Please see also the Payment Plan and Payment Plan Item Interface for Direct Input, which provides you with an overview.

4. Overview of important Control Parameters within FS-CD Master Data