1 2 3 9 Previous Next

SAP for Insurance

131 Posts

Current Situation in SAP Policy Management (FS-PM)

FS-PM is the SAP for Insurance module to handle the management of policies. It has a quite flexible and elaborate business object lying underneath with a lot of entities that connected to each other with different cardinalities. This flexibility can lead to an quite extensive i. e. large business object consisting of a lot of entities depending on how the insurance product is modeled. Everyone who wants to do an implementation of business logic in this module has to interact with this object tree using the so called Unified Business Object Interface (UBOI). This interface allows the fetching or updating of information stored in the business object. And exactly here comes the problem with FS-PM with respect to unit tests: If you want to do unit testing you have to introduce test doubles exactly for the UBOI as they are one of the central sources of the data your business logic depends on. Unfortunately the UBOI layer up to now "refused" to be mocked up with a reasonable effort due to several reasons (although a few brave developers tried to do so in the past). As a consequence the usual FS-PM developer was locked out from using unit-tests in FS-PM.


In order to make the story more complicated there is also one second important source of data within FS-PM the so called journal. This journal contains all the information about historical actions that took place on a policy. So at many places you also have to introduce a test double for this part of FS-PM, which proved to be as complicated as the mocking of the UBOI interface itself.

Up to now only bad news for developers who would like to benefit from a test-driven development approach in FS-PM. But with SP09 of Netweaver 7.40 the situation changes ...

The ABAP Test Double Framework

With SP09 SAP offers as a new out-of-the-box functionality in order to deal with the most annoying part of writing unit test namely the mocking up of dependent objects (like the UBOI interface in FS-PM). This functionality is called ABAP Test Double Framework which makes writing unit-tests easier or maybe, speaking for FS-PM, possible for the very first time. The blog ABAP Test Double Framework - An Introduction by Prajul Meyana gives a quite comprehensive introduction into the topic in general. Therefore I will not dive into the depth of the technical description of the framework, but throw a light on how this framework enables unit testing in FS-PM for the very first time without relying on FS-PM "infrastructure" to do so.

So dear FS-PM developer community fasten your seat belts as we will now ...


...tame the FS-PM beast

Although FS-PM up to now nearly completely denied the developer the option to do test driven development the infrastructure of FS-PM is very well prepared to allow the usage of the ABAP Test Double Framework without a lot of adoptions of the existing code or established patterns in the FS-PM code. The two big advantages are:


  • the UBOI and also of the journal object in FS-PM is represented by classes with interfaces. So all the relevant methods for the fetching of information from the business object policy are located in these interfaces. This is a very good starting point as the ABAP Test Double Framework has some limitations but it can perfectly deal with the mocking of interfaces.
  • a lot of classes already fetch the reference to the UBOI/journal object in the constructor of these classes and store the references as private instance attributes e. g. all timemodel functions or the classes of the cashflow component. This is very well fitting in order to allow the injection of the test double references into the classes under test.


So the central question is: What steps have to be done in order to enable the unit testing in FS-PM?


Let us a take a look at a concrete example: we want to write a class with one method that checks if all coverages underneath a specific contract have the same end date as the contract itself. If this is the case a flag is returned with the value ABAP_TRUE if not the flag has the value ABAP_FALSE. The importing parameter of the method is the UBOI key of the contract. As the goal of the blog is to show the feasibility of unit tests in FS-PM I will not do that in a test driven way (test first) but start with the regular coding as I want to show that even existing classes can now be covered with unit tests.


Step 1: Enable the Class for the Injection of the Test Double

As mentioned above we follow the FS-PM best practice and fetch the UBOI references in the constructor of the class using the corresponding factory call and store them in private instance attributes. We adopt the usual procedure in FS-PM as this time we allow in addition the importing of these references in case that the creator of the class wants to inject them. These parameters are marked as optional and if they are not bound the "classical" FS-PM style of fetching the references is used. The class definition looks like this:

2015-03-29 15_51_28-ABAP - Globale Klasse ZCL_FSPM_ABAP_TESTDOUBLE_DEMO [SA8] - Aktiv, Gesperrt - SA.png

The implementation part of the class with respect to the constructor is depicted in the following screenshot:

2015-03-29 15_54_14-ABAP - Globale Klasse ZCL_FSPM_ABAP_TESTDOUBLE_DEMO [SA8] - Aktiv - SA8_090_lech.png

As mentioned before if the UBOI references are given to the constructor they are stored in instance attributes, if not the references are fetched using a factory call.  When classes are created from scratch this procedure is straight forward. But even for existing classes the adjustment (i. e. adding optional parameters in the constructor of the class and enhancing the logic in the constructor with the IF...ELSE logic shown above) is not a cumbersome task that may result in severe problems for existing business logic.


