Skip to Content

Simple Finance was quite a popular topic during the ASUG Annual Conference in Orlando in May. In particular, many conversations sparked around Simple Finance deployed as Central Journal. Unfortunately, we didn’t have enough time to go into the details and I believe one particular scenario was overlooked and deserves a deeper dive: how Simple Finance, deployed as Central Journal, supports companies in their merger and acquisition processes.

I won’t go into the details of Simple Finance and Central Journal, which have already been described in previous articles:

Don’t hesitate to use the comments section if some details are still missing.

40,000 transactions a year

There is an increasing number of Mergers and Acquisitions (M&A) and the average deal size is also on the rise. Just today, “Goldman Sachs just hit $1 trillion mark for advisory work on merger and acquisition deals” [1]. The Institute of Mergers, Acquisitions, and Alliances (IMAA) estimates that more than 40,000 transactions valued over 4,000 billion USD will be completed worldwide in 2015 only [2].

figure_announced mergers & acquisitions worldwide.jpg

After the business combination transactions, the first close is critical and needs to be completed at the end of the next quarter, 90 days at most. Any time saved in the process is critical [3]. Under these circumstances, what could you do to speed up the integration of systems, while ensuring an accurate and complete consolidation of the financial information from both the acquiring and acquired entities?


Solving Acquisitions


It is fair to assume that in most of the above described 40,000 transactions, the acquired company already has a financial software in place, from very small like Quickbooks to medium-sized like SAP Business One or large to very large like SAP ERP Business Suite, running all modules for Finance, Production, Sales, Procurement, Human Capital Management, etc.


The least disruptive way to integrate these systems into the landscape of the acquiring company is to let them run independently and only interface the financial transactions for regulatory consolidation purposes. The option to merge information systems can come later. We won’t be focusing as much here on the pure financial reporting, which can be solved with specialized solutions like BPC, but rather take a closer look at how companies run their daily transactions and operations, as well as their data warehousing and reporting strategies.

Let’s take an example. In the pharmaceutical and life-science industry, mergers and acquisitions have become a popular corporate strategy in the past decades to attain growth and mitigate the costs and risks of research and development. For instance, within a week of getting approval from the FDA after 2 rejections of its sole drug, known as the “female viagra”, Sprout Pharmaceuticals received approval and got acquired by Valeant for $1 billion [4].

In this environment, picture a fictitious company called PharmaCorp Unlimited, acquiring SmartPills Inc after the approval of the first ever anti-hangover pill (unfortunately, this is only a hypothetical scenario.) Like most companies, SmartPills already has an ERP system. Within 90 days, all financial information from SmartPills have to be normalized and integrated into PharmaCorp’s consolidation system for reporting.


Traditionally, companies would have 2 choices to run their transactions and reports: absorb the acquired company in the existing landscape or maintain the 2 systems separated and use a data warehouse or consolidation solution to deliver the required reports.


Traditional Merger Architecture #1: merge into the acquiring company's ERP

Traditional Merger Architecture #1: merge into the acquiring company’s ERP


Traditional Merger Architecture #2: maintain 2 systems and consolidate in data warehouse

Traditional Merger Architecture #2: maintain 2 systems and consolidate in data warehouse


The trouble with the solution #1 is mostly related to master data: the financial ledgers, customers master data, and products databases need to be aligned. This is preferred when the acquired company is very small and / or is limited to R&D and therefore doesn’t really have any products or customers.


Solution #2 is not perfect either, even though it is more frequently used in cases where the acquired company has a significant operation already or when separated operations is favored because of long-term strategy or simply because the cost of integrating would be too high for a limited return. The data integration is achieved through standard data warehousing tools and existing reports might be leveraged. However, this architecture is limited because the data feeds between the ERPs and the reporting systems are far from real time (usually monthly, nightly at best) and is almost always aggregated, which means that the traceability down to the document or line item is lost in the process, as well as opportunities for insights or corrections of transactions.


The best solution in that case would be to architect ERP systems around a Central Journal, as depicted below:

Preferred architecture using Simple Finance as Central Journal in Merger or Acquisition scenario

Preferred architecture using Simple Finance as Central Journal in Merger or Acquisition scenario

In this chart, you can easily identify PharmaCorp’s environment. There are usually 2 cases here: either the ERP system is already a Simple Finance or S4/HANA platform or it’s not. In the first case, all prerequisites are met. In the second, PharmaCorp will have the choice between upgrading their current landscape or setting up a new instance. This is the so-called Central Journal deployment option. In both cases, SAP Landscape Transformation (SLT) will be connected to SmartPills system to import all financial information, in real time and at the most granular transactional level, either from an ERP or a 3rd party platform.

This architecture can be setup quickly and is very effective for the consolidation of data, thus enabling companies to reach a first close faster.

Solving Dispositions and Spin-Offs

The situation that is more problematic is the case of Dispositions or Spin-Offs. We could easily imagine from the above architecture what it would take to resell SmartPills: simply cut system connections and let the new company sail its own wind.


However, what would happen if the technology or drug had been internally developed? What would you do with all their master and transaction data that reside inside the original environment? Let’s say PharmaCorp wants to spin-off an amazing diet pill called SuperThin. How would you go about setting its own ERP system?


Traditional Disposition architecture: copy and filter

Traditional Disposition architecture: copy and filter


Most companies would probably perform a full system copy to a new machine and progressively select and remove or disable the information from the previous company. The consequence here is that the Data Warehouse and Reporting environments would also have to be copied, otherwise the new company would loose its complete reporting and may not be able to support some of its processes.


Preferred architecture using Simple Finance as Central Journal in Disposition scenario

Preferred architecture using Simple Finance as Central Journal in Disposition scenario


What if there was a better option? What if you could easily create a new instance of an SAP Simple Finance system and leverage SLT to filter and only export what you need? By leveraging standard technology and reports, only a few Fiori Apps or reports would have to be transferred if needed. In addition, thanks to the real-time replication, this could be done at any time during the lengthy selling and due-diligence process, thus enabling less time-constrained setup and testing and providing a smoother transition.


Your turn …


There are as many situations as organizations. Let’s use the comment section below to take a snapshot of your own environment and specificities.


How many ERP systems does your company currently run in production? Which architecture is currently in place for transaction and analytical / reporting data? Does it support real-time reporting and line-item analysis?

How frequently does your company merge with, acquire or retire other companies? How do you currently solve these cases? Which advantages and limitations do you see?

Have you considered a Central Journal deployment? Which advantages and limitations do you foresee?


Sources

[1] Business Insider: Goldman Sachs just hit a mythical number for M&A advice

http://www.businessinsider.com/goldman-sachs-just-hit-a-mythical-number-for-ma-advice-2015-8

[2] IMAA: Statistics of Mergers, Acquisitions, and Alliances

http://www.imaa-institute.org/statistics-mergers-acquisitions.html#TopMergersAcquisitions_Worldwide

[3] Division of Corporation Finance: International Financial Reporting and Disclosure Issues

https://www.sec.gov/divisions/corpfin/internatl/issues0501.htm#P309_28448

[4] How a tiny company brought the first ‘female Viagra’ to market against all odds

http://www.businessinsider.com/sprout-pharmaceuticals-got-approval-and-acquired-by-valeant-all-in-one-week-2015-8#ixzz3jyuP4Vi4

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

Leave a Reply