S4F12 – Basics of Customizing for Financial Accounting (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: SAP S/4HANA Overview

Lesson 1: Getting an Overview of SAP S/4HANA

Explain the technology trends behind SAP HANA and SAP S/4HANA, position S/4HANA inside the Intelligent Enterprise, and compare the cloud and on-premise deployment options.

Learning journeys

The lesson opens with the SAP S/4HANA Finance learning journey: a visual roadmap of courses that leads to a certification for a given solution. S4F12 is one stop on the Financial Accounting path. Learning journeys are found by searching the web for "SAP Learning Journeys".

The connected digital world

Business challenges are driven by a digital, networked world. The course cites several trend figures to make the point: most of the world's data was generated in the last two years, business-network adoption is growing quickly, hundreds of billions of devices will be internet-connected, billions of mobile users exist, and more than half of workloads already run in the cloud. The message: companies need software that can process huge data volumes in real time, on any device, and in the cloud.

Advances in hardware that enabled SAP HANA

• Cheap, abundant memory – an entire enterprise database can now sit fully in main memory. Disk (and even SSD) latency disappears because the CPU reads directly from RAM. 64-bit operating systems are needed to address that much memory.
• Fast multi-core CPUs – complex tasks are split and processed in parallel, so even predictive analytics can run in real time.
• Horizontal scaling – additional servers can be added to the landscape for more memory or compute.
• Software rewritten for the hardware – SAP rewrote its business applications together with hardware partners (who shared CPU blueprints) to exploit this architecture.
• Mature cloud computing – virtualisation lowers running costs, and subscription-based public cloud gives every customer access to the latest release without installing and maintaining a landscape.

OLTP and OLAP reunited (HTAP)

Traditionally, transactional systems (OLTP) are built for fast record-level read/write, while analytical systems (OLAP) are built for batch loads, aggregated storage and read-heavy queries. Data was therefore copied from one to the other through interfaces, producing multiple copies, latency, and inconsistent views (often analysis could only start the next day). SAP HANA handles both workloads on one platform – Hybrid Transaction/Analytical Processing (HTAP). There is one copy of the data, no data movement, live data for every application, less integration complexity, and the ability to build new applications that mix transactions and analytics – which is exactly what SAP S/4HANA does.

SAP S/4HANA as the intelligent core

SAP's view is that best-run businesses are "intelligent enterprises" applying advanced technologies within agile, integrated processes. The Intelligent Enterprise is described through four core components and then a set of portfolio elements:

Universal Journal and continuous accounting

In S/4HANA the Universal Journal (table ACDOCA) is the single source of truth for Finance. Every posting writes line items into this one table, which combines the data previously held in separate FI, CO, Asset Accounting and Material Ledger structures. Many redundant tables (totals, index tables) were removed, shrinking the data footprint and simplifying application design and extensibility. This is what enables "continuous accounting" – reporting on live data without period-end data transfers.

Deployment options

S/4HANA keeps the same data model, user experience and code line whether deployed on premise or in the cloud, so a customer can use any combination. Dimensions to consider when choosing:

The deployment spectrum runs from SaaS public cloud, through private cloud on hyperscalers, to on premise ("any premise"). Cloud maximises agility: standardised best-practice processes, innovation up to four times a year, fast time to value, lower TCO. Any premise (own data centre or IaaS) maximises specialisation: full control to customise and extend.

Lesson 2: Introducing SAP Fiori

Describe the SAP Fiori user-experience principles, the three app types, and the SAP Fiori launchpad features including personalisation and spaces/pages.

Scenario

The business wants users to work with SAP applications on any device without compromise, with a solution that integrates into the existing landscape and can be extended. The lesson checks whether SAP Fiori meets these requirements.

The five Fiori design principles

What SAP Fiori delivers

The SAP Fiori launchpad is the single entry point: apps are reached via tiles, links or search. Fiori brings a harmonised look and feel across all SAP products, embedded intelligent guidance (machine learning, dynamic home pages, a digital assistant) and cross-product / cross-device integration with notifications. The course describes a pyramid of usage:

1. Overview – Overview Pages, List Reports and Work Lists show what needs attention; notifications alert on urgent items.
2. Quick actions and drill-down – e.g., extend a contract or change a delivery date, or ask the SAP CoPilot digital assistant for ad-hoc help in context.
3. Details – Object Pages for the full view of a business object, or editing frequently changed fields (amount, date, items) in a sales order.

Fiori also marks the move from monolithic transactions to activity-based apps that simplify processes by role and empower users.

Three types of Fiori apps

Launchpad features and personalisation

• Themes and branding; stable URLs that can be bookmarked and shared; browser-based so it works across devices.
• Active (dynamic) tiles show live figures on the home page without opening the app.
• Users can add apps from the catalogs assigned to them, remove apps they do not need, and save filtered report variants as their own tiles. Example: a group cash manager focused on Germany creates a tile that jumps straight to the German cash position.

Spaces and pages

"Spaces mode" gives administrators finer control over layout for user groups. A business role is assigned spaces; each space contains pages; pages are organised into sections that define the order of apps (e.g., most-used apps at the top, related apps grouped together). SAP delivers predefined spaces and pages as a starting point.

Unit 2: Core Financial Accounting (FI) Configuration

Lesson 1: Managing Organizational Units in Financial Accounting (FI)

Create a company code, understand the other FI organisational units and when they are needed, and check the company code / controlling area assignment.

Business example

A medium-sized client is a single legal entity and needs a new company code created and assigned. To do this well you must understand company codes, the optional organisational units, and controlling areas.

Client and company code

• Client – the top of the hierarchy, a self-contained unit with its own master data, tables and data. In business terms it is the corporate group. Data entered at client level (e.g. exchange rates) is valid for every organisational unit below and does not have to be repeated. To log on via SAP GUI a user needs a client key and a user master record in that client.
• Company code – an independent legal accounting entity with its own set of accounts; legally required financial statements are produced at this level. It is the minimum structure required for FI and the most important FI organisational unit. International groups normally create one company code per country because each tax authority wants a separate legal entity. Rule of thumb: every organisation that produces its own balance sheet and P&L becomes a company code.

Creating a company code

1. Use the Copy, delete, check company code function to copy an existing company code. The copy carries over the definition, global parameters, Customizing tables, G/L accounts (optional) and account determination.
2. Adjust the copied data with Edit Company Code Data.

Meaning of the main definition fields:

• Address – used in correspondence and printed on reports.
• Currency – the local (company code) currency; accounts are managed in it and every other currency is "foreign" and is converted into it.
• Language key – lets the system print texts (e.g. cheques) in the right language.
• Country key – defines the home country; other countries are foreign, which matters for payment forms and address formats.

Country templates: when a company code is needed for another country, look for a prepared SAP Best Practice company code for that country and copy it, or copy the company code from your own corporate template and then adjust the country-specific settings.

Optional organisational units in FI

Whether to use them depends on two questions: for which areas/segments is separate reporting required, and for which responsibility areas must a separate balance sheet or P&L be produced?

Guiding questions when picking organisational objects: What is the main accounting principle? Which principles are used internally and externally? Is the P&L structured by nature of expense (period accounting) or cost of sales? Is segment reporting mandatory? Is a consolidated statement required?

Recommended procedure per reporting requirement

Complete financial statements by profit center or segment require document splitting to be active.

Company code and controlling area

The controlling area is the central CO organisational unit – a closed system in which costs and revenues are managed and allocated. Several company codes can share one controlling area (cross-company-code cost accounting) only if they all use the same operating chart of accounts and the same fiscal year variant.

Lesson 2: Checking the Basic Settings in General Ledger (G/L) Accounting

Understand leading, non-leading and extension ledgers, ledger groups, and compare the ledger approach with the accounts approach for parallel accounting.

Why

G/L Accounting must be configured so the company can meet all reporting requirements, e.g. IFRS segment reporting by profit center, business line or geography, and parallel valuation under several accounting principles.

Standard ledgers: leading and non-leading

• The leading ledger 0L is delivered by SAP. Each client has exactly one; every company code is assigned to it automatically and it cannot be deactivated. It represents the group valuation view (the accounting principle of the consolidated statements), is integrated with all sub-ledgers, and in the standard system is the only ledger whose values flow to Controlling.
• Non-leading ledgers run in parallel and are activated manually per company code, typically for a local accounting principle (one non-leading ledger per local GAAP). Their fiscal year variant may differ from the leading ledger's.
• Both are standard ledgers: each holds a complete set of journal entries for all transactions. A normal FI document is posted to the leading ledger and all non-leading ledgers assigned to the company code.

Ledger groups

Ledger groups let you post adjustments to only one or a selection of ledgers (needed for parallel accounting). Any number of ledgers can be combined; when a ledger is created the system automatically creates a ledger group with the same name; you only need extra groups where several ledgers should be processed together; if no ledger group is entered the system posts to all ledgers.

Extension ledgers

An extension ledger sits on top of a standard ledger and stores only delta postings. Reporting on the extension ledger always includes the underlying standard ledger's data, while postings made to the extension ledger are not visible in the underlying ledger. Only manual postings are allowed, no configuration beyond the master record is needed, and ledgers can be "stapled" to build different views (e.g. management view on top of IFRS or local GAAP data) with a minimal data footprint.

Accounts approach versus ledger approach

In the accounts approach each valuation is posted to different G/L accounts and the financial statement version decides which accounts belong to which view.

For new (greenfield) systems SAP strongly recommends the ledger approach.

Lesson 3: Outlining the Variant Principle

Explain the three-step variant principle that recurs throughout FI Customizing.

Variants make it easy to maintain properties that many objects share: define the properties once and attach them to many objects. The method always has three steps:

1. Define the variant (give it a key).
2. Define the values/properties of the variant.
3. Assign the variant to the objects that should use it (e.g. company codes).

The course points to three places where FI uses it: field status variants, posting period variants and fiscal year variants.

Lesson 4: Managing Fiscal Year Variants

Define fiscal year variants (calendar, non-calendar, year-specific, shortened) and assign them to company codes.

Business example

The company's fiscal year equals the calendar year, and the accounting manager wants four special periods for year-end closing postings.

Fiscal year and periods

• A fiscal year is defined as a variant and assigned to the company code. It holds the posting periods and the special periods – at most 16 in total (e.g. 12 + 4).
• Special periods are not time periods; they are used for year-end closing postings. The system derives the period from the posting date; if the date falls in the last normal period, the user may instead choose one of the special periods (13–16 in the example).
• Standard variants are delivered and can be used as templates.
• Important: the fiscal year variant says nothing about whether a period is open or closed – that is controlled by the posting period variant. It only defines the number of periods and their start/end dates.

Types of fiscal year variant

Most fiscal year variants in practice are year-independent.

Lesson 5: Identifying the Basic Functionality of Currency Keys and Exchange Rate Types

Understand currency keys, exchange rate types, translation ratios, direct/indirect quotation and the tools for keeping exchange rates up to date.

Business example

The company trades with customers and vendors in many countries. The head accountant fears that maintaining exchange rates will be a lot of work; you must show how the S/4HANA tools reduce that effort.

Currency keys and exchange rate types

• Every currency must have a currency key; most currencies are delivered with their ISO keys. Each key can have a validity date.
• Exchange rate types exist for different purposes – valuation, conversion, translation, planning. Rates are maintained per exchange rate type and currency pair.
• Translation ratios define the relationship between two currencies per exchange rate type (e.g. 1:1 or 1:100) and are usually maintained once; because inflation can change the ratios they are time-dependent.

Exchange rate maintenance tools

Maintaining rates is an ongoing task. Options:

Direct versus indirect quotation

• Direct: one unit of foreign currency expressed in local currency – e.g. local EUR, USD 1 = EUR 0.8832.
• Indirect: one unit of local currency expressed in foreign currency – e.g. EUR 1 = USD 1.1319.

Quotation type is a cross-application, cross-country setting; the market standard or the transaction decides which is used. Per currency pair you set one quotation as the standard; a rate entered in the other quotation is highlighted. Prefixes distinguish the two when entering and displaying rates: blank for direct and "/" for indirect by default.

SAP Note 783877 collects FAQs on currency translation.

Lesson 6: Managing Currency Types

Know the standard currency types and how parallel currencies are assigned per ledger and company code.

Each ledger must carry at least one currency: the company code (local) currency, needed for legal reporting. The document (transaction) currency is always recorded exactly as entered. Since S/4HANA 1610 the Universal Journal can hold many additional parallel currencies per ledger and company code, which is useful for internal reporting – for instance to strip out uncontrollable currency fluctuations and show true performance. You choose which types to update (00 and 10 are always there) and may define your own types if the standard ones do not fit.

Lesson 7: Common Practices for Implementing SAP S/4HANA

Survey the configuration decisions typically made for an international group in a greenfield S/4HANA implementation and how the Universal Journal links them.

Context

Not every topic applies to every customer (a public body may only use local GAAP; a hospital needs no consolidation), but because the Universal Journal stores internal and external accounting in one table, these topics should be analysed together.

Universal Journal as basis for reporting

ACDOCA is the single line-item store for General Ledger, Profit Center Accounting, Asset Accounting, Material Ledger, Controlling and (account-based) Profitability Analysis. Hence the same settings serve parallel accounting, segment reporting, consolidation preparation, period vs cost-of-sales accounting and CO-PA. Any line-item characteristic can be used to report G/L balances.

Organisational elements and recommendations

Priority when the functional area could come from several sources: substitution → manual entry → G/L account → CO object. Every line item carries account, functional area, profit center and segment, so both P&L methods and segment reports come from the same data.

Currency types in practice

Company code currency (10) is the first FI currency; a second and third FI currency (parallel currencies, e.g. a hard currency) can be stored alongside the document currency in the data entry view. The controlling area has its own currency type – SAP recommends 30 (group currency) – and both company code and controlling area currencies are updated for every document in the Universal Journal. Because company codes use different national currencies, a uniform group currency is needed; group currency 30 should be the second FI currency (Note 119428) and must also appear in Asset Accounting as a depreciation area per ledger. The Universal Journal can hold 8 further currency types (e.g. for transfer prices). The document currency is always stored.

Unit 3: Master Data

Lesson 1: Maintaining General Ledger (G/L) Accounts

Understand the chart of accounts and the two-segment structure of a G/L account, and configure account groups, field status, reconciliation accounts, open item management, account currency, mass maintenance and group/country charts of accounts.

Business example

The chart of accounts and company code settings can be copied from company code TA00, but accounting needs extra expense accounts for authorised travel expenses and payments, and those accounts must sit in their own number interval. This calls for understanding the chart of accounts, G/L account structure, account types, and single and mass maintenance.

Chart of accounts

The chart of accounts is itself a variant: it holds the structure and basic data of G/L accounts and is assigned to every company code that needs accounts with that structure (several company codes may share one). Examples: YCOA, IKR, CAUS or any country chart. Defined with a four-character key, it contains:

FI and CO share the same chart. Company codes can only do cross-company-code controlling if they share the operational chart (course figure: CC1000 and CC2000 can, CC2000 and CC3000 cannot).

The two segments of a G/L account

An account exists in a company code only when the company code segment is created; account numbers and names are therefore identical in all company codes, while control settings (e.g. tax category) may differ per company code. An account that one company code does not need (e.g. a foreign-currency bank account for a country where it has no partners) remains available to other company codes. The Fiori app Manage G/L Account Master Data maintains both segments.

G/L account types

For the two cost-element types the controlling-area data holds the cost element category, which restricts the CO transactions the account may be used for – e.g. category 21 (internal settlement) only for settling orders or projects.

Balance carryforward

• Balance sheet accounts: balance carried forward to the same account.
• P&L accounts: balance moved to a retained earnings account and the P&L account reset to zero. The retained earnings account is identified by a key (e.g. X) entered in the P&L statement account type field of the chart of accounts segment.
• With one retained earnings account the system assigns it automatically when P&L accounts are created; with several, the user must pick one per account. Retained earnings accounts are defined via the Automatic Account Determination app (Define Retained Earnings Accounts).

Account groups

Account groups organise accounts of the same kind (cash, material, asset, P&L …). Each group has a number range so similar accounts share an interval (intervals may overlap). The group is entered in the chart of accounts segment and it controls the field status of the company code segment – e.g. make "open item management" a required entry for the cash clearing account group.

Field status

Fields are grouped so one status covers a group (e.g. all interest-calculation fields). Account currency and field status group are always required. The account group normally drives the status; a transaction-specific (activity) control exists to restrict editing when changing master data – e.g. set the currency field of a GBP cash account to Display under Define Screen Layout for Each Transaction → Change. When account group and transaction definitions differ, the higher priority wins: Suppress > Display > Required > Optional. In Display transactions fields can only be shown or hidden. If you do not want transaction-specific control, set everything there to Optional (lowest priority).

Reconciliation accounts

Reconciliation accounts are G/L accounts that receive the sub-ledger postings automatically, keeping the general ledger always current. The sub-ledger type (customers/receivables, vendors/payables, assets) is set in the company code segment field Reconciliation account for account type, and the account is valid only for that type. Direct postings to reconciliation accounts are not possible.

Open item management

With the indicator set, each item is either open or cleared, which lets you check whether a transaction has its offsetting entry and list open versus cleared items separately. Typical accounts: bank clearing, GR/IR clearing, salary clearing. The indicator can only be switched when the balance is zero. If OIM is set up per ledger, ledger-group-specific clearing is available.

Account currency

• Default account currency when creating an account = company code (local) currency. Such accounts accept postings in any currency; each item is translated into local currency. This works regardless of line item display.
• An account in a foreign currency can only be posted in that currency.

Ways to create G/L accounts

Collective processing / mass change

Several accounts can be changed at once: chart of accounts data, company code data, descriptions, and (only in Manage G/L Account Master Data) controlling data. In Edit Multiple G/L Accounts – Company Code View you pick the fields and enter new values that replace the old ones for all selected accounts. In Manage G/L Account Master Data (up to 50 accounts per run): select and mark accounts → Mass Change → Other Attributes → add hidden fields via Settings → enter replacement values in the "By" column → Apply → Save. Changes take effect on save and can have far-reaching effects, so review first.

Group chart of accounts

Used when company codes need different operational charts (e.g. for local legal reasons) but the group must consolidate. Steps:

1. Create the group chart containing all group accounts.
2. Assign it to each operational chart – the group account number field becomes required.
3. Enter a group account in each operational account (several operational accounts may map to one group account).
4. Build a financial statement version on the group chart.

Drawback: no cross-company-code controlling between company codes with different operational charts.

Country chart of accounts

Alternative: all company codes use the same operational chart, and company codes needing local statements get a country chart assigned; the country account number is entered as alternative account number in the company code segment of each operational account (each alternative number may be used only once). Cross-company-code controlling remains possible. Disadvantage: local clerks must learn the operational chart.

Group scenario: European company codes (Spain, Germany, UK) share YCOA, North American ones (US, Canada) share CAUS, so controlling works within each region. Country charts are added for local reporting, and group chart CONS is assigned to both YCOA and CAUS for consolidation, since cross-regional controlling is not needed.

Lesson 2: Creating Profit Centers and Segments

Know what the segment characteristic is for, how it relates to IFRS 8 segment reporting, and how segments are derived – normally from the profit center.

The segment characteristic

The segment is a standard account assignment object in FI for evaluating entities below company code level, intended for a detailed analysis of business areas such as markets or products, and for meeting IFRS / US GAAP segment reporting. Business area and profit center could serve the same purpose, but because these were often used for other things in the past, SAP added the segment as a dedicated object.

IFRS 8 describes a business segment as a component of the enterprise that (1) earns revenues and incurs expenses (including from internal transactions), (2) has operating results that the chief decision maker regularly reviews for resource allocation and performance evaluation, and (3) has separate financial information available.

Derivation

• Standard practice: store the segment in the profit center master record. Posting to the profit center automatically posts the segment; without a segment on the profit center, no segment is posted.
• SAP Note 1035140: segments are only officially supported together with profit centers; automatic derivation is only from profit centers; in many (especially logistics) transactions the segment cannot be entered manually; several standard interfaces do not support segments.
• If the profit center cannot provide the segment, General Ledger Accounting with document splitting offers: manual entry, BAdI FAGL_DERIVE_SEGMENT, substitution rules, or assignment to standard accounts.

From the assessment: segments have no time reference and belong to no hierarchy; they are used across company codes; typically only a few segments exist and each is assigned to many profit centers.

Lesson 3: Managing Business Partners

Describe the business partner model (categories, roles, segments), how customer/vendor integration keeps FI customers and vendors in sync, how field status and number ranges are controlled, and the special cases of one-time accounts and sensitive fields.

Business example

S/4HANA introduces the business partner as the master record for customers and vendors. Management wants to understand how AR/AP master data is created and configured under this concept, how it integrates with FI, and how one-time accounts and sensitive fields work.

Business partner categories

The business partner (BP) is the single point of entry to create, edit and display customer and vendor data. The category – person (natural person), organisation (legal entity or part of one, e.g. a department), or group – decides which fields are available (legal form for an organisation; first name, last name, gender for a person). It is mandatory at creation and cannot be changed afterwards.

Business partner roles

A role represents a business context and supplies application-specific data: FI Vendor (FI-AP), FI Customer (FI-AR), Customer (SD), Supplier (MM), contract partner (FI-CA), prospect, general BP. A BP can hold several roles; central data (name, address, bank details) is entered once. The General Business Partner role is always assigned automatically as the foundation.

Segments of the business partner

A complete vendor = general + company code + purchasing org segment; a complete customer = general + company code + sales area segment. Maintenance is via the Fiori app Maintain Business Partner or transaction BP.

Role grouping lets one user create a partner in several roles in one step (e.g. FI Customer and SD Customer), enabling centralised maintenance. When AR and SD are both implemented, both teams must agree on configuration and ownership of customer master data.

Customer/Vendor Integration (CVI)

• FI keeps its own customer and vendor master records as AR/AP sub-ledger accounts, while applications such as Loans Management or Treasury use the SAP Business Partner. CVI synchronises the two when FI and BP are used in parallel; customer and vendor integration can be activated independently, and CVI is designed for one system / one client.
• Assignment is 1:1 – one customer and/or one vendor per BP, each in the corresponding role. When the BP is created or changed, the system creates/updates the customer or vendor in the background according to the synchronisation control and CVI Customizing; this only happens for role categories configured for it.

Groupings, number ranges and account groups

• Every BP gets a grouping at creation (unchangeable) which determines the number range and whether numbering is internal (system) or external (user, possibly alphanumeric). Standard groupings for internal and external numbering are defined, and a grouping can be hidden from the F4 list, e.g. to reserve it for interfaces.
• In CVI Customizing each BP grouping is mapped to a customer and/or vendor account group, so the FI account is created with the right group. The account group cannot be changed after the FI account exists.
• The Same Number flag makes the customer/vendor number equal to the BP number. Prerequisites: BP and customer/vendor number ranges cover the same intervals, and the FI account group uses external numbering. Not using identical numbers gives more flexibility (internal numbering in FI is then possible). Customer and vendor account groups can share number ranges; a number range can serve several account groups.
• Flexible grouping: instead of the fixed grouping→account group mapping, the accountant can pick the account group manually when creating the BP – useful when customer numbers carry meaning or different field status requirements call for different account groups.

Field status for business partners

Marking important fields as required (e.g. all address fields for complete correspondence) matters. Recommendation: control the FI-relevant field status through the FI customer/vendor settings and set the BP-side field status to the lowest priority so it does not interfere. FI offers three layers – account group-specific, activity-specific and company code-specific – and the highest priority among them wins; setting activity-specific status to Optional leaves the account group in control. BP and FI settings must not contradict each other.

Field status can also be maintained per BP role (possible but not recommended). Because a BP can have several roles, link rules resolve conflicts. For "same criteria" (several roles on one field) the priority is reversed compared with G/L master data, so that a field required in FI but hidden in SD stays required: 1 Required, 2 Optional, 3 Display, 4 Hide, 5 Not specified (no active decision taken).

One-time accounts

For customers or vendors you deal with rarely, create a one-time master record. It holds receivables/payables for many partners, so partner-specific fields are hidden in the master and the name, address and bank data are entered directly in the document during posting.

Sensitive fields and dual control

Under the dual control principle one person changes critical customer/vendor data and another confirms it. Define the sensitive fields in Customizing; when such a field is changed, the system blocks payments to that account until an authorised user confirms or rejects the change (individually or via a worklist filtered by account, company code, not yet confirmed, rejected, to be confirmed). Reports RFDABL00 (customers) and RFKABL00 (vendors) display master data changes.

Unit 4: Document Control

Lesson 1: Configuring the Header and Line Items of Financial Accounting (FI) Documents

Explain the document principle and the structure of an FI document, and configure the two control keys – document type (header) and posting key (line item) – together with number ranges and field status groups.

Business example

Hundreds of documents are created each day. Internal audit wants all authorised-expense documents to carry a unique document type and come from a separate number range, and the customer wants a mandatory explanatory text on every item posted to the authorised-expense account. You therefore need to know how documents are classified, displayed and structured.

The document principle and structure

1. Every posted business transaction produces a document.
2. The document stays in the system as a complete unit until archived.
3. Each document is uniquely identified by document number + company code + fiscal year.

A document has a header (data valid for the whole document, e.g. posting date, company code, document type) and line items – at least two (debit/credit) and at most 999. Items created by an accounting interface (sales, purchasing) are nearly identical in most fields.

One business transaction can produce several documents: a goods receipt creates a material document for inventory management and an accounting document for FI. Some transactions, e.g. creating a purchase order, create no accounting document because they do not affect accounting. Related documents are linked so the whole transaction can be traced. Document numbers are assigned internally (by the system) or externally (by the user).

Document types

The document type controls the header and classifies business transactions. It is defined at client level (valid for all company codes); SAP delivers types that can be copied or changed. It determines:

For billing transfers with internal numbering FI assigns a new number; with external numbering the billing document number is reused as the accounting document number if free.

Document number ranges

• Ranges must not overlap and are defined per fiscal year of use.
• Internal numbering: the system stores the last number used in Current number and assigns the next one.
• External numbering: user or external system supplies the number; it can be alphanumeric and is not sequential, so no current number is kept.
• Range definition: continuous (numbering continues across fiscal years) or per fiscal year (restarts at the first number each year, so the range never runs out).
• Intervals can be copied between company codes and between fiscal years. Report RFBNUM00 finds gaps in number assignment.

Posting keys

Posting keys are also client-level. They control the line item: debit or credit, the account type that may be posted, the field status of the item, and additionally whether the item is payment-related (needed for payment history and payment notices) and whether it is sales-relevant (updates the account's sales figures, e.g. a customer invoice).

SAP recommends keeping the standard keys; if you change or add keys, every table referencing them must be updated. Asset and material posting keys only work when those components are configured. Because sub-ledger accounts have no field status group, their postings are differentiated by many posting keys; G/L postings are differentiated by field status groups, so only 40 and 50 are needed.

Document field status and field status groups

Which fields appear during entry depends on the transaction and the account: an expense posting needs cost center and tax data, a cash posting does not. Priority rules for document field status: Suppress > Required > Optional. Suppress combined with Required causes an error; tax fields are only enterable on tax-relevant accounts.

1. For each kind of G/L account (cash, expense …) define a field status group that sets every entry field (text, cost center …) to required / optional / suppressed.
2. Assign the group in the G/L account master (company code segment).
3. Collect the groups in a field status variant and assign it to the company code(s); posting is impossible until the variant is complete. Usually all company codes share one variant.

Copy the delivered standard groups and adapt the copies. For postings to sub-ledger accounts, the field status group of the reconciliation account applies. Field status definitions of posting keys and of field status groups can both be changed to make the status transaction- or account-dependent.

Lesson 2: Managing Posting Periods

Open and close posting periods with posting period variants, differentiate by account type and account interval, use the three period intervals and the related authorisations, and understand how the posting period is derived.

Business example

Sub-ledgers are closed at period end, but G/L accounts stay open longer to reconcile FI and CO for the last period – so periods must be controlled per account type.

Posting period variant

• Periods themselves come from the fiscal year variant; the posting period variant says which are open. Usually only the current period is open; at period end it is closed and the next opened, by entering a range that includes the period. Any number of periods can be open; special periods are opened for closing postings.
• Several company codes can share a variant, so their periods open and close together (variant principle).

Period checks by account type

• Account type + (all accounts) is checked first at header level and is mandatory in the table; it must be open for every period that any other account type should have open. If all account types are treated alike, the + line is sufficient.
• Account types A, D, K, M, S can be controlled separately (e.g. customers open, vendors closed). At item level the system checks the account type of the posting key.
• The account interval always holds G/L account numbers; for sub-ledger types you enter reconciliation accounts, so customers/vendors with different reconciliation accounts can be treated differently.

The three period intervals

During year-end closing two intervals must be open at the same time (last period and special period), hence intervals 1 and 2. CO-relevant FI postings and FI-relevant CO postings need both the FI period open (OB52 / app) and the CO period lock (OKP1, where you lock specific transactions per period; menu Accounting → Controlling → Cost Element Accounting → Environment → Period Lock). Report RFOB5200 can also maintain posting periods (authorisation per SAP Note 2251160). Since S/4HANA 1809 the Fiori app Manage Posting Periods writes the same table as OB52.

Determination of the posting period

The user enters a posting date; the system derives posting period and fiscal year from it and updates the transaction figures of that period, which are what account balance displays show per period.

Lesson 3: Managing Posting Authorizations

Limit the amounts and discounts employees may post by defining tolerance groups and assigning users to them.

The accounting manager wants different posting limits for different clerks. In Customizing, Define Tolerance Groups for Employees sets upper limits per group and company code:

You can define as many groups as needed and assign users explicitly. Users without an assignment fall under the blank tolerance group, which should exist in every company code and holds values suited to most employees; special groups with higher or lower limits are created for exceptions and attached to those users' IDs.

Lesson 4: Creating Simple Documents in FI

Post simple G/L, customer and vendor documents with the Fiori apps and know the entry aids: default document types, screen and account assignment templates, held/parked documents, item texts and journal entry templates.

Simple postings

Fiori apps exist for G/L account postings, customer invoices and credit memos, and vendor invoices and credit memos. In Create Incoming Invoices the header holds invoice date, posting date and text. A default document type per transaction can be configured (it can be overwritten if the field is ready for input); without configuration the standard type is proposed, e.g. KR for vendor invoices. The basic-data tab shows the frequently used fields, other tabs the rarer ones. After entering the account and amount and pressing Enter, the partner's name, address and bank data appear; an Open Items button lists open items, and an information area shows the account balance. A Tree button offers screen variants, account assignment templates and held documents. Further items are entered in the lower table, where columns can be resized, reordered and items copied. The document can be parked, posted or held.

Post General Journal Entries

• The general posting transaction remains available.
• Each item can carry an explanatory text. Prefixing it with * makes it external – printed on correspondence, dunning notices and payment advices (the asterisk itself is dropped on printout).
• Text templates with a four-character key can be defined in Customizing; entering the key in the text field copies the template into the item.
• Templates can be chosen at the bottom of the screen; the Manage Journal Entry Templates app lets you save the fields and values you need for recurring entries and optionally share templates publicly within the organisation.

A document with zero balance can be posted normally.

Unit 5: Posting Control

Lesson 1: Analyzing Document Splitting

Understand why document splitting exists, the difference between entry view and general ledger view, passive vs active split and zero-balance clearing lines, and how the splitting procedure is built and activated.

Business example

You want complete balance sheets at segment level. Document splitting ensures objects below the company code (profit center, segment, business area) balance to zero in every document.

Two views of every document

Each FI document has an entry view (as the user entered it) and a general ledger view (as stored per ledger). Both views always exist and cannot be switched off. Without document splitting the two views are identical; with splitting, the G/L view shows the items split by the splitting characteristics while the entry view does not.

What splitting does

Document splitting ("online split") transfers the splitting characteristics (profit center, segment, business area) to line items that did not carry them, following Customizing rules, so each characteristic balances within the document. Example from the course: a vendor invoice with two expense items (account 65003000) on different profit centers/segments – the vendor item and the tax item are split in the G/L view in proportion to the expense items. Splitting is only for customers that need an additional balance sheet characteristic beyond the company code.

Three steps of the splitting process

Customizing

• Splitting is activated per client and can be deactivated per company code; all company codes in a client must use the same splitting procedure. SAP delivers procedure 0000000012 – copy it (e.g. Z000000012) before changing anything.
• Inheritance: if an account assignment is unique in the document, it is passed online to every item lacking it. Always switch this on.
• Default account assignment: a constant (e.g. a default profit center or segment) fills any characteristic that is neither entered nor derived. This lowers data quality because wrong rules are hidden behind the constant – test without defaults first to find errors.

Terminology of the active split

The document type determines the business transaction (variant) and so the rule applied.

Lesson 2: Maintaining Default Values

Know the user-level and system-level default values that reduce repetitive entry and prevent input errors.

User defaults

• Parameter IDs store default values for rarely changing fields (company code, currency) in the user profile; the value appears automatically in transactions.
• Editing options customise areas such as document entry, document display, open items, line items and cash journal.
• User-specific properties include logon language, date format, decimal notation and default printer.
• To simplify administration: create a dummy user with the accounting department's settings, then copy it for new users.

System and accounting defaults

• The current date is proposed as posting date (changeable); the company code of the last document is proposed for the next one.
• Every document must balance to zero before posting (document principle).
• Document types and posting keys are proposed per transaction – e.g. vendor invoice KR with credit posting key 31.
• Per company code you can decide whether the fiscal year is proposed when displaying/changing documents (with year-specific numbering, the last document number and its fiscal year are proposed) and whether the CPU date is proposed as value date.
• A maximum percentage deviation between the exchange rate in the document header and the rate in the exchange rate table can be set per company code; exceeding it triggers a warning to catch entry errors.

Lesson 3: Configuring Change Control

Define which document fields may be changed after posting, under which conditions, and how changes are logged and analysed.

Users may change posted documents, but only certain fields: in the header the reference number and header text; in line items fields such as assignment, text and payment terms. Amount, posting key, account and anything else affecting reconciliation can never be changed. Every change is logged with field, old and new value, user, date and time.

Document change rules

Rules are differentiated by account type (customer, vendor, G/L), transaction class (only for special G/L transactions such as bills of exchange and down payments) and company code (blank = all company codes). A field is changeable only if the posting period is open, the item is not cleared, the item is a customer debit or vendor credit, and the document is not an invoice-related or down-payment credit memo.

Report RFBABL00 lists document changes, selectable by company code, document number, fiscal year, change date and user.

Lesson 4: Configuring Document Reversal

Reverse wrongly posted documents with normal reversal or negative posting and configure reversal reasons.

Incorrect documents are not edited but reversed and re-posted, so the correction is documented. G/L, customer and vendor documents can be reversed individually or in mass with the same function. A reversal reason is mandatory; its configuration decides whether the reversal date may differ from the original posting date and whether negative posting is allowed. Documents with cleared items cannot be reversed – reset the clearing first.

Prerequisites for negative postings: the company code permits them and the reversal reason allows them. Negative postings can also correct a wrong account assignment: remove the item from the wrong account with a negative posting and post it normally to the right one – requires a document type that explicitly permits negative postings.

Lesson 5: Configuring Payment Terms and Cash Discounts

Define terms of payment (baseline date, day limits, cash discount periods, instalments, payment controls) and set up automatic cash discount posting in the gross and net procedures.

Terms of payment basics

Terms of payment are the conditions agreed with a business partner: they determine the due date and the cash discount for early payment. The system needs the baseline date, the discount terms (days) and the discount percentage. Standard terms are delivered and new ones can be added. Terms stored in the business partner master are proposed in documents and may be overwritten.

On vendor invoices a fixed cash discount amount or fixed percentage can be entered in the Cash Discount field, independent of the payment date.

Credit memos

• Invoice-related: enter the invoice number in Invoice Reference; the terms are copied and both documents fall due together.
• Other credit memos: payment terms are ignored and the memo is due on the baseline date – unless you enter V in the Invoice Reference field, which activates the terms. The customer master has a separate Credit Memo Payment Term field (shown if the field status allows) whose value is proposed for credit memos.

Structure of a payment term key

Block key and payment method can be set during posting, in the BP company code segment, or in the payment term; the term's values are defaulted into the line item.

Instalment payments

Select Instalment payment in the term (no discount periods) and define per instalment a number, a percentage and its own payment term; percentages must total 100 %. When an invoice is posted with this term, the system creates one line item per instalment with the corresponding amount and term. A portion can also be retained for later payment.

Cash discount base and posting

• Depending on country law the discount base is the net value (G/L and asset items without tax) or the gross value (tax included, e.g. Germany, Switzerland); set per company code or highest tax jurisdiction level in the global parameters.
• Gross procedure: the invoice is posted gross; when the open item is cleared, the discount taken is posted automatically to the cash discount expense (vendors) or cash discount received/revenue account defined in account determination. Discounts can be entered manually or taken from the terms, and changed after posting.
• Net procedure (vendors only, via a net document type): at invoice entry the expense or balance sheet account is reduced by the expected discount and the same amount goes to a cash discount clearing account (must be OIM-managed). On payment the clearing account is cleared; if paid after the deadline the lost discount is posted to a separate account.

Lesson 6: Maintaining Taxes and Tax Codes

Understand how S/4HANA calculates, checks and posts taxes through tax calculation procedures, tax codes and automatic account determination.

Tax systems and levels

Supported: taxes on sales and purchases (VAT), US sales tax, country-specific additional taxes, and withholding tax. Taxes can be national with uniform rates, or state/jurisdiction based (e.g. more than 67,000 US jurisdictions – external tax software is often attached through SAP's generic interface). Some countries (Canada, India, Brazil) tax on both levels.

The system checks or calculates the tax, posts it to tax accounts, and adjusts tax for cash discounts and other deductions. The tax base can be gross (including discount) or net (discount deducted), defined per company code or highest jurisdiction level.

Tax calculation procedure

One preconfigured procedure per country, consisting of: the sequence of steps (each step may reference a "from" step as its base), the tax types / condition types relevant to the country, and the account key (transaction key) used for automatic account determination – use the standard keys.

Tax codes

• Entered in the document, the tax code links the item to the calculation. It is defined per country key, or per country + tax jurisdiction code; jurisdiction tax codes are date-dependent (document date or posting date, as configured).
• The tax code holds the rates per tax type. Normally one rate; several when an item is taxed by several types – e.g. 10 % input tax of which 40 % is non-deductible = 6 % deductible + 4 % non-deductible.
• Zero-rate codes are needed for tax-exempt items that must still be reported and for exempt transactions such as goods movements.
• The tax type decides whether the base is "percentage included" or "percentage separate".
• Check indicator: set → error if entered tax differs from calculated; not set → warning. It is left off for input tax codes because the amount on the vendor's invoice must be posted as is.

Tax postings and account determination

• Standard: calculated tax goes to a separate tax line on a tax account. Alternatively, with account keys such as NVV, the tax is distributed to the expense/revenue items (sales tax payables, non-deductible input tax).
• For each account/transaction key you assign the tax accounts, posting keys (40/50 recommended) and the rules (e.g. whether determination depends on tax code or account key).
• Exchange rate differences from tax adjustments in foreign currency normally go to the usual exchange-rate-difference account; per company code you can allow a manual tax exchange rate or use the posting/document date rate, with resulting differences to a special account.

Tax category in the G/L account master

Tax accounts can be set to Post automatically only to prevent manual postings. Posting without tax allowed lets you post to a tax-relevant account without a code, needed for jurisdiction procedures with foreign customers lacking a jurisdiction code. Cash discount accounts need a tax category so that tax adjustments can be posted.

Lesson 7: Posting Cross-Company Code Transactions

Configure clearing accounts and post transactions that involve several company codes, understanding how the documents are linked and how tax is handled.

Concept

A cross-company code transaction touches two or more company codes – central procurement (one company code buys for others), central payment (one pays for others), or intercompany sales. Because a document belongs to exactly one company code, the system creates one document per company code and inserts automatically generated items on clearing accounts (receivable/payable between the company codes) so that each document balances. All documents share a cross-company code transaction number = first document number + first company code + fiscal year, stored in every header for the audit trail. Report RFBVOR00 displays cross-company transactions; reversal uses the dedicated cross-company reversal function.

Central procurement example

A vendor delivers different goods to company codes 1000 and 2000 but sends one invoice to 1000. The user posts the vendor item and part of the expense in 1000 and the rest of the expense in 2000; the system adds the clearing items and tax. The tax is posted entirely to the company code of the first item, so enter the invoice item first and use this only when the transaction is not tax relevant or the company codes form one taxable entity. Where law requires tax in the company code of the expense (e.g. Japan, Denmark), redistribute it with report RFBUST10.

Clearing accounts

• Every company code needs clearing accounts; they can be G/L, customer or vendor accounts and must be assigned with posting keys that identify the account type.
• Clearing accounts are defined for every pair of company codes between which postings should be possible – three company codes need 3 × 2 = 6 assignments.

Unit 6: Financial Document Clearing

Lesson 1: Performing Open Item Clearing

Post with clearing, clear an account, run the automatic clearing program, process manual incoming and outgoing payments, use the assignment field for sorting, and reset clearing.

Open items and clearing

An open item (e.g. an unpaid invoice) is an incomplete transaction. It is completed by a clearing posting that brings a group of items to a zero balance; the items are then marked cleared. Documents with open items cannot be archived. Every clearing transaction creates a clearing document. Example: an invoice is posted on a customer account (open) → the customer pays and the payment is assigned to the invoice → both are cleared and the balance is zero. Manual clearing is typical for bank sub-accounts and clearing accounts, agreed debit memo procedures, and vendor refunds.

Two clearing functions

Each cleared item stores the clearing document number and the clearing date (current date or user-defined).

Automatic clearing program

Clears G/L and sub-ledger accounts that are flagged for automatic clearing in Customizing. It groups items with identical company code, account type, account number, reconciliation account, currency and special G/L indicator, plus up to five user-defined criteria from header or item (e.g. assignment, reference). If a group balances to zero in local currency it is cleared and a clearing document created. It does not clear noted items, statistical postings and certain bill-of-exchange special G/L transactions, down payments (unless matching down-payment clearing items exist), or items with withholding tax.

Assignment field and sort key

• The sort key in the master record (G/L account or business partner) tells the system how to fill the Assignment field automatically when posting – e.g. purchase order number for a vendor, cost center for a G/L account, or document number + posting date.
• The assignment field can combine up to four fields with a maximum of 18 characters.
• Line item display and clearing can be sorted by assignment. SD billing documents pass their reference and assignment (configurable: PO, order, delivery or billing number) to the FI document, so the FI document can be traced back and selected by these fields.

Manual payment process

A manual payment clears open items with a manually assigned clearing document: incoming payments (AR) clear debits, outgoing payments (AP) clear credits. Steps: enter the header, select the open items, save.

In the Process open items screen all unassigned items (payments, memos, invoices) are listed. Cash discount is proposed from the item's payment terms and included in the assigned amount; it can be overwritten as an amount or percentage within the tolerance limits. The document can be posted when Amount entered equals Assigned. Use Document → Simulate to see all items including the automatic ones (tax adjustments, bank charges, exchange rate differences). If an error is found later: reset the clearing, reverse, and re-post.

For manual cross-company payments, assign a clearing transaction (incoming or outgoing payment) to the pair paying company code / company code being paid for; the open items of both company codes are then offered for selection.

Reset clearing

Clearing can be reset per document, removing the clearing data from the items (since 1709 also via the Reset Cleared Items app). The reset is logged in change documents, and in AR the payment history and credit limit are corrected.

Lesson 2: Managing Payment Differences

Configure the three kinds of tolerance groups and process payment differences automatically (within tolerance) or manually (partial payment, residual item, difference posting with reason codes, write-off).

Three tolerance groups

Permitted payment differences

Both the employee and the business partner tolerance groups define limits for automatic cash discount adjustment and for unauthorised deductions; a difference must be inside both to be handled automatically, i.e. the lower limit applies. Course example: a difference below 3.00 (one group) and 2.00 (other group) is written off as a cash discount adjustment; a difference below 200/100 currency units and below 2.5 %/2.0 % of the open amount is posted as unauthorised deduction – for an open amount of 1,000 the effective limit is 20, for 100,000 it is 100. Tolerance amounts are always in local currency.

At clearing the system compares the difference with the tolerances: within tolerance → automatic posting as cash discount adjustment or unauthorised deduction (special account); outside → manual processing. The employee group also defines the maximum cash discount percentage the employee can grant, so adjusting the discount stays within authorisation. Different groups are assigned to users via Assign users to tolerance group.

Manual processing options

The business partner tolerance group controls residual items: whether they inherit the payment terms of the cleared item or get fixed terms, whether cash discount is granted only partially, and the maximum dunning level or a dunning key for separate printing.

Reason codes

Reason codes describe why a difference arose and can be attached to difference postings, partial payments and residual items (several codes via Distribute Difference). They support analysis and follow-up, and optionally control the type of payment notice sent to the customer, the account to which a residual item or difference is posted automatically, and whether disputed residual items are excluded from the credit limit check.

Lesson 3: Managing Exchange Rate Differences

Understand when realised exchange rate differences arise during clearing and how the gain/loss accounts are determined.

When open items in foreign currency are cleared, the rate at payment usually differs from the rate at posting; the resulting realised gain or loss is posted automatically to the revenue/expense accounts defined in Customizing and stored in the cleared item. Exchange rate differences also arise when open items are valuated for the financial statements: the unrealised gain/loss is posted to a separate P&L account with the offset on a balance sheet adjustment account. When an already valuated item is later cleared, the valuation correction is reversed and the remaining difference goes to the realised-difference account.

Account determination

Every reconciliation account and every G/L account with open items in foreign currency must have realised loss and gain accounts assigned. The assignment can be made for all currencies and currency types, per currency and currency type, per currency, or per currency type.