Next we add the method that checks if the end dates of the coverages belonging to one contract are in sync or not. The definition of the method looks like this:

2015-03-29 16_01_02-ABAP - Globale Klasse ZCL_FSPM_ABAP_TESTDOUBLE_DEMO [SA8] - Aktiv - SA8_090_lech.png


The implementation is shown in the following screenshot:

2015-03-29 16_05_17-ABAP - Globale Klasse ZCL_FSPM_ABAP_TESTDOUBLE_DEMO [SA8] - Aktiv - SA8_090_lech.png

This is something like a typical piece of FS-PM code:

  • You fetch the contract data into LT_POLPR using the fully qualified key so the table can contain only one entry (code in the red box)
  • Then you fetch the coverages that are beneath the contract into LT_COV (code in the green box)
  • After that you compare the end date of the coverages to the one of the contract (code in the blue box)

As you can also see there are real specifics in order to prepare the class for unit testing, all the coding is done "as usual" in FS-PM. Now let us see how easily this class can be unit tested although we are using the UBOI to fetch the data from the business object policy.


Step 2: Mock up the UBOI

We now create the test class. The definition of the test class contains one method TEST_FOR_SYNC that will test the method we have just created:

2015-03-29 16_11_07-ABAP - Globale Klasse ZCL_FSPM_ABAP_TESTDOUBLE_DEMO [SA8] - Aktiv - SA8_090_lech.png

The implementation of the test method consists of three parts:


(1) We create the test double for the UBOI of the contract in order to provide a contract end date for the unit test:

2015-03-29 16_13_49-ABAP - Globale Klasse ZCL_FSPM_ABAP_TESTDOUBLE_DEMO [SA8] - Aktiv - SA8_090_lech.png

This is done by calling the test double framework CL_ABAP_TESTDOUBLE=>CREATE and hand over the interface that shall be mocked. Be aware to cast the returned reference back to this interface. Next we fill the data that shall be stored in the test double. As you can see you do not have to specify all fields of the contract structure but only the relevant ones. After that we set the test data into the test double using the method CL_ABP_TESTDOUBLE=>CONFIGURE_CALL. Last but not least we specify the method (GET_POLPR) that has to be mocked. I did not specify any key for that call (LS_POLPR_KEY is initial). This is just for the sake of this demo, in real life unit testing you can of course transfer a key here and this key is afterwards considered when executing the unit test.


(2) We create the test double for the UBOI of the coverage as we did it for the UBOI of the contract

2015-03-29 16_21_19-ABAP - Globale Klasse ZCL_FSPM_ABAP_TESTDOUBLE_DEMO [SA8] - Aktiv - SA8_090_lech.png

(3) Implement the test i. e. create an instance of the class under test and inject the created test doubles into the constructor of the class. After that call the method and check the result using the standard ABAP unit test framework.

2015-03-29 16_23_39-ABAP - Globale Klasse ZCL_FSPM_ABAP_TESTDOUBLE_DEMO [SA8] - Aktiv - SA8_090_lech.png

For the parameters that we chose the expected result of the method call is ABAP_FALSE, which is what we assert.


Step 3: You are done :-)

That is it - you can now run the ABAP unit test or to be more precise you can now run a unit test in FS-PM on a class that uses the UBOI interface ... be aware that that nearly impossible up to now.


2015-03-29 16_27_09-ABAP - Globale Klasse ZCL_FSPM_ABAP_TESTDOUBLE_DEMO [SA8] - Aktiv - SA8_090_lech.png



Within this blog I presented you the application of the ABAP Test Double Framework delivered with SP09 of the SAP Netweaver in the insurance module FS-PM. I did this because since the birth of this module it was nearly impossible to do unit testing in FS-PM. This is now definitly a story of the past. No matter if it is standard or customer development the technical foundation is now given for unit tests and in consequence for test-driven development in FS-PM.


So enjoy unit testing and test driven development ... even in modules where boldly no unit test has gone before



P.S. Be aware of the fact that the central class CL_ABAP_TESTDOUBLE exists already in 7.40 SPs prior to SP09 but it is not released in them. So when you use the class this will result in an error.


P.P.S. If you want to get an overview on test driven development and its benefits AND a little glimpse into the future developments of that topic with respect to SAP Netweaver the slides of  Christian Drumm and Thomas Fiedler that you find here might be worth a look.

Sapphire 2015.jpg

As I look out my New England window at the very slowly diminishing snow (which totals 105.7 inches in Boston so far, just 2 inches shy of the all-time record) I can’t help but turn my thoughts to a warmer, sunnier, happier place. It is time to look forward and cast aside the snow shovels, ice picks and rock salt. I must resort to the inspiring quote from Robin Williams, “Spring is nature’s way of saying Let’s Party”. And what better location and venue than the 2015 SAP SAPPHIRENOW event in Orlando, for the 3 days of May 5th-7th. I need to project myself there now and focus on what attendees will experience in less than 2 months.           

Firstly, let’s start with the location, as this will really help shake off these winter blues. The weather in Orlando in May is warm and humid; requiring one to only pack light clothes…you had me at ‘warm’. Now, let’s look at some of the benefits that you’ll enjoy during the event. In just three days, you can maximize your time by leveraging diverse points of view, experiences, and best practices – from SAP subject matter experts and other customers in your role and industry. Technology trends and solutions will be discussed, including SAP S/4HANA, the next generation business suite designed to help you run simple in a digital and networked economy. You will also see demos and be able to consult with SAP partners and solution providers that can help with your implementation. Overall, it is really the ultimate opportunity to maximize your SAP investment and find the solutions to your most pressing business challenges.   


There is also plenty of insurance-specific content which will be covered during the event. You can take a “Look into the Future of the Insurance Industry” and learn how to create a foundation that will protect your entire insurance software platform now and in the future. There’s a session on becoming a customer-centric insurer, which will explain how your company can adapt to the influence of new competitors, while at the same time delivering a great customer experience across all touch points. Another discussion will focus on how insurers can transform their underwriting and pricing with usage-based insurance, which examines opportunities for them to rethink their approach to risk management. And there’s much more.

Please check out the SAPPHIRENOW site for more details, including creating your own agenda. And you can take advantage of the early bird rate through March 17th.  Now, back to my reality of dripping icicles!

Accelerate your sales cycles with SAP’s customizable sales assets for Banking (customer facing)

  • Placemats to create awareness:

Insurance Placemat

SAP HANA Enterprise Cloud Services for Insurance Placemat  


Asset to learn more and share with customers in demand generation campaigns



Breakthrough SAP HANA Customer Success Stories E-books (customer facing):


Assets available via PartnerEdge.com. To stay updated about sales/marketing assets available to Insurance Partners visit the Insurance Pages in PartnerEdge.com


Insurance Product Development: Streamline the Entire Process for Speed-to-Market Advantage


By Mike Key, Vice President Business Development, Global Core Insurance at SAP

Economists.pngDo you need to deliver better, more responsive services to customers, and improve your time to market?  This is no longer wishful thinking in the insurance industry - it’s the only way to succeed. For Insurance Companies product speed to market and flexibility are top priorities, however only a small proportion are actually getting it right as discussed in my earlier blog about Speed and Flexibility: The New Mantra for the Insurance Industry and as highlighted in a recent report from The Economist Intelligence Unit.

However, despite prevailing challenges in the insurance sector, there are significant opportunities for you to streamline your product development cycle to achieve more - faster. 


Speed-to-market benchmarks 

When pressed about product speed to market, executives can generally only give rough timeframes. Yet they are only too well aware of legacy constraints that impact their ability to respond to market or competitive changes. 

Even the companies that can provide informed metrics on speed can typically only provide the time benchmarked from when the new product definition was scheduled by the IT department. This does not take into account all the work conducted in marketing, compliance, operations, and product development prior to the IT department receiving their schedule of work. 


However, those businesses that have focused on improving speed to market, have ascertained that the ideation and development stages of the product development cycle are typically as long as, or even longer than, the timeframe required for actually programming the legacy environments. 


Surprisingly, this ideation stage is typically loosely managed, without formal processes. In most cases there’s no workflow even though it includes many interaction points between marketing, compliance, product development, sales, operations, and IT.



Business Process Transformation


It doesn’t make sense that this part of the product development cycle is so loosely controlled. Especially when you consider how a project, once it’s active in the IT organization, falls under the project management organization and is tightly managed. There is comprehensive visibility through progress reports, timelines, and the ability to identify potential bottlenecks in deliverables and reallocate resources to improve delays and target dates. 

Repeatable and manageable process


To achieve optimal speed to market, it surely makes sense to apply the same degree of rigor to the early stages of the development process as it does to the later stages. 

And this means having a repeatable and manageable process with a centralized single source of the truth for existing product content. Add to this profile-restricted access to the  product change and creation process allowing for collaboration and access to a library of reusable forms, verbiage, and components, and you have streamlined efficiency. 

In all, this allows for product definition right down into reusable assets. In one deft move you can simplify the components of the product portfolio while providing greater flexibility to differentiate the marketable offerings by channel and target customer. 


40% improvement

As a case in point, one of our customers has been able to transform their product development process using this approach. In just the first 12 months, the company improved the speed to market of new products by a staggering 40%. 


