I'm glad to add this document from Jochem Schueltke to blogs.sap.com. It was released in SCN and is still valid, but not refer to BRIM. I have updated some links and did some minor changes. I split the document in parts.
© SAP AG 2014, Jochem Schueltke
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 modelling 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 utilizing FS-CD Documents. In this context ‘universal’ means that an FS-CD Contract Account can be used for all lines of insurance business, and for all categories 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 for instance. And 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’tbe 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’. Amongst 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). It defines contract accounts, which have the
same fundamental characteristics. When a Contract Account is created, it is assigned to a
Contract Account Category. You can’t assign another Contract Account Category to an existing
Contract Account after it has been created.
The Outside Account View is a control parameter that belongs to the cross-partner Contract Account Master Data (Contract Account Header). It is a criteria for grouping items when Invoicing, and for the Payment Program. Following two view types are supported:
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 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’. Amongst 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, crosspartner) 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-RelationshipMaster 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 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 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.
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 possible to clear open debit and credit items with each other automatically (based on detailed rules), which are posted on different Contract Accounts, if they 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 in ContractAccount-BusinessPartner-Relationship Master Data and InsuranceObject-BusinessPartner-Relationship Master Data. For example, the Clearing Variant must not contain the Contract Account as a grouping or selection criteria. That’s very unusual in practice.
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 ontract 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 as well as high impact on FS-CD transactions and mass activities. Under this view angle one has to consider various aspects to decide for an appropriate Contract Account structure, such as:
All these aspects need to be considered, before FS-CD Master Data are modelled. 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 policy holders (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) insurance types could be adequate (e.g. divided into Life Insurance, and Non-Life Insurance), if items have to be managed strictly separated. 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 line of business. But the group of companies share one and the same Business Partner data commonly (cross lines of business). 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:
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, for 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.
Part 3 will continue with FS-CD Insurance Object with its relationship to Business Partner.
More information about FS-CD:
Please check also the Q&A section for FS-CD.
- Part 1: Overview and Business Partner
- Part 2: FS-CD Contract Account with its relationship to Business Partner
- Part 3: FS-CD Insurance Object with its relationship to Business Partner
- Part 4: FS-CD Payment Plan assigned to an InsuranceObject-BusinessPartner-Relationship
SAP Collections and Disbursements - Overview of FS-CD Master Data
© SAP AG 2014, Jochem Schueltke
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 modelling 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 utilizing FS-CD Documents. In this context ‘universal’ means that an FS-CD Contract Account can be used for all lines of insurance business, and for all categories 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 for instance. And 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’tbe 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’. Amongst 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). It defines contract accounts, which have the
same fundamental characteristics. When a Contract Account is created, it is assigned to a
Contract Account Category. You can’t assign another Contract Account Category to an existing
Contract Account after it has been created.
The Outside Account View is a control parameter that belongs to the cross-partner Contract Account Master Data (Contract Account Header). It is a criteria for grouping items when 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 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”.
Contract Account with CA Relationships, SAP Fioneer
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’. Amongst 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, crosspartner) 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-RelationshipMaster Data (not to the cross-partner Contract Account Master Data).
Business Partner with multiple Contract Account Relationships, SAP
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 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 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.
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 possible to clear open debit and credit items with each other automatically (based on detailed rules), which are posted on different Contract Accounts, if they 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 in ContractAccount-BusinessPartner-Relationship Master Data and InsuranceObject-BusinessPartner-Relationship Master Data. For example, the Clearing Variant must not contain the Contract Account as a grouping or selection criteria. That’s very unusual in practice.
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 ontract 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 as well as high impact on FS-CD transactions and 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 collects also premium on behalf of the property and casualty insurance company)?
- How does an insurer – a single legal entity (Company Code) – organize its billing and payment processes overall, for instance strictly divided per line of business (e.g. separated in life Insurance, Property and Casualty Insurance, and Health Insurance - if operated by one insurer), per individual insurance business versus group (collective) insurance business, or per customer segments (customer target groups)?
- What types 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 receivables and payables 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), presupposed aggregation is legally permitted?
- How does an insurer receive payments, which are initiated by policy holders, 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?
- Is it possible that a certain Business Partner is the policy holder 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 'hierarchy clip' to group open items, 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 hierarchy plateau to group overdue items (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 modelled. 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 policy holders (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) insurance types could be adequate (e.g. divided into Life Insurance, and Non-Life Insurance), if items have to be managed strictly separated. 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 line of business. But the group of companies share one and the same Business Partner data commonly (cross lines of business). 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:
- A ‘Premium Contract Account’ with relationship to a policy holder, 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).
- 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.
- A 'Claim Contract Account’ with relationship to a policy holder, 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).
- 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 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’). - 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 ummarized
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. - 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, for 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.
Part 3 will continue with FS-CD Insurance Object with its relationship to Business Partner.
More information about FS-CD:
- SAP ERP: Collections and Disbursements
- SAP S/4HANA: Collections and Disbursements
- SAP S/4HANA Cloud, private edition: Collections and Disbursements
Please check also the Q&A section for FS-CD.
- SAP Managed Tags:
