Back to Basics: Primary Cost Elements 101
The accountants are talking about General Ledger accounts. The department managers are talking about cost elements.
What’s the difference?
As a follow up to Back to Basics: FI and CO 101 discussing the difference between FI and CO, a primary cost element is a master record in the CO module; it represents a P&L account (from FI), and is used in controlling processes (in CO). A primary cost element uses the same account number as its G/L counterpart.
When a posting is made to a P&L account, the system checks to see if a primary cost element exists. If so, it requires that a controlling object is entered. These controlling objects – including cost centers, projects, internal orders and production orders, to name a few – provide the capability of tracking the costs associated with these P&L accounts on a more detailed basis.
To illustrate this logic, the diagram below shows that if a posting is made to account 123, it has a corresponding cost element; therefore, the system requires a controlling object to be referenced, in this case project (WBS element) XYZ. If, instead, the posting is made to account 456, there is no primary cost element, and no controlling object is entered. Examples of P&L accounts for which cost elements are commonly created include resources that are used during manufacturing, such as salary expenses, material consumption accounts, and expense accounts for overhead costs such as utilities. Examples of P&L accounts that are not created as cost elements include the work in process offset account and manufacturing variance accounts that will be written off. (Note that the strategy of not creating variance accounts as cost elements may be different if you have implemented CO-PA, or profitabililty analysis – a topic for another time.)
You may want to limit which accounts/primary cost elements can post to particular controlling objects. The G/L account contains the field status group; the field status group determines which fields are open for entry. For P&L accounts with corresponding cost elements, you can define, by account, which controlling objects are available for posting. For example, some accounts used for product costing may only allow postings to (production) orders, while other accounts may allow postings to cost centers and to orders – and to projects.
For many financial entries, the controlling objects are entered manually during the creation of a journal entry. In logistics processes, such as production/product costing, the controlling object – such as a production order – is defaulted directly from the manufacturing processes. In this case, multiple documents are created:
- An inventory document to capture the material quantity posting.
- A financial journal entry to the inventory account on the balance sheet, and the material consumption account on the P&L.
- A CO document, which references the production order.
As a final point, when reporting on controlling processes, the source document is the CO document.
Or since it's close to year-end for many of us, a review of typical year-end processes.
Many thanks,
Tammy
I like your ideas.....to keep with the cost element theme, I'll do the statistical cost elements right after the secondard cost elements.
Good suggestion on year-end as well, that will probably be multi-part 🙂
Best,
*Birgit
Thank you for your very informative article. Could you kindly explain one more thing:
Why do cost objects need to be associated with a primary cost element ? In other words, if I take your example, why can't project XYZ be directly associated to cost element 123, without having a cost element in between ?
The system could simply check if a cost object is associated to a GL and if so ensure the costs are transferred to this cost object (in other words, it could work without a cost element).
I couldn't find any explanation elsewhere so I was hoping you could maybe help me understand this.
Thanks and regards,
Michael.
Why can't project XYZ be directly associated to GL 123, without having a cost element in between ?
Thanks and regards,
Michael
Thanks for your question.
The intention of using cost elements is to reduce the number of G/L accounts that are required. Typically, the G/L accounts are used for external reporting; the intetion of using cost elements is to ensure that there is no proliferation of G/L accounts to handle internal, management reporting. I posted an overview of FI/CO that explains this in more detail - essentially, using the FI/CO concepts, there is no longer a need to create one G/L account for each controlling object:
Back to Basics: FI and CO 101
In terms of associating one project with one account, you get increased flexibility if you use cost elements the way they are designed.
I would ask the following questions:
- Do you truly mean that one G/L account would only be used for one controlling object? Is one type of expense really only relevant for one cost center or project? I have rarely come across a business situation in which that was the case (but, I realize, you never know).
- Using a project as an example, there are many layers in the set-up of a project. Costs are rarely assigned to one project bucket; instead, costs are usually tracked at a lower level of detail, such as project phases. These sub-divisions of a project are represented by different WBS (work breakdown structure) elements, or even tasks at a lower level, which all roll up to one project. Each of these sub-levels is its own controllig object. For the same cost element, you would not want to create a G/L account for each WBS element or task. Instead, using a cost element, you can still differntiate your postings and assign costs to different WBS elements or project tasks (in a network), without having to create potentially dozens or hundreds of new G/L accounts.
If you truly want to associate one controlling object with one account, you can create "substitutions" in accounting documents to ensure that default takes place.
I hope that helps.
Best,
*Birgit
Thanks for your answer. Your article is very good.
What I meant was: why couldn't we imagine that the various CO objects are associated directly to the GL account ? For example, for GL 123, we could have project abc, cost center xyz and wbs kkk directly connected to the is GL (instead of GL 123 being linked to a cost element 123, which in turn is linked to all these cost objects). I know SAP doesn't work like this, but I'm wondering why SAP had to introduce the notion of cost element. After all, why not have the cost objects tied directly to a GL, without having a cost element in between ?
Is it because it makes things easier if the chart of accounts has to change (if a GL changes, you just need to link it to the cost element - in other words, you don't need to re-create all the links to the various cost objects) ?
Thanks and regards,
Michael.
I'm glad you enjoyed the article!
The reason the cost element was introduced is to minimize the chart of account maintenance. To do the linking you describe, it either means creating additioanl G/L accounts - which makes postings more cumbersome, especially for allocations - or having to go through a maintenance/table mapping step each time a new account or a new controlling object is created. If you have 100 cost centers or projects, and 100 accounts, that translates to a lot of mapping each time you create either an account or a controlling object. The cost element allows that mapping to happen dynamically in a transaction.
Actually, when you create a G/L account, you can automatically create the corresponding cost element, so that makes it even easier!
Best regards,
*Birgit
Thanks again for your answer.
I'm still wondering about something. I understand that a lot of mapping will be needed, however don't we have to do this mapping anyway at the cost element level (because you have to map each cost element to different cost objects) ? Indeed, the GL account would be mapped only to one cost element. However the cost element could be mapped to many cost objects (and hence we would still have a lot of mapping to do). So what makes cost elements really useful ?
Thanks and regards,
Michael.
Cost elements are useful in that they indicate that a posting for costing is necessary. To address your question about mapping - mapping cost elements to controlling objects is actually not done in configuration, there is no table that links the two. Instead, the link between cost elements and controlling objects is made dynamically in the transaction, when the journal entry is posted. If a cost element exists, the accountant is required to enter a controlling object, and this establishes the link.
The other benefit is that the use of cost elements results in fewer G/L accounts, since the controlling objects are split out in a different field/master record. The cost element is simply the mechanism that allows the controlling objects to receive a posting.
Make sense?
Best regards,
*Birgit
Thank you very much for your answer. I hope you don't mind me asking all these questions.
I have another question related to your article. Why do you make reference to posting to a P&L account ? Does this mean that cost elements do not apply to Balance Sheet accounts ? If so, can you kindly explain why ?
BR and wish you all the best for 2011 !
Michael.
Happy 2011 to you, as well!
I just returned from vacation, I apologize for my delay in responding.
The primary cost elements are related to P&L accounts, not balance sheet accounts.
Your question comes at an excellent time, I am planning on posting another blog within the next week on the topic of statistical cost elements, which should help clarify how that works, so I will defer to that blog. As always, questions are welcome!
Best regards,
*Birgit
nice to see you are picking up the topic.
ad rem, it's good to think in terms of coding your journal entry. this is probably one of the few instances where accountants are better coders than programmers. whenever an economic event is recorded, any bookkeeper worth their salt would know how to account for it for all the parties concerned, ie management (CO), auditors (FI), tax authorities (DART), his or her own boss (workflow/email?), and whomever would wish to ask for an explanation. if the journal is coded properly, there won't be any follow up questions, but there could always be reclasses if one's wants to keep them really happy 😉
And glad to see you weighing in!
I agree with you - plus, correctly coded journal entries mean less error correction and better information for follow-on processes, such as intercompany eliminations and financial statement generation!
Best,
*Birgit
Hi Brigit,
Thank you for the valuable information and detailed answers which are the extra bonus tips to learn.
Kind regards,
Raj
Hi Brigit,
I could not find your topic on "statistical cost elements " which you have mentioned in this blog is that you are going to post it. I really find your post are very valuable and easy to understand. You explain the subject logically to understand.
Kind regards,
Raj
Hi Brigit,
I know this blog is from several years ago, but we're seeing a new visibility pain point. Essentially, we're looking for visibility into the primary cost element line items that make up a secondary cost element allocations. We'd like to see the dollars that debit our machine cost centers, but at the primary debit / cost element level. We seem to lose that visibility once those dollars ride a secondary cost element / allocation.
Thank you!
Hi Brock,
Unfortunately, the overhead allocations in this case are not handled like cost center distributions. The best way to get that visibility is to create a secondary cost element for each primary cost element. I know that's a lot of cost elements, but at least then you could see the information you are looking for.
Best, *Birgit