IFRS 9 and IFRS 15 Business Case with SAP Revenue Accounting and Bank Analyzer.

Dear,

Since January the 1^st 2018, Banks and Corporates should be compliant to the new Accounting Standards IFRS 9 and IFRS 15.

In my opinion, most of Banks and Corporates are far from being ready to be compliant to these legal requirements and we will see some examples in the oncoming months.

On the other hand, there is some confusion about the implications of IFRS 9 and IFRS 15, so I’ll try to make a short description with a practical example.

IFRS 15 is relevant for Contracts with customers with particularly visible implications in contracts combining the delivery of Services and Goods.

For instance, a Telecommunications company confirms a contract with a customer committing to deliver Internet access for 12 months for 35 EUR/month and a subsidized Wifi Router for 50 EUR.

Before the IFRS 15 Accounting Principle was implemented, the above contract would produce a revenue in the Telecommunications company of 35 EUR every month, and a one-time revenue of 50 EUR (for selling the Router).

With the implementation of IFRS 15 the company is required to adjust the revenue recognition to a Fair Price of the two sold elements (Router and Internet Access) and the completion of the commitment with the client (deliver the Router and provide the Internet Access). For instance, the Router has been sold to a lower price (subsidized) because the client has committed with a 12 months contract of Internet Access, so it seems logical that a portion of the revenue for selling the router is distributed during the 12 months of the Internet Access.

The International Accounting Standard Board proposes a 5 steps process for fulfilling the IFRS 15 requirements.

Step 1.- Identify the contract with the customer.- This first step has been run just above, identify the contract with the client, in which the company commits to deliver a bundle of services and goods.

Step 2.- Identify Separate Performance Obligations.- Performance Obligations are the promises to the client to transfer Goods or Services. In the above example, the two Performance Obligations are, delivering the Internet service and the Router. At the same time, the company must identify the Stand Alone Selling Price of each Performance Obligation, which is a “Fair Price” that the company would charge for the goods or services if they were sold separately.

The current version (1.3), SAP Revenue Accounting and Reporting does not have the capacity of determining the Stand Alone Selling Prices, but the company can use average historical prices for determining the Stand Alone Selling Price of each Performance Obligation.

In this example we would assume that the Stand Alone Selling Price of the Internet Access is 40 EUR/month and the Stand Alone Selling Price of the Router is 55 EUR.

Step 3.- Determining the Transaction Price which is the actual price that the company is charging to the client for each Performance Obligation. In this case the Transaction Prices are 35 EUR/month for the Internet Access and 45 EUR for the Router.

Step 4.- Allocating the Transaction Price to each Performance Obligation in an amount that depicts the revenue that the company can recognize for delivering the Goods/Services to the client. In our example, they are the following.

Performance Obligation	Transaction Price	Standalone Selling Price	Allocated Amount	Calculation of the Allocated Amount
Router	50 EUR	55 EUR	48 EUR	470*55/535
12 month Internet Service	35*12=420 EUR	40*12=480 EUR	422 EUR	470*480/535
	470 EUR	535 EUR	470 EUR

Step 5 .- Recognize revenue when each performance obligation is satisfied.

Month 1.- Performance Obligation 1 is fully satisfied and Performance Obligation 2 is satisfied in 8.33%. Revenue Recognition is 48 EUR + 35.17 EUR

Month 2.- Performance Obligation 2 is satisfied in 8.33%. Revenue Recognition is 35.17 EUR

Month 3.- Performance Obligation 2 is satisfied in 8.33%. Revenue Recognition is 35.17 EUR

Month 4.- Performance Obligation 2 is satisfied in 8.33%. Revenue Recognition is 35.17 EUR

….

Month 10.- Performance Obligation 2 is satisfied in 8.33%. Revenue Recognition is 35.17 EUR

Month 11.- Performance Obligation 2 is satisfied in 8.33%. Revenue Recognition is 35.16 EUR

