S4F15 – Financial Closing (S/4HANA)

Unit-by-unit study notes written from the course material. Every lesson of the course is covered in the same order as the original.

Unit 1: Financial Closing Overview

Lesson 1: Explaining the Periodic Closing Process

Learn how the closing process is staged over time (pre-closing on the last days of the old month, then managerial close, then closing for external reporting) and which application component is responsible for each step.

Business context

The scenario is that of a project team member who has to define which closing activities are performed in the SAP system and when. The course starts with the SAP S/4HANA Finance learning journey (the visual roadmap of courses for Financial Accounting) and then presents the closing process as a sequence of phases. The key idea is that closing is not one program but a choreography of many steps in different components (FI, MM, HR, SD, CO, AA), and the order matters because later steps depend on the values produced by earlier ones.

Month-end (periodic) closing: three phases

Phase 1 – Pre-closing activities (last day of the old month). These prepare the ledgers so that period-end valuations can run on complete data.

Phase 2 – Managerial closing. Controlling runs its period-end allocations and repostings (assessments, distributions, settlements). Afterwards the old accounting period is locked, and the G/L is re-opened only for the adjustment postings that the external close still needs.

Phase 3 – Closing for external reporting.

• FI: valuation of open items in foreign currency (and the other balance-sheet valuations).
• Technical: final closing of the previous period.
• FI/CO: produce the document-based reports – tax reports, asset history sheet for external purposes, management reports for internal use.

Year-end closing

In the last period of the fiscal year the normal month-end steps are supplemented by annual activities. Again the material distinguishes pre-closing steps from external-reporting steps.

Year-end activities for external reporting: GR/IR clearing account analysis, regrouping (reclassification) of receivables and payables, reconciliation of the prior year with the new year and other adjustment postings; the technical final close of the old period for AR, AP and G/L; and the creation of the external and internal reports.

Golden rule: subledgers before the general ledger

Every subledger (AR, AP, and especially Asset Accounting) has to be closed for a fiscal year before the general ledger is closed. Ignoring this produces inconsistencies between subledger and G/L balances; SAP Note 619969 documents the issue for FI-AA. This rule explains why the technical steps in the tables above are always listed first.

Unit 2: Financial Statements

Lesson 1: Managing Financial Statements

Understand the financial statement version (FSV) as the structure that turns G/L account balances into a balance sheet and P&L, and learn how to create and maintain FSVs both in the Fiori app Manage Global Hierarchies and with the classic transactions.

What a financial statement version is

An FSV is a hierarchical reporting structure that tells the financial statement program which accounts belong to which balance-sheet or P&L item, in what order, with which texts and with which totals. Because the format of statements differs by audience, you can define as many versions as you like (tax authorities, internal management, external investors, different GAAPs). The same version can be used for the structured balance list, for planning and for drill-down reporting, and when you run it you can add parameters to report at company code, business area, segment or profit center level.

An FSV controls:

• the items to include and their sequence and hierarchy;
• the descriptive text for each item;
• which chart(s) of accounts and which individual accounts feed each item;
• which totals/subtotals are displayed.

Two maintenance tools

Manage Global Hierarchies is the single entry point for many hierarchy types: cost centers, profit centers, functional areas, G/L account hierarchies (FSVs) and hierarchies for Group Reporting. It is meant for reporting hierarchies only – not for planning – and there is no synchronisation between a hierarchy built here and the "native" hierarchy of the respective application (e.g. a standard cost center hierarchy). The app is delivered to several business roles: General Ledger Accountant (SAP_BR_GL_ACCOUNTANT), Overhead Cost Accountant, G/L Accountant – Intercompany (SAP_BR_RECON_ACCOUNTANT), Group Accountant and Cash Management Specialist; the hierarchy types each role sees are governed by its business catalogs.

Features of the Global Hierarchies app worth remembering:

• Create, edit, copy, import, activate and deactivate hierarchies, with status control (draft vs. active).
• Time frames: a hierarchy ID can have several validity periods; time dependency is kept on the top node only, and the report's key date selects the frame.
• Drag-and-drop editing, spreadsheet export/import, node texts in several languages, change logs.
• Semantic tags on nodes and accounts (used by KPI content), aging attributes on nodes for reporting-based reclassification, and custom extensibility (custom hierarchies, fields, logic).

Creating an FSV in Manage Global Hierarchies

1. Choose "+" (create), pick hierarchy type Financial Statement Version, enter ID (four characters), description, chart of accounts and validity, and create.
2. Alternatively select an existing FSV, choose Copy → New Hierarchy, and give it a new four-digit ID – useful for reorganisations or new reporting needs.
3. Build the hierarchy levels: assign items (nodes) to each level – the program totals each node – and at the lowest level assign the G/L accounts (or functional areas) whose names and balances are listed. The "+" next to a node adds a subnode or an account; the "…" menu offers Fast Entry to add many subnodes/accounts at once.
4. Activate the hierarchy. On activation the system checks that the validity does not overlap with another time frame of the same hierarchy.

Special items every FSV must contain

The report computes net profit/loss only from the accounts assigned under Assets and Liabilities & Equity. Accounts under Notes or Not assigned are excluded from the net result and also from the P&L result, which is formed from the remaining accounts. Moving an account into the Notes item is therefore the way to keep it out of the P&L result.

Accounts with fluctuating balances (debit/credit indicators)

For each account (or group of accounts) under an item you set whether its balance is to be shown when it is a debit balance, a credit balance, or both. A bank account that may be in credit or overdraft is typically assigned to two items: under an asset item with the debit indicator only, and under a liability item with the credit indicator only (the two nodes are "contra items" containing the same accounts). An account that always appears in the same place gets both indicators. The decision is made on the joint balance of all accounts listed under the item.

