Accruals Management - Purchase Order Accruals

As soon as there are liabilities to a third party, for example to a supplier, but the related costs have not yet been posted, accruals need to be posted. By posting accruals in the system, the relevant costs are allocated to the fiscal period in which they occurred. The posting of accruals is typically a period-end closing activity because the accrual amounts are usually known only at the end of a period.

Use Cases

Use-Cases for Purchase Order Accruals:

Purchasing of consumable material or service – without goods receipts

• There is no recording of the goods receipts in the system. In this case the accruals are proposed:

  1. Either based on the delivery schedule given in the purchase order item: All planned deliveries with a delivery date in the past are assumed as received.

  2. Or using a straight-line approach, that is, a linearization of the total value of the PO item between start and end date.

Purchasing of consumable material or service – with non-valuated goods receipts

The quantity of the received material or service was recorded in the system using non- valuated goods receipts: Non-valuated means that no costs were posted by the goods receipt entry.

Purchasing of consumable material – with valuated goods receipt postings

The valuated goods receipt (GR) entry posts the costs as entered quantity multiplied by net price of PO item. In this case accruals are only needed if the GR has not been posted despite the material was already received.

That’s why the system proposes the accruals based on the delivery schedule given in the purchase order item: All planned deliveries with a delivery date in the past are assumed as received. The costs posted by the GRs are considered of course in the proposed accruals.

Purchasing of service – with service entry sheet postings

A service entry sheet posts the costs like a valuated goods receipt. Usually there is no delivery schedule available in the PO item.

In this case the accruals are proposed based on a straight-line approach. The total value of the PO item is distributed linearly between start- and end date of the PO item.

Note

The fields start- and end date are visible in the PO screens if the PO item uses the Lean Servicesapproach. Product Type Group is 2 — Service.

Accruals are posted for costs that are expected to occur in future fiscal periods or years.

As a consequence accruals are only relevant for purchases where costs will occur:

• Accruals are usually not relevant for the purchasing of products that are put on stock, for example raw material that will later be used for producing other products.

• Products that represent a fixed asset, for example a laptop. Their value is posted to a balance sheet account. The costs will occur later during depreciation postings.

Process Flow

The process is as follows:

Transfer

When a purchase order (item) is created in MM, the system determines whether accruals are potentially relevant for it. If yes, then the system transfers and creates an accrual (sub)object for the purchase order (item) in the Accrual Engine. This transfer and creation of accrual objects for a purchase order can be done either:

• Offline, after the purchase order was created. Existing purchase orders are transferred into the Accrual Engine using customizing transactionPOAC_MM2ACE_TRANSFER or using job template Accrual Engine for POs — Transfer Purchase Orders to Accrual Engine in the SAP Fiori app Schedule Accruals Jobs.

• Online, when the purchase order is being created in materials management.

Calculate

According to IFRS accruals may be posted if there is a potential debt to some 'external' legal entity (e.g. to a supplier). The logic/algorithm how this debt and the related accrual amount has to be determined is specific for each use-case.

The Accrual Engine especially supports the following procedure:

The system calculates two amounts: Planned costs and actual costs in the following sense:

• The amount that has been 'received' already. For example the amount of service that was received or goods delivered by a supplier for a purchase order item up to a certain key date. The application Purchase Order Accruals uses by default the delivery schedule of the purchase order item to calculate this amount. In other words, the system assumes that the deliveries were indeed received on the dates as planned in the delivery schedule. These amounts are stored in the Accrual Engine in an accrual item type that is referred to as Planned Costs.

• Independently of the planned costs, the system calculates the actual costs that have already been posted. For example in case of non-valuated goods receipts, the actual costs are posted by the supplier invoice. So the system selects all invoices that have a posting date before the key date. These amounts are stored in the Accrual Engine in an accrual item type that is referred to as Actual Costs.

• The system calculates the accrual amount as plan minus actual: The difference between planned and actual costs represents the debt to the supplier - of course only if this difference (plan minus actual) is greater than zero: The system calculates this difference and stores it in an accrual item type that is referred to as Accruals (ACCRL).

For each purchase order, you can display the monthly accrual amounts the system calculates using transaction Display Accrual Objects (POACTREE03) or the Fiori app Display Purchase Order Accruals.