Month 12.- Performance Obligation 2 is satisfied in 8.33%. Revenue Recognition is 35.16 EUR

On the other hand, when the company issues the invoices to the client, the company assumes a Credit Risk that the client is not paying the due amount.

IFRS 9 describes the process for measuring the Expected Loss, which starts by determining the Probability of Default of the Client, based in a Credit Risk model which classifies the Client according to the payment behavior of the clients belonging to the same Risk segment. This process is called Historization and is supported by the SAP Bank Analyzer System.

The second step is determining a Fair Value provision that will reduce the recognized revenue until the client makes the payment. The provision amount is determined by the Key Date Valuation of the AFI-Bank Analyzer module, by discounting the Cash-Flow (due amount) with a Yield Curve with the same maturity of the Cash-Flow and the correspondent Spread of the client’s Probability of Default.

Obviously the provision will increase if the client does not make the payment on time, and the Account Receivable becomes impaired.

SAP offers a complete business suite for fulfilling the requirements of the new Accounting Standards. Unfortunately, technical and functional skills for implementing them are scarce, making the implementation projects very challenging.

Looking forward to read your opinions.

K. Regards,

Ferran.

www.capitency.com

Join the SAP Banking Group at: https://www.linkedin.com/group

Visit my SAP Banking Blog at: http://sapbank.blogspot.com/

Let's connect on Twitter: @FerranFrancesGi

Ferran.frances@capitency.com

Financial Instruments Product Costing Planning with SAP Bank Analyzer.

Dear,
Capital Optimization requires efficient planning, providing management with the necessary information for having resources when they are requested, and taking corrective actions in case of deviations.

Planning relies in accurate Product Costing, assuring that profit and margin objectives are fulfilled in every financial period.

Product Costing for Financial Products has three dimensions; Risk driven Capital Costs, Funding Costs and Process Costs.

1) Risk driven Capital Cost.- IFRS 9 and Basel III require that every bank develops a Risk Model which supports the estimation of the Expected Loss of every Financial Asset. The Expected Loss represent the values of the potential losses in a Financial Asset, multiplied by the probability of that loss occurring, and it is the basis for determining the Fair Value Provisions and Capital Requirements of the Bank. The Fair Value Provisions and Capital Requirements represent a cost for the bank, which must be included in the Product Costing estimations of the bank.

Bank Analyzer -AFI supports the determination of the Fair Value Provisions (IFRS 9) and Bank Analyzer – Credit Risk supports the determination of the Credit Risk Capital Requirements (Basel III), according to the Expected Loss of the Financial Asset. Credit Risk Capital Requirements can be included in the Financial Asset Statement (AFI sub-ledger) as Off-Balance Postings, representing the Capital Cost of the Financial Asset, assuring that the sales price will cover the Risk Driven Capital Costs.

Assuming that the bank has a consistent common risk model per Financial Asset, it means that we can assume a direct relationship between the Expected Loss for Capital Requirements (Basel III) and Fair Value (IFRS 9), to the extent that gives the bank an opportunity to reduce Fair Value provisions in case of excess of Capital Requirements determination.

This double approach of the Expected Loss (Solvency and Accounting) per Financial Asset is a very interesting Value Proposition of the Integrated Financial and Risk Architecture.
Bank Analyzer stores the Expected Loss in the Credit Risk Result Type, and the Fair Value Provisions on the Accounting Result Type of the Results Data Layer. In both cases the results are stored individually per every Financial Asset which opens the gate for representing the Capital Requirements as Accounting Provisions per Financial Asset.

Capital Requirements must be determined under base and stressed scenarios, for this reason, in practical terms, Product Cost Planning requires the bank use Standard Costs, that must be reconcilable with the Expected Loss of the banks risk model, and Capital requirements estimations. This reconciliation is also supported by the Integrated Financial and Risk Architecture of Bank Analyzer.