And while the company was delighted with this result, it was able to continue to improve the speed to market for the next two years.  All this was achieved through organizational, process, and workflow changes that centered on the use of a product agility factory. There were no expensive, time-consuming changes to their legacy administrative systems.

Interested in finding out more? Why not discover how SAP is helping insurance companies around the world turn organizational and workflow changes into significant competitive advantage. 


Look forward to your Thoughts. Please follow me on Twitter @Mike_Key.




The ability to react quickly and cost effectively to consumer needs and market demands continue to define success in the insurance industry, particularly when it comes to product agility.

However, while product speed to market and flexibility may be the top priorities for all insurers, only a small proportion is actually getting it right. In a recent report from The Economist Intelligence Unit focused on changes to the Insurance Industry, when asked whether disruption was more
likely to occur in distribution, service or products, at least 30% of respondents saw the potential for disruption in each of the three areas. However, less than half (46%) believe their companies are “well prepared” for change, while nearly one in four see the industry as “well prepared” for pending disruption.

And the rate of change isn’t going to slow down any time soon. Indeed, an SAP survey of 200 insurance executives conducted earlier this
year at the IASA Annual Conference pinpointed three major factors driving this need for speed, namely:


  • Rising consumer expectations
  • Heightened regulatory demands
  • Availability of new technology

Customer experience

These days, consumers don’t set their expectations on what is a great customer experience by sizing up what your competitors are doing. They set their expectations on the very best experiences online. And more often than not, these exceptional experiences are delivered by customer-centric companies such as Amazon or Apple.  To even get close to delivering this kind of experience, a 360-degree view of both the customer and your products is critical.

Regulatory framework

Insurers must increasingly address more complex and converging regulatory issues which have created significant compliance and governance burdens.   These new requirements call for actionable information from integrated, real time transactional information analytics.
Operational data that is trapped in legacy core systems needs to be accessible alongside financial information that is currently layered deep in data warehouses. 

New technology

Technology is critical to success. Insurance companies must effectively use technology to give customers more of what they want. Major opportunities will arise for insurers that embrace the Internet of Things to create more compelling customer offers. Those that don’t will face significant risks, as customers jump ship and find products that are better suited to their needs and lifestyles.

Innovation is key

Of course, to embrace a customer-centric way of business, to adapt to the regulatory framework and to embrace new technology, innovation is critical. More often than not, taking a legacy approach will simply constrain your ability for speed and flexibility.  One innovative way to propel your organization forward is to use technology as an enabler to product flexibility. You take a building block approach to product construction where reuse is a central tenant.  By developing a comprehensive view of product functionality, you separate product from policy, billing, and claims systems. This gives you the freedom to focus on the configuration of reusable components by the business, as opposed to programming by more expensive, backlogged developers.

Business transformation is essential

Many of our  customers have scrutinized legacy product development cycles and have discovered that the elapsed time prior to engaging the IT department in product development can be as long as the actual implementation cycle in IT.  When speed is of the essence, it’s clear that this approach is not going to drive business success.

However, with a realigned workflow centered on a holistic view of product lifecycles, you are better able to document and refine process metrics.  A single source of the product truth for product development, compliance, sales, finance, operations and IT is a critical step in the alignment of people, processes, and technology to enable change.

SAP Customers

Embracing innovation and business transformation, I’m happy to say that SAP customers have experienced a 30 – 60% improvement in product speed to market with both product introduction and change. Some of our customers have benefited from implementing an agile, iterative product approach to new market offerings.  While others have orchestrated product agility as a key to their legacy modernization framework, showing early and repetitive wins. 

Either way, SAP customers have been able to focus strategies on product agility, leveraging technology innovation to drive simplicity in process - and positive organizational change.


Strategic competitive advantage

While these organizations have employed these approaches to successfully convert the speed-to-market constraint into strategic competitive advantage, the business and technical architectural foundation is not one that can be developed overnight. 

At SAP we have been crafting a focused product agility module for insurance carriers through two releases a year over the last 10 years.  Through this, customers on multiple continents, are experiencing agility in all lines of business including P&C (Personal and Commercial), Health and Life products have experienced improved speed and quality.


Our experience has shown that the way to gain this competitive advantage is to identify the challenge and focus on it as part of your near- and long-term plans; choose a partner that has successfully demonstrated success in the industry; lead with technology and then execute, execute, and execute. 



Find out more about what SAP is doing to turn insurance industry challenges into competitive advantage for our customers. 

Recently The Economist Intelligence Unit published some new research about how mobile technologies are transforming the insurance market and it makes very interesting reading indeed. Please see my prior post on this topic here.