Review / Approve

At the end of each fiscal period, a reviewer can adjust the accrual amounts (or planned costs) that the system proposes for the current fiscal period. As a prerequisite, the proposal amounts must be generated for the given fiscal period using transaction ACEPROPOSALRUN or using the job templateAccrual Engine for POs - Propose Period Amounts. This action also generates work items in the Fiori app My Inbox for the purchase order owner, when you use workflow in the review step. The review can be performed as follows:

• For the purchase order owner: Work item in the Fiori app My Inbox or transaction Review Purchase Order Accruals — Purchase Order Owners (FACRARVWBU).

• (Optional): For the controller: The Fiori app Review Purchase Order Accruals – for Cost Accountantor transaction "Review Periodic Accruals — Controllers" (FACRARVWCO).

Machine Learning supports the review of periodic accrual amounts at the end of the fiscal periods. The machine provides for each purchase order item the info whether the proposed accrual amount is reliable, i.e. the info whether the reviewer can accept the proposed accrual amount without need to adjust it. ​

In addition to the review, an approval can be performed using transaction "Approve Periodic Accruals — G/L Accountants" (FACRAAPPRVGL).

Post

Finally the accruals will be posted at the end of each fiscal period: The accrual amounts can be posted using job template Accrual Engine for POs – Periodic Posting Run in the SAP Fiori app Schedule Accruals Jobs or with the transaction "Periodic Posting Run" (ACEPOSTINGRUN).

Display Accrual Objects — Transaction POACTREE03

In the applicationPurchase Order Accruals, an accrual object represents a purchase order. An accrual subobject represents a purchase order item that is subdivided based on the account assignments given in the purchase order.

Basic Settings — Accrual Item Types:

• Please be aware of the following important general principle of the Accrual Engine: For each amount to be calculated by the Accrual Engine you have to create a separate accrual item type in Customizing.

• Regarding purchase order accruals the purpose of the Accrual Engine is to calculate an amount that will be posted as accruals (at the end of each fiscal period). To achieve this, you must create at least one accrual item type in Customizing. SAP delivers accrual item type ACCRL for this purpose.

• Theoretically, it would be sufficient to have only one accrual item type. You could assign a suitable algorithm to the corresponding accrual items that calculates the accrual amounts. However, if you'd only use one accrual item type (representing the relevant algorithm), you wouldn't able to see how the amounts are calculated (which values are used, for example).

• To make the calculation of accrual amounts more transparent, the Customizing process for purchase order accruals provides a three-step approach. Instead of using one single accrual item type only, you can define three accrual item types: One for the planned costs (PLNCST), a second one for the actual costs (ACTCST) and a third one for the accruals (ACCRL). In this approach, the accruals are calculated by subtracting the actual costs from the planned costs.

Before the review or approval can be performed at end of the fiscal period, the proposal accrual amounts have to be generated. This is done using transaction ACEPROPOSALRUN or job template Accrual Engine for POs — Propose Period Amounts in the Fiori app Schedule Accruals Jobs. This task is typically executed after the last invoice and goods receipt was posted for the fiscal period.

Review and approval of periodic accrual amounts are implemented in the following way in the Accrual Engine:

• Review is always an optional activity. If nobody performs the review of the proposed accrual amounts for the given purchase order item, the system will post the proposed accrual amount.

• Approval means that the system will post the proposed accrual amount for the purchase order item only if the approver has granted his approval.

Both steps, review and approval of the periodic accrual amounts can be active at the same time. This way a 4-eye principle (dual control) system can be established. For example the purchase order owner performs the review of the accrual amounts and afterwards a G/L accountant performs the approval.

In both steps, review as well as approval, the reviewer/approver can adjust the proposed accrual amounts or planned costs.

For the review and approval of the periodic accrual amounts that the Accrual Engine proposes, the following user roles are supported:

• Purchase Order Owner: This person is supposed knows the purchase order in detail. Typically this is a project lead or cost center responsible. In general the purchase order owner is supposed to be the preferred person to judge the progress and accruals of the purchase order. The system supports several ways to identify the purchase order owner: It can be the goods recipient of the PO item, the PO requestor ('requisitioner') or the creator of PO.

• Controller: Since posting of accruals means posting of costs, the accruals affect the budget of cost centers etc. That's why it can be reasonable to involve Controllers in the review/approval process for periodic accruals.

• G/L Accountant: The G/L accountant usually is interested in the accrual amounts because they affect the gain/loss in the P&L statement.

Purchase Order Accruals Posting

In the SAP S/4HANA Accrual Engine, transaction ACEPOSTINGRUN or the job template Accruals Engine for POs — Periodic Posting Run in the Fiori app Schedule Accruals Jobs can be used for posting the accrual amounts at period end.

All postings that were done by the SAP S/4HANA Accrual Engine can be reversed using the reversal transactions FB08 (reverse a journal entry) and F.80 (mass reversal of journal entries). The postings can be identified by Reference Procedure = ACES4.

Reversing a whole journal entry using transaction FB08 or F.80 is sometimes not desired, because one journal entry can contain accrual postings from several accrual objects.

If you want to reverse the accrual posting of only a single accrual object, you can do this using the display transaction for the accrual object for Purchase Order Accruals (POACTREE03). In the Postings tab there is an icon for performing the reversal.

The customizing settings for purchase order accruals consist of two main parts:

• Customizing settings for the Accrual Engine: Since the application purchase order accruals is based on the Accrual Engine, these settings are prerequisite for the customizing settings of purchase order accruals. Not all available customizing settings are relevant if you want to use the Accrual Engine only for purchase order accruals.
• Customizing settings that are specific for the application purchase order accruals.

Both steps are contained in transaction "Accruals Management - IMG" (ACEIMG).

Purchase Order Accruals — Accrual Item Types

If you use the following three-step approach (which is the recommended standard procedure for purchase order accruals) you have to define the following accrual item types in order to ensure that the Accrual Engine calculates the accrual amounts for each period using the correct algorithm:

• One accrual item type calculating the planned costs of the purchase order item (based on account assignment) for each period. The planned costs are calculated based on the delivery schedule, for example. When dealing with services, you can also apply an even distribution of the PO item's net amount over a specific period of time (linear approach).

• One accrual item type calculating the actual costs of the purchase order item (based on account assignment) for each period. Actual costs are either:

  • The goods receipt postings - if valuated goods receipts are used for this PO item, or.

  • The supplier invoice postings - if no or non-valuated goods receipts.

• One accrual item type for the accruals: This accrual item type has to be configured to be the result of planned minus actual costs (but always remaining a positive amount). This means that if the actual amount is greater than the planned amount, the system will set the difference amount to zero.

Accrual Item Types

SAP delivers the following three predefined accrual item types:

• PLNCST for planned costs

• ACTCST for actual costs

• ACCRL for accruals

In the Define Accrual Item Types activity you define the relationship between these three accrual item types in order to let the Accrual Engine know that the periodic amounts for ACCRL are calculated based on the other two accrual item types by subtracting ACTCST from PLNCST (but keeping only positive amounts).

In the IMG activity Define Accrual Item Types in sectionItem Type Settings for Ldrgrp incl. Repr. Ledger an entry must exist for each of the three item types:

• PLNCST Planned Costs

• ACTCST Actual Costs (the posted invoices / goods receipts)

• ACCRL Accruals which are the result of planned costs minus actual costs

These three accrual item types must have the same setting for:

• Ledger Group

• Frequency and

• Handling of Currency

The Posting Frequency defines how often Accrual Engine postings are made. Monthly, for example, means that accrual postings are made on the last day of each month.

The Reversal Posting Type determines the transfer of reversal postings as negative or inverse posting from the accrual engine to financial accounting.

Currency Handling

Since the accrual object is created by transferring the purchase order into the Accrual Engine, the only available currency is the purchase order currency - which is regarded as transaction currency:

• It automatically assigns the currency type 00 (transaction currency) to the Accrual Engine.

• The system automatically assigns the representative ledger of the ledger group to the accrual item type.

• You need to define the Currency Handling for currency type 00. For purchase order accruals it is mandatory that you define the currency handling as A - By Accrual Engine. This setting means that the Accrual Engine will calculate the accrual amounts in this currency type.

The Accrual Methods provides the logic how the periodic amounts are calculated by the Accruals Management.

The Accruals Management offers an additional Review and Approval process which can be activated here.

SAP delivers several accrual methods as default customizing content. Some of these accrual methods can be used for calculating planned costs. These methods are important because they represent the different possibilities how the planned costs of a purchase order item can be distributed over its lifetime.

This distribution then determines the accrual amounts in the different fiscal periods. Some other accrual methods like ZERO_AMNT, DERIVED, PLN-ACT are needed for technical reasons.

For example if an accrual item becomes obsolete, for example because the purchase order item is deleted, the Accrual Engine automatically assigns the method ZERO_AMNT to it in order to achieve that in the next accrual posting run, the accrual amount will be set to zero.

When a purchase order (item) is created, for example, using the SAP Fiori Manage Purchase Orders app, the system determines whether accruals are potentially relevant for it. This is done by evaluating the settings of the Purchase Order Transfer Variant in the configuration.

In Customizing activity Define Accrual Item Types and Methods for MM Purchase Order Items, you define -beyond others - which purchase order items shall be accrued. In section Define accrual item type and method based on PO item, you create entries for combinations of Purchasing Document Type and Purchasing Document Item Category.

These entries define for which purchase order items accruals are relevant at all. For a purchase order item, the system will create an accrual subobject only if there is an entry in this Customizing table. If no entry exists in this table for the document type and item category, then no accrual subobject will be created.

For some purchase order items, no accrual objects shall be created:

• Purchase orders that represent a purchasing to stock do not need to be accrued, since no costs are associated to such purchase order items.

• Purchasing of fixed assets: No accruals are needed for such purchase order items.

• Purchase orders that represent an inter-company stock transfer. They are not related to an external supplier, so no accruals are needed.

After a purchase order item has been selected, in the second step the system classifies each purchase order item with respect to accruals. This accrual classification will determine which accrual method the system will use to calculate the accruals for the individual periods.

Accrual item types and accrual methods will be determined by the accrual classification and the purchase order type and purchase order item category.

By default, the system supports two accrual classifications of purchase order items:

• SDELS: Lifetime dates from delivery schedule

• SPERP: Lifetime dates from performance period

These values are predefined in the SAP standard delivery and cannot be changed by the customer.

The classification value SPERP is used by the system if the purchase order item represents a Lean Service or an enhanced limit (Item Category "E" in transaction ME23N, for example). In this case, the Product Type Group of the purchase order item has the value 2.

As a consequence the user can enter in the purchase order item a start and end date. These dates define the period of time in which the service is planned to be received from the supplier.

If a purchase order item was classified as SPERP, the system will - in case the default customizing is used - calculate the planned costs by performing a linearization of the total amount of the purchase order item between start and end date.

The classification value SDELS is the default value that the system uses as classification for a purchase order item.

If purchase orders are relevant, the system creates an accrual (sub)object for the purchase order (item) in the Accrual Engine. This creation of accrual objects for a purchase order can be done either offline or online:

• Offline, after the purchase order was created. Existing purchase orders are transferred into the Accrual Engine using the job template Accrual Engine for POs - Transfer Purchase Orders to Accrual Engine in the appSchedule Accruals Jobs . Alternatively you can use transaction POAC_MM2ACE_TRANSFER.

• Online, when the purchase order is being created.

You determine the online/offline update as setting for the PO Transfer Variant in customizing under: Financial Accounting→General Ledger Accounting→Business Transactions→Accruals Management→Applications of the Accrual Engine→Purchase Order Accruals→Transfer of Purchase Orders from MM to the Accrual Engine→Define Accrual Item Types and Methods for MM Purchase Order Items.

Assign the PO transfer variant to your company code, in Customizing under :Financial Accounting→General Ledger Accounting→Business Transactions→Accruals Management→Applications of the Accrual Engine→Purchase Order Accruals→Transfer of Purchase Orders from MM to the Accrual Engine→Define Accrual Item Types and Methods for MM Purchase Order Items→Assign company code to transfer variant.

Review and/or approval of periodic accrual amounts is activated in customizing of the accruals management (Accrual Engine) on the level of company code, accrual item type and ledger group.

The review can be activated only for currency type 00 which means that the reviewer and approver can adjust the proposed accrual amounts in transaction currency. All other currencies are read-only during the review.

The corresponding IMG activity is Define Accrual Item Types -> Item Type Settings for Ldrgrp incl. Repr. Ledger, see transaction ACEIMG:

• The checkbox Review Active activates the review process.

• The checkbox Approval Required activates the approval process.

In SAP Fiori a workflow is available for reviewing the periodical accrual amounts. The corresponding workitems appear in the app My Inbox. SAP delivers the workflow scenario ID WD78500077, which can be activated in transaction SM30 using the view V_SWF_FLEX_SCACT.

The receiver of the workitems, start conditions and step sequences will be managed by the SAP Fiori App Manage Workflows for PO Accruals Review.

It is possible to restrict the time period in which the review and/or approval can be performed.

You can define corresponding time interval variants and:

• Either enter them in the IMG activity Define Accrual Item Types -> Item Type Settings for Ldrgrp incl. Repr. Ledger

• Or mark the variant as default

The time interval variants for review/approval are created and maintained in the IMG activity Define Time Interval Variants:

• In the section Time Intervals for Review and/or Approvalyou can define the start and end dates and times when the review and approval are allowed. This activity is a current setting: You can perform it in the productive system.

• You define the start and end dates and times for each fiscal period separately.

• Since the Accrual Engine supports not only fiscal periods but also additional frequencies, the fiscal period is identified by the Last day of the fiscal period.

You can activate review and/or approval process only for the planned costs accrual item type. For the other two accrual item types for actual costs and accruals you do not activate it!

For the review of periodic accrual amounts you can define two thresholds:

• Upper Threshold: If the proposed accrual amount is above this threshold, a review/approval of this amount is required.

• Lower Threshold: If the proposed accrual amount is below this threshold, this amount will not be posted.

If the proposed accrual amount is between lower and upper threshold, no review or approval is required: The approval is granted automatically. In the IMG activity Define Accrual Item Types -> Item Type -> Item Type Settings for Ldrgrp incl. Repr. Ledger, you can enter a threshold variant.

The usage of threshold variants is optional. The threshold variant is defined in the IMG activity Define Threshold Variants. If you mark a threshold variant as default, the system will use this variant if no other variant is entered in theItem Type Settings for Ldrgrp incl. Repr. Ledger.

A typical sequence of a purchase order item lifecycle is shown in the figure.

Initial situation:

• A purchase order (item) is created with a delivery schedule that has delivery dates within the current fiscal year.

• Non-valuated goods receipts were posted.

• An Accrual Object was automatically created.

1. Accruals are posted at the end of each fiscal period (PP 1 — PP 3).

2. A supplier invoice has been posted after the accruals End of Life. A utilization posting (UP) generates additional line items in the vendor invoice posting (online posting mode).

3. At the end of the fiscal year the final supplier invoice(s) were not posted. Result: Some accruals remain.

4. At the beginning of the next fiscal year, Controlling manually releases (RP) a partial amount of the remaining accruals, cause they expect that the outstanding invoice(s) will post less costs than the originally planned.

5. After the manual release the final supplier invoice is posted. A purchaser sets the indicator Final Invoice in the purchase order item. Accruals Management changes the status of the accrual object to F (Prematurely Finished) and automatically releases (FP) the remaining accruals.

6. The corresponding release posting (FP) is performed by the periodic accrual posting run.

Each accrual item type that performs accrual postings must be assigned to postings schema(s). This is done in IMG acitivity Financial Accounting→General Ledger Accounting→Business Transactions→Accruals Management→Accrual Postings→Define Posting Schema.

The posting schema defines:

• How many lines an accrual posting shall contain.

• Which (symbolic) G/L accounts shall be used in which line item.

• Which type each line item has: The posting schema used for periodic postings (PP) must contain one line item that has line item type 9003. Important: The line item with type 9003 must be posted to a balance sheet account (accrual account), because this line must be carried forward into the next fiscal year: The line item type has got the following internal function: The Accrual Engine determines the already accrued amount by selecting all line items of the current fiscal year that were posted with line item type 9003! The line item with type 9000 can be posted to any account. Usually this is the expense account.

SAP delivers standard posting schemes like SAP_ACE_PP (Periodic Posting), SAP_ACE_UP (Utilization Posting), SAP_ACE_RP and more.

After determining the posting schema that shall be used, as a next step, you assign the Accrual Item Type to anAccrual Management Transaction Type (Accr. TType = PP, UP, RP,...) and its corresponding Posting Schema. This setting determines which type of postings shall be performed. For purchase order accruals some Accrual Management Transaction Types must not be used (for example IP (Opening Posting)). This transaction type is only relevant for Manual Accruals.

Examples:

Usually at the end of each period, a partial amount of the total amount is being posted. In purchase order accruals, the amount is calculated as planned costs minus actual costs. The relevant Accrual Management Transaction Type is PP (Periodic Posting).

• You assign the accrual item type to accruals management transaction type PP (periodic posting) and enter the posting schema SAP_ACE_PP.​ This means that the Accrual Engine will perform periodic accrual postings for this accrual item type.​

• The indicator Post Periodically must be set, because the periodic posting is performed by the periodic accrual posting run.

If accruals have been posted and afterwards costs are posted for example by a supplier invoice, then this posting of costs will utilize the full or a partial amount of the accruals.​ In addition to the settings for the periodic posting (PP), the following different customizing settings are possible:

1. The Accruals Management Transaction Type UP is assigned to Posting Schema SAP_ACE_UP.​ This means that utilization postings shall take place.​

   • If the indicator Post Online is set, then during the posting of the invoice additional line items are added in the journal entry of the invoice or goods receipt.

   • If the indicator Post Periodically is set, then the utilization posting will be performed by the periodic accrual posting run.​

   • You can set both indicators, Post Online and Post Periodically. ​ This does not harm. In this case the periodic accrual run will not post the utilization posting a second time.

2. The Accruals Management Transaction Type UP is not assigned to a posting schema.​ In this case the accrual amounts will be corrected/updated as late as with the next periodic accrual run: The corresponding posting will be done with Accruals Management Transaction Type PP.

• Post Deltas: The accrual engine only posts the delta compared to the amount that has already been posted in former periods​.

• Post full amounts​: The accrual engine first creates a posting that inverts (reverses) the accrual amount that was posted in former periods. ​Afterwards it posts the full accrual amount using the last day of the current period as translation date.​

For Purchase Order Accruals the recommendation is to customize the accrual item type to perform delta postings:

• This is the recommended setting at least for utilization postings and release postings (Accrual Management Transaction Types UP, UL, FP and FL) otherwise it would be difficult to explain and understand the amounts in accrual utilization line item during the invoice posting.

• For periodic postings (transaction type PP) full postings can be reasonable.

Finally the real G/L accounts needs to be determined from the symbolic account. For determining the G/L account the following possibilities are offered by the system:

• Simple account determination using a predefined configuration table. This is the IMG activity Create and Edit Basic Account Determination.

• BAdI ES_ACE_DOCUMENT_ACCDET_CUST.

Example: Posting Schema SAP_ACE_PP (Peroidic Posting):

For purchase order accruals on the accrual account needs to be determined by the account determination. Only an entry for the symbolic account PER_ACCR_ACCNT must be maintained. The offsetting account is the expense account. This account is taken from the purchase order item by default.

Only if the purchase order item does not contain an expense account, then as fallback, the account determination (symbolic account PER_OFFSTNG_ACCNT) is evaluated also for the expense account.

Side note: Utilization and Release Postings – Manual Accruals

The SAP S/4HANA Accrual Engine supports utilization and release postings for manual accruals, too. If utilization postings shall be performed, the Accrual Engine needs to calculate not only the accrual amounts, but also the amounts that were posted as actual costs (with reference to the accrual object). Therefore, an accrual item type is needed for the actual costs, for example ACTCST.

If the Plan Minus Actual approach is used for manual accruals, then in addition to accruals and actual costs also planned costs are calculated. In this scenario, an accrual item type is needed for the planned costs, for example PLNCST.

When posting a supplier invoice (for example FB60, F-43 or MIRO) or a manual G/L journal entry (FB50 or F-02), the reference to an accrual object can be entered on line item level.

The Accrual Object can be made available in the posting screens by configuring this field as optional or mandatory in the field status of the corresponding G/L accounts. This is done in customizing transaction OB14 in sectionAdditional account assignments.