2) Funding Costs.- The bank has to get liquidity from the market, compensating the liquidity consumed in Lending and Investing. Bank Clients and Capital Markets provide this liquidity at an interest rate, which represents a cost, that the bank must include in the cost estimations of its products.

Liquidity requirements fulfillment are a shared responsibility by all the bank branches and Treasury department. Some branches get liquidity that others consume, with the Treasury department compensating liquidity requirements or excess in the Capital Markets. In exchange for covering the liquidity requirements of other branches, liquidity providers receive internal transfer of the funding cost value (transfer price for liquidity). We’ll talk about this in more detail in a future blog.

3) Process Costs.- In order of getting clients and managing investing and contracts with them, the bank needs resources; staff, information systems, branches, etc. Every contract has to support a fair distribution of its related banks costs, assuring that the selling price is higher enough for assuring a positive margin. The fair distribution of the banks process costs is achieved with the cost analysis model of the bank, using Management Accounting techniques for services like Activity Base Costing, Internal Cost Orders, Cost Center Accounting, etc.

As you can see above, the first two families of costs are financial services driven, while the third is general services driven. Integrating all in the same Financial Statement requires a seamless integration between the Analytical Banking and the ERP System. This is the main advantage of combining SAP Bank Analyzer and S4 HANA Universal Journal, combining in the a unified Financial Statement, all the revenues and cost of a Financial Instrument, so the bank will have the profits and losses of every business segment, and the allocated capital.

We looked at the concept briefly in a previous blog.

https://www.linkedin.com/pulse/why-bank-analyzer-afi-sub-ledger-anymore-chapter-ii-ferran-frances/

And we will come back to this topic, in more detail, in a future one.

Looking forward to read your opinions.
K. Regards,
Ferran.

SAP Performance Management for Financial Services (FS-PER).

Dear,

Recently, we finished a Proof of Concept of SAP Performance Management for Financial Services (FS-PER), in a client which implemented Bank Analyzer – AFI some years ago.

SAP has always had strong Cost Management and Accounting functionalities, even in SAP R2, which was the first SAP system I ever put my hands on.

Today, we have SAP Finance and Controlling, Business Planning and Consolidation, and some Cost Management and Accounting Functionalities in Bank Analyzer (Profit Analyzer), so, when I first heard about SAP Performance Management for Financial Services, I thought it should have an overlapping with other SAP Systems.

I was wrong, SAP Performance Management for Financial Services covers an important gap that we had with previous Cost Management systems in Financial Services.
One of the main challenges we have in Banking implementations is the data collection from multiple legacy systems, with different sets of master and transactional data. It’s very difficult to find a Bank which has a Single Source of Truth for Operational data. Usually, Business Partners, Contracts, Products, etc. are stored in multiple systems with a different set of values in every legacy system of the bank.

In SAP Bank Analyzer, we have the Source Data Layer for building a Single Source of Truth of Operational Data, but the Source Data Layer Primary Objects are oriented to the management and storing of “banking” master and transactional data (business partners, financial transactions, business transactions, positions, etc.)

On the other hand, managing “non-banking” data like process-costs, assets-amortization costs, etc. in the Bank Analyzer Source Data Layer, is not that simple.
Actually, these costs and revenues are more easily managed with the Accounting Management modules of  SAP-ECC or SAP Business Planning and Consolidation. But, what happens when we want to merge banking and non-banking data in a Cost Analysis model, or the client stores the Cost Management data in a legacy system?

For instance, let’s look at the direct cost that a foreign bank charges to our bank because our clients use the foreign bank ATM machine; this cost is posted as an invoice for a service provided by a vendor. If the foreign bank gives us the list of the ATM-cards using its ATM machine, we should post these costs as a direct cost of every account related to each of the ATM-cards.

With SAP Performance Management for Financial Services, we can easily collect the invoice cost from the Vendor’s Invoice and post it in the Bank Analyzer – Results Data Layer. Once in the Results Data Layer, we can include the ATM-card costs of the foreign bank in the cost and profit analysis of our client’s accounts (Financial Transactions).
In my opinion, this is the main advantage of SAP Performance Management for Financial Services, its capacity of integrating in a cost analysis model, data from different and heterogeneous sources.

SAP Performance Management for Financial Services supports data collection from the Bank Analyzer Source Data Layer, the General Ledger, HANA tables, external data, etc. and write the results in Business Warehouse or Business Planning and Consolidation Infocubes, or, as I mentioned before, in the Bank Analyzer Results Data Layer.

Additionally,  SAP Performance Management for Financial Services offers data cleansing capabilities, that we also can find in other SAP systems (BW for instance). The advantage is we can optimize the process of data transformation by having all the elements in the same system.
In terms of Data Transformation and Calculation, SAP Performance Management for Financial Services comes from a very rich library of functions for Costs Settlement, Funding Price Calculation, etc.

Finally, SAP Performance Management for Financial Services comes with two pieces of Business Content; Sample Content for Profitability and Efficiency Management and Business Content on Solvency II. The business content can be used as a template for our own Financial Calculations and Transformations, accelerating the implementation process.

Combining the functionalities of SAP Performance Management for Financial Services with the functionalities of the new Financial Services Data Platform and the high performance computing of HANA, SAP is offering us a powerful business suite for Profit Analysis in complex banking landscapes.

Looking forward to read your opinions.
K. Regards,
Ferran.

www.capitency.com
Join the SAP Banking Group at: https://www.linkedin.com/groups/92860
Visit my SAP Banking Blog at: http://sapbank.blogspot.com/
Let's connect on Twitter: @FerranFrancesGi
Ferran.frances@capitency.com

IFRS 15 for Banks with SAP Revenue Accounting.

Dear,

From January 1st 2018, a new Accounting Standard becomes mandatory for reporting the Revenue Recognition in Contracts with Clients IFRS 15, becomes effective.



IFRS 15 enhances the process of Revenue Recognition by establishing a 5 steps process.

1) Identify the contract with the customer.

A contract with a customer falls within the scope of IFRS 15 if all the following conditions are fulfilled.

- The contract has been approved by the parties to the contract

- Each party’s rights in relation to the goods or services to be transferred can be identified

- The payment terms for the goods or services to be transferred can be identified

- The contract has commercial substance; and it is probable that the consideration to which the entity is entitled to in exchange for the goods or services will be collected.



2) Identify the performance obligations in the contract.

Usually, operational systems represent the Performance Obligations in the contract but there are two possible exceptions:

- Several Operational Items representing the same Performance Obligation. For instance, in a Desktop Computer (represented by a Sales BOM), several Items are detailed in the Sales Order (Monitor, CPU and Keyboard) but they represent the same Performance Obligation of delivering the Computer.

- One Operational Item representing several Performance Obligations. For instance some Computer Manufacturers offer one year technical support service (Performance Obligation) with every computer sold (Performance Obligation).



3) Determining the Transaction Price.

The transaction price is the amount that the vendor expects to receive in exchange for the goods or services.



4) Allocating the Transaction Price to performance obligations.

Once the transaction price for the contract has been determined, IFRS 15 requires to allocate it to the performance obligations of the Contract. Considering the two cases above, in which the Operational System Items does not represent univocally the Performance Obligations, we can understand the challenge of allocating the Transaction Price to the Performance Obligations.



First, IFRS 15 requires to determine the Stand-Alone Selling Price which is the price that the vendor expects to receive in exchange for delivering the goods or services of the performance obligation are sold separately to a customer. Be aware of the difficulty of estimating the Stand-Alone Selling Price when several performance obligations are sold together with a bundle price.

In order of determining the Stand-Alone Selling Price, IFRS 15 permits three approaches.

1. Adjusted Market Assessment. Estimating the Stand-Alone Selling Price according to the conditions of an specific market, reflecting the vendor costs and margins.