Time frames

You can copy an FSV to a new time frame (same ID and description, new validity) to reflect organisational changes. The course example: an Office Supplies account sits under the "Supplies" node in January 2018 and under the "Admin" node from February 2018 onwards; the key date chosen at report time determines which structure is used.

Classic FSVs and Fiori reporting

Classic FSVs (OB58/FSE2, table T011) are still maintained in S/4HANA but cannot be consumed directly by Fiori analytics. Two bridges exist:

1. Import the classic FSV into Manage Global Hierarchies (Import Hierarchy function) and continue maintaining it there with all the app's features.
2. Replicate the classic FSV into the HRRP* tables as a runtime hierarchy that Fiori reports can select. Replication can be triggered in the back end with HRRP_REP (report FINS_REPLICATION_HIER_N, schedulable) or by saving in OB58/FSE2 with the option "Activate after modifying"; in Fiori with the app Replicate Runtime Hierarchy (F1478) or the Manage/Change Financial Statement Versions apps with the same activation option.

The reverse direction does not exist: a hierarchy created in Manage Global Hierarchies cannot be pushed back into T011, so classic reports like RFBILA00 cannot use it (see SAP Notes 3064994 and 3064950).

Lesson 2: Using SAP S/4HANA Reporting Options

Get an overview of the analytics architecture of SAP S/4HANA (embedded analytics on CDS views), the Fiori app Balance Sheet / Income Statement – Multidimensional, and SAP Analytics Cloud as the cloud BI, planning and predictive tool.

Embedded analytics and user roles

SAP S/4HANA Embedded Analytics merges transactional processing and analytics so that operational reports run on live transactional data without a separate data warehouse. The analytics roadmap distinguishes three user groups:

Technically the content is a Virtual Data Model (VDM) of Core Data Services (CDS) views on top of the S/4HANA transactional and master data tables. CDS views are created and extended in the ABAP layer, and the system generates SQL runtime views in SAP HANA so that reading and transforming data is pushed down into the database.

Balance Sheet / Income Statement – Multidimensional

This Fiori app produces balance sheets and P&L statements using an FSV from Manage Global Hierarchies, for the operational, local or global chart of accounts. From a statement line you can drill to the G/L account line items and even to customer or supplier line items, and the result can be exported to Excel or PDF.

SAP Analytics Cloud (SAC)

SAC is SAP's self-service analytics solution on the SAP HANA Cloud Platform / Business Technology Platform. It bundles business intelligence, planning and predictive analytics in one product, and can be used independently of other SAP applications. Points the lesson stresses:

• Planning: financial and operating plans can be built and linked on one platform.
• Predictive: machine learning surfaces new insights during analysis and allows modelling complex future scenarios.
• Deployment: SAC is delivered as SaaS, hosted and updated by SAP. With an on-premise SAP HANA system the user calls SAC in the browser and data is accessed through a reverse proxy (live connectivity) – the data stays inside the company. For non-HANA sources data is replicated to the cloud and leaves the corporate network.
• Business content: SAP delivers financial reporting content (stories and a Digital Boardroom) built on live connectivity to S/4HANA. The CDS view that exposes the financial KPIs identifies them with semantic tags (which is why FSV nodes carry semantic tags). The Digital Boardroom shows the real-time financial situation for current and previous year with KPIs grouped under Growth, Profitability and Liquidity, and can be plugged in out-of-the-box.

Unit 3: Fixed and Current Assets

Lesson 1: Executing Closing Activities Within Asset Accounting

Learn the sequence of period-end and year-end activities in FI-AA and how each of them affects General Ledger Accounting.

Overview of asset closing

Asset Accounting records assets by quantity and value and posts every change automatically; at closing, some of these values have to be completed or adjusted for legal reporting. Year-end closing in FI-AA has two kinds of drivers: legal requirements (what tax authorities and GAAP demand) and technical/organisational requirements (what the system and the accounting organisation need to move into a new year cleanly).

The year-end sequence is:

1. Fiscal year change in FI-AA – performed by the central Balance Carryforward program of FI-GL (there is no separate asset transaction any more).
2. Physical inventory of assets, posting of the adjustments found, and the depreciation posting run which posts depreciation to the G/L.
3. Creation of the asset history sheet.

Country-specific procedures may add further steps.

Depreciation posting run

The run is started from the Fiori app Schedule Asset Accounting Jobs. It posts the following value types:

Postings go directly to the FI accounts and to the account assignment objects of the assets. Only one real CO object (e.g. cost center) receives the posting; further objects can be posted statistically. Always run a test run first: it lists errors such as locked cost centers in an error list so that they can be corrected before the update run.

Fiscal year change

From the point of view of FI-AA, the G/L balance carryforward is the fiscal year change: the cumulative asset values of the old year are carried into the new year, after which asset postings with a reference date in the new year are possible, while the old year still remains open for postings. Constraint: the year change cannot be executed before the last period of the old fiscal year has been reached.

Year-end closing in FI-AA

Preparation: check depreciation lists and the asset history sheet, then post depreciation; if you change any depreciation values afterwards, repeat the depreciation run. The year-end closing program then checks two things: that depreciation is posted completely, and that all assets are complete and error-free. If no errors are found, the last closed fiscal year is updated per depreciation area and ledger, and the closed years are locked against further postings from Asset Accounting.

Asset history sheet

The asset history sheet is the central closing report in FI-AA. Like the balance sheet, its layout depends on national requirements, so several history sheet versions can be defined. A version is organised in history sheet groups, typically: opening book values, acquisitions, retirements, repostings (transfers), depreciation, and closing book values. Imputed interest is not a history sheet group.