In the past the insurance industry hasn’t been known for being particularly innovative with technology, but it seems that times are changing. Globally the percentage of executives who agree that mobile provides a new set of capabilities and has a business changing-potential that other channels lack is 62%. And in North America the percentage is even higher at 79%.

And it seems executives are backing their opinions with investments. There are plenty of examples in the report of how mobile technologies are enabling insurers to reach current and potential customers in new ways with new offerings.

EIU Mobile 2.png

For example, one enterprising insurer is offering location-specific, low cost, short-term insurance products through the local mobile network provider. Users receive recommendations for travel insurance at airports, golf insurance at golf clubs, and sports and leisure insurance at ski locations. And premiums are low, starting from as little as $2.50.

Another insurer has formed an alliance with a manufacturer of smart devices to track health statistics such as blood pressure, glucose levels, and weight, as well as environmental conditions and details of an individual’s exercise program.

Yet a third is doing away with paper-based vehicle insurance policies and putting the whole policy on customers’ phones. With a driver’s permission it enables the company to use GPS to send help in the event of a breakdown and coach policy holders on driver safety.

New developments like these prove that insurers are throwing off their conservative shackles.  As they do they will move from simply providing protection for policy holders, to becoming trusted partners who deliver services that are useful to people in their everyday lives.


Read the full EIU report here and please share your thoughts.

sagar tasgaonkar


Posted by sagar tasgaonkar Feb 2, 2015

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


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



  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



  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



  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



  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



  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



  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



  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.



  1. There is absence of above functionality


2. Comparison: Business Processes


2 a. Postings



  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



  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



  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)



  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



  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



  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



  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



  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



  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



  1. Direct Updating of GL data is done


2 f. Write-offs



  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)



  1. Posting are carried out manually

EIU Mobile.png

Mobile technologies are radically changing many industries and they have great potential to transform the insurance industry. Indeed, according to recent research by The Economist Intelligence Unit (EIU), 62% of respondents see mobile as offering unique capabilities with the potential to change the insurance game1.

The reality is insurers are forging ahead with new mobile products and services for their customers. Usage-based insurance, one-off products, location-based recommendations, and health monitoring are just some of the new developments that are being pioneered.

But has anyone asked consumers what they want or are prepared to accept? It seems not. The same EIU research that found insurers to be bullish about mobile technologies also polled consumers around the world. And it found that insurers and consumers are somewhat at odds in their attitudes to mobile insurance.

Insurers see the benefits of collecting data about policy-holders, but consumers are not convinced. In fact, seven of 10 policyholders (70%) say they would be strongly or moderately concerned about their insurer collecting and using their personal information to personalize products and services. Almost as many (67%) would feel the same way about insurers collecting personal data to discourage risky behavior1.

What are the lessons for insurers? First of all they must be able to clearly demonstrate the benefits of collecting individual consumer data. The advantage may be lower premiums, more proactive healthcare, a lower risk of accidents, or complementary services. But, whatever it is, the consumer has to  understand the value they are getting for sharing their data. Secondly, insurers that forge ahead without getting their policyholders on board, or offering the expected privacy protection, could be putting themselves at risk from a backlash. 

While the insurance industry is lagging other consumer industries in mobile consumer proliferation and embrace, a few are doing it right.

Read the full EIU report here to see what some of them are doing.

1 Source: From protector to partner: Can insurance expand insurers’ relationships with consumers?

Dear Colleagues,