2. Expected cost plus margin. Estimating the Stand-Alone Selling Price according to the expected costs of the performance obligation for the vendor, plus its correspondent margin.

3. Residual Method. In case of bundle prices for grouped performance obligations, in which we can not estimate the Stand-Alone Selling Price of all the performance obligations, IFRS 15 proposes the following two-steps approach.

First we have to estimate the Stand-Alone Selling Price of the performance obligations of the group, that can be estimated with one of the previous approaches. The we will estimate the Stand-Alone Selling Prices of the rest of the performance obligations, by deducting the Stand-Alone Selling Price of the performance obligations already estimated, from the total contract price of the group of performance obligations.



5) Recognize revenue when each performance obligation is satisfied.

In case of a good or service delivered in one step, the performance obligation is satisfied at the moment of the final delivery to the customer, but in case of services or goods delivered during a period of time, IFRS 15 requires that the revenue is recognized according to the percentage of the performance obligation that has been delivered in every financial period.



Although, IFRS 15 impacts other industries much more than Banking (which is much more impacted by IFRS 9), there are some banking services impacted by the requirements of IFRS 15.

Fulfilling IFRS 15 requirements, requires Information Systems with strong sub-ledger capabilities, that we described briefly in a previous blog.



http://sapbank.blogspot.com/2016/02/fulfilling-ifrs-9-and-ifrs-15-sub.html



Additionally, SAP provides the Revenue Accounting and Reporting module for IFRS 15, which supports all the requirements of the 5 steps approach for Revenue Recognition described above.

We have worked recently in the design of an IT architecture, combining Bank Analyzer and SAP Revenue Accounting and Reporting for IFRS 15, for supporting IFRS 15 requirements in Banking.

I’ll give you some details in a future blog.

Looking forward to read your opinions.

Kind Regards,

Ferran.



www.capitency.com

Join the SAP Banking Group at: https://www.linkedin.com/groups/92860

Visit my SAP Banking Blog at: http://sapbank.blogspot.com/

Let's connect on Twitter: @FerranFrancesGi

Ferran.frances@capitency.com

What is SAP Bank Analyzer Smart-AFI?

Dear,

In the last months, several clients have asked me about the new concept of Smart-AFI of Bank Analyzer, and its differences with the traditional Accounting for Financial Instruments Module of SAP Bank Analyzer.

I’ll start with a short description of the evolution of the Accounting for Financial Instruments module of SAP Bank Analyzer until the most recent 9.0 version, which includes Smart-AFI.

The Accounting for Financial Instruments module of Bank Analyzer is the system responsible of creating a Financial Statement, including the valuation, of the Financial Instruments (Securities and Over the Counter Contracts) of a Bank. Actually Bank Analyzer call them Financial Instruments when they are securities, and Financial Transactions when they are Over the Counter contracts.

Until the Version 5,  the Accounting for Financial Instruments Module of Bank Analyzer was not a proper sub-ledger. The Version 4.2 and older versions were not capable of integrating the Financial Statements of the Financial Instruments in the General Ledger, in fact the results were stored in the Results Data Base (precursor of the Results Data Layer but much less flexible). From the Results Data Base, the system provided Data Sources for sending the Financial Statements to an specific Business Content in Business Information Warehouse. At the end we could import the Financial Instruments statements and the General Ledger Statements to a Business Information Infocube which contained the complete Financial Statement of the Bank. This approach, which “merged” the Financial Instruments Statements and the General Ledger in a Business Information Warehouse Infocube, was called Merged Scenario.

With the Version 5.0 (released 10 years ago), we got the first Bank Analyzer - AFI System which could be called a real sub-ledger, this version brought two big improvements:

- The Results Data Layer, capable of storing Accounting, Risk and other formats of data (including external Data). Foundation of the Integrated Financial and Risk Architecture.

- The General Ledger Connector, responsible of extracting the Accounting Data from the Results Data Layer and send it to the General Ledger, where the aggregated accounting entries, fully reconcilable with the Financial Instruments sub-ledger, are posted.

