Skip to Content
Personal Insights
Author's profile photo Dick Westman

Universal Allocations: How to utilize custom dimensions in allocations


This blog post continues a series of Controlling related topics, which circle around showcasing new functionalities in S/4HANA Cloud, comparing functionalities between SAP S/4HANA Cloud, public edition and SAP S/4HANA Cloud, private edition (and SAP S/4HANA) (at the time of writing the latest SAP S/4HANA release is 2022). I cover also general topics that should be considered from Management reporting/Controlling point of view when implement S/4HANA.

Focus of this blog posting is to give the user an overview of when the different allocation types should be used and the posting can be considered as a “deep dive” to the earlier blog “Fundamentals, Basic Functionalities and Considerations to enable Management Reporting in S/4HANA”.

You might ask yourself, “We have Universal Allocation, we have all allocations in one place; what is the point of this blog posting?” – Yes true, but it is good to understand how the different allocation types are used and with what dimensions. Furthermore, many companies are considering how to improve their reporting model, to get to most out of the Universal Journal, when moving to S/4HANA (or when you are already there). That is a time when it becomes very important to understand how the different fields behave and can be used. Also, when planning to use customer specific fields (“Own dimensions”, that can be easily added e.g. through the “Custom fields and logic” app), it becomes vital to understand how the fields behave in allocations, to ensure you are fulfilling your management reporting requirements. Finance improvements and architectural changes delivered Universal Parallel, should also be understood.


Figure 1: Illustration of the Universal Journal.

Figure 1: Illustration of the Universal Journal.


Universal Parallel Accounting

Universal parallel accounting (“UPA”) is an enabler for better support for Multi-Gaap reporting, management valuation, currency conversions (up to ten currencies per ledger), end-to-end processes, resolving many restrictions of the past, improving steering effectiveness and providing simplified configuration and processes. It is the foundation for additional innovations in the future for finance with SAP. When UPA is activated, Universal Allocation is to be used.

For further information on UPA, please visit following blogs. Blog series on Universal Parallel Accounting with focus on:

Universal parallel accounting is always activated in SAP S/4HANA Cloud, public edition, but in the private edition and on-premise, you can select whether to activate it or not (note that in 2022, it can only be activated in greenfield projects). New innovations will be developed based upon UPA and the general recommendation is to use UPA, however in 2022 version there are certain restrictions that might prevent from activating it (for further details see: 3191636 – Universal Parallel Accounting (SAP S/4HANA 2022): Scope Information ). It also affects how you can do as majority of old data model transactions are not available (as seen in below table 1).  Personally, I see this as a good thing, as then you do not need to give the option to select a less efficient way of working (even though it might need some more change management). The old transactions were also lacking the capability to handle multi-GAAP requirements from Controlling point of view (e.g. some could handle only 2 currencies, compared to Universal allocation 10 currencies).


Table 1. Comparison of allocation types that can be used (SAP S/4HANA, SAP S/4HANA Cloud, Private/public edition).


Different type of allocations & Custom defined fields

How Universal Allocation works in S/4HANA has been presented quite well in earlier blog postings (see e.g. Universal Allocation in SAP S/4HANA 2021 | SAP Blogs By Daigo Imai or  Allocations & Universal Allocation | SAP Blogs By Dick Westman (me)). Table 2, below, provides an overview of what dimensions can be used as senders and receivers. The sender and receiver fields can be used to influence what amounts are being allocated. In addition to the receiver fields, that can be used to split the amounts, there are “inherited fields” that are being passed along and populated on the receiver side posting, e.g. company code or partner profit center etc..


Table 2. Overview of allocation types in Universal Allocation.

There are a few ways to extend the Universal Journal with additional fields, to fulfil your specific reporting requirements and depending on requirements you might opt for coding block extension or Market segments (Margin analysis). Figure 3 gives you also an overview and for the full details see this note:   2453614 – FAQ: Universal Journal Extensibility.

A simple example of Margin Analysis fields, related to Profit and loss accounts (PnL) is from a sales process. Here you would typically first have a sales order, then a delivery with a Post Goods Issue (which creates financial accounting document, in which COGS will be a PnL account with profitability dimensions), and finally Billing document, that also creates a financial accounting document. The revenue account (account 41000000 in figure 2 below) would be PnL account, for which there will be derived the Profitability dimensions in the accounting document. The profitability segment dimensions can be SAP pre-delivered or your own created Margin analysis (Market Segment) dimensions.

Figure 2. Example of Financial Accounting document from Billing, showing the Profitability segments derived for the revenue PnL account.

In some industries there are requirements for additional dimensions also on balance sheet accounts, e.g. in postings on inventory accounts from goods movements. Alternatively, postings coming from an interface, which generate accounting postings to other balance sheet accounts. In those cases, coding block extensions could be used to enable a posting on balance sheet accounts for these additional dimensions.



Figure 3. Overview of Universal Journal Extension options.

From an allocation point of view, it is important to understand how the different fields behave.

For margin analysis fields, you can allocate separate amounts, as those can be defined in the allocations as receivers, when using allocation type “Margin Analysis” (Overhead allocation, distribution or Top-down distribution).  For “coding block” and “Journal Entry Item business context”, the same is not possible with Universal Allocation in S/4HANA 2022. To take this type of fields (“coding block” and “Journal Entry Item business context”) into account, you can enable silent inheritance. This means that the values are passed over in the allocation (meaning they are not separate receiver fields, for which you can allocate specific amounts, but rather are “inherited” from senders to receivers). Following two notes describe the solution in more details: 3216317 – Universal Allocation – Enable Custom fields for silent inheritance from sender to receiver  and 3105083 – Universal Allocation: issues with custom fields . “Coding block” fields can be set as receivers with the old General ledger allocations (FAGLGA31 etc.), but this is not available in SAP S/4HANA Cloud, public cloud edition. Alternatively, they can be allocated with e.g. SAP Profitability and Performance management.

Before extending your system with custom fields, it is always recommended to investigate the use of SAP standard fields, which can be influenced by how you configure your system. There are also many cost objects  (WBS, Production Orders, Plant Maintenance Orders…) that you might settle at period end (for which you can also derive an attributed profitability segment during the period for reporting), which will influence your allocations. The fields can also vary depending on what solutions you are using (e.g. are you using Joint-Venture accounting, Public sector management or RE-FX to name a few). For public sector you should also see the scope (3228518 – SAP S/4HANA 2022, Public Sector Management:).


This blog post was highlighting the change with UPA, with respect to allocations showing that most of the old transactions are not available at all anymore, which is logical as universal allocation provides a lot more functionality compared to the old ones. The blog presented what to consider when there are requirements for custom fields in the context of allocations in S/4HANA. And while you might require running allocations at period end, I believe, the aim should always be to derive to correct account assignment at the time of posting, so there is no need for an allocation at all at period end.

  • What are your experiences with custom fields and allocations? Does the above provide any clarity? Please share and let me know in the comments below.











Assigned Tags

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

      Great blog Dick! Particularly I found interesting the functionality of silent inheritance to be used with coding block and journal entry item business context fields.

      As a follow-up topic, would be interesting to hear your thoughts on the usage of different use cases for different types for field extensions. E.g. are there scenarios where it would be preferrable to use the "Journal Entry Item" business context instead of "Market Segment" business context. The linked note 2453614 - FAQ: Universal journal extensibility has a lot of information on this topic of course as well already.

      Btw, I noticed that at least for me the support launchpad links are directing to but the links don't land to the note itself, just the landing page.

      Author's profile photo Dick Westman
      Dick Westman
      Blog Post Author

      Thank you Erno!

      Regarding your question about Journal Entry Item vs. Market segment, there is no one answer fits all to it, but it  depends quite a lot on what are the requirements for the field(s) and the specific customer case. Something to consider: What are the "trigger" for  the postings and what are requirements for follow-up processing. E.g. Do you need functionality from margin analysis for the fields (e.g. top-down distributions, realignments), or only reporting. Where do the postings come from ? (e.g. Only from inbound interfaces, that and can easily be filled by sending system, or through multiple different integrated postings, which require logic to derive the value). Also what is the effort required for updating them in the future. Before implementing, one or the other it is good to make an analysis which one to select.  You can also see here some examples: Use Cases for Custom Fields in Finance SAP Help Portal

      Author's profile photo Erno Nykanen
      Erno Nykanen

      Yes, I was thinking of the use cases specifically for "reporting only" type of fields.

      E.g. if we want to be able to display a product master attribute (e.g. product group) whenever the product dimension is used in the P/L posting, we could either

      1. report based on the product attribute (but then it's not possible to report on the attribute alone without the main dimenions if one would want to group all products within the product group on the report)
      2. Add a custom market segment
      3. Add a custom Journal Entry Item dimension

      If we then want to allocate costs via cost center overhead allocation to the market segment "product" and want to see the same allocation reflected also on the "product group", are there any differences in using the market segment or Journal Entry Item dimensions? In both cases the value should be derived from the product. When thinking this through, ideally I would like to have the product group purely as an attribute (not stored in the ACDOCA) but the only issue is that then it's not available as a standalone dimension in the Fiori reports.


      Author's profile photo Dick Westman
      Dick Westman
      Blog Post Author

      Yes, you are correct.

      Regarding  market segment or Journal Entry Item dimensions: from an allocation point of view, if you e.g. top-down distribution, then you need to have the field as market segment (or realignment ). Regarding the product group, it is quite common to have some postings (e.g. sometimes freight or insurance) to be posted on a product group level, and then you want to allocate it to a product level. This is not possible if it just an attribute. The derivation in many cases is easier, when you can you the Margin analysis configuration. Also not to forget if manual entries are needed or not.

      But yes, it depends always what is the specific need.