Lesson 2: Managing Closing Activities in Materials Management

Understand how MM closing supplies the balance-sheet values for current assets: counting stock (physical inventory), cleaning up the GR/IR clearing account, and valuing raw materials, work in process and finished goods for the key date.

Physical inventory

The physical inventory determines the quantities shown as stock on the balance sheet. Three methods are supported:

The counted quantity becomes the new book quantity; the difference is posted in MM and flows to FI. For a stock shortfall the FI posting is debit "expense from inventory differences", credit the stock (value adjustment) account.

Procurement postings: three-step reconciliation

1. Purchase order – MM only, nothing is posted in FI.
2. Goods receipt – material document in MM plus FI document: debit stock or consumption account, credit GR/IR clearing account.
3. Invoice receipt – invoice verification in MM plus FI document: debit GR/IR clearing account, credit vendor.

Steps 2 and 3 may occur in either order. The GR/IR account therefore shows, per PO item, whether goods have been invoiced and invoices have been matched by goods.

GR/IR clearing account maintenance and analysis

When quantities and prices of GR and IR match, the items clear automatically. Items stay open when a GR or IR is missing, amounts differ, the PO was created with an outdated price, or delivery costs were posted to the wrong GR/IR account. Resolving these is a manual exception process that often delays the close. SAP S/4HANA for Goods and Invoice Receipt Reconciliation (apps Monitor GR/IR Account Reconciliation and Intelligent Goods and Invoice Receipt Account Reconciliation) presents all data on one screen, documents processing status, and a machine-learning proposal service suggests the next step, a priority and a probable root cause for each unmatched item.

Two different activities must be distinguished:

• Maintaining the GR/IR account (MM, MR11-type activity): clearing quantity differences when no further delivery or invoice is expected. Recommended monthly.
• Analysing/regrouping the GR/IR account (FI, program for GR/IR analysis): on the key date, any PO item with a non-zero balance represents either goods invoiced but not yet delivered (a receivable from the vendor) or goods delivered but not yet invoiced (a payable). The program transfers these balances to a "GR/IR – invoiced but not delivered" or "GR/IR – delivered but not invoiced" account via an adjustment account, so that they appear on the correct balance-sheet side, and automatically reverses the posting on the first day of the next period because the regrouping would distort day-to-day processing. The GR/IR account and its adjustment account are then shown in the balance-sheet appendix (notes).

Stock valuation: the three groups

RSC valuation (lowest value principle)

1. Balance sheet valuation: lowest value determination by market price (report RMNIWE00) and/or by rate of movement and range of coverage (RMNIWE10/RMNIWE20). Methods can be used alone (single-level) or chained (multilevel).
2. Value determination: market prices are derived from goods receipts or invoice receipts; slow movers and materials with long coverage can be devalued by percentages.
3. Price update: the determined values can be written to price fields in the material master; if a new standard price is set the balance sheet value follows directly and step 4 is unnecessary.
4. Revaluation of total: MRN9 (Fiori tile Balance Sheet Values by Account) aggregates balance-sheet values per account and company code; with the Database Update flag additional buttons appear to update material prices and to post the delta.

Delta posting automates the adjustment: the difference between the computed balance-sheet value and the book value on the stock accounts is posted, keeping the original assignment to plant, profit center, segment, business area. Prerequisites:

• Set up the delta run: IMG Materials Management → Valuation and Account Assignment → Balance Sheet Valuation Procedures → Set Up Delta Run for Balance Sheet Valuation. Besides document type and header text you must assign an accounting principle (so the posting reaches only the ledgers of the ledger group linked to that principle – parallel accounting) and an account modifier for MM account determination; both are mandatory. Accounting principles are defined under Financial Accounting → Financial Accounting Global Settings → Ledgers → Parallel Accounting.
• Maintain a number range for material ledger documents of transaction type MY (Maintain Number Ranges for Material Ledger Documents).
• Delta accounts are set in MM account determination under transaction keys BSD (delta balance sheet) and UMD (offsetting entry).

Because the account modifier steers account determination, several valuation approaches (e.g. different GAAPs) can be run in one period and shown on separate accounts. MRN9DELTA (tile Delta Runs for Balance Sheet Valuation) checks, analyses and reverses delta postings.

WIP valuation

Example: a production order with six operations, four of them partially confirmed on the key date, goods not yet in the warehouse. Procedure:

1. Calculate WIP on the key date.
2. Settle the production order: WIP appears on the balance sheet and the change in stock is posted in the P&L.
3. After the key date the order is finally confirmed and settled: the WIP is cancelled (key-date posting reversed in the next period), finished goods appear in stock and the order is credited.

WIP can be computed at actual costs (debit of actual costs minus credit for partial deliveries) or at target costs (remaining quantity per operation × planned costs from the current standard or version-specific cost estimate, typical for repetitive manufacturing). Customizing determines which cost components are capitalised.

Finished goods valuation

1. Costing run (CK11N for a material with quantity structure); the costing variant decides whether it is a book or tax inventory costing.
2. Value determination / price update as configured; e.g. if RSC inputs were devalued by lowest-value determination, the new cost estimate reflects the lower product cost.
3. Revaluation of total with MRN9 if the standard price in the material master was not updated.

Unit 4: Receivables and Payables

Lesson 1: Creating Balance Confirmations

Know the order of AR/AP closing steps and how the balance confirmation programs produce letters, reply slips, reconciliation lists and result lists for auditors.

AR/AP closing sequence

1. At the start of the new fiscal year run the central balance carryforward of FI-GL, which also carries customer and vendor balances forward (it can be run separately for customers and vendors).
2. Block the posting periods of the old year and open the special periods for closing entries.
3. Confirm balances, valuate foreign currency documents, post value adjustments and regroup receivables/payables.
4. Close the special periods once the confirmations are complete.

Country-specific additional steps may apply.

Balance confirmation process

The system generates balance confirmation letters with reply slips for any selection of customers and vendors, plus a reconciliation list and a results table. Letters go to the business partners; the lists go to a "control center" (internal or external audit). Partners check the balance and reply to the control center, which compares the replies to the reconciliation list.

Lesson 2: Managing the Foreign Currency Valuation

Understand why and how foreign currency open items and foreign currency balance sheet accounts are revalued at the key date with program FAGL_FCV, how valuation areas, methods and accounting principles are configured (ledger approach), and how the delta posting logic avoids reversal documents.

Scope and basic mechanics

Foreign currency valuation runs before the financial statements are created. It covers (a) G/L balance sheet accounts kept in a foreign currency, valued at balance level, and (b) open items of customers, vendors and open-item-managed G/L accounts posted in foreign currency, valued line by line. Program FAGL_FCV (Fiori app Perform Foreign Currency Valuation) handles both. In the standard logic the valuation document is reversed automatically on the first day of the following month by the same program, regardless of valuation area; to avoid reversals you have to switch to the delta logic (below).

Why it is needed: an open item of USD 500 was translated to EUR 600 at entry. If the rate differs at the key date, the program revalues the item with the new rate, stores the difference in a valuation table and posts "expense/revenue from valuation" against an adjustment account. The adjustment account is used because reconciliation accounts cannot be posted to directly; it is shown on the same balance-sheet line as the reconciliation account. In the next period the posting is reversed so that later valuations and the final clearing are based on the original amount; the key date is the posting date and reversal is the following day unless another date is set.

Features of FAGL_FCV: parallel data selection and parallel processing; logs of test runs are kept (Outputs and Technical Settings tab); a simulation run can post its result to a simulation extension ledger for reporting (see Unit 6).

Customizing: valuation areas, methods and accounting principles

A run requires an FI valuation area, which must exist in Customizing and carry a valuation method; neither can be created during the run. The valuation area is an FI object (not an FI-AA depreciation area) and is also the vehicle for parallel reporting; if only the local approach is needed one area suffices. Linking valuation areas to an accounting principle is mandatory for balance valuations and whenever several ledgers exist, optional for open-item valuation in a single ledger.

The valuation method (time-dependent) specifies the valuation procedure – lowest value principle, strict lowest value principle, always valuate, revalue only – the document type for the differences, and the exchange rate type/basis. (A "high rate of interest principle" does not exist.) In practice several areas with technically identical local methods may be needed.

Account determination for open-item accounts defines, per reconciliation account, the accounts for valuated (unrealised) gains and losses, the adjustment account, and the realised gain/loss accounts posted when items are cleared. In the ledger solution the same accounts serve all ledgers, so the valuation area field in account determination can stay blank. Foreign currency balance sheet accounts instead use the exchange rate difference key in the G/L account master to find their gain/loss accounts.

Delta posting logic

Some countries forbid reversing year-end valuation postings in the next year. A valuation area can be switched to delta logic: only one document is posted, no reversal; the item is revalued only if the rate has changed, and then only for the difference to the previous valuation. Differences are stored in table FAGL_BSBW_HISTRY. Realised differences work as follows:

1. When a foreign currency invoice is cleared, the clearing document is posted identically in all ledgers, so the "realised" difference it shows is simply invoice rate vs. clearing rate.
2. In the next valuation run the correct realised difference per valuation area is computed from the history table and the actual clearing-date rate, and posted against the realised exchange rate account.
3. That correction normally carries the valuation run date (month end); setting the indicator "use clearing date as reversal date" moves it to the clearing date – but only use it when necessary, since the program cannot guarantee that period is open; if it is closed the posting lands in a batch input session.

The lesson's summary figure compares the posting pattern over several periods for the lowest value principle (only devaluations, up to original value) versus the strict lowest value principle (every drop below the previous valuation is posted).

Foreign currency balance sheet accounts

Select the accounts on the G/L Account Balances tab of FAGL_FCV. Depending on method and balance sign the account may be devalued or revalued; the run can be repeated with the same selection, and transactions posted since the last run are included in the current one.

Lesson 3: Managing Value Adjustments

Learn the options for writing down doubtful receivables: individual value adjustments via a special G/L transaction, automatic flat-rate individual adjustments with program SAPF107V, and manual G/L postings.

Three ways to post value adjustments

Individual value adjustment life cycle

The special G/L method is suited to doubtful receivables because the adjustment stays visible on the customer account while hitting a separate G/L account. Later: (1) once the receivable is either paid or confirmed uncollectible, reverse the individual adjustment; (2) if uncollectible, clear the item from the customer account against the "depreciation of receivables" (bad debt write-off) account; (3) correct the output tax that was charged on the original invoice.

Flat-rate individual value adjustment with SAPF107V

1. In AR Customizing define a valuation adjustment key with the overdue period in days and the bad debt expense percentage.
2. Maintain account determination: adjustment account and bad debt expense account for doubtful receivables.
3. Assign the valuation adjustment key in the customer master (not on the document) of every customer to include.
4. Run the periodic valuation: the program produces a proposal that can be edited; when accepted it is transferred to the G/L, posting on the key date and reversing one day later.

Lesson 4: Regrouping Receivables and Payables

Understand why receivables and payables must be reclassified for the balance sheet (debit-balance vendors, credit-balance customers, remaining term, affiliated companies, changed reconciliation accounts) and how program FAGL_CL_REGROUP and the reporting-based reclassification of Manage Global Hierarchies do it.

Why regroup

• Receivables and payables must be shown separately: a vendor with a debit balance at the key date belongs in receivables, a customer with a credit balance in payables.
• Many countries require grouping by remaining life (e.g. under 1 year, 1–5 years, over 5 years).
• Payables/receivables to affiliated companies must be disclosed separately.
• If a reconciliation account was changed in the master record during the year, open items still sit on the old account.

All these transfer postings are made by a program at the key date against adjustment accounts (reconciliation accounts cannot be posted directly) and are reversed on the first day of the next period because daily processing does not need them. Different legal requirements can be served by posting the results of valuation and regrouping to different accounts that are picked up by different FSVs.

Program FAGL_CL_REGROUP (Balance Sheet Supplement – OI Analysis)

• Sorts receivables and payables by remaining life and posts the transfers.
• Makes adjustment postings for changed reconciliation accounts (indicator on the Parameters tab) – the report shows all items at the key date under the new reconciliation account.
• Decides where transfers are needed on the basis of the sort method defined in Customizing, where you select which cases (debit-balance vendors, credit-balance customers, remaining-term intervals) are to be regrouped. Without these selections the program posts nothing.

Reporting-based reclassification (Manage Global Hierarchies)

An FSV maintained in Manage Global Hierarchies can carry reclassification attributes, so the balance sheet report itself shows receivables/payables by remaining term without adjustment postings:

1. Define an aging set with category REC – Reclassification: IMG Financial Accounting → General Ledger Accounting → Periodic Processing → Advanced Valuation in General Ledger Accounting → General Settings → Define Aging Increments for Advanced Valuation.
2. Assign the aging set to the FSV on its Hierarchy tab.
3. Assign the aging increments to the relevant balance sheet subnodes.
4. Add the G/L accounts to be sorted to these subnodes.

This does not replace FAGL_CL_REGROUP; it is a way to report by remaining life before the period-end postings have been made.

Affiliated companies

If a business partner is both customer and vendor and belongs to the group (e.g. another company code), enter the same company ID in the Trading Partner field of both master records and use alternative reconciliation accounts ("receivables from / payables to affiliated companies"). In Customizing assign adjustment accounts to these special reconciliation accounts so that the regrouping program nets and discloses them correctly.

Unit 5: Profit and Loss

Lesson 1: Explaining Cost of Sales Accounting

Distinguish period accounting from cost of sales accounting and learn how the functional area is derived so that expenses can be reported by function.

Two P&L formats, one operating result

Which format is used is either dictated by law or chosen by the company for business reasons such as international comparability. The operating result is identical in both.

Functional areas

A functional area is an organisational unit that splits postings on the same expense account into different report items. Example from the course: personnel expense charged to production belongs in the gross result, whereas personnel expense of administration appears under overhead. Functional areas therefore also tell you which business activity caused each expense.

Cost of sales accounting is part of the Universal Journal (ACDOCA). The functional area in a journal entry is filled by, in order of priority:

1. Manual entry (highest priority).
2. Substitution rules.
3. The functional area in the master record of the P&L account.
4. The functional area in the master record of the CO object (cost center, order …).

The system should be configured so that manual entry is normally unnecessary and the value comes from the CO object, the account or a substitution.

Lesson 2: Posting Accruals and Deferrals

Understand why expenses and revenues must be shifted into the period they economically belong to, and how this is done with accrual/deferral documents that are reversed automatically, or with recurring entries.

Accrual vs. deferral

• Accrual: the expense or revenue belongs to the current period but the invoice (and the posting) will only arrive in a later period – e.g. a service consumed this month, billed next month.
• Deferral: the invoice is posted now, but part or all of the expense/revenue belongs to future periods – e.g. prepaid rent.

Technique: post an accrual/deferral document at period end and reverse it later; the reversal date stored in the original document becomes the posting date of the reversal. When a manual accrual document is entered, reversal reason and reversal date must be specified (the user name is not entered). If the same accrual recurs, use the recurring entry program (Fiori: Manage Recurring Journal Entries).

Course examples

Warehouse lease (deferral): rent EUR 500/month, three months paid on 1 December: Dr Occupancy costs 1,500 / Cr Bank 1,500. On 31 December only one month has been used, so Dr Prepaid expense (accrued income) 1,000 / Cr Occupancy costs 1,000. On 1 January the document is reversed: Dr Occupancy costs 1,000 / Cr Prepaid expense 1,000, so the expense lands in the new year.

Annual invoice received in period 7 (accrual): an invoice of 120 for goods used all year must be spread as 10 per period. For periods 1–6 six accruals of 10 are posted before the invoice arrives; after the invoice (period 7) the remaining 50 is distributed over the last five months.

Recurring accruals: each period the same amount is posted Dr Expense / Cr Other payables – or Cr Provisions if the reason or amount is uncertain and can only be estimated. The credit balance on the payables/provision account grows each period until the invoice arrives.

Lesson 3: Accruals Management – Manual Accruals

Get to know the SAP S/4HANA Accrual Engine and its Manual Accruals application: how contract-like basis data (accrual objects) is maintained and how the periodic posting run turns it into journal entries.

Why an Accrual Engine

Traditional accrual processes pull data from spreadsheets, e-mails and contracts, which means high manual effort, many errors and poor auditability. SAP S/4HANA Accruals Management calculates, reviews and posts accruals automatically. You work with an application component (Manual Accruals or Purchase Order Accruals) that feeds the engine; the engine then performs the periodic postings – like driving a car without touching the engine directly.

The S/4HANA Accrual Engine is fully integrated into the G/L: all G/L currencies are supported, its postings exist only as Universal Journal line items in ACDOCA, it follows the fiscal year variant of the ledgers, and standard reversal (FB08, F.80) works. Posting schemas allow complex postings with more than two lines.

The two manual accrual processes

1. Maintain basis data: contracts are stored as time-dependent accrual objects containing everything needed for the postings.
2. Periodic accrual run: accrual objects are selected; the engine reads ACDOCA to see what has already been posted for each accrual item and posts the difference as normal FI documents.

Accrual objects

Transaction ACACTREE02 displays accrual objects; here you can attach files or notes (e.g. the contract or an Excel sheet), see the Calculated Accruals tab, download Excel templates for mass upload of accruals, and reverse the postings of one single object. Changes to fields are time-sliced: each change is valid from its Valid From date, and the drop-down shows the separate validity intervals. The optional review/approval process (built for PO accruals) is available but normally not needed for manual accruals.

Posting and reversing

ACEPOSTINGRUN posts the periodic amounts for any Accrual Engine application; enter application component ACAC for manual accruals. Postings are identifiable by reference procedure ACES4 and can be reversed with FB08 or F.80 – but since one journal entry may bundle several accrual objects, a single object is better reversed from ACACTREE02. If an object is ended prematurely, the closing posting books the residual not yet covered by periodic postings and sets the accrual account balance to zero.

Lesson 4: Accruals Management – Purchase Order Accruals

Learn how the Purchase Order Accruals application transfers PO items into the Accrual Engine, calculates accruals as planned minus actual costs, lets owners/controllers/G/L accountants review and approve them, posts them periodically, and how all of this is configured in ACEIMG.

Business need and use cases

As soon as a liability to a supplier exists but the cost has not yet been posted, an accrual is required so that cost hits the right period; amounts are typically known only at period end. Use cases differ by how receipts are recorded:

Start/end dates appear on PO items of the Lean Services type (product type group 2 – Service). Not relevant for accruals: stock purchases (no cost yet), fixed-asset purchases (cost arises later via depreciation) and intercompany stock transfers (no external supplier).

Process flow: Transfer → Calculate → Review/Approve → Post

1. Transfer: when a PO item is created the system checks the PO transfer variant and, if relevant, creates an accrual object (= PO) with subobjects (= PO items per account assignment). Transfer is online at PO creation or offline via POAC_MM2ACE_TRANSFER or the job template "Transfer Purchase Orders to Accrual Engine" in the Fiori app Schedule Accruals Jobs (also used at go-live for existing POs and after Customizing changes).
2. Calculate: planned costs (item type PLNCST) from delivery schedule or linearisation; actual costs (ACTCST) from GR, invoices or service entry sheets before the key date; accruals (ACCRL) = plan – actual, floored at zero. View per PO in POACTREE03 / Fiori Display Purchase Order Accruals.
3. Review / Approve: first generate proposals with ACEPROPOSALRUN (job template "Propose Period Amounts"), normally after the last GR/invoice of the period. Review by PO owner (My Inbox work item or FACRARVWBU), optionally by controller (FACRARVWCO); approval by G/L accountant (FACRAAPPRVGL). Machine learning flags whether a proposed amount is reliable. Review is optional (unreviewed proposals are posted); approval is binding (only approved amounts are posted); both together give dual control. Reviewers/approvers can change proposed accruals or planned costs.
4. Post: ACEPOSTINGRUN or job template "Periodic Posting Run". Reverse with FB08/F.80 (reference procedure ACES4) or per object on the Postings tab of POACTREE03.

Roles: the PO owner (goods recipient, requisitioner or PO creator) knows the PO best; controllers care because accruals consume cost center budgets; G/L accountants because they affect the P&L.

Lifecycle example (course figure)

PO with deliveries in the current year, non-valuated GRs, accrual object created automatically. (1) Periodic postings PP in periods 1–3. (2) A supplier invoice posted later triggers a utilization posting UP, adding lines to the invoice document (online mode). (3) At year end some invoices are missing, so accruals remain. (4) Controlling manually releases part of the remainder (RP) because less cost is expected. (5) The final invoice is posted and the purchaser sets "Final Invoice" on the PO item; the object gets status F (prematurely finished) and the rest is released automatically (FP). (6) The FP posting is executed by the next periodic run.

Customizing (ACEIMG, Accruals Management IMG)

Two layers: general Accrual Engine settings (prerequisite) and PO-accrual-specific settings. IMG root: Financial Accounting → General Ledger Accounting → Business Transactions → Accruals Management.

SAP Note 2812479 documents the full configuration and posting logic. Side note: utilization and release postings also work for manual accruals if ACTCST (and for plan-minus-actual also PLNCST) item types exist; the accrual object can be referenced on invoice (FB60, F-43, MIRO) or journal entry (FB50, F-02) line items once the field is enabled in the G/L account field status (OB14, additional account assignments).

Unit 6: Ledger Group-Specific Postings

Lesson 1: Posting Ledger Group-Specific FI Documents

Learn how the ledger solution models several accounting principles, what extension ledgers add, how ledger groups bundle ledgers for valuation runs, and what has to be configured to post to non-leading ledgers only.

Parallel accounting

Globalised creditors and partners expect statements under an internationally recognised standard (IFRS, US GAAP) in addition to the local GAAP, so companies must report under several sets of rules. SAP offers two modelling options in G/L accounting: the account approach (separate accounts per GAAP) and the ledger approach (separate ledgers storing the different valuations). The ledger approach is not the same as the old Special Purpose Ledger (FI-SL).

Standard ledgers

A leading ledger (0L) plus non-leading ledgers each represent one accounting principle. Deciding which GAAP sits in the leading ledger is a fundamental choice; customers upgrading to S/4HANA are advised not to change the leading view during the conversion but, if ever, in a separate project.

Extension ledgers

• An extension ledger stores only delta postings and points to an underlying standard ledger (or to another extension ledger – ledgers can be stacked).
• Reporting on the extension ledger shows underlying ledger + deltas, so no data is duplicated and nothing has to be reconciled.
• Typical use: management adjustments on top of legal data (IFRS or local GAAP); also the simulation extension ledger used by FAGL_FCV for simulated valuations (Unit 4).
• Configuration is minimal – a master record; several extension ledgers can share one underlying ledger.
• Extension ledgers live in the Universal Journal like standard ledgers and may have their own posting period variant, so the standard ledger can already be closed while the extension ledger stays open for adjustments.

Ledger groups

The course scenario: foreign currency valuation must be run for both US GAAP and IFRS.

Ledger groups are defined under Financial Accounting → Financial Accounting Global Settings → Ledgers → Ledger → Define Ledger Group. They are an optional convenience: the system automatically creates one ledger group per ledger with the same name, so nobody is forced to define groups. When a document is entered with the Ledger Group field filled, it is posted only to the ledgers in that group; if the field is empty, it goes to all ledgers.

Posting to non-leading ledgers only

If a ledger group consists solely of non-leading ledgers, a document type must be defined for the entry view in that ledger (Financial Accounting Global Settings → Document → Document Types → Define Document Types for Entry View in a Ledger) with its own number range. The general ledger view is always ledger-specific. Typical apps: Post General Journal Entries with ledger group, or FB50L / FB01L.

Unit 7: Technical, Organizational, and Documentary Closing Activities

Lesson 1: Managing Technical Steps During Period-End Closing

Know the sequence of general ledger closing operations, how the balance carryforward treats each account type, and how posting periods are defined and controlled.

General ledger closing sequence

1. At the start of the new fiscal year run the balance carryforward for G/L, customer, vendor and asset accounts.
2. Block the old year's normal posting periods; open the special periods for closing entries.
3. Valuate foreign currency documents, post accruals, analyse and regroup the GR/IR clearing account.
4. Close the special periods.
5. Run the balance audit trail and create the financial statements for documentation.
6. Produce statutory reporting messages.

Country-specific variations exist. Remember the principle from Unit 1: all subledgers, FI-AA in particular, must be closed before the G/L fiscal year is closed; otherwise serious inconsistencies in G/L balances can arise.

Balance carryforward (Fiori Carry Forward Balances / FAGLGVTR)

Posting periods and the fiscal year variant

The posting date entered in a document determines its posting period. The fiscal year variant defines the start and end of the fiscal year, the number of normal periods (up to 16), the number of special periods (the remainder up to 16) and the period lengths.

Posting period control (OB52 / Manage Posting Periods)

The posting period table opens and closes periods; any number can be open simultaneously. Columns:

• Posting period variant – assigned to company codes, so several company codes can be opened/closed in one step.
• Account type – controls open periods per account type.
• Interval 1 and 2 – period ranges that are open (e.g. current period and special periods).
• Interval 3 – in S/4HANA used for postings from CO to FI; if empty, intervals 1 and 2 apply to them too.

Periods listed are open, all others closed; the specific account type lines can only narrow the range given in the "+" line. Because FI and CO are unified in S/4HANA, CO-relevant FI postings and FI-relevant CO postings need both the FI period open (FAGL_EHP4_T001B_COFI for interval 3) and the CO period lock released (OKP1).

Lesson 2: Executing the Balance Audit Trail

Understand the purpose of the balance audit trail as the documentary evidence of how account balances evolved, to be produced before documents are archived.

Concept

The balance audit trail lists, for a chosen period, the opening balance of each account and all the changes up to the closing balance – essentially a compact journal per account in list form. It serves two purposes: documenting posting information and document status for a fiscal year, and providing a statement for external auditors.

Legislation requires that balances can be justified by their documents for several years. While the documents are in the database this is trivial; but to reduce system load older documents are archived and deleted. Therefore the balance audit trail must be generated (and stored) before archiving, so that balances remain explainable afterwards. Programs exist for G/L accounts and for customers/vendors (open item and balance-based variants).

Lesson 3: Explaining the Purpose of Document Splitting in G/L Accounting

See why document splitting is needed to produce complete balance sheets for entities below company code (segment, profit center) and how it enriches and splits vendor, tax and payment lines without changing data entry.

The problem

A vendor invoice has expense lines with account assignments (cost center → profit center → segment) but the vendor and tax lines have none. For a segment balance sheet the payable and the tax must nevertheless be attributed to the segments. Document splitting solves this in the general ledger view only.

Course example

Vendor invoice with 10 % tax, two expense lines on account 61003000 with different cost centers (hence different segments). The user enters the vendor once. In the entry view there is one vendor line and one tax line; in the general ledger view both are split in proportion to the expense lines, so that segment 1000_B carries its share of the payable (EUR 2,200 in the example). The balance per segment is zero. The subledger (AP) still shows a single open item – splitting is invisible there.

Mechanics

• Enrichment / inheritance: lines without an account assignment inherit the splitting (balancing) characteristics – e.g. segment, profit center – from the lines that have them.
• Active split: vendor and tax lines are split according to splitting rules based on the assigned expense lines; the online check ensures each characteristic balances to zero, without altering the user's entry process.
• Follow-up processes: when the invoice is paid (with 3 % cash discount in the example), the payment document is split according to the rules of the original invoice, so bank, discount and payable lines carry the same characteristics. In line item display, invoice and payment appear as cleared items exactly as before.

Unit 8: Financial Closing Cockpit

Lesson 1: Managing the Financial Closing Cockpit

Learn the benefits of orchestrating the closing process in the FCC, walk through its six-step configuration procedure, and see how released task lists are scheduled, executed with dependencies and analysed.

What the FCC is and when to use it

