Skip to Content
Author's profile photo Former Member

Deployment Scenarios for Simple Finance as Central Journal (it depends!)

[Edit May 1st, 2015: I included here answers to very interesting questions from the comments]

I was lucky to be able to attend both BI / HANA and Financials conferences offered by SAP Insider in April 2015. In both cases, Simple Finance was covered in details and customer questions were frequently related to specific situations for which most answer had to start with : “well, it depends”.

I am also taking this opportunity to follow-up on my article on Implementing SAP Simple Finance that generated lots of very interesting questions in the comments section or by email. If you missed it, I suggest you read it first.

It’s not a Solution, it’s a Deployment Option

To paraphrase TruQua’s David Dixon: “Central Journal is not a solution, but a deployment option for Simple Finance”. And not a recent one. As early as 1998, several of our large customers have chosen to use several ERP systems, for reasons related history / growth (mergers or acquisitions), sizing / performance optimization (separate finance from logistics from purchasing, etc.) or legal / regulatory considerations (separate different GAAPS). SAP used to support and promote hybrid implementations in its battle to outpace best-of-breed solutions like JD Edwards or Siebel.


Source: David Dixon, TruQua Enterprises

What is wrong with today’s way?

If you have multiple ERP systems, you have to consolidate the financials just to meet regulatory reporting requirements. Today, most companies are consolidating several ERP and/or non-ERP systems into a business warehouse like SAP BW and may use reporting tools from the Business Objects tool set.


(c) Julien Delvat, Alta Via: Consolidation through SAP BW

There are however several limitations here:

  • Data import from ERP systems into BW is batch driven, mostly overnight. Not real-time,
  • Data is aggregated in BW. Access to line item can be achieved through report-report interface, but makes it hard to find and correct line-item mistakes.


This last point is critical. To the point that several large organizations have chosen a slightly different architecture, in which all financial information is consolidated into a central ERP system where only the Finance (FI) and Controlling (CO) modules are active. Doesn’t it look like a Central Journal already?


(c) Julien Delvat, Alta Via: Consolidation through standard SAP FI/CO

Why not merge into a single instance?

“Since Simple Finance would solve performance issues, why not simply migrate all my systems to a single instance?” I received this question quite a bit by email, so let’s tackle it.

Advantages of a single instance with Simple Finance:

  • No need for reconciliation
  • Single set of master data
  • Lower TCO
  • Increased performance
  • New user experience with Fiori
  • Can be implemented on premise or in the cloud


On paper, this looks great, but the problem lies in the migration project, especially the merger of all master data, including accounts in the general ledger, customer references, material master, vendors, etc.

An automotive supplier company in Europe is currently consolidating 8 ERP systems into one. After 3 years, they still have 5 systems to go. A global pharmaceutical company currently merging 50 systems into 40 also pointed that even if this would only take 1 year, they would have acquired another 3-5 companies in the meantime.

There are also situations where a system cannot be integrated into a single instance. Maybe that particular business unit is on Classic G/L and doesn’t want to upgrade to New G/L. Maybe your small subsidiary’s ERP is not on SAP and it would be too costly for them (believe it or not, SAP may not always be the best option).

To sum it up, merging your ERP systems into a single instance may not be feasible or the migration project could be too expensive to justify the return. In such cases, using Simple Finance as a Central Journal may be a better option. For your particular case? Well, it depends!

Deployment Scenarios

Let’s assume you are considering using Simple Finance as a Central Journal. What are your options? As you probably guessed: well, it depends ;o)

Option 1: elevate one of your systems to become the Central Journal


(c) Julien Delvat, Alta Via: Consolidation through upgrading to Simple Finance

The requirements for a system to take full advantage of Simple Finance are:

  • ECC 6 with EhP7
  • Unicode data types
  • New G/L
  • SAP HANA database
  • Financial Add-On
  • SAP Fiori User Interface

Should any of these components is missing, you may be able to leverage Rapid Deployment Solutions offered by SAP or consulting partners like Alta Via Consulting (Rapid-deployment Solutions | SAP).

Option 2: you install a side-car Simple Finance system.


(c) Julien Delvat, Alta Via: Consolidation through side-car Simple Finance

If any of these requirements prevents your system from being upgraded, then you may consider a new instance, on premise or in the cloud.

Which one do you recommend?

We usually recommend this second option over the first one for several reasons:

  • It’s faster (no migration),
  • The master data of the “main” ERP may not be as clean as expected,
  • It’s an opportunity to clean master data and apply master data governance,
  • The Central Journal can be wiped out and reinitialized if master data rules need to change

In the future, the first option may become prevalent as the upgraded system will not only benefit from Simple Finance, but also from the expected future Simple Applications like Simple Logistics (due 2015), Simple CRM, Simple SRM, etc.

[Edit May 1st, 2015]

Mark Chalfen: What if you need to update the source systems from the central journal S/4HANA system?

