Key Insights from Implementing Oracle Cloud EPM Predictive Cash Forecasting

I recently completed an implementation of Oracle Cloud EPM Predictive Cash Forecasting (PCF). It was an interesting and challenging experience. PCF was introduced a little over a year ago and this was our first implementation of the product. It was a learning experience for everyone involved. While at its core PCF is a Planning application, there are many features and functionalities that come out-of-box which make it different from a regular Planning implementation. While it’s fresh in my mind, I want to review some of the things that we encountered, limitations to know about, and general lessons learned. I also want to state that Oracle Product Management was extremely helpful during the implementation by providing guidance, clarification of functionality, and even enhancements to the product. In no particular order, here are my thoughts on PCF.

If you’ve seen the Oracle demo of PCF, be aware that not all what is presented is OOB. Everything shown is possible, but some of it is custom development. Specifically, the features and functionality in the Treasury navigation flow are all custom development. It was not a difficult development, but it did require additional work that added to the timeline. We discussed it with Oracle and their approach to that functionality was to show how other capabilities can be added to the OOB solution and tied together for the forecasting process. Remember, at its core PCF is a Planning application, so there are lots of features that can be incorporated into it.

Another demonstrated item that is not OOB is the reports and dashboards called FVA. They are meant to highlight the forecast results by different forecast methods (i.e. driver vs prediction vs manual input). This is custom development and adds time and effort to the implementation. While somewhat useful to compare the results of different forecast methods, I think it’s more of a nice to have and not necessary. That’s just my opinion, others may feel different.

One of the most challenging, if not most challenging, aspects of the PCF implementation is the integration of BAI data files. The banking industry has a standard file format that banks use for exporting data. EPM Planning does not currently have a native method to integrate these files. We had to develop a custom transformation process to convert the BAI text files into a usable CSV format to integrate into PCF. Interestingly, EPM ARCS does natively consume BAI files, but ARCS is a different architecture than Planning, thus the ability to take in the files. This was an issue we discussed extensively with Oracle, and I am happy to say they listened and put it on the roadmap for future enhancement.

Another issue with the BAI files is that even though it is a standard format that all banks use, each bank has their own configurations in play. For example, there are multiple codes for ACH transactions, multiple for ZBA transactions, and several other groupings. In PCF we need to know if the transaction is an inflow or outflow to cash and map it to the appropriate line item. But with so many different codes in the BAI file, and each bank using different codes for similar transactions, mapping can become rather complex. And the descriptions that each bank applies to transactions can vary greatly as well. This was challenging for us because we were using words in the descriptions as part of the mappings. This was partly due to how we used the Category dimension.

The Category dimension is a custom dimension, but it is part of the OOB configuration whether you use it or not. We decided that instead of adding too many Line Item members beyond the default OOB members, we would use Category members to further define the transactions. For example, OOB Line Item Other Payables gets transactions that include bank fees, credit card fees, bank transfers, and more. We needed to have visibility into those details, so we used the Category dimension to have members for the several types of payables. This added complexity to mappings. It may have been better to add more Line Items and have a more straightforward mapping of the BAI code to the Line Item. It would also have simplified forms and reports. Definitely something we will consider in our next implementation.

An especially important consideration when implementing PCF is what ERP will be used as a source. PCF is optimized for integration with Oracle Fusion ERP, several of the OOB features and functionality depend on Fusion ERP for advanced forecasting capabilities. With that said, it is still worthwhile to have PCF integrated with other ERP sources. In ours we integrated with SAP to load AP and AR forecast data based on the due dates of invoices. We could have also brought in actuals from SAP, but a decision was made by the client that they wanted to use the bank files for that data as it was more timely for their analysis (there is a lag between when transactions are recorded at the bank vs when SAP reflected the transactions). Had we used SAP as the source for actuals, mappings would have been easier.

One of the more unusual issues we encountered was with alternate Period hierarchies. OOB configuration creates alternate hierarchies to group days into weeks. The parent members for the full year have alias’ that include the year name, and the week parents have alias’ that include the calendar days. For example, Reporting Hierarchy1 for FY25 has the alias “Jan 2025: Jan 2026” and Reporting Hierarchy1 W1 has the alias “06-Jan: 12-Jan”. However, W1 contains Period members Day1 through Day7. That’s a problem because Day1 is “1-Jan”. The OOB alias for week one is accurate, but the members included are not. The alternate hierarchies are supposed to automatically update based on the current year and can be refreshed annually when the current year rolls over. As built at this time, we are not able to rely on them and had to create custom alternates to reflect the correct days per week.

Overall, PCF is an excellent product in the EPM stack. I’ve said several times over the last few months that as a new product in EPM, at introduction PCF was much more developed and ready to use than other products when first introduced (I’m looking at you Workforce). Oracle has been very responsive to our questions and suggestions, and is actively making improvements based on our implementation.

As always, happy EPM’ng!

2 thoughts on “Key Insights from Implementing Oracle Cloud EPM Predictive Cash Forecasting

  1. thanks for sharing your experiences on PCF. Could you please help me understand how you managed to bring transactional data in PCF.

    Was it by invoice ? If so what dimension you managed to keep invoice numbers.

    Like

Leave a comment