FSCD Vs FI-AR

SAP FSCD (Collections and Disbursement) Vs FI-AR (Accounts Receivable)

FSCD Vs FI-AR: After reading this blog we shall be in a position to understand why we have FSCD to manage receivables rather than using the traditional SAP AR module. For the simple reason that FSCD was intended and built to handle high-volume transaction in Insurance Industries, including:

1. Automation of previously done manual processes for e.g. postings
2. Supports all revenue and receivable types that can be flexibly adapted to changing Insurance rules and regulations
3. Lean data model because of the triple structure model consisting of BP, CA & IO
4. Performance through parallelization of mass runs (like payment runs, dunning runs, etc,)

The FI-AR component also manages accounting data of all customers (somewhat like hundreds or thousands).

With FSCD able to manage data for large number / volume of customers (say like in millions) and offering some amazing functionality like broker collection, insurance specific correspondence, coinsurance handling, commission & remuneration payment processing, advance write off features, and many more, it is not possible to overrule FSCD in favor of SAP AR.

FSCD & FI-AR comparison has been made on the basis of the following to keep it simple;

1) Master Data

2) Business Process

Here only important features are highlighted and the actual comparison may be quite exhaustive.

1. Comparison: Master Data

1 a. Business Partner / Customer

FSCD

1. Uses SAP central business partner as a cross component application with BP created with contract role
2. Representative can be assigned for e.g. the broker can represent a BP that takes over the processing of certain processes (for example, payment or dunning) for the end customer
3. More than one address are allowed per BP and address data can be verified (city, street, postal code, etc.)
4. Future dated changes possible with validity period
5. Screens layout (required fields, etc.) can be easily modified as per Insurance business needs

FI-AR

1. Customer data and A/R control data is utilized in a single data entity (customer)
2. One address per customer is allowed and address data cannot be verified as in FSCD
3. Different dunning procedures, payment control can only be implemented by creation of an additional customer record

1 b. Contract Account

FSCD

1. More than one account is allowed for each BP as separate data entity hence several accounts can be defined per customer (Insured / policy owner)
2. Separate payment data for incoming and outgoing payments can be defined for the CA in the payments tab
3. Contract Account relationships can be defined
4. Account determination indicator – GL account determination can be influenced according to customizing setting in the contract account
5. Alternate dunning recipient or dunning address can be defined for contract account
6. Control of payment assignment & tolerance per contract account is possible
7. Ability to set time-restricted blocks with “from – to” date, at the CA level such as correspondence locks, dunning locks, payment locks, clearing locks.
8. Screen layout can be made easily adaptable as per Insurance business needs for General , Payment / Taxes, Correspondence tab

FI-AR

1. There is absence of comparable data entity below the customer level unlike in FSCD ( as in FSCD this is possible due to the triple structure architecture)
2. There is no provision to define relationships unlike in FSCD

1 c. Insurance object

FSCD

1. Feature to define the payment plan key
2. Payment plan items can be scheduled and posted via VYSPA
3. Current balance of the installments can be viewed
4. Insurance relationships can be defined
5. The type and line of insurance product can be defined at IO level

FI-AR

1. There is absence of comparable data entity below the customer level unlike in FSCD
2. There is no provision to define relationships unlike in FSCD

1 d. Creditworthiness scoring

FSCD

1. Assess the BP based on payment patterns in the system (FPCR1)
2. Manual credit worthiness value can also be set for the BP overwriting the assigned values
3. Creditworthiness points from dunning, returns, and clearing are assigned automatically and the values can be adjusted via customizing. Creditworthiness is stored in the business partner’s master data record. Creditworthiness can be updated manually or in the dunning run.
4. Weighting table (TFK046A) for time-based weighting of automatic creditworthiness points such as % factor for flat-rate increase or reduction of automatic creditworthiness
5. You can override automatic determination of creditworthiness by entering a percentage-based weighting and creditworthiness data manually (FPCR2).
6. Creditworthiness data can be entered manually in the system. This means that business transactions such as a customer complaint over unjustified returns (creditworthiness improvement) or black lists from external credit evaluators (worsening creditworthiness) can also influence a BP’s creditworthiness.
7. Manual creditworthiness entries influence a BP’s creditworthiness the same as the entries created by the system. They can contain positive (worsening creditworthiness) and negative (improved credit worthiness) values. They can also be reversed.