Version 5 of Bank Analyzer supported multi Accounting System functionalities (actually older versions supported several accounting systems too), meaning that the Financial Statements of the Financial Instruments could be generated according to different Accounting Principals (typically Local GAAP and IFRS).

And finally, we arrive to Bank Analyzer 9 and Smart-AFI. One point that we must consider when we’re thinking about Bank Analyzer-AFI is that Bank Analyzer valuates individually and builds a complete Financial Statement per individual contract (Financial Transaction or per every Security managed in an specific Securities Account), and this is a huge computing effort, when we’re valuating the portfolio of a commercial or investment bank.

Additionally, if the Bank is evaluating the portfolio according to several Accounting Systems (for instance Local GAAP and IFRS), the system suffers a double computing effort. This is the way that all Bank Analyzer versions, older than Smart-AFI, support the multi Accounting System requirements.

On the other hand, there’s a more efficient way of generating multiple Financial Statements, according to multiple Accounting Systems. Instead of creating completely isolated Financial Statements, the system can create a Central Ledger, and additional Ledgers, with the differences-adjustments, also called “deltas”, from the Central Accounting Systems to the parallel ledgers, supporting alternative Accounting Systems.

From a Legal Accounting perspective, the result is the same, but from a performance-computing perspective, the Smart-AFI is much more efficient. Smart-AFI covers the same multi-Accounting requirements, with the same accuracy and flexibility, but with much less computing effort; this is the Smart part of Smart-AFI.

Looking forward to read your opinions.

Kind Regards,

Ferran.

www.capitency.com

Join the SAP Banking Group at: https://www.linkedin.com/groups/92860

Visit my SAP Banking Blog at: http://sapbank.blogspot.com/

Let's connect on Twitter: @FerranFrancesGi

Ferran.frances@capitency.com

IFRS 9 for Dummies.

Dear,
Last months I have given several workshops of Bank Analyzer, and the implications of the new IFRS 9 regulation, which was issued by the International Accounting Standard Board on 24 July 2014, and it is mandatory from 1 January 2018.

In some cases, I’ve seen that the IFRS 9 regulation and its implications is not fully understood; this made me think about the opportunity of writing this blog.

IFRS 9 is the new Accounting Standard for Financial Instruments, which is replacing the former IAS 39, and it covers the following topics.

- Classification and measurement of financial instruments
- Impairment of Financial Assets.
- Hedge Accounting.

The Classification and measurement part establishes that Financial Instruments must be classified according to the business model, which must be determined by the company executives, and the nature of the cash flows.

IFRS 9 also establishes two measurement category, depending on the Financial Instrument classification: Fair Value and Amortized Cost.

Amortized Cost is available for assets that meet two conditions:

1) The assets must be held in a business model whose objective is to collect the contractual cash-flows.
2) The contractual cash-flows must represent repayment of principal and interest on principal.

IFRS 9 proposes the following classification of Financial Assets:

- Debt instruments at amortized cost.
- Debt instruments at fair value through other comprehensive income with cumulative gains and losses reclassified to profit or loss upon derecognition.
- Debt instruments, derivatives and equity instruments at fair value through profit or loss.
- Equity instruments designated as measured at fair value though other comprehensive income, with gains and losses remaining in other comprehensive income.

Finally, IFRS 9 permits reclassifications when the company changes its business model or the holding of the assets.

The Impairment of Financial Assets topic has changed from the model of incurred losses on IAS 39, based on the principle that the Loans are repaid unless there’s an event producing the losses, to the model of expected losses that are recognized during the life-cycle of the Financial Asset.

Some advantages of this new approach are:
- Reduce the complexity of impairment measurements to a unified model.
- Avoids late recognition of the credit losses, as it happened during the 2008 Financial Crisis.
The Hedge Accounting part has been redesigned towards an approach which aligns Hedge Accounting with Risk Management, with the following requirements.