Work is still required here by SAP, or there might be scenarios the customer needs to build.

I believe there would be 3 main types of updates that need to happen: integration, master data, or transactional data.

If the problem is related to the integration, like a new material or customer reference is created but not picked up correctly by SLT, then it should be fairly easy to identify (Totals from all systems and Central Journal wouldn’t match). Next, the mapping integration would need to be updated and transactions would have to be reimported. The good news is that since the Central Journal system would consist of a replica of the other ERP systems, you could erase as much data as you want before re-running the import.

In the other cases, master data and transactional data, an error is identified in the Central Journal system, but the root cause is in the source system. For instance, a wrong date on an shipping document, incorrect amount on an invoice, typo in customer number, etc.

I don’t think it would be a technical challenge, as opposed to a process one. The clerk / analyst who did the error in the first place should know about it and correct it himself. You are right that there is currently no automated way to correct it in the source system. Something to recommend to our friends in the SAP development group 😉

Patrick Brandicourt: You  refer to the migration project challenge in  the single instance scenario, have you not the same underlying data challenge for any of the explained scenario ?

Yes, we would have similar, but not identical master data governance challenges. If a customer is identified as ABC in system 1, DEF in system 2, and GHI in system 3, the mapping could be tedious. This is especially true with material master data that have auto-generated numbers as opposed to a naming logic. Here, you would highly benefit from having setup an SAP Master Data Management (MDM) system.

Anyways, the difference here between the consolidation of multiple systems and a Central Journal approach is that the operational systems wouldn’t be touched. You don’t need to convert all your invoicing and accounting documents for the last 3 or 4 years with the risk that not everything has been taken into account. Since the Central Journal is a separate copy of all the source systems, the mapping could be done “on-the-fly”. As explained in the previous question, if after the integration you were to identify a material or vendor that was forgotten or incorrectly mapped, you could always drop transactions from the database and rerun the integration.

I believe this is a much better solution. What do you think?



As stated by Carsten Hilker, SAP Solution Owner of Simple Finance: “With a Central Journal, customers can get a consolidated financial and management reporting, a central process execution like intercompany or cash management, and integrated transaction processing and planning, consolidation, and reporting.”

In the past, companies used SAP BW or a standard ERP system, with limitations due to aggregation, performance or TCO. This familiar deployment option called Central Journal can be reproduced with greater benefits with SAP Simple Finance. It is better, faster, with more features and more affordable than merging several ERP systems into one.

Central Journal with Simple Finance can be deployment either by upgrading an existing ERP system or by installing a side-car system, on premise or in the cloud.

I hope this article helped you. Do not hesitate to ask questions in the comments sections below or by email. Especially, don’t forget to share some details because, you know, it depends!

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Hey Julien

      thanks for this blog..

      this is a very detailed overeview and I was unaware of the previous services. I agree the new approach is much more attractive for customers and I know a few who are currently looking at this now.

      I would add one point where you have many systems feeding into one (even for a short period of time) there may be scenarios where you need to update the source systems from the central journal s/4hana system. Work is still required here by SAP, or there might be scenarios the customer needs to build.

      using the cloud to prove the central journal seems the most sensible of approaches as it is quicker and cheaper, and if it does not work out you dont have loads of HANA kit lying around unused.


      Author's profile photo Former Member
      Former Member
      Blog Post Author

      Always great comments, Mark ;o)

      I have updated the blog with your question. I hope I answered it fully.

      Author's profile photo Former Member
      Former Member

      Great article highlighting it is not easy to get simple.

      I have a question :

      - you  refer to the migration project challenge in  the single instance scenario

      - have you not the same underlying data challenge for any of the explained scenario ?

      Author's profile photo Former Member
      Former Member
      Blog Post Author

      Great question.

      I have updated the blog to answer it. Let me know what you think.

      Author's profile photo Former Member
      Former Member

      is CJ aka a top-down adj?

      Author's profile photo Former Member
      Former Member
      Blog Post Author

      I am not sure what your acronyms mean, here ...

      Author's profile photo Former Member
      Former Member

      CJ = Central Journal, aka = also known as, top-down = as in the last step of closing, and adj = adjustment (correction, storno).

      Author's profile photo Mikhail Lukyanau
      Mikhail Lukyanau

      Central journal is a core in this technology.This is the best way which lets you get analityc intrface at once. Great reminder about that. Just only one thing: solution manager should know ahout it and never turn left from this strategy.

      Author's profile photo Former Member
      Former Member
      Blog Post Author

      You are absolutely right.

      Solution Manager is usually consider too late in such processes.

      Author's profile photo Hai Tran
      Hai Tran

      Central Journal is just full Accounting and Finance function activated, right? And it will stand alone to get update data in detail line item posting from other ERP and/or system by using Interface, i am correct?

      Do you think it is worthy to build all interfaces (both inbound and outbound) to get update data into Core Central Journal system?

      As what I understand if using S4 HANA, data will come instantly and we can analyst data in multiple dimensions. Question here is if we use only 1 Core Central Journal system under S4HANA, will it be possible to analyst data into multiple dimensions as expected? I suspect it would be relied on solution of design of interface from other to this core.

      Any ideas?


      Author's profile photo Shashank Sinha
      Shashank Sinha

      Hi Julien,

      Do we have any comparisons(effort, difficulty, timelines) on integrating it with an SAP system vs a Non-SAP one.

      Are there any restrictions on other Finance systems that can be integrated to it?



      Author's profile photo Erno Nykanen
      Erno Nykanen

      Hi Julien, an excellent post I must say.

      I was a little bit left wondering about the part where you noted that currently many organisations already have a central finance-like systems in place where there is just a central ERP with only FI/CO modules and other systems consolidate data to there.

      Could you just clarify that what is the motive of not upgrading this system and instead implement a side-car central finance?

      You refer to master data problems if one was to migrate all systems to one but what if the intent is to just use the system as-is? Migration to Simple Finance is another topic entirely but are there some specific factors that need to be considered when using the system as central finance?

      Author's profile photo Former Member
      Former Member

      Hi Julien,

      thank you for very good overview of the hot topic.

      Just a few questions regarding how this is should be deployed (unfortunately did not find any details regarding this on SCN or SAPHelp):

      Option one:  we have separate SoH with sFIN installed where we will move Fi+Co documents using SLT Replication Server, however question is will SLT handle initial load of master data and configuration so FICO documents can go to that system or separate migration project (master data, manual configs, transports) should be done?

      Option two: not really clear what are components to handle "Central journal"? Does it require NW, Core Financial components, etc or it is just HANA DB with sFIN models imported?

      Best regards,


      Author's profile photo Erno Nykanen
      Erno Nykanen

      Hi Igor,

      Option 1: I have studied SLT a bit and the way it works is that when you set it up, it does the initial upload first than then begins the real-time replication.

      Option 2: You really need every component in the "Central Finance" deployment model that you would as in full Simple Finance. As a matter in fact, Central Finance is exactly the same as full Simple Finance deployment but the Central Finance name is just given to this one scenario where SAP sees sFIN could be used.

      Author's profile photo Former Member
      Former Member

      HI Julien,

      Thank you for detailed document. Its a great detailed explanation.  I have gone through the SAP note which says some of the functions not support by sFIN 2.0 like JVA for new asset accouting, RE and cost based COPA.....these are  challenges I for see...

      Author's profile photo Asheesh Bhatia
      Asheesh Bhatia

      Hello Julien,

      Thanks for the excellent post. I have a few questions.

      1. If we go with option 2 (Central Journal side car), how is that different from the existing approach of merging multiple ERP systems into one central ERP system, before sending the data to BW?

      2.  Let's say we still go with option 2. One of the big advantages of SFin is the central table where all data is stored. How will this be achieved if the data is fed from multiple sources (including non ERP systems), if my source systems do not have the same SFin data table structure?



      Author's profile photo Avishay Levi
      Avishay Levi

      Hello Julien,

      Thanks for the excellent post.

      I have a few questions , If we go with option 2 (Central Journal side car)

      1)   If the source system use classic G/L and the side Car new G/L with document splitting (let's say document splitting by profit center) , how do we set the openning balance in A/R and A/P  in the central finance for the initial load.
      I undersatnd that replication after initial load should work as it take it in the SLT from ACCTID structure

      2)   If in the source systems we don't use account-based CO-PA and in the side Car we use account-based CO-PA .....will it create any problem with profitabilty segemnt derivation.

      3) Let's say we decide later on once we implemnet the S/4 HANA OP 1511 in the side car solution to start converting the source systems into the central system will it be possible as we already have set the financials balances or we need complete new set of company code buildout and convert them.



      Author's profile photo Former Member
      Former Member
      Blog Post Author

      Thanks everybody for the very interesting questions. I realize that I didn't take the time to answer some of them and some might be outdated.

      As a preferred partner for Simple Finance / Central Finance, Alta Via has been invited to test the latest development in Walldorf. I will be there next week for testing and feedback with the product managers and developers.

      I will be writing a blog post of the event when I get back, but it’ll of course be more interesting if it matches your most pressing questions.

      Do you have any outstanding questions or topics that you would like me to focus on? Please contact me directly with your questions.




      Julien Delvat

      Author's profile photo Former Member
      Former Member

      Hey Julien

      I hope you are well.

      The area I would like to see some development would be in sending messages back to the original ECC systems where you have central finance.

      Example would be 3 current ECC systems linked to a central finance system.

      In Central Finance you process data such as AP (so enter invoices). If there is a price difference in the AP invoice - the moving average price in the legacy ECC system is updated.

      So my question would be - will these scenarios be in scope in the future?

      Author's profile photo Former Member
      Former Member
      Blog Post Author

      Let's have a call when you can. I'm julien.delvat on skype ...