The FCC is a structured interface for executing the many transactions and programs that make up a complex, recurring process such as the period-end close – for a single company code or across several organisational units. All stakeholders start or monitor their tasks there, see the status of automatically scheduled jobs and report issues. It pays off when:

• activities recur every period;
• several responsible people are involved;
• the steps follow a fixed chronological order or have dependencies;
• everyone needs one uniform interface;
• the status of all periodic activities must be transparent to all parties;
• the closing tasks must be documented for later checks (compliance).

Users can set a manual status, document that a task was checked and confirm that a transaction has been performed. From the task list you reach status information, issues, job logs, spool lists and application logs, whether tasks ran automatically or manually.

Building blocks

Task types

Tasks are reached centrally from FCLOCO or the Fiori app Process Closing Tasks (Classic). Types: notes (manual steps), transactions, programs, jobs (program + variant), workflow (for chains of programs with variants that should run automatically), Business Automation Enabler (formerly SAP CPS), external jobs, remote tasks, tasks in other SAP systems and automation in other SAP systems.

Configuration procedure

1. Create a template: Template/Task List → Create → Create Template; enter the 10-character key, choose a closing hierarchy, add a description. The template header shows the time-dependent selection variables; the system proposes a template structure from all organisational objects of the hierarchy (e.g. controlling areas with their company codes and sub-folders). Scope should mirror the overall process and organisational units, not application silos. Templates can also be copied.
2. Create task groups for cross-template maintenance and mass changes.
3. Create tasks: define the activities in chronological order within the org structure; structure transactions and programs.
4. Define dependencies: on the Dependencies tab enter the upstream programs/transactions of each task; the sequence is enforced during processing.
5. Create a task list: open the template, choose Create Periodic Task List, enter Key Date, Fiscal Year and Posting Period. The task list takes the template's name, is filed under the template by key date, and automatically fills the time-related parameters of the program variants from its header. Depending on the closing type chosen, only the tasks allowed for that type are transferred.
6. Release the task list by setting the status to Released; only then can it be used in the application and its tasks selected and scheduled.

Compliance: FCLOCOT separates the roles of the group-level closing planner (maintains templates) and the local closing manager, who can only derive task lists from the approved template.

Execution and analysis

After release, tasks are selected and scheduled in the FCC. In the list display you see every task's details and processing status and can jump to its detail list, where you can check or process the spool request, job log, batch input session and status changes. Dependencies make sure a task does not start before its predecessors are finished.

Unit 9: Intercompany Reconciliation

Lesson 1: Intercompany Matching and Reconciliation (Overview)

Understand the ICMR architecture – real-time matching of Universal Journal items in SAP HANA without ETL – and the configuration objects (data source, matching method, matching rules, reconciliation case, display groups, tolerances) behind the matching and reconciliation apps.

Business problem

With more mergers and acquisitions, groups suffer from a lack of transparency between legal entities, which makes reconciling intercompany transactions expensive and slow and delays the close. Differences typically arise from timing, currency and similar causes, and the focal point is AR against AP. Ideally variances are fixed at the source, early in the closing process. ICMR supports exactly this early, continuous analysis from company close to corporate close.

Key features

• Flexible definition of matching and reconciliation rules; user-defined organisational dimensions.
• Matching reads the source data directly (Universal Journal or external data) – no ETL – and runs in SAP HANA, so very large volumes are processed in minutes; real-time reconciliation and error detection.
• Fiori apps to manage assignments at aggregate or line-item level, with in-app communication and workflow.
• Automatic discrepancy adjustment, optionally with approval: attach a workflow scenario to the reason code; standard scenario WS78500087 is delivered and configured in Manage Workflows – Intercompany Variance Adjustment.
• Reason codes and recommended solutions are recorded for matched and nearly matched items with variances, to explain them and to automate resolution.
• Result: faster month-end close and higher visibility of the reconciliation process; supports continuous accounting.

Configuration objects

Prerequisite noted in the course: fiscal year variants and charts of accounts of the entities must be aligned for meaningful comparison.

Process and apps

1. Run matching on the continuously arriving documents – manually from Define Matching Methods, Manage Assignments – By Matching Method or Manage Assignments – By Reconciliation Case, or as recurring background jobs via Schedule Matching Runs. Matching results are stored in table ICADOCM.
2. Manage Assignments – By Reconciliation Case: choose the case, fill the mandatory filters (display group, amount field, currency plus data-source fields), choose Go to list unassigned items of the leading unit and its partners, choose Auto Match to apply all rules sequentially, then review the Assignments table. Actions on items:
   • Assign: manual match where rules do not apply (e.g. equal amounts in different currencies due to a posting slip); items get an assignment number.
   • Communicate: Add Note (public comment, optional due date → status Note Added; overdue items flagged red), Send Notification (to selected recipients via the Fiori launchpad, status Notification Sent), Set to Done (clears due date and alarm).
   • Adjust or approve variances (auto-adjustment with optional workflow approval).
3. Reconciliation Balances: YTD and period amounts of the selected organisational units and their partner units with differences for a fiscal year/period and reconciliation case; netting available when display groups are paired; drill-down to matching items and original documents.
4. Reconciliation Status Overview: line-item matching status and aggregated reconciliation status per case, period and organisational unit. The matching status is derived from the leading display group: for AR → AP, the Not Assigned count of a company = its unassigned AR items + unassigned AP items of its trading partners (the two "Unassigned" tables of Manage Assignments) – not all AR/AP items of the company. Items with status 00 New have not yet been processed by the matching engine and are not counted. The Details arrow leads to Reconciliation Balances.

Status determination compares the differences between company and trading partner postings with the tolerances of the display group, resulting in different reconciliation statuses.