The most important aspects about the new dimension called ‘budget category’ required for active budget control will be covered in this blog post. I would like to give answers to the following questions that might arise:
Why was the budget category introduced?
Where is it defined and maintained?
In which master data can it be assigned?
How is the budget category populated in the purchase order (PO) or supplier invoice?
How are the actual postings (journal entry lines being populated)?
What are the rules and strategies for budget category derivation?
Question: Why has the budget category been introduced?
There are 2 main answers.
The granularity of a G/L Account is in 90% of the real-world situation too granular to conduct a budget check. Example: Travel cost on a cost center might be planned on a single ‘placeholder’ G/L Account. The actuals in the journal entry might be at a granularity like (hotel, taxi, train, flight, parking, rental car). I hope you all get the point. But why couldn’t reporting structures or top of G/L Accounts be used as an aggregation level at which budget checks are conducted?
The budget check is implemented to verify against: released budget YTP – (actuals + forecast incl. encumbrances). Forecast collects information where multiple ‘anticipated’ future actuals are accounted for that will consume budget and therefore reduce the available budget. One of those forecasts is the already implemented PO encumbrance capability in SAP Business ByDesign. But we wanted to design a solution architecture where for example partners could introduce other forecasts that allocate budget way before the actual posting really occur. This could be a travel request or a travel plan way before it is reimbursed or even approved. But the ‘further you are away’ from the actual posting the less likely it is to have all the granular data available to do a proper account determination. So, it is easier to simply pass the ‘budget category’ information directly. For this future extensibility the design decision was taken to introduce the budget category.
Question: Where is the budget category defined and maintained?
The budget category is defined in the configuration fine-tuning activities for budget queries.
P&L account assignment
Thus, you create a G/L Account group that is defined chart of account independently and flag it as budget relevant. By setting this flag it automatically will be treated as a budget category. Customers can create additional budget categories. (These have to start with a “Z .... as an ID”). In the lower section of the UI you have to assign the necessary G/L accounts that are relevant in the overhead cost area to the budget category. In case scoping has budget check activated these assignments will be used to derive the budget category in the respective journal entry lines in case the original transaction does not pass the budget category. Note: if you create a new P&L account this should also be a fine-tuning activity in future to also do a proper assignment
Definition of Budget Category and P/L Account Assignment
Question: In which master data can the budget category be assigned?
First, I will start with some background information.
In some industries (e.g. public sector) a traceability of budget relevant data is subject to regulatory requirements. As the budget check will be conducted at a granularity cost center / budget category / fiscal period and the actual data in the journal entry the budget category is part of the overhead subledger data structure. This allows to ensure the required traceability at any given time. So we decided to persist the budget category in the journal entry lines for the relevant subledger.
Now the challenge arises how to deriveautomatically the budget category efficiently without prompting the business user for this additional information in all transactions. The solution is that in multiple places derivation strategies have been put into place.
Product category definition
During purchase order creation or supplier invoicing it is possible to create items without using materials or services and just using the product category. In this case the product category is used to derive the assigned budget category. I also would recommend to properly assign the budget category to all relevant product categories because it will be used as a lookup if the budget category is not maintained on material or service level. A manual budget category assignment on purchase item level is not possible to assure that no misuse by switching budget categories can happen.
Product Categories with Budget Category Assignment
Material master data
If a material is procured and the purchase order has a cost center, direct cost or cost collector project (overhead) account assignment the budget category will be defaulted by the derivation of the material master. As a preparation activity all materials that are not stocked should be enhanced by a budget category assignment as illustrated in the next picture. If there is no budget category assigned on material level the budget category is derived form the related product category.
Material Master - Valuation View : Budget Category Assignment
Service master data
The same applies in case services are procured. Therefore, the service master data has been enhanced in the valuation view to assign the respective budget category.
Service Master - Valuation View : Budget Category Assignment
Question: How is the budget category populated in the purchase order or supplier invoice?
In case active budget control is switched on, additional fields are made available in the purchase order and supplier invoice. These can be added to the UIs using personalization.
There is a budget category derivation sequence now taking place:
Derivation from preceding document (Example: supplier invoice or credit memo with preceding purchase order)
Product master data
- material master
- service master
Error !!! By purpose it is not allowed to enter manually a budget category during purchase order or invoice creation. Otherwise, the purpose of budget check cannot be ensured.
Question: How is the budget category derived in the journal entry?
Since the budget check for cost centers and overhead cost projects is conducted at a budget category level considering ‘Released Budget YTP – (Actuals + Forecast)’ also the actual postings must have a notion of budget category in the respective overhead cost lines in the journal entry. For auditing reasons in public sector, the design decision was made to really assure that the budget category is stored in the journal entry lines affecting the overhead cost ledger. Also, for non-public sector customers the budget category is to be correctly populated to execute a proper budget check.
A derivation strategy during journal entry creation has been put into place as well:
Population by the preceding business document
- Goods receipt with reference to purchase order.
- Supplier invoice
- Supplier credit memo
- Goods return with reference to purchase order
Derivation from product master
- Material master data
- Service product master data
Derivation from product category
BADI implementation (all partner extensibility topics are subject to a dedicated blog post. (Active Budget Control in SAP Business ByDesign - Scenario Extensibility)
Derivation from G/L Account using the budget category definition and G/L Account assignment maintained there
In addition, the journal entry voucher as well as the recurring journal entry voucher are extended to enter the budget category by the accountant. This allows corrections or assigning a budget category for postings that initially did not carry the budget category.
Note Limitation: The Excel Plugin to enter Journal Entry Voucher has not been extended
I explained that the budget check is conducted at budget category level. Therefore, in financial planning, budget release, purchase order and supplier invoice creation the budget category will be derived as well as in the journal entry creation process. I have illustrated where in the master data and budget category definition relations are established to automatically derive the budget category if needed.