it`s a pleasure to announce that we are live with our new web experience for INSURANCE on sap.com. For sure, you will find a general announcment in SCN as well.

... have fun!

Best regards




Digitalization & Communication | IBU Insurance | SAP SE

Analytics video.png


We are pleased to introduce a new SAP Analytics for Insurance-Policy video.

Find out how SAP HANA Live for Insurance, together with SAP Lumira,
lets you explore production data in a user-friendly format, quickly share
information across departments, and generate production reports in real time.

What better way to quickly (3:42 minutes) and effectively gain an
understanding of the value of SAP Analytics solutions which help Insurance
companies Run Simple?

Demo videos are constructed based upon the ‘day-in-the-life’ approach to using SAP solutions.   

Enjoy the video and please share your feedback.

What if rush hour traffic vanished? What if your office came to you, instead of vice versa? Imagine the possibilities, imagine the convenience, imagine…roving happy hour?

To the uninitiated, there's a new concept known as “automobility,” that enables your car to drive itself and morph into your office with a set of wheels - making self-driving cubicles a reality. The only thing missing would be the coworker who always picks the worst time to talk sports.

But would working in a self-driving car really be necessary? If you’re already afforded the autonomy of working from home, is there really a perk with this? Those that could stand to benefit might be sales reps and consultants, and just about anyone that’s on the road all day. Want to see a modular office for yourself? A super futuristic demo can be found here:


How it will work

When you’re driving (and working) through downtown, your self-driving office will lock into a citywide grid system designed to prevent gridlock. The technology will utilize radar, infrared sensors, and a vision system where projector elements will reflect visuals linking to other cars in close proximity to ensure harmony. But what if the grid is hacked or overcapacity and goes down? What if an EMP explodes in the sky? In that case you'd quickly have rush hour take the form of a long, backwards in time march home where hopefully you’d have the moon to help you follow the river.

Special delivery

Need a package delivered before the meeting starts? No problem. Other projections for work day dynamics include a modular “deliverbot” designed to deliver your packages. It will even broadcast its whereabouts to your rolling office so you know it’s in the area, just in case you need to ship something out. Is this a good idea? After all Stephen Hawking recently warned that artificial intelligence could spell the end of the human race. Yikes- is it possible you’re going to end up really missing that friendly delivery person with the shorts and baseball hat?

Roving happy hour anyone?

One possible upside to the self-driving modular office is the potential for sight-seeing during happy hour. Trouble planning a destination for your next work meeting?  No problem. You’ll have the ability to ask your finely calibrated machine to surprise you. Since you’ll get to see westbound sunsets and colorful foliage it will surely make for a more interactive team discussion- if anyone’s paying attention that is. Though considering that you’ll have a permanent designated driver it could be safer. But other than a few fun moments, would many workers actually benefit from a self-driving, modular office?

The complete “driveable” experience of the future may take about 15 to 20 more years according to Ideo. However, there’s already a transition underway towards more modest upgrades in connected driving that offer a simpler driving experience.

What’s next?

Not surprisingly, emerging technology utilizes the cloud and BMW has created a ground breaking research prototype powered by the SAP HANA Cloud Platform and featuring the “ConnectedDrive system.

BMW states on its website that, “ConnectedDrive will offer you greater comfort so you can focus on the essentials. It also gives you the choice: travel guide, entertainer, or guardian angel - you decide who your traveling companions should be.”

With Shell and Volkswagen also recently announcing co-innovation with SAP, in this case for connected fueling, clearly there are a few changes for the drive ahead. However, there is a big difference between the added conveniences of connected driving finding you a better parking spot or a cup of coffee and a completely self-driving office operating on a network grid that communicates with robots.

How do you think automobile insurance carriers would manage and price the coverage for these self-driving vehicles? Would a self-driving office on wheels be worth the sacrifice of freedom and control? Would it enhance or complicate your work life, or are you just fine with a few new upgrades offered by a more connected car?

By Joseph Pacor, SAP Insurance Industry Content Director


In a previous posting, I wrote that cloud technology has become business as usual for insurers. I based my conclusion on a study conducted by Ovum on behalf of SAP that involved 200 senior CIOs from the global insurance sector. The study also found many ways in which cloud-based solutions are transforming the industry.


Early adopters have used the cloud technology known as software-as-a-service (SaaS) to support e-mail, backup/archiving, and business continuity. Increasingly, insurers are also supporting core business activities such as customer service, policy administration, underwriting, and fraud detection. In addition, a small but expanding number of companies use the technology for new business acquisitions, marketing, customer targeting, and the development of new products.


Cloud contributes to business growth and agility


Many insurers believe that SaaS will foster business growth and organizational agility by shrinking IT development cycles. This, in turn, will help them respond more rapidly to new business opportunities, move more quickly into new market sectors and countries, and deliver greater product innovation. (See Figure 1)


Source: Charles Juniper, “The Critical Impact of Cloud for Insurance on Business Transformation,” Ovum, 2014

Figure 1: Agreement/disagreement with statements about the impact of SaaS on insurers

Cloud technology should also help insurers move to a variable IT cost model, reduce overall IT costs, and fundamentally alter the role of IT in an organization. The standardized infrastructure and application components can dramatically shorten development cycles and let insurers fund technology on a subscription basis. In addition, insurers can hand over responsibility for ongoing IT maintenance and the enhancement of platforms and applications.


Insurers need a clear cloud strategy

In this evolving environment, all insurers should have a clearly defined and widely communicated strategy for cloud technology that extends beyond cost reduction. In planning their IT and cloud strategies, insurers must focus on the transformative role that SaaS can have on their organizations. Ovum believes that most cloud strategies in the insurance industry today should be more comprehensive and fully encompass the potential for organizational transformation.


As insurers broaden their cloud strategies, the role of IT in their companies will likely change. Ovum believes that IT personnel will become like brokers, finding relevant cloud vendors to support their companies’ wider business functions. IT groups should thus begin to expand their knowledge of the cloud vendor landscape and actively promote opportunities that cloud solutions enable within their organizations.


It is clear that insurers of different sizes, geographies, and types of business are adopting cloud technology in greater numbers. Smaller players can now access tools that only larger insurers could once afford. The technology should also help new industry entrants gain a foothold more quickly. Both developments will make the industry even more competitive than it is already.  A ‘wait and see’ approach could prove very costly to those that delay their cloud decisions. Insurers should be prepared to leverage cloud computing now to optimize its benefits.


For a brief summary of findings from the Ovum study, click here.

By Joseph Pacor, SAP Insurance Industry Content Director


Cloud technology has generated significant interest among insurers in recent years. For a clearer understanding of how insurers are using this  technology, Ovum conducted an independent and in-depth study with 200 senior CIOs from the global insurance sector on behalf of SAP. Let’s examine what the study has to say about the growing use of cloud-based solutions among insurers.


For the purposes of this study, Ovum identified cloud technology as the combined use of 1) infrastructure as a service (IaaS), 2) platform as a service (PaaS), and 3) software as a service (SaaS) to deliver business functionality through a public network (such as the Internet), a private network, or a combination of both.


Business as usual in the cloud


The study found that most insurers routinely use cloud technology. Over half of those surveyed currently spend between 20% and 39% of their relevant budgets on cloud technology or services. Most insurers currently deploy SaaS solutions in a tactical way - using them for new IT projects where they are the most appropriate choice.


While approximately a third of insurers rarely consider using SaaS, it is the preferred deployment option among nearly a quarter of those surveyed. This cloud-first policy is particularly prevalent among insurers in European and North American markets. In fact, a small number of European insurers report that they only implement new projects if they can be deployed using SaaS.






Source: Charles Juniper, “The Critical Impact of Cloud for Insurance on Business Transformation,” Ovum, 2014   

Figure 1: Respondent organization’s policy toward the use of SaaS


Greater use of cloud computing for additional purposes

Among respondents, 33% and 21%, respectively, expect to increase spend substantially on both SaaS and IaaS/PaaS within the next 18 months.Those most likely to increase spending are already significant adopters of cloud technology. This result suggests that while insurers as a whole are still in the adoption phase with cloud technology, early adopters are realizing a range of business and cost benefits that are further accelerating adoption by their organizations.


The initial use of SaaS among insurers has been around horizontal and collaborative-focused systems to support e-mail (65%), backup/archiving (65%), and business continuity (58%). Increasingly, SaaS is supporting a broad range of vertical and core-business activities. These include customer-focused activities (such as customer servicing), back-office functions (such as policy administration), and complex activities (such as underwriting and fraud detection).


In addition, a small proportion of insurers - particularly new entrants and startups - are deploying SaaS to support new business acquisition, marketing, customer targeting, and the development of new insurance products. According to Ovum, “this broader adoption marks a watershed shift in attitudes from that of only three years ago, when the majority consensus of the insurance industry was that cloud had only a limited role in supporting core, business-critical processes.”


Insurers cited concern over regulatory compliance as the major reason they had not yet adopted SaaS. Ovum believes this is “a situation that is changing and will be resolved over the next three years, particularly as governments and the public sector globally are rapidly adopting cloud technology themselves.”

As vendors of cloud technology enhance their service level agreements and demonstrate compelling business benefits of cloud technology for insurers, companies that have been reluctant to embrace these solutions are more likely to move forward.


Next Week: How Cloud Technology is Transforming Insurance

Written by Li-May Chew, Associate Director, IDC Financial Insights. Li-May can be contacted at lmchew@idc.com

I have previously blogged on how operational pressures are nudging typically siloed risk and finance fractions at insurers to think more earnestly about creating shared priorities and enhancing partnerships to improve strategic decision making. This piece further expands upon those commentaries on Europe and U.S., but with a keener focus on the Latin American (LATAM) insurance market.

Our conversations indicate that the Brazilian and Mexican insurers are feeling the strongest pressures and keenest need for risk-finance collaborations vis-à-vis global peers. These regional insurers are getting their risk and finance teams to collaborate to reap benefits from shared business analytics and valuation engines that can enhance decision making for reporting, planning, and capital management. Furthermore, given that operating off common data sets would simplify operations and enhance control over data quality, accuracy, completeness and timeliness, they are also integrating risk with finance to reduce complexities and manage expenses.

When it comes to the extent of progress, insurers from Brazil and Mexico appear to have advanced the most with their integration programs given that 58% have consolidated risk with finance versus 48% globally (with almost a-third of these 58% in LATAM being satisfied with the extent of their implementation), another 32% being at advanced stages of planning, and 10% having at least started some sort of planning program.


While there are undoubted benefits from interdepartmental integration, incorporating risk-based data into financial and performance management obviously engenders obstacles. The principal concern for LATAM insurers stems from a divergence in the way these two groups might define similar terms and measure divisional performance. Data would be defined and accessed differently due to the varying perspective between risk and finance, their information requirements, and tabulation methods. Ranking almost as critical is the lack of experienced personnel, and difference in perspectives and cultures between their finance and risk fractions - with both equally cautious of integrating for fear of ceding autonomy to the other.

Technological concerns also evoked great concerns amongst the LATAM respondents, with robustness of data being most crucial when it comes to providing the momentum for, or conversely stalling, integration projects. Another IT challenge centers round limitations from existing legacy technologies such as lack of scalability or interoperability of systems restricting risk-finance implementation.

To alleviate risk-finance coordination, insurers in LATAM see investments in enterprise business intelligence and analytics strategy nudging them towards deeper inter-departmental collaborations, alongside the sharing and joint development of common data warehouses and modeling competencies. Market leaders are also widening their competitive advantage by capitalizing on innovations such as enterprise information management to centralize data modeling and flow management, data visualization capabilities and unified data platforms.

As LATAM insurers continue to make inroads in consolidating their risk and finance divisions, they need to enhance this partnership by having a clear vision of what the joint responsibilities between both divisions are, while still preserving the independence of both. It would further serve them well to engage vendors with a comprehensive, yet integrated risk-finance data platform that can help establish shared data processes and management systems to reduce total cost of ownership.

Please click here to download a copy of the IDC Financial Insights' White Paper: Risk-Finance Collaboration at Global Insurers: A Partnership in Transition.

Written by Li-May Chew, Associate Director, IDC Financial Insights. Li-May can be contacted at: lmchew@idc.com

Following my earlier commentaries on the partnership between the risk and finance fractions at European insurers, I want to now turn to the United States (U.S.) and highlight some survey data specific to this country in my next blog.

Discussions with the tier one and two insurers from the States indicated that they are likewise conscientiously trying to forge greater risk-finance collaborations. As a matter of fact, indicating that they are going beyond just paying lip-service but actually taking decisive actions, 47% in the U.S. have already consolidated risk with finance, albeit just a handful of these respondents professed to have completed satisfactory integration. Those that have done so are actively working on collaborative initiatives around capital project evaluations, mergers and acquisitions and globalization strategies, financing decisions and budgeting. Furthermore, it is heartening to note that another 40% is just one stage behind and ironing out their integration kinks, while an equally sizeable cohort have concrete plans to achieve consolidation in the coming months.

What is driving these collaborative efforts? Factors compelling them to do so include being able to enhance analytical expertise for improved financial forecasting, and getting access to more complete, real-time view and precise reporting of the insurers' businesses. Achieving cost savings from consolidation was also foremost on the minds of the American insurers, with interviewees ranking potential cost efficiencies as the foremost driver spurring collaborations. These organizations are obviously cognizant of the fact that expenses can be reduced from having data, reporting processes and supporting systems that are all common rather than siloed and disparate.




And given that this chief risk officer-chief finance officer (CRO-CFO) partnership entails a degree of internal reworking, where is the funding coming from? We are encouraged to note that a very respectable 53% in the U.S. (against 36% of peers globally) have secured specific monies for these change-management endeavors, with only 20% needing to dip into their business-as-usual (BAU) funds. The remaining 27% however, have to put their case forth to senior management to secure additional discretionary funding.

As with all innovative programs, organizations are bound to encounter some barriers when it comes to implementing their risk-finance integration programs. Amongst all the operational and technological challenges, the American insurers noted that limitations from existing legacy technologies such as lack of scalability or interoperability of systems as the core factor restricting their risk-finance implementation. While this was given a score of 3.1 out of 5 globally, it was ranked as the top technological concern by the U.S. respondents at 3.7/5. Legacy modernization is therefore a critical imperative for these insurers to enhance business process and system capabilities and make way for greater risk-finance collaborations and business agility.

As these insurers busy themselves to integrate their risk and finance offices, we see them continually tweaking the extent of their risk-finance cohesiveness. While this is not an easy task, as integration efforts can derail from differences in objectives and priorities, benefits from more coordinated interactions would make it worth their while.

For those keen to read on developments specific to your region, do have a look at my previous blog on Europe, and an upcoming write up that will cover the Latin American market.


Please click here to download a copy of the IDC Financial Insights' White Paper: Risk-Finance Collaboration at Global Insurers: A Partnership in Transition.


Filter Blog

By author:
By date:
By tag: