Recently, Janet Salmon, chief product owner for management accounting at SAP and co-author of Controlling with SAP S/4HANA: Business User Guide, took part in our SAP PRESS Book Club and answered readers’ controlling questions. Here’s what she had to say.
Q: What do you think is going to be the biggest change to controlling in the coming years?
A: The big scary one for us at the moment—in terms of it being fascinating, but huge—is probably the whole sustainability thing. The idea is that we try to look at things like carbon footprint across the whole supply chain. So, we’re going from the basic costing idea where you're going from widget to semi-finished product to finished product to something that you can sell to the customer, and adding the idea that you can follow that chain and say “What's the energy impact, how much green energy is involved, how much carbon is in the component?” then roll that all the way through so you can have a carbon balance sheet and see what you're using. There's a lot of research going into this topic at the moment. A lot of clever people are getting together to talk about what to do and how to actually do it.
It's basically a costing question, and the challenge is to do it in an integrated system. At SAP we're the guys with the integrated system, and we've got all the information somewhere in a lot of cases, but how do we roll it all together? It used to be just about carbon trading and having a good idea of how much carbon there was in what you were involved with, buying and selling them like a financial instrument, etc. Now it’s super critical to your whole supply chain. Down the line we’ll probably be able to see this information on the packaging. For example, you'd pick up a jar of jam and you could read the ingredients and the carbon impact.
Q: What's your favorite part of controlling?
A: I'm still a product costing person at heart. I still love that moment where you walk into somebody's factory and you can see the products that they're proudly showing and can follow the raw materials around the factory. I found that so much easier to visualize than allocations, even after all this time. I had a wonderful term come in from one of our customers who called the allocations “Financial voodoo” and went on to say “what's really important is here on the shop floor.” I still feel a bit like that.
Q: Do you know of any industries out there that haven't touched costing?
A: The one group of customers that I have never had anything to do with has been railways for some reason. I know we have railroad customers, but they've never spoken to me. So, if there are any railway customers reading this, feel free to drop me a line.
Q: Are there any industries where costing is so complicated that you feel bad for them?
A: Every industry has their different challenges, and I think one of the things that we're seeing changing is that I used to be very clear about using the coding block to add fields where you wanted to have the extensions in the balance sheet and profit/loss, whereas in CO-PA adding fields to the operating concern meant extending the profit and loss statement. We're now starting to see those borders merge so that you're getting things like work in process and so on showing up with the market segments attached. So, my old definition of CO-PA as being basically just a more detailed version of your profit and loss is actually starting to change. We're reworking this so that you can have balance sheet items with the same granularity and that's a long, long process because it depends very much on the industry. We're quite a long way with commercial projects, but we're right at the beginning if you're a bank or a media company.
Q: How is SAP helping customers handle volatile business impacts such as changing currency values?
A: One of the things that we typically find is that we tend to run out of currencies in controlling, and that's something that's becoming critical at the moment. If you imagine a US-headquartered customer, you know that their corporate currency is obviously going to be US dollars. They're probably also operating in Europe, so they're also reporting in euros. That's fine—it’s just two currencies. But then if they’re operating in Switzerland, they’ll need Swiss francs. Again—fine, dollar and francs, no problem. But because their Swiss company is operating to a large extent with euros they actually have a legal requirement to keep euros as well. That's where things start to get challenging, and this business change has been driving change here.
The Universal Journal can handle 10 currencies, and we're getting to the stage with on-premise 2021 where you can have those currencies neatly in each column and handle them completely separately. This means that you can really see what's happening for your business. You're not constantly converting between currencies, but you're looking at the Swiss franc column or the US dollar column or the euro column and treating each separately. Because of the exchange rate changes, the swings between them are quite significant. It can be really interesting to look at what the different flows are doing in those currencies.
Q: What would be your sample procedure for switching from costing-based profitability analysis in SAP R/3 to the new accounting-based CO-PA in SAP S/4HANA Finance? And how would you organize a possible transition period or start-up period in the new SAP S/4HANA system with account-based CO-PA?
A: If you're doing a migration project, we recommend that if you've been doing profitability analysis before to activate account-based profitability analysis as you get into the new system. What that'll do is it'll create columns in the Universal Journal for all the characteristics that you had in your old operating concern. What most people do is they don't actually turn off costing-based CO-PA on day one after their migration; they typically keep it running for a couple of years. Partly this is just so that they've got old historical data. What will happen after the migration is the first document, the first revenue, the first cost of goods sold that you published will have all the market segments attached in the Universal Journal, but all the documents from the 10 years that you've brought with you during your conversion won't have that information. They'll only know which profit center they belong to, which company code, maybe which functional area, but they won't have that nitty-gritty detail of the product, region, and so on. So we usually recommend people to just keep filling the tables. Most people do it for two years and then they say “Okay, I'm going to turn off costing-based CO-PA,” unless there's some really pressing reason where there's something they really want to do in costing-based CO-PA that we don't actually support in marginal analysis.
Q: We have a lot of documents in the database tables of our Material Ledger (because of batch single valuation). When switching to SAP S/4HANA, our costs for storage space would therefore be enormous. However, archiving in SAP R/3 deletes access to the archived Material Ledger documents via CKM3N. Is there an archiving option in the SAP S/4HANA that still allows access to the original ML documents via CKM3N?
You've definitely got to switch in the Material Ledger because the actual costing tables switched in release 1610, so we went to a flatter structure. You've got the Material Ledger document (MLDOC) and the cost components (MLDOC_ CCS). Obviously, we try and convert everything we found in the system. So anything that you've already archived we wouldn't touch. We would just convert all the stuff that's still there. I need to check on this one (accessing archived Material Ledger documents). I know we've got archiving access to the normal journal entries and so on, but I'm not quite sure on the new Material Ledger documents.
Q: When a new business client starts to use CO-PA for the first time, what will be the most important thing that they need to understand about the transaction side and potential of a CO-PA setup if they currently only understand the management controlling model via front-end reporting?
It should be easier to understand margin analysis than it was to understand costing based CO-PA. This is because, essentially your market segment becomes this multi-dimensional cost object, so if you've been used to posting costs against cost centers, orders, or projects, you're just posting revenues against this multi-dimensional thing. Of course, which dimensions you choose is as important as it ever was, because you want to decide how you structure and segment your business and what you want to look at. But your revenues and cost of goods sold will be automatically assigned at that level.
The challenge, then, is as you do your allocations to allocate at a level that makes sense, because you can very quickly come up with something like top-down distribution that generates millions and millions of data records with about two cents in them. It'll take forever to post and the business rationale behind it is almost zero. My favorite example was a paint factory in India that was trying to look at each individual color of paint in each shop in the country. You can imagine the number of potential combinations was just enormous, and you take a thousand dollars or a thousand rupees and spread it across all of those combinations and you end up with vast numbers of documents that don't actually tell you very much at all. So, the point is to take a step back and ask what decisions you are going to drive off that info, and that's almost irrespective of whether you're an SAP ERP user or whether you're in SAP S/4HANA. The key question is what decisions are you going to drive off it and how granular can you be usefully?
Q: Instead of using COSP and COSS tables, should we use COSP_BAK or the ACDOCA table in SAP S/4HANA?
A: Very good question, and actually it's one of those things where the marketing speak tends to overtake the real world speak. To explain the question a little more, COSP is the old, primary cost table, and it's the old totals table and it was very much there in the SAP system in the first book I wrote. It's been eliminated since the publication of my second book, and this is what we at SAP did in return: you'll have seen in the conversion programs that we wrote a backup table to store the historical data. CSP_BCK is the backup table for everything we found in your system when we did the conversion, and we stored the data there just so that we could then go object for object and say: “This is the sum, this is the sum of your line items, and this is what we have in the totals.” So long as the two match, in principle you didn't need your totals table anymore. But if they didn't match, it was a sign for us that you'd archived some of your line items and that we needed to create an extra document that just documented what we could find in the totals table.
So neither COSP or COSP_BCK are actually real tables anymore; although it's not quite as simple as that. All the actual costs are in the Universal Journal, so your actual cost, your actual revenue—anything that's going as a primary or a secondary cost or revenue—is in the Universal Journal. You're actually accessing it just by views, but table COSP isn't totally empty. There's still a few things that we update in there: we still update statistical costs, and we still update some of the public sector business objects, business, and processes. (But you shouldn't really be using those views actively anymore. You should be accessing the data from the Universal Journal directly.)
All of our new SAP Fiori apps read from the Universal Journal directly, and we've been reworking the settlement programs and the allocation programs: basically anything that goes into the totals tables and says “Give me the cost for March.” Instead of getting them out of the totals tables or getting them by the view, we've been getting them directly from the Universal Journal, which has allowed us to do some of the things like universal allocation. COSP looks like it's still there—if you use SE11, you'll still see it—but it's actually just a view. We call it a compatibility view. It makes sure that anything that anybody might have written that used to use those tables still carries on working.
Q: How many custom fields can a company add to the Universal Journal/ACDOCA? And if you add custom fields will that cause problems during an upgrade?
No, it shouldn't. You can have up to 60 characteristics in the Universal Journal as part of the market segment. You've got to imagine that the Universal Journal has got its 350 fields or so, and there's various extension points so you can add coding block extensions. There are different constraints on adding coding blocks and adding characteristics in CO-PA at the moment. We still have got the limit of 60 and you know, that's my second most-frequent question: “When are you going to change that because you said SAP HANA could do everything?” At some point we'll try and get away from that but at the moment we've got a lot of interfaces that still stop at 60 characteristics.
Q: What kind of insight can you provide on universal parallel accounting? What is the expected effort to change from the current model to universal parallel accounting?
Anybody who wants to know what universal parallel accounting actually is—search the SAP Community blog posts that came out for the cloud edition of 2105. You'll find the explanations of what's different in asset accounting, controlling, production accounting, and actual costing out there. Of course, the challenge is, then, how do you convert? How do you go from the way you do it today to the way you maybe want to do it in the future? When SAP S/4HANA OP2022 goes out in the autumn our plan is to only offer universal parallel accounting for greenfield customers, so we're saying to put the structure in and then feed your data in. We haven't actually got conversion tools and, of course, I’m now talking to all the customers who've got all sorts of different ways of doing it. The first challenge is actually to understand how they are doing this thing today because you probably have some form of parallel accounting already, whether you've implemented the old parallel cost of goods manufactured solution or you've been using multiple ledgers in the general ledger.
Maybe you haven't had your controlling attached to anything other than the leading ledger. So I think sometimes it's a philosophical question. Have you been the sort of customer that's been very centralized, tried to push out a template to all your local subsidiaries, and then allowed them to do some kind of adjustment postings for whatever they specifically need? These would have been very much island implementations where every island has gone ahead and built its own stuff. You really need a laundry list of what you're doing today and what's different, and then you start to understand how you can move forward. So maybe you've had lots of different valuations in asset accounting, but you've basically had one approach in controlling and one in actual costing, and then the question is “How different are they and where do you want to be? How do you want to be? Is it even material to represent the differences?” I can remember having discussions with people where you could derive things like the Japanese GAAP from the US GAAP with actually only a few postings. Or is it really important to keep them separate and really understand them, and from a conversion point of view, that's our challenge for the next while: to try and take everybody with us.
Everybody's coming and asking us when are we going to be finished with the conversion tools? It’s a totally reasonable question. Of course, there's the SAP R/3 people that haven't made the leap at all. We’ve often found that people are still using the design that they put in place in 1993 and they haven't really made significant changes to it at all. Others are going for a transformation and saying they’re going to take this ledger approach and they’re going to think about our currencies and what have you. They're putting in structures today knowing that we're doing something down the line, and they want to be able to make a small leap then down the line to where we’re going to be.
Q: What are the biggest challenges in terms of ledgers and currencies at the moment?
A: I think the reason that most people want to come and talk to me is that they want to be future proof. They want to know what we are planning to do two years down the line, so they don't miss on their day to day, and then they want to know exactly which day of the week I'm going to release it. But, you know, a lot of people are moving from the old world with separate accounting and controlling, and they're trying to put the two together, and they're trying to bring this idea of a ledger into controlling. They're trying to understand how many ledgers they need and what the different purposes of the ledger are.
If they’re based in the US, it would be easiest to use US GAAP for all branches so they can actually have a corporate view of the world. In each of the subsidiaries I work in I always have US GAAP locally for my US companies, but I’ve got Canadian GAAP, Mexican GAAP…you name it in that second ledger. Some of them are starting to understand the future and saying “Because we're all friends and family we're all part of a consolidated group, so we'd like to start eliminating and storing those elimination postings by ledger.” That's something we're working on at the moment. We're planning to bring it out, so it's not in my book yet. I can only write about stuff SAP’s done.
The future is bright, but it’s pretty complicated compared to the world we all grew up in where you would have single plants for single ERP instances and then a great big data warehouse sort of hooked over the top. We’re trying to help you pull the pieces together and make it make sense. You can have a common data model now, but then you've got three people at the table with very different requirements all trying to squeeze into one box. What should we do with them?
Q: With SAP changing so much, and now that you're able to do a little bit more like all these moving parts, do you think it's easier to describe information now to people?
A: That was the challenge I had in the writing of the book, and I'd actually be interested in some comments from readers because I did actually try wherever I could to explain using the new user interfaces. I used the T-account app and said “This is balance sheet, this is P/L, and this is how it flows through.” I tried to tell the story through our screens and, of course, I was doing this with 30 years’ experience in my head. What I really needed was somebody who left college last week to sit there and go through my book and tell me “No, this isn’t clear” where necessary.
Q: How did you handle change management in your book? There have been big changes in controlling.
A: What we tried to do was to assume we're doing things the modern way. Let's assume we've got a Universal Journal, let's assume we're using margin analysis rather than costing-based profitability analysis, let's at least mention that there's this event-based production accounting coming to be future-proof so we can hopefully write more about it two years down the line. We wanted to give people the idea this is this is where you want to go, but we also knew that probably 60-70% of people reading the book wouldn't even have an SAP S/4HANA system in front of them. They're trying to make the decision on when to go to SAP S/4HANA, or if they have made the switch, it's not necessarily the most modern one. They may be on OP1610 which is the release of four years ago. So if we showed an SAP Fiori app we tried to let the reader know not to worry if they haven't got that app, and tell them what the transaction code would be that allows them to do something similar. They shouldn’t worry too much if they haven't got the fancy SAP Fiori UI because they can still do things. Every so often we had to say that a T-account app was only in SAP Fiori, but only when absolutely necessary.
Q: Do you think SAP Fiori apps are going to help users be able to do their job better with limited training, or do you think they’ll hurt a company because the user is not going to actually understand the entire process of what they’re doing?
A: It’s a good question. When we first started SAP Fiori development, I used to tell my developers that they were developing for my children who have no patience, never read a manual, and either things work immediately or the device is thrown away. I still think there's an element of that in SAP Fiori now. You're aiming for a different generation, and of course not everybody's been working with SAP for 30 years like I have. We've got new hires as well who actually want to do use SAP Fiori as much as possible. I think you've also got to remember that when I started you used to spend a week in Waldorf just learning how to do FB01 and all the different permutations that you could post there. You could do everything—it was the original Swiss pen knife. But you had to know what you were doing.
Now, of course, we're trying to help people more but there can be times where the SAP Fiori app is frustrating because you know you can do it the old way. You almost have to accept that things are different now. I get a lot of reports from people saying, for example, “Can you give me a one-to-one transaction list of how many of these are in SAP Fiori?” When I tell my SAP Fiori developers to get going I don't typically say “Can you do KB21 now?” I try to work around the business question and try to get them to understand the business question. You see all sorts of nice things coming out of those conversations. For example, our allocation cycles have Excel (spreadsheet) loads so you can upload data into the sender and receiver tabs that we never had before.
Q: What is the future of investment management in SAP S/4HANA? I cannot find standard SAP Fiori apps to support investment from an IM program to investment measure follow up.
I think there's an SAP Note written by me that says “Investment management is still there and it does what it does.” That’s the short version of it. Basically we haven't yet gotten around to creating SAP Fiori apps there. There was a lot of debate internally about what the role of investment management should be versus EPPM, because investment management was always single system and EPPM was always cross-system and generated WBS elements and so on. As their operative structure, I think there is still a future for IM. Even in the cloud, you'll find a small amount of IM, so you'll find that you can still create projects that generate assets under construction and create all the accounting entries that go with investment management or in the cloud. What's missing is this kind of umbrella structure that sits over the top in the form of the investment program and the investment program items with all those budgeting and planning functions. We talk about it briefly in the book, but they're not in SAP Fiori. They are a bit of a style break in the book.
Q: How do you see the role of SAP consultants changing in the future? Do you expect less configurable SAP HANA versions?
What we're trying to do is we're trying to not force you into things. Asset accounting is a really good example. Asset accounting used to have about 15-20 tables where you did all these different things and we're now saying, “No, it's all related to the ledger and it's all in one place.” The idea is to actually answer business questions rather than all sorts of super techy questions, because that's often been the challenge in the past. We are trying to simplify that, but of course the challenge is not to take away those sort of configuration options where it really was a philosophical question i.e., you could do it this way, you could do it that way, and both approaches had their pros and cons.
When you go to the pure cloud approach, there's almost no configuration. We deliver the settings for your order types and your costing variants and you name it. Every day I hear from customers, “Can you open up the costing variant again? I need to be able to change the settings.” We're trying to hide settings as we want to only allow those things that are supported in the cloud, so it's a completely different way of thinking. Rather than having this Swiss army pen knife where you can do just about anything, you're going to have to embrace change. I think we are going to have to open up some things a lot more than we did, and that takes you back to the role of the CO consultant probably 20 years ago. If you knew the costing variants and how to assign the cost elements in the cost component structures, you could probably travel from customer to customer doing configuration. Now here's me saying “You're still hidden, we're not going to let you touch that.” I think the challenge though is to be the business person that actually talks to people and says, “Look, this is margin analysis. How do you get your contribution margins? These are our standard reports, but would you like something more specific to your organization? Do you need something more specific to you?” There's still going to be that configuration effort, but not configuration at all costs where we pretty much gave you a table and said do what you like with your order types. So now that's a challenge at the moment. We tried to put things like the scope items in my book just so you had a reference point to go and say, okay J54, that's overhead accounting.
Watch Janet's full Q&A here: