Accrual Item Type Settings for Postings – Since S/4HANA 1809 SP03
- In the old Accrual Engine, the type of postings to be performed was defined using the setting Define Accrual Type.
- In the new S/4HANA Accrual Engine, this approach has been replaced by the posting schema concept.
How Posting Behavior Is Now Defined:
- The type of posting that will be performed is determined by assigning:
- An accrual item type
- To an Accrual Engine transaction type (e.g. IP, PP, FP)
- Along with the appropriate posting schema
- This assignment is made in the IMG activity: ACEIMG—> Accrual Postings–>
Assign Accrual Item Types to Journal Entry Types and Posting Schemas - Technically, this is managed via:
- Customizing view: V_TACE_ITEMTYPES
- Configuration table: TACE_ITEMTYPES
Examples:
- No assignment is made for an accrual item type
→ No postings will be performed for this accrual item type. - Only periodic postings are assigned
- The accrual item type is assigned to transaction type PP
- The posting schema SAP_ACE_PP is used
→ Only periodic accrual postings will be performed
- The accrual item type is assigned to:
- IP (Opening Posting) with schema SAP_ACE_IP
- PP (Periodic Posting) with schema SAP_ACE_PP
- FP (Final Posting) with schema SAP_ACE_FP
→ This means:- An opening posting is performed when the accrual object is created
- Periodic postings are made during each period
- A final posting is made if the accrual object is closed early
Accrual Item Type Settings for Postings – Upgrade from S/4HANA 1809 SP0–2 to SP3
- In systems where customizing migration had already been performed in S/4HANA 1809 SP0 or SP1, the settings are automatically corrected during the upgrade to Support Package 3 (SP3).
- As part of the upgrade, an XPRA program is automatically executed to update the relevant configuration in the IMG activity: Assign Accrual Item Types to Journal Entry Types and Posting Schemas
Post-Upgrade Behavior
- After upgrading to S/4HANA 1809 SP3, the previously used indicators such as Op. Entry: Deltas become obsolete.
- These obsolete fields are also no longer visible in the IMG activity Define Accrual Item Types from SP3 onwards.
Additional Transaction Types in the Accrual Engine – From S/4HANA 1809 SP3
- Starting with S/4HANA 1809 Support Package 3 (introduced with SAP Note 2800607), new Accrual Engine transaction types are made available.
These transaction types allow more detailed handling of accrual utilization and release activities:
UP – Utilization Posting
- This transaction type is triggered when actual costs (e.g. an invoice posting) are recorded, and these costs reduce the accrual amount
- The reduction is posted automatically by the system
UL – Late Utilization Posting
- Similar to UP, but used when the utilization of accruals relates to a previous Accrual Closing Period, typically in a prior fiscal year
- This ensures proper period-based tracking of late adjustments
RP – Manual Release Posting
- This transaction type is used when accruals are manually released by a user
- The posting reduces the accrued amount accordingly
RL – Late Manual Release Posting
- Similar to RP, but used when manually released accruals were originally posted in a prior Accrual Closing Period (e.g. a previous year)
- This allows proper handling of late manual corrections across fiscal periods
Posting of Accruals: Account Determination
- In the posting schema, symbolic accounts are specified for use in accrual postings.
- Once the appropriate posting schema has been determined, the actual G/L accounts must be derived from these symbolic accounts.
- The G/L account determination is handled by the system in one of the following ways:
- Basic Account Determination (Standard Method)
A predefined configuration table is used for a straightforward mapping of symbolic accounts to G/L accounts.
This is maintained in the IMG activity: Create and Edit Basic Account Determination
- Enhanced Account Determination (Using BAdI)
If more detailed or flexible account determination is required (e.g., based on additional criteria), the standard table may not be sufficient
In such cases, the BAdI ES_ACE_DOCUMENT_ACCDET_CUST can be implemented
This allows custom logic to be used for determining G/L accounts at a more granular level