- Increase the available information for Risk Management, including the integration of the Risk Management policies in the Financial Statements.

- Support Hedge Accounting with internal information for Risk Management.

- Disclose the impact and effectiveness of the Risk Management and Hedge Accounting measures in the Financial Statements, including the impact of the Derivatives in the future cash-flows.

This is just a short introduction of the new IFRS 9 regulation, but this is a very important topic and we will look at it in future blogs.

Looking forward to read your opinions.
Kind Regards,

Ferran.

www.capitency.com

Join the SAP Banking Group at: https://www.linkedin.com/groups/92860

Visit my SAP Banking Blog at: http://sapbank.blogspot.com/

Let's connect on Twitter: @FerranFrancesGi

Ferran.frances@capitency.com

IFRS 9 implications on Accounts Receivable Open Items.

Dear,
IFRS 9 implications go further than what many Banks and Corporates executives expect. For this reason, many Banks and Corporates are far from being ready to be compliant to IFRS 9, which is mandatory from January 1st, 2018.

A particularly interesting example is the management and Value Recognition of Account Receivable Open Items on IFRS 9.

According to IFRS 9 Accounts Receivable Open Items are classified as LAR (Loans and Receivables) and valuated at Amortized Cost using the effective interest method. Technically, this means to determine the Cost of Capital related to the Open Item (considering the Probability of Default of the Counter-party and Loss Given Default of the Exposure) and penalize its Nominal Value accordingly.

Remember that not only banks, but also publicly listed companies are subject to IFRS 9, which means that in 2 months they should have developed the Risk Models for determining the Probability of Defaults of their clients, and Loss Given Defaults of their Account Receivable Open Items. 

Are they going to be ready on time? We’ll see.

But let’s look at the IFRS 9 implications from the Banks perspective.

Factoring is a very common Financial Service offered by Banks for the management of Account Receivables; with Factoring a Corporate “sales” its Account Receivable rights to a Bank in exchange for cash, which means that the Bank is taking the counterparty Risk and the Cost of Capital related to the Assets (Accounts Receivable Open Items).

Again, this means that in 2 months they should have developed the Risk Models for determining the Probability of Defaults of the counterparties of the acquired  Account Receivables, and Loss Given Defaults of the related Exposures, so they can valuate the acquired assets at Amortized Cost, using the effective interest method. . 

Are they going to be ready on time? We’ll see.

But the analysis becomes a little bit more complicated when we look carefully at the IFRS 9 implications for the acquired assets. If the Bank acquiring the assets has the positive intention to hold to maturity the acquired assets, they are classified as LAR and valuated at Amortized Cost (analogously as the corporate would), but if not, they must be valuated at Fair Value, which obviously brings new challenges to the Valuation of the acquired assets.

Once again, are they going to be ready on time? We’ll see.

On the other hand, there are two different Financial Services related to  Accounts Receivable Open Items, one is the Factoring, that we analyzed above, the second one is Invoice Discounting.

With Invoice Discounting Financial Service, a Corporate borrows cash from a Bank, using its Account Receivable Open Items as Collateral of the Loan.

With Invoice Discounting, the Counterparty Risk remains in the Corporate and the associated Cost of Capital of the Account Receivable Open Items must be posted in the Corporate books. Additionally, the Corporate holds a liability (the money borrowed from the Bank) that must also be reflected in the Corporate books.

SAP offers a complete solution for the management of the Account Receivables Open Items and the Factoring and Invoice Discounting Financial Services related, combining FI-CA, Bank Analyzer and other modules, but this blog has become too long, we’ll talk about it in a future one.

Looking forward to read your opinions.
Kind Regards,
Ferran.

www.capitency.com

Join the SAP Banking Group at: https://www.linkedin.com/groups/92860

Visit my SAP Banking Blog at: http://sapbank.blogspot.com/

Let's connect on Twitter: @FerranFrancesGi

Ferran.frances@capitency.com