FI-AR

1. There is absence of above functionality

2. Comparison: Business Processes

2 a. Postings

FSCD

1. Uses Transaction concept consisting of main and sub, enabling reduced error rate and ensuring data consistency
2. Pre-defined codes with two-level hierarchy (main / sub transactions) to classify charges / interest calculations.
3. Main & sub transaction used for account determination (auto)
4. Manual entry of GL accounts is not required

FI-AR

1. Uses the concept of posting keys

For e.g.

Posting key      Name Credit /Debit                   Account type
40                   Debit entry Debit                      G/L account
50                   Credit entry Credit                    G/L account

1. Posting key defines debits and credits and with restriction of 2 digits to control line items
2. Posting key defines screen selection for each account in tandem with the GL account
3. GL accounts are entered manually in each line item

2 b. Dunning and Collections

FSCD

1. N number of dunning levels per dunning procedure can be defined in the system upto 3 char/digits and are utilized during dunning runs VPVA & VPVB
2. N activities per dunning procedure – forms, function modules, mail, workflow for external activities, and exception handling, can be used
3. Better to check BP and / CA overdue items in FBL9 account balance before dunning
4. Dunning dependent on creditworthiness
5. Dunning history (FPM3) – Each dunning notice can be traced in the system at document level
6. Transfer of dunned items to external collection agencies can be done (FP03)

FI-AR

1. Maximum nine dunning levels can be defined (FBPM) and used for dunning run (F150)
2. Only dunning letters as dunning activities can be defined
3. Better to check customer overdue items in FBL5N before dunning
4. No dunning history feature is present but only can view information showing which document was in the last dunning procedure
5. No special collections agency functions present hence transfer of dunned items to external collection agencies is not present

2 c. Payment Run

FSCD

1. Incoming / Outgoing Payment can be applied to different bank accounts / cards possible at both CA and IO level
2. Payment medium program SAPFKPY3 can be called during payment run FPY1 for creation of payment media
3. Ability to block incoming and outgoing payments separately at both CA and IO level
4. No amount limit per bank due to parallel execution
5. Banks (using house bank and customer bank) can be selected per run and do not have to be specified in Customizing

FI-AR

1. Incoming/ Outgoing Payment always applies to the same bank account
2. Payment medium program SAPFPAYM can be called during payment run F110 for creation of payment media
3. Payment block cannot be done separately and applies to both incoming and outgoing payments
4. Amount limit can be set and can be defined for each bank
5. Bank priorities are defined in Customizing and depends upon amount limit

2 d. Return

FSCD

1. The return reopens the source receivable and clears the payment posting instead
2. Activities possible for each return reason – dependent on number of returns and creditworthiness of business partner
3. Return reasons can be defined specific to Insurance process

FI-AR

1. No separate functions exist unlike in FSCD
2. Achieved through resetting of clearing, manual posting of returns, and account maintenance

2 e. Transfer to General Ledger

FSCD

1. Updating of GL data from the sub ledger due to high volume of data
2. Postings are summarized in totals records according to posting date and reconciliation key
3. One document per totals record -one line item per account/additional account assignment
4. Totals records are transferred to the GL daily

FI-AR

1. Direct Updating of GL data is done

2 f. Write-offs

FSCD

1. Uncollectable receivables can be written off automatically – automatic determination of the expense accounts
2. Write-offs can also be carried out in a batch run (FP08M)

FI-AR

1. Posting are carried out manually