TFIN50 Part 2 – Financial Accounting I (ECC)

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: Automatic Payments

Lesson 1: Executing an Automatic Payment Run

Get a bird's-eye view of what the automatic payment program does and the six processing steps every payment run passes through.

Why a payment program?

Paying invoices one by one is not feasible for a company with thousands of payables. The SAP payment program is a mass-processing tool that runs at intervals the accounting department chooses, picks the open items that are due, posts the payment documents and produces the payment media (printed forms, Data Medium Exchange files, or EDI messages). It covers domestic and international payments, works for vendors and customers (so both outgoing and incoming payments), and is designed so that country-specific features such as payment methods, forms and data-carrier formats can be configured rather than programmed.

The business cycle around the program

1. Invoices are entered (manually in FI or via MM/SD).
2. Open items are analyzed for due dates.
3. Items due for payment are prepared for review.
4. Proposed payments are approved or rejected.
5. The approved invoices are paid.

The six processing steps of the payment program

Keep this sequence in mind: all later lessons of this unit are simply a deep-dive into one of these steps or into the master data and Customizing that feed them.

Lesson 2: Using Bank Accounts

Learn how banks are represented in SAP: the central bank directory, the company's own house banks and their accounts, and the bank details held in customer and vendor master records.

The bank directory

Every bank that appears anywhere in the system has one bank master record in the central bank directory (table BNKA). The record is identified by the combination bank country + bank key; it carries address data, control data such as the SWIFT BIC, postal giro data and a bank group. The bank group is what lets the payment program optimise payments (pay from a house bank in the same clearing network as the partner's bank). Useful reports:

Bank master data can be created in several ways: directly in the bank directory, on the fly from a customer/vendor master record (Bank Data pushbutton), in house-bank Customizing, by file import (RFBVALL_0), or via batch input from the lockbox procedure that updates customer bank details.

House banks

A house bank is a bank the company itself holds accounts with. It is defined per company code with a house bank ID and points to a bank master record. It also stores information needed for electronic payments: DME details, EDI partner profiles, and the list of bank accounts held there. The payment program uses the house bank ID to decide which bank actually pays.

House bank accounts and G/L accounts

Each account at a house bank is identified by house bank ID + account ID. The account record stores the bank account number (and IBAN), the account currency and the G/L account that represents it in the general ledger. The link works in both directions: the house bank account refers to the G/L account, and the G/L account master (tab Create/bank/interest, FS00) refers back to house bank and account ID. Both must carry the same currency. One G/L account per bank account is mandatory.

Customer and vendor bank details

In the Payment Transactions view of a customer or vendor master you enter bank country and bank key; because the bank must exist in the directory, the system fills in name and address automatically. If it does not exist yet you can create it from there. These bank details are what the payment program uses as the partner bank when it transfers money or collects it.

Configuration summary

Lesson 3: Modifying Master Records and Financial Accounting Documents

Identify the fields in vendor/customer master records and in FI documents that the payment program evaluates, and understand the special relationships between master records (customer=vendor, alternative payer/payee, head office/branch).

Vendor master fields relevant to payments

Customer masters carry the same fields. In addition, for direct debit the customer needs bank details, the collection payment method (standard method E), the collection authorization indicator and, for SEPA direct debit, a signed SEPA mandate. When a partner has several banks, the BnkT (partner bank type / bank category) field distinguishes them, and the partner bank can be chosen from the input help when an invoice is entered.

Customer = vendor (clearing between accounts)

If the same business partner is both customer and vendor, the payment and dunning programs can net the two accounts. Three settings are required:

1. Enter the customer number in the Customer field of the vendor master (control section, general data).
2. Enter the vendor number in the Vendor field of the customer master.
3. Set Clearing with vendor / Clearing with customer in the company code data of both masters — so each company code decides for itself.

With this link you can also see customer line items while displaying the vendor account. Report RFDKVZ00 / RFKKVZ00 (customer/vendor list) with "Account Control and Status" under further selections shows these partner relationships.

Alternative payer / payee

A customer may let someone else pay its invoices; a vendor may want payment sent to a third party (e.g. a bankruptcy administrator). The alternative payer/payee can be set at client level and at company code level; the company code entry wins. Two variants exist:

• Individual specifications indicator: during invoice entry you type the details of a one-time payer/payee that does not exist as a master record.
• Permitted payer/payee: list existing customer/vendor numbers in the master; at invoice entry pick one via input help.

Effect: with an alternative payer, the item is cleared on the original customer but the money is collected from the alternative payer; with an alternative payee, the liability is cleared on the vendor but the payment goes to the payee. RFDKVZ00/RFKKVZ00 with "Payment Data" selected lists these assignments.

Head office / branch

Some customers order through branches but pay centrally. In SAP each branch account is linked to a head office account; every posting to the branch is automatically carried in the head office account as well, and payment/dunning normally address the head office. If Decentralized Processing is set in the head office master, the payment and dunning programs work with the branch account instead. The customer/vendor list shows the head office for each branch.

FI document fields relevant to payments

Lesson 4: Implementing SEPA

Understand what the Single Euro Payments Area changed for businesses, how SEPA Credit Transfer and SEPA Direct Debit work, what a mandate is, and which SAP ERP settings are affected.

What SEPA brought

SEPA harmonised euro payments across the participating European countries so that one domestic account can be used for all euro credit transfers and direct debits in the region. The course lists benefits for consumers (one account for everything), SMEs and corporations (one standard file format and platform, faster settlement, lower cost), merchants (debit cards accepted everywhere), governments (common schemes, e-government) and banks and payment-service suppliers (new products and more efficient back offices).

Requirements for businesses

• Uniform rules for all euro credit transfers and direct debits.
• The IBAN is the only account identifier; the BIC was additionally needed for cross-border payments only until 1 February 2016.
• Banks that accept national equivalents may not refuse SCT/SDD transactions; payers and payees cannot be forced to use an account in a specific country.
• Additional debtor protection for direct debits: block collections, white/black lists of creditors, maximum amounts, intervals.
• Equal charges for comparable domestic and cross-border euro payments.
• ISO 20022 XML is the mandatory message standard between banks and for bulk submission by businesses (micro-enterprises exempt).
• Multilateral interchange fees for direct debits were abolished (cross-border first, national by 1 February 2017).

SEPA Credit Transfer (SCT)

An SCT moves euro from a payer's account to a payee's account anywhere in SEPA. The scheme is a set of interbank rules for mass, non-urgent payments; the interbank leg is always fully electronic, and only a minimum set of data elements is required from the payer. Flow: (1) payer submits the transfer order to its bank; (2) the payer bank validates the instruction (authenticity, BIC/IBAN plausibility), debits the payer and sends the credit transfer instruction through a Clearing and Settlement Mechanism; (3) the payee bank credits the payee and informs it as agreed.

SEPA Direct Debit (SDD)

An SDD is a collection initiated by the creditor through the creditor bank against the debtor's account, both within SEPA. The legal basis is the mandate, the debtor's authorization to both the creditor and the debtor bank. Rules worth remembering:

• Pre-notification to the debtor at least 14 calendar days before the due date unless a shorter period is agreed; recurring debits of equal amount need only one notification listing all due dates.
• Full straight-through processing, including exceptions (rejects, returns, reversals, refunds, refusals, revocations).
• Mandate data between banks is electronic only; between creditor and debtor it may be paper or electronic.

The mandate document

The mandate form has fixed field identifiers in a language of the debtor's country (plus English if uncertain). SAP mandate management fills most fields from the customer and company code master data; the mandate reference comes from a mandate number range; the Type of payment says whether the mandate is one-off or recurring.

SEPA in SAP ERP: three work areas

1. Update master data – maintain IBANs in customer, vendor and house bank data. SAP can usually generate the IBAN from country, bank key and account number, but there are national exceptions.
2. Adapt payment media – produce ISO 20022 XML files for SCT and SDD with the Payment Medium Workbench (the XML formats replace the classic RFFO* programs; SAP follows the Common Global Implementation initiative). Alternatively outsource file generation via B2B interfaces. Required Customizing: house bank data in FI12/FBZP, payment method in country adapted to the SEPA format, company code settings and bank determination.
3. Activate mandate management – either centrally in SAP (explicit activation in SPRO; creditor identifiers and mandates stored in SAP, integrated with FI-AR and FI-CA) or outsourced to an external platform via BAPIs. SAP Note 1686264 describes prerequisites for SEPA bank statement processing; EhP 6 added automated import and post-processing.

Lesson 5: Configuring the Payment Program

Learn the structure of payment program Customizing (FBZP) and the settings for all company codes, paying company codes, payment methods per country and payment methods per company code.

Structure of the configuration

Payment program Customizing is reached from the application (F110 → Environment → Maintain config.) or directly with FBZP. The entry screen has one pushbutton per area; work from top to bottom to be sure nothing is missed:

1. All company codes
2. Paying company codes
3. Payment methods in country
4. Payment methods in company code
5. Bank determination (bank selection – Lesson 6)
6. House banks (FI12)

The first three areas usually need little work because SAP delivers many payment methods and forms per country.

All company codes

Paying company codes

• Minimum amounts for incoming and outgoing payments – smaller payments are not made.
• Forms (SAPscript or PDF) for the payment advice and EDI accompanying sheet; company-code-dependent sender texts on the Sender screen.
• Bill of exchange specifications: how many bills per account, and due-date rules for selecting items for the bill of exchange payment method.

Payment methods in country

For each country you define the valid payment methods (check, bank transfer, SEPA credit transfer, direct debit, bill of exchange …). Each method specifies:

Payment methods in company code

These settings may differ from company code to company code for the same method.

Selection variants for PMW formats

For Payment Medium Workbench formats you also assign a selection variant of the generic payment medium program to each payment group (e.g. company code + house bank). IMG: Financial Accounting (New) → AR/AP → Business Transactions → Outgoing Payments → Automatic Outgoing Payments → Payment Media → Make Settings for Payment Medium Formats from PMW → Create/Assign Selection Variants, transaction OBPM4.

Lesson 6: Configuring the Bank Selection

Configure bank determination: how the payment program decides which house bank and account pays, how much is available, which value date applies and how bank charges are handled.

The five folders of bank determination

Bank determination is maintained per paying company code in FBZP and consists of five folders that must all be completed:

Ranking order

For each payment method you list the house banks in the order the program should consider them. A new entry needs payment method, optional currency, rank number and house bank ID. The program takes the highest-ranked bank that still has sufficient available funds and meets the other criteria (optimisation, currency).

Amounts and accounts

For every house bank / payment method combination you name the G/L subaccount that is posted when the payment is made (the counterpart to the subledger clearing). The subaccount can be a true cash account or a clearing account; with a clearing account the cashed-checks program later moves the amount from the subaccount to the bank account once the check clears. The Available Amounts screen holds the planned liquidity per bank account; the "days" entry (e.g. 999) corresponds to the value-date days.

Value date

Value date = payment run posting date + days until value date. Cash management uses it to know when money actually leaves. Example: bank transfers are debited the next day, so enter 1 day for that method; checks take longer. The days configured here should match those used for available amounts, and may depend on an amount limit.

Expenses and charges

Incoming and outgoing payment functions have a bank-charges field. For incoming payments the charge is subtracted from the clearing amount, for outgoing payments it is added. The charge is posted to an expense account via a posting key and account assignment delivered in the standard charts of accounts; with your own chart you must enter the accounts. The accounts need the Relevant to cash flow indicator.

Lesson 7: Running the Payment Program

Walk through the operational steps in F110: entering parameters, scheduling the proposal, reading the proposal and exception lists, handling payment blocks, running the debit balance check and editing the proposal.

Parameters

A payment run is identified by run date + identification (the identification distinguishes several runs on one day). On the Parameter tab you define:

Proposal run

1. Items are selected according to the parameters and the due-date rule (considering tolerance days): the discount period has expired, a lower discount tier would apply by the next run, or the net due date has passed.
2. Items are grouped into payments; payment method and bank details are assigned.
3. Items for which no valid method or bank can be found go to the exception list.
4. Proposal list and exception list are produced for online review or printing.

The proposal list shows partners and amounts (and, depending on the layout, document numbers and discounts); you can drill down to individual items. The exception list shows items that matched the parameters but cannot be paid; the additional log explains why.

Payment blocks

You can define further block reasons and decide for each whether it may be changed in the payment proposal.

Debit balance check

Without this check the program may pay a vendor whose account has a debit balance. Course example: vendor has an invoice of 98 with payment method in the line and a credit memo of 100 without any incoming payment method. The credit memo lands in the exception list, the 98 gets paid. Running the debit balance check (report RFF110SSP, Edit → Proposal → Debit Balance Check) after the proposal offsets all due debit items without incoming method against the proposed payments; if the resulting balance is below the minimum payment amount the account is put on a blocked-accounts list and its payments move to the exception list. The block holds for the subsequent payment run with the same identification; it is lifted by creating a new proposal or releasing the account manually.

Editing the proposal

The proposal can be filtered by accounting clerk (clerk key maintained in the master). The first screen lists all proposed payments; double-clicking a payment lets you see its open items, change payment block and cash discount per item, move an item to another existing payment, or create a new payment with a different method and house bank. The edited proposal is the basis for the payment run.

Lesson 8: Executing a Payment Run

Execute the actual payment run, understand the resulting postings and bank subaccounts, and learn how payment media are produced with classic print programs and the Payment Medium Workbench.

The payment run

Until now nothing has been posted; the proposal only locked the selected items against manual payment or other runs. The payment run takes the edited proposal and:

• posts the payment documents and clears the paid open items;
• posts related items – taxes, cash discounts, exchange rate differences;
• marks payments that can be sent by EDI;
• supplies the print programs with the data they need.

Some countries forbid posting a payment before it is settled. For such methods set Generate payment order only: the run produces a payment order, the items stay blocked, and the payment document is created later when the bank statement shows the payment.

Bank subaccounts

Payments are not posted directly to the main bank G/L account but to subaccounts such as "outgoing transfers", "outgoing checks", "incoming checks". Advantages: the main bank account can be reconciled with the bank statement at any time, and the subaccounts show money in transit until the value date, when the bank statement (manual or electronic) moves the item to the bank account. Subaccounts are assigned in bank determination per house bank, method and currency and are usually managed on an open-item basis.

The payment document

• Document type comes from the payment method (country level); cross-company payments need a second document type for clearing postings; both use internal numbering.
• The header text contains run date and identification (e.g. 20120630-AC##).
• Value date = posting date + days until value date (from bank determination, depending on method, account, currency, amount limit). For checks a check-cashing time in the master overrides this.
• Business area: the bank posting takes the business area of the paid items if payments are made per business area; otherwise a default business area can be given, or none.

Payment media and the print run

The print run (Printout / Create Payment Medium) starts the print programs, which hand payment forms, advice notes and the payment summary to spool administration, pass DME data to DME administration, and create IDocs for EDI payments. Two generations of media programs coexist:

PMW process

1. SAPFPAYM_SCHEDULE performs the preservice: sorts payments by format and format-specific fields, builds payment groups according to the format's granularity (e.g. one group per company code + house bank → one file each), generates the note to payee.
2. SAPFPAYM creates the payment media, accompanying sheets, error log and payment summary; at least one selection variant is needed per payment group.
3. RFFOAVIS_FPAYM creates advice notes and zero-balance notices.

Granularity of SAP-delivered formats can be refined but not reduced, because it reflects bank requirements. Format mapping (filling the file fields from SAP data) is done either by programmed function modules or declaratively in the DME Engine, which lets you build bank-specific file formats without coding.

Note to payee

Each PMW payment method has a PMW format and a content template for the note to payee. Every format offers three reference text types: type 1 invoice information (the classic note), type 2 internal reference (for returned media), type 3 external reference for the partner. The template is format-independent, maintained in Customizing (language-specific) or via function module, and feeds the reference fields when the medium is created.

Lesson 9: Automating a Payment Run

Schedule the whole payment cycle – proposal, debit balance check, payment run and media – to run periodically in the background without manual intervention.

Program RFF110S

Manual operation of F110 is fine for a weekly run, but the cycle can be fully automated with report RFF110S, which schedules the payment program SAPF110S in the background. Its selection screen mirrors the F110 parameters; you fill it once, save it as a variant and schedule the variant as a periodic job. Because the run date, posting date and next payment date must move with each run, use selection variables (dynamic date calculation) in the variant. RFF110S can trigger up to four further programs in sequence.

Automated sequence

1. RFF110S is scheduled as a proposal run so that debit balances can be caught.
2. It automatically calls RFF110SSP, the debit balance check.
3. It calls RFF110S again, this time as the update (payment) run, optionally creating the payment media.

Unit 2: The Dunning Program

Lesson 1: Executing the Dunning Program

Get an overview of what dunning is for and the four steps of the SAP dunning process.

Purpose

When a customer does not pay by the net due date, the company sends a reminder. The first one is typically friendly; later ones become firmer. SAP's dunning program automates this: it selects overdue open items on customer (and vendor) accounts whose overdue items produce a debit balance, determines the dunning level of the account and generates the dunning notice. Vendors can be dunned too — for example when a credit memo leaves the vendor account with a debit balance. If a business partner is both customer and vendor, the two balances can be offset against each other before dunning (see Unit 1, Lesson 3 for the master-data link).

The four steps

1. Maintain parameters – tell the program which company codes, accounts and documents to look at; parameters from an earlier run can be copied and the dates adjusted.
2. Schedule the dunning run – the program determines the accounts and items to dun, the dunning level and all other data, and saves everything in a dunning proposal.
3. Change the dunning proposal – the clerk reviews it; the proposal can be edited, deleted and regenerated as often as needed.
4. Start the dunning printout – the notices are printed (or e-mailed) and, in the same step, the dunning data (date and level) is written into the master records and the dunned documents.

It is also possible to print directly after the run without touching the proposal, if no review is required.

Lesson 2: Updating Master Records and Financial Accounting Documents

Know which fields in the customer/vendor master and in the FI document control whether and how an item is dunned.

Master record fields

Dunning data sits mainly on the Correspondence tab of the company code data, with a few general-data fields also relevant:

Document fields

Besides the master data, the following fields can be maintained on the individual line item and override or refine the account-level data: dunning area, dunning key (restricts the maximum level or separates the item on the notice), dunning block (blocks only this item), and payment terms (determine due date). These are changed via line item display (FBL5N → double-click → change mode) or document change (FB02).

Lesson 3: Configuring the Dunning Program

Learn the structure of dunning Customizing (FBMP, reached from F150 → Environment → Change configuration) and every setting of a dunning procedure, plus the environment settings that apply across procedures.

Configuration structure

The dunning configuration screen shows one icon per category; work through them left to right. SAP delivers standard procedures (e.g. 0001) with forms, so in practice you copy a procedure and adapt it, then adjust company-code-specific settings.

Dunning procedure header

Dunning levels

Dunning charges

Charges are defined per procedure, currency and dunning level, as a fixed amount or a percentage of the dunned amount, optionally from a minimum dunned amount upwards and with a minimum charge. They are printed on the form through text variables (they are not posted automatically).

Minimum amounts

To stop trivial amounts from triggering a harsh dunning level, each level has a minimum amount and/or minimum percentage of total open items, plus a minimum amount for interest. If a level's items do not reach the threshold they are pushed down to the next lower level and the check is repeated there.

Dunning texts

For each procedure, company code and account type you assign the form to use per dunning level. Forms may be SAPscript, Smart Forms or Adobe PDF forms (course BC460 and SAP Note 526824 are referenced for form design). The program can also produce payment advice notes and payment forms.

Environment settings

Lesson 4: Running the Dunning Program

Run the dunning program in F150: set parameters, understand in detail how the run selects accounts and items and assigns dunning levels, edit the proposal, and print the notices.

Parameters

A dunning run is identified by run date (need not be the execution date, but recommended) and identification. Parameters can be copied from an earlier run. On the Parameter tab you set the dunning date, documents posted up to, company codes and optional account ranges; the Additional Log tab enables a detailed log for selected accounts — use it only for testing because it consumes resources.

The three steps of the dunning run

1. Account selection – an account is considered only if it has a dunning procedure in the master and its last dunning date is older than the dunning interval allows.
2. Dun line items – for every open item of the selected accounts the program checks whether it is overdue (after grace days) and which level it reaches.
3. Dun account – the program decides whether the account must be dunned at all and at which level.

Due dates

Clearing with credit memos and vendor items

Due credit items are offset against the due debit items with the highest dunning level. With "clearing between customer and vendor" active (and the same dunning procedure on both accounts), due vendor credits are offset as well. After this netting the account must still show a debit balance to be dunned, unless the procedure allows dunning with a positive balance. The notice lists the credit items used for netting.

Due date vs. dunning date; grace periods

The due date is when payment was owed; the dunning date is when the reminder is issued. Every dunned item is overdue, but not every overdue item is dunned: items still within the line item grace period are skipped.

Reasons an overdue item is not dunned

• The account is outside the run parameters, or has no dunning procedure, or the interval has not elapsed.
• The item is within the grace period.
• The item or account carries a dunning block (goes to the blocked items / blocked accounts list).
• The item or account has an incoming payment method and no payment block (the payment program will collect it).
• The overdue amount is below the minimum amount for the level.
• The item is netted by overdue credit items.
• No item reaches the minimum days in arrears (account).

Dunning levels for items and account

Each dunned item receives a level from its days in arrears; a procedure has up to nine levels and the level can only rise by one per run (no skipping). Invoice-related credit memos inherit the invoice's level. A dunning key on an item caps its level. Then the minimum amount check runs per level: if the sum of items at a level (or their share of total open items) is below the threshold, they drop to the next lower level. The minimum days in arrears (account) must be reached by at least one item for the account to be dunned at all — the course example has four overdue items, one still in grace, one reaching the account minimum, so three items are dunned. Finally the account level = highest level of the dunned items, and that level selects the text when one notice covers all items. Levels are only recorded in items and master at printout.

Is a notice actually sent?

The account is dunned only if the dunning data changed since the last run (new item, item at a higher level, account level changed) or if Always dun is set for the level. Accounts in a legal dunning procedure (start date in the master) follow different rules: they get no customer notices, but an internal note for the legal department is produced when there were postings since the last run or Always dun in legal dunning procedure is set — the latter ensures items posted before the legal procedure started are not overlooked.

Editing the dunning proposal

Supporting lists: dunning statistics, dunning list, blocked accounts, blocked line items, dunning history; plus a sample printout on screen. The clerk can, within the proposal: block/unblock an account, block/unblock an item, lower an item's dunning level. Changes to master data or documents do not affect the current proposal — delete and recreate the run for those to count. An unprinted proposal must be deleted, otherwise its items stay locked for other dunning runs.

Printing the notices

The print program groups the items to be dunned into notices, generates one notice per group, and writes dunning date and level into the items and accounts. Sort criteria define the print sequence. For one-time customers only the items' dunning data is updated (SAP Note 6591 explains how to reset dunning data).

Dunning text controls (SAPscript form)

• Variables fill italic text; standard texts ADRS_HEADER, ADRS_SENDER, ADRS_SIGNATURE, ADRS_FOOTER carry company-code or dunning-area data.
• Recipient may differ from the dunned account; dunning clerk or, if none, accounting clerk is printed.
• Dunning interest per level via interest indicator with minimum amounts; payment deadline shifted by a public holiday calendar assigned to the procedure.
• Totals of due items from a given level; sorted list of dunned or all items (items with dunning block or collection method are not shown; "all items" not possible with notice-per-level).
• Items with a special dunning key can be listed separately; dunning charges per level (fixed or percentage, with minimum).

Payment forms and payment advices

A notice can carry an attached payment form (bank transfer form in Germany, ESR in Switzerland), either in a separate window of the form or on an extra page; the notice must then contain only items in company code currency. The program can also create a payment advice (number 10 digits starting with 08; advice type 08 must be configured) listing the dunned items, so that the incoming payment can later be matched; the advice number can be printed in the reference field.

Unit 3: Correspondence

Lesson 1: Explaining Correspondence

Understand the purpose of the correspondence function as formal, largely automated communication with business partners about FI transactions.

What correspondence is

Correspondence is any written communication the company sends to a customer or vendor about the financial transactions recorded in SAP ERP. The correspondence function automates most of the recurring letters and can also be used on demand or triggered automatically after particular transactions (for example after a payment with a difference). Typical correspondence types are account statements, open-item lists, individual letters, standard letters, balance confirmations and document extracts. Output can be printed or sent electronically (e-mail).

Why it matters

Correspondence documents the dialogue with third parties formally and is a cheap way to check that the company's view of its receivables and payables matches the partner's. Discrepancies and misunderstandings surface early and can be corrected before they turn into disputes or bad debts.

Lesson 2: Modifying Master Records

Know the fields in the customer/vendor master that correspondence relies on, especially those on the Correspondence tab of the company code data.

Structure of the master record

A customer or vendor master consists of general data (address, control data, payment transactions) and company code data (account management, payment transactions, correspondence, insurance, withholding tax). Correspondence draws on both parts.

Lesson 3: Configuring Options for Correspondence Types

Distinguish the ways correspondence can be triggered (periodic, online, posting-driven) and the two-step request/print process.

Ad hoc vs. automatic

Three kinds of correspondence

• Periodic correspondence – driven by an indicator in the master record (e.g. account statement weekly/monthly).
• Online correspondence – requested by the user while processing manual payments or from the line item display.
• Correspondence for postings – configured in Customizing so that certain postings, such as payment differences, automatically create a correspondence request.

The two-step process

1. Request – the system only records that a correspondence of a given type is wanted (a correspondence request).
2. Print – the requested correspondence is produced, usually in a scheduled run (daily/weekly) for mass types like account statements or dunning letters, or individually on demand. The output goes to the spool and from there to a printer, or is transmitted electronically.

Lesson 4: Creating a Correspondence

Define a correspondence type, assign its print program and variant, decide where it can be called up, and link it to tolerance groups and reason codes for payment differences.

Correspondence types

A correspondence type stands for one kind of letter. SAP delivers standard types; to adapt one, copy it to your own key (Z…) first, because standard entries are overwritten by upgrades. Standard examples:

IMG: Financial Accounting (New) → Financial Accounting Global Settings (New) → Correspondence → Define Correspondence Types. For each type you specify:

• Which data is required: account number and/or document number (and how many date fields).
• Whether individual text may be added to the form.
• Whether the type is cross-company-code (then company codes are assigned to a correspondence company code so one letter can combine several).

The required data is either typed by the user or derived automatically from the context (e.g. the document being displayed). All of these except customer statements can be used in every company code.

Print program and variant

IMG: … Correspondence → Assign Programs for Correspondence Types. Per company code (or company-code-independent) and correspondence type you enter the print program, a selection variant and, for individual letters, the standard text (e.g. F140_IND_TEXT). The variant chooses the printer and the form ID; a correspondence type may have several forms (SAPscript/PDF), which you can modify with logo, address and extra texts.

Call-up functions

IMG: … Correspondence → Determine Call-Up Functions. Here you decide, per company code, in which online functions a type is offered: document entry (DocEnt), document display/change (DocDsp), payment, account editing (balance display, line item processing). Payment notices typically appear in payment transactions; account statements almost everywhere. If no company-code-specific entry exists, the company-code-independent entries apply.

Tolerance groups and reason codes

For payment differences the default correspondence comes from the tolerance group of the business partner:

• Message required field filled with a type → that type is always proposed.
• Field blank → the user chooses the type during payment settlement.
• According to reason code selected → each reason code carries its own correspondence type (e.g. reason code MD, miscellaneous deduction, → letter asking for an explanation of a short payment).

Rule for several line items with different reason codes: the reason-code-specific notice is only used if all reason codes point to the same type; otherwise, or if a reason code has no type, the tolerance group's type is sent. Course example: tolerance group type SAP01; a customer pays partially two months late; the clerk posts a residual item with a reason code and requests SAP01; after posting, the request is printed and the letter is built from master data and line items.

Requesting and printing in practice

Unit 4: Accounts Approach

Lesson 1: Outlining the Accounts Approach

Describe the idea behind the accounts approach and the configuration steps required before you can post valuation differences to separate accounts.

Starting point: one accounting principle

With a single accounting principle every FI document is posted to one general ledger (leading ledger 0L in new G/L). The G/L account numbers have a maximum length defined in the chart of accounts (e.g. CAUS, INT) and are usually numeric. All accounts are reported in one balance sheet according to the local principle (US GAAP, UK GAAP, HGB …). In this course new G/L is active, and with the accounts approach everything stays in 0L; no non-leading ledger is needed.

Target: two principles, one ledger

Most companies now need a local and an international (usually IFRS) view. In the accounts approach you keep using the existing accounts for everything that is valued identically under both principles (shared accounts) and create additional accounts only where valuations differ. The course visualises this as a "Mickey Mouse" model: a large head of shared accounts with two small ears – international-only and local-only accounts. A plain vendor invoice for spare parts, for instance, is posted to exactly the same six-digit accounts regardless of the principle.

Where valuation differences arise

• Manual posting of provisions
• Foreign currency valuation
• Valuation adjustments of doubtful receivables
• Fixed asset valuation (depreciation)

Course example: an asset with APC 20,000 is depreciated over five years locally (4,000 per year: expense 211100 / accumulated depreciation 011010) but over four years internationally (5,000 per year). The two amounts cannot share accounts, so seven-digit accounts with a leading digit are introduced: 1211100 / 1011010 for the international values and 9211100 / 9011010 for the local values. The depreciation program RAPOST2000 then posts two documents, one per accounting principle.

Financial statement versions

Two financial statement versions are needed: the international version contains shared + international accounts, the local version shared + local accounts. The accounts of the "other" principle land in the appendix / section V "Unassigned accounts", which must always net to zero. An alternative is to rename section V "GAAP not needed for this report" and add a section VI for genuinely unassigned accounts (also required to be zero).

Configuration steps

Notes: the account number can be extended up to 10 digits; 11 is technically impossible. The P&L statement type field only appears in the account master when more than one P&L type exists. The international retained earnings account must be assigned to the same item as the shared one in the international version, and the local one likewise in the local version. Because CO can only carry one valuation, you must decide which principle (trend: the international one) feeds Controlling and create cost elements only for those expense accounts.

Lesson 2: Processing Manual Postings in the Accounts Approach

Post provisions with different amounts under two accounting principles using separate accounts, secure the consolidation transaction type, and analyse the result with two financial statement versions.

Why provisions?

A provision is a liability of uncertain timing or amount (IAS 37). Under IAS 37 a provision is recognised when there is a present obligation from a past event, an outflow of resources is probable and the amount can be estimated reliably, using the best estimate. Provisions are a classic source of valuation differences: the amount and the period covered can differ between principles (e.g. warranty provisions for six months of sales locally but two years internationally), and some provisions permitted locally are not allowed internationally or vice versa. The amounts usually come from the tax consultant or auditor and rest on estimates, so a complete provision history sheet must be kept.

Process in SAP

1. Post the provision expense: expense account / provisions balance sheet account (FB50 or FB01), once per principle on the respective accounts.
2. When the underlying event occurs (e.g. warranty claim), post the actual cost – goods issue of spare parts or vendor invoice of a third party.
3. Post gain from addition to or reduction of the provision: provisions account / gain account (again typically two documents, one per principle).
4. Clear the provisions balance sheet account with F-03 (account clearing) or directly while posting with F-04 (post with clearing).

Specifics: the provisions balance sheet account should be managed on an open item basis; each balance sheet line should carry a consolidation transaction type so a history sheet can be built later; normally only the international amount is passed to CO (cost center on the international expense line, profit center only on the local one).

Avoiding mixed postings

Nothing technically prevents a "cross posting" such as local expense 9476300 against international provisions 1089000. To stop this, define a validation (Financial Accounting Global Settings (New) → Tools → Validation/Substitution → Validation in Accounting Documents, OB28) at call-up point 3 (complete document) with a user exit in the check step; a validation at call-up point 2 (line item) can additionally enforce the transaction type. Since ERP 6.0 EhP4 there is also FAGL_VALIDATE (Define Validation Rule for Account Assignment Combinations) for such combinations.

Forcing the consolidation transaction type

Further checks

1. Standard transaction types exist: OC08 (Financial Accounting Global Settings (New) → Ledgers → Fields → Standard Fields → Maintain Transaction Types for Consolidation).
2. The transaction type is stored in the new G/L totals table FAGLFLEXT: leading ledger 0L needs the scenario Preparations for Consolidation (FIN_CONS) (Ledgers → Ledger → Assign Scenarios and Customer Fields to Ledgers).
3. The provisions accounts (1089000 / 9089000) have open item management (Control Data tab in FS00).

Reporting

The traditional balance sheet program RFBILA00 still works, but new G/L recommends drilldown reporting: Financial Statement: Actual/Actual Comparison (S_PL0_86000028) with currency type 10, ledger 0L and the relevant financial statement version (207I for the international view, 207L for the local view). Expanding Liabilities and the P&L section shows the respective provisions and expense accounts; selection variants (e.g. VAR##_INT, VAR##_LOC) save the parameters. In the document display you can add cost center, profit center, segment and transaction type as columns and save the layout (e.g. L1, user-specific or default).

Unit 5: Ledger Approach (Within New General Ledger Accounting)

Lesson 1: Outlining the Ledger Approach

Describe the logic of the ledger approach, when it is the right choice, and the Customizing needed to define and assign non-leading ledgers.

Starting point

As in Unit 4, a company with one accounting principle posts everything to one general ledger – in new G/L the leading ledger 0L – and produces one balance sheet, typically under the local principle (US GAAP, UK GAAP, HGB …). To add an international valuation without touching the accounts, you add a non-leading ledger.

Which ledger carries which principle?

Because the valuation assigned to a ledger cannot be changed later, three customer situations must be distinguished:

Basics

• Every client has exactly one leading ledger, posted to by all company codes. In the recommended setup it carries the international principle and is the only ledger integrated with CO.
• Non-leading ledgers map other principles: typically one for the local GAAPs (a single non-leading ledger can serve different local principles because its meaning is defined per company code), possibly another as a tax ledger, which is becoming more important as tax valuations diverge.
• Keep the number of ledgers manageable – one ledger per local GAAP would bloat the totals table and hurt readability.
• Companies that put local GAAP into 0L end up with one controlling area per company code, otherwise CO mixes incomparable local valuations.
• Non-leading ledgers of new G/L are not the same as Special Purpose Ledger (FI-SL) ledgers.

How postings behave

All ledgers use the same accounts; only the ledger differs. Any posting with a uniform valuation (e.g. a vendor invoice, or the office-supplies cash purchase in the exercise) is written automatically to all ledgers with identical accounts, amounts, dates and document number. In the document display, the general ledger view offers an "Other Ledger" button to switch between 0L and L6. The FI document generates one CO document (from the leading ledger).

Reporting

Because the accounts are identical, the same financial statement version serves both principles. The differentiator in every FI report is the Ledger field on the selection screen; if left blank, the leading ledger is evaluated.

Configuration

Caution: adding a non-leading ledger to a productive company code that already runs new G/L is itself a migration (scenario 7 or 8) and must be done with SAP's migration service; otherwise data consistency is not guaranteed and support is not available.

Lesson 2: Processing Manual Postings in the Ledger Approach

Post provisions with different amounts per principle into specific ledgers using ledger-group transactions, handle clearing with "Clearing Specific to Ledger Groups", and analyse the results per ledger.

Provisions recap

Provisions are liabilities of uncertain timing or amount (IAS 37: present obligation from a past event, probable outflow, reliable estimate, best-estimate measurement). Their amounts and covered periods differ between principles (warranty example: six months of sales locally vs. two years internationally), so they are a prime case for ledger-specific postings. A provision history sheet is required, which is why a consolidation transaction type should be recorded on the balance sheet line.

Ledger-group-specific posting

FB50/FB01 always post to all ledgers, so they are useless for a valuation difference. Instead use FB50L (Enter G/L Account Document for Ledger Group) or FB01L and fill the Ledger Group field. When a ledger is created the system automatically creates a ledger group of the same name containing just that ledger (0L → group 0L, L6 → group L6). Ledger groups can also be defined manually (IMG: … Ledgers → Ledger → Define Ledger Group) with several ledgers, which is useful when more than two principles must be served and one posting should hit several of them. For the end user the work is the same as in the accounts approach: two provision documents, one per principle.

Clearing Specific to Ledger Groups

Provision accounts are normally open-item managed, but ledger-group-specific transactions cannot post to open-item-managed accounts. SAP therefore added the account parameter Clearing Specific to Ledger Groups (Control Data tab in FS00), available from ERP 6.0 EhP3 with business function FIN_GL_CI_1 (details in course AC210). It replaces open item management and line item display for that account and allows different open items per ledger. It was built for provisions; other processes should keep ordinary open item management. The field is only shown for company codes that are assigned to at least one non-leading ledger – which is why it is invisible for accounts 1089000/9089000 in AA30 but active for 89000 in 0005. SAP Note 1070629 (FAQ 17) lists other EhP functions of new G/L.

Provision process with ledger-group transactions

Only the leading-ledger document (international amount) creates a CO document; the L6 document has no CO follow-on even if a cost center is entered.

Settings for provisions (same as accounts approach)

1. Force the consolidation transaction type on the provisions account either by a field status group with the transaction type as required entry (FBKP, variant 1000, course group ZPRO on account 89000 in 0005; assign in FS00) or by a validation in OB28; account assignment combinations can also be validated with FAGL_VALIDATE (EhP4).
2. Check the standard consolidation transaction types in OC08: 500 opening balance, 520 allocation, 540 drawing/utilisation, 560 elimination/reduction.
3. Ensure the transaction type is stored in the totals table: scenario FIN_CONS (Preparations for Consolidation) assigned to ledger 0L (Assign Scenarios and Customer Fields to Ledgers).
4. Define ledger groups manually if needed.

Analysis

Document display → General Ledger View shows the Ledger Group in the header (no switching possible for a ledger-specific document). FAGLL03 (Display/Change Items (New)) lists open items per ledger via the Choose Ledger button, showing 1,000 for 0L and 2,000 for L6 on account 89000. The drilldown report S_PL0_86000028 (Financial Statement: Actual/Actual Comparison) is run with the same version INT but ledger 0L or L6; because all participants post to the same account only cumulative values appear, so navigate to the line items to see individual ledger-specific documents.

Unit 6: Financial Closing Overview and Basic Settings

Lesson 1: Explaining the Periodic Closing Process

This short lesson gives the roadmap for the rest of the course: it lays out the month-end closing process as a timeline of activities grouped by purpose (technical, pre-closing, managerial, external reporting) and explains which additional activities are added at year-end.

Why a closing roadmap matters

Closing is a cross-component effort. Many of the individual activities (accruals, foreign currency valuation, GR/IR analysis, regrouping, balance confirmations) are covered in detail in later units, but they only make sense when you know when they happen relative to each other. The business example for the lesson is a project team member who must define the type and timing of all closing activities in the system. The key ordering principle is: first make the technical preparation, then post all operational transactions of the old period in the subledgers and feeder components, then do the managerial (CO) closing, and finally make the valuation and reporting steps needed for the external financial statements.

Month-end closing: the sequence

The course presents the periodic (monthly) closing as a time line that starts on the last day of the old month and continues into the first days of the new month. Reconstructed as numbered steps:

1. Technical preparation (last day of the old month): open the next posting period in FI; close the old period in Materials Management (MM period shift); close the subledgers (AR, AP, AA) for the old period; make a preliminary close of the general ledger.
2. Pre-closing postings in the feeder components and FI:
   • FI: post accruals and deferrals, run recurring entries, process bad-debt (doubtful receivables) expense in AR.
   • MM: maintain and analyze the GR/IR clearing account, post material revaluations.
   • HR: post the payroll results to FI.
   • SD: post the goods issues for customer deliveries so that cost of goods sold and stock reductions land in the old period.
3. Managerial (internal) closing: run Controlling period-end allocations and repostings (assessments, distributions, settlement); then lock the old accounting period; afterwards the G/L may be reopened for adjustment postings only.
4. Closing for external reporting: FI valuates open items in foreign currency; the old period is finally closed (technical step); FI/CO produce the required reports, for example tax reports and the asset history sheet for external purposes and management reports for internal purposes.

Year-end closing: what is added

For the last period of the fiscal year the normal month-end steps still apply, but extra activities are added. Pre-closing activities that already start in the old year:

• Technical: open the first period of the new fiscal year in FI, run the fiscal year change in Asset Accounting, and carry forward balances in FI (G/L, customer and vendor balances).
• MM: physical inventory count (can also be done monthly).
• PP/CO: update product cost estimates (can also be done more often).
• MM: lowest value determination and LIFO/FIFO valuation of inventories.
• AA: asset valuations and investment support.
• FI: balance confirmations with customers and vendors.

Year-end activities for external reporting then include: analysis of the GR/IR clearing account, reclassification (regrouping) of receivables and payables by remaining term and by changed reconciliation account, reconciliation of the prior year with the new year, further adjustment postings, the final close of the old period in AR/AP and G/L, and the creation of external and internal reports.

How the following units map to this roadmap

• Unit 7 – Financial statements and drilldown reports (the external/internal reporting step).
• Unit 8 – Balance confirmations, foreign currency valuation, value adjustments (doubtful receivables), regrouping of receivables/payables.
• Unit 9 – Accruals and deferrals.
• Unit 10 – Technical steps (balance carryforward, period control), balance audit trail, ledger-group-specific postings.
• Unit 11 – Financial Closing Cockpit, the tool that schedules and monitors all of these tasks.

Unit 7: Financial Statements

Lesson 1: Managing Financial Statements

Learn how SAP ERP produces a balance sheet and profit and loss statement with report RFBILA00, and how the layout of that report is entirely controlled by a configurable financial statement version (FSV).

Report RFBILA00

RFBILA00 is the standard ABAP report that creates financial statements. It does not contain any fixed layout: the structure comes from the financial statement version you enter on the selection screen, so the same program can produce completely different statements (for the tax authority, for internal management, for external investors) simply by selecting another version. In the exercise it is reached via Accounting → Financial Accounting → General Ledger → Information System → General Ledger Reports (New) → Financial Statement/Cash Flow → General → Actual/Actual Comparisons → Financial Statement (the classic transaction is S_ALR_87012284).

Important facts about the report and the versions:

• FSVs are used not only by RFBILA00 but also in the structured balance list, in planning, in drilldown reporting and when transferring data to consolidation.
• Selection parameters let you choose the reporting level: company code, business area, segment, profit center and so on (with New G/L). With classic G/L only company code and business area level statements are possible.
• Instead of a true financial statement you can also use RFBILA00 to print a structured list of account balances, but then no profit/loss is calculated, accounts not assigned to an item are suppressed and the "nonassigned accounts" item is not shown.
• Since EhP5 (business function General Ledger Accounting (new) 3) the report can read totals records from the archive: the Data Sources option lets you choose database, archive or both.
• SAP delivers sample versions (for example INT); the recommended approach is to copy one and adapt it rather than build from scratch.

What the FSV controls

Defining a financial statement version

IMG path: Financial Accounting (New) → General Ledger Accounting (New) → Periodic Processing → Document → Define Financial Statement Versions (transaction OB58). Two steps:

1. Create the entry in the directory of versions: key, name, maintenance language, chart of accounts (or cross-chart), whether item keys are assigned automatically, and whether functional areas are allowed.
2. Choose Fin. Statement Items and build the hierarchy: create items on up to 20 hierarchy levels, give each item a text, and assign accounts to the lowest-level items. For every item the program computes a total/subtotal at run time.

Every version must contain a set of special items, which are created as fixed nodes when the version is defined:

How the result is computed: net profit/loss is derived only from the accounts assigned to the Assets and Liabilities items. Accounts under Notes to financial statement and under Accounts not assigned are excluded both from the net result and from the P&L result; the P&L result is the balance of all remaining (P&L) accounts. Moving an account to the notes item is therefore the way to keep it out of the profit calculation while still printing it.

Account assignment by balance (debit/credit indicators)

When you assign an account (or range) to an item you set a D (debit) and/or C (credit) indicator. This decides on which side of the balance sheet the balance of that group of accounts appears:

The one-sided assignments are meant for accounts with fluctuating balances such as bank or clearing accounts: the same account is assigned twice, once under assets with D and once under liabilities with C. Note that the decision is made on the joint balance of all accounts listed under the item, not account by account.

Texts, translation and forms

• Up to four lines of text may be entered at the beginning and/or end of an item.
• Item texts are translated with the translation workbench: SE63, Translation → ABAP Objects → Other Long Texts, object type FI – Balance Sheet/P&L Statement.
• The P&L hierarchy is maintained exactly like the balance sheet part; graduated totals are typically used there, for example to show operating result plus financial result as one subtotal.
• RFBILA00 can print on a SAPscript form: in the version directory select the version, choose Goto → Create form (one- or two-column), adjust and activate the form, then enter it on the Output Control tab of the report selection screen.

Lesson 2: Executing Drilldown Reports

Use the cross-application drilldown reporting tool to analyse G/L transaction figures and financial statements interactively, switching between characteristics such as financial statement item, profit center and segment and navigating down to line items.

What drilldown reporting offers

Drilldown reporting is an interactive analysis tool that works on the G/L totals (and, since EhP5 with business function General Ledger Accounting (new) 3, also on archived totals via the Data Sources button). Typical uses are financial statements by any characteristic, variance analysis such as plan/actual or fiscal-year comparisons, and ad-hoc navigation from a summary to the details. Supporting functions include sorting, conditions (thresholds), ranking lists, SAP Graphics, SAP Mail and export to the Microsoft Excel list viewer.

Characteristics and key figures

Being able to tell the two apart is a classic exam point: "total debit balance" is a key figure; company code, business area and segment are characteristics.

Drilldown list versus detail list

A report is a set of lists of two kinds, depending on how many characteristics and values you have selected:

Navigation in the classic drilldown report

The figures in the lesson show the navigation block on the left of the classic drilldown output. You can:

1. Select a navigation characteristic (for example FS Item/Account) and swap it with another one (for example Profit Center) so that rows are now by profit center.
2. Click the hash sign or magnifying glass next to a characteristic to pick a single value (a specific profit center) and so filter the whole statement.
3. Expand the hierarchical FS items with the + signs down to individual accounts.
4. From an amount, choose Goto → Line items to jump to the G/L account line item display for exactly that selection.

The standard G/L financial statement drilldown report used in the course is Financial Statement: Actual/Actual Comparison (S_PLO_86000028), reached through General Ledger Reports (New) → Financial Statement/Cash Flow → General → Actual/Actual Comparisons. Its selection screen asks for currency type (10 = company code currency), company code, the FSV, the ledger (0L), reporting year/periods and comparison year/periods, and lets you choose the output type (classic drilldown report, object list or graphical report output).

Unit 8: Receivables and Payables

Lesson 1: Creating Balance Confirmations

Understand the overall sequence of closing steps in AR and AP, and learn how the balance confirmation programs create letters, reply slips, reconciliation lists and result tables to verify customer and vendor balances with the business partners themselves.

Closing sequence in receivables and payables

The subledger closing follows a fixed logic that is identical for customers and vendors:

1. At the start of the new fiscal year the balance carryforward program transfers the customer/vendor balances into the new year.
2. The normal posting periods of the old year are blocked and the special periods are opened so that only closing postings can still be made.
3. A technical reconciliation confirms that documents, transaction figures and indexes are consistent (see unit 10).
4. The valuation work is done: balance confirmations, foreign currency valuation, value adjustments and regrouping.
5. Once the balances are confirmed the special periods can be closed.

Country-specific procedures may add further steps; the course points out that the instructor can explain local requirements.

How balance confirmation works

The system can produce balance confirmations for any set of customers or vendors you select. Each run creates the letters with reply slips for the business partners plus two internal outputs: a reconciliation list (what was sent to whom) and a results table. The letters go to the partner; the lists go to a control centre (in the IDES demo system this is the internal audit department). The partner checks the balance and sends the reply to the control centre, which compares the replies against the reconciliation list and records the outcome in the results table.

Programs and procedures

Key selection fields on F.17: company code, reconciliation key date, individual customers (or sampling), sort variant for the correspondence, line item sorting, date of issue and reply date, and separate printers for the form set, reconciliation list, results table, error list and selections.

Customizing

• The reply address (where partners send their answer) is defined per company code under an address ID, for example ID 0001 for the internal audit department. The same ID must then be entered in the selection screen of the run. If the confirmations should go to the external auditor, the ID field is left blank.
• The letter and reply slip are SAPscript forms; if no form exists in the partner's communication language, output falls back to German. The language is taken from the Communication block on the Address tab of the customer master.

Lesson 2: Managing the Foreign Currency Valuation

Learn why open items and G/L balances in foreign currency must be revalued at the key date, how the New G/L program FAGL_FCV does this with valuation areas, valuation methods and account determination, and how the delta posting logic differs from the classic post-and-reverse approach.

Scope and timing

Foreign currency valuation is done before the financial statements are created (not after; the learning assessment tests exactly this). Two kinds of objects are valuated:

• Foreign currency balance sheet accounts: G/L accounts managed in a foreign currency, valuated at balance level.
• Open items in foreign currency on customer, vendor and open-item-managed G/L accounts, valuated line item by line item.

Example: a vendor invoice of USD 500 was translated at entry to EUR 600. At the key date the rate has moved, so the open item must be re-translated; the difference is written into the line item as a valuation difference and posted as expense (or revenue) from currency valuation against an adjustment account. Posting directly to the reconciliation account is not possible, so the adjustment account is shown on the same balance sheet line as the reconciliation account.

Standard valuation posting logic

1. On the key date the program posts the valuation difference (adjustment account against FX expense/revenue).
2. On the first day of the following period the same program reverses this posting automatically (independent of the valuation area), so balances return to the original translation; another posting date can be chosen.
3. Later valuations and the eventual payment clearing always start from the original document values.

If you do not want the reversal (for example because the reversal would fall into a new fiscal year), you must activate the delta posting logic (below).

Program FAGL_FCV versus its predecessors

Transaction FAGL_FC_VAL (menu: Periodic Processing → Closing → Valuate → Foreign Currency Valuation (New)) now starts FAGL_FCV. If the old program had been used in a client, FAGL_FCV must be started once explicitly; after the first update run of FAGL_FCV the new program is used from then on regardless of how the valuation is called. Logs can also be listed with program FAGL_PROT.

Customizing overview

Ledger approach prerequisites: at least one non-leading ledger in addition to the leading ledger; valuation areas; accounting principles; area-to-principle and principle-to-ledger-group assignments; a valuation method per area. In practice several areas may be needed even when the local valuations are technically identical.

Delta posting logic

With delta logic the valuation posting is not reversed the next day. Instead the cumulative valuation difference per line item is stored in table FAGL_BSBW_HISTRY and each later run only posts the change (the delta) against the previous valuation. This avoids a reversal in another fiscal year, which some countries do not allow. Consequences when an item is cleared:

1. At clearing in New G/L the clearing document is posted identically to all ledgers, but the realised exchange rate difference may legitimately differ per ledger/valuation area.
2. The system therefore always posts the difference between the original invoice rate and the clearing rate as the realised difference at clearing time.
3. During the next valuation run the correct realised difference per valuation area is computed from the history table and the actual clearing-date rate, and a correcting posting is made against the realised difference already booked; the next run also reverses the sum of valuation postings for items cleared since the last run.
4. This correction normally carries the posting date of the valuation run (month end). With the clearing date as reversal date indicator it carries the clearing date instead, but use this only when really needed: the program cannot guarantee that period is still open, and if it is closed the posting lands in a batch input session with an error message.

The lesson's summary figure compares the posting sequence of the lowest value principle (write down only, never above acquisition value) with the strict lowest value principle (every change in the write-down is posted) over several periods. SAP Notes 960661 and 1006684 list the support packages that deliver the delta logic for the various releases.

Valuation of foreign currency balance sheet accounts

• Also done with FAGL_FCV; select the accounts on the G/L Account Balances tab.
• Valuation is at account-balance level; depending on method and balance the account may be written up or down.
• The run can be repeated with the same selection; new postings since the last run are included.
• Account determination is driven by the exchange rate difference key entered in the G/L account master (control data), which maps to gain/loss accounts defined in Customizing.

Lesson 3: Managing Value Adjustments

Learn the three ways to write down doubtful receivables in SAP ERP: individual value adjustment via special G/L transaction, automatic flat-rate individual value adjustment with program SAPF107V, and manual G/L posting of a flat-rate adjustment.

Value adjustment options

Individual value adjustment for doubtful receivables

Because the posting is made to the customer account, the customer's total exposure stays visible, while the special G/L account keeps the write-down separate from the reconciliation account in the balance sheet. Use a tax code with 0% because no tax correction is made at this point. Follow-up steps:

1. When the outcome is known (receivable paid or definitely irrecoverable), reverse the individual value adjustment.
2. If irrecoverable, clear the receivable on the customer account and post it to the account for depreciation (write-off) of receivables.
3. Correct the output tax in that write-off posting.

Flat-rate individual value adjustment with SAPF107V

1. Configure the valuation adjustment key in AR Customizing: for each key, the overdue period in days and the bad-debt percentage to apply.
2. Account determination: define the adjustment account and the bad-debt expense account for doubtful receivables.
3. Customer master: enter the valuation adjustment key in the company code data (Account Management tab, field Value Adjustment) of every customer to be included.
4. Valuation run (F107): create a run (run date + identification), maintain parameters (key date, valuation method 3 = flat-rate individual value adjustment, valuation area, generate postings, posting date = key date, reversal date = key date + 1, document type SA), restrict selection options to company code and customers, then Edit → Valuation Run → Dispatch to execute. Review the valuation list, change the proposal manually if required, and finally Forward (valuation transfer) to post. The adjustment is posted on the key date and reversed one day later. The posted values can be seen on the valuated line item via Environment → Valuation → Display Values.

Lesson 4: Regrouping Receivables and Payables

Learn why and how receivables and payables are reclassified for the balance sheet at the key date: by remaining term, for customers with credit balances and vendors with debit balances, for affiliated companies, and for reconciliation accounts changed during the year.

Why regroup

• Receivables and payables must be shown separately: a vendor with a debit balance at period end is in substance a receivable and must appear in the receivables section; a customer with a credit balance is a payable.
• Many countries require payables and receivables to be split on the balance sheet by remaining life (e.g. due within one year / after one year).
• Readers of the statements get a better picture of liquidity.

All regroupings are pure balance-sheet presentation postings. They are made on the key date to an adjustment account (the reconciliation account itself cannot be posted) with the counter-entry on a target account for the new classification, and reversed on the first day of the next period because they are irrelevant for daily processing. Different sort methods and valuation areas allow different legal requirements to be posted to different accounts and picked up by different financial statement versions.

Programs

Functions of FAGL_CL_REGROUP:

• Sorts open receivables and payables by remaining term according to the sort method (e.g. SAP: up to 1 year, 1–5 years, over 5 years) and posts the transfers.
• Regroups customers with credit balances and vendors with debit balances (the balance decides whether an account is a receivable or a payable).
• Posts adjustments for changed reconciliation accounts.
• In Customizing of the sort method you decide which of these cases should actually generate transfer postings.

Selection screen essentials: company code, balance sheet key date, sort method, valuation area; Postings tab with "generate postings" and the batch input session name (default FAGL_CL_REGR); Selections tab for account type and accounts; Other tab for the changed-reconciliation-account indicator. The postings are delivered as a batch input session that must be processed (System → Services → Batch Input → Sessions).

Affiliated companies

When a business partner is both customer and vendor and belongs to the group (another company code), receivables and payables with affiliated companies must be shown separately for consolidation. Set-up (also for partners from non-SAP systems):

1. Enter the same company ID in the Trading Partner field of the general control data of both the customer and the vendor master.
2. Use alternative reconciliation accounts in the master records ("receivables from / payables to affiliated companies").
3. In Customizing, assign adjustment accounts to these special reconciliation accounts so that the regrouping program can post against them.

Changed reconciliation account

The reconciliation account in a customer or vendor master can be changed during the fiscal year (the assessment question about this is "false": you can change it). Existing open items stay on the old account. At the key date, FAGL_CL_REGROUP with the relevant indicator on the Other tab transfers the balance of those items from the old to the new reconciliation account via adjustment accounts, so the balance sheet shows all receivables under the new account.

Unit 9: Accruals and Deferrals

Lesson 1: Posting Accruals and Deferrals

Learn to distinguish accruals from deferrals, to post an accrual/deferral document that reverses itself on a given date, and to use recurring entries to spread an expense evenly over several periods.

The problem: expense in the wrong period

Invoices are posted when they are received or issued, but the underlying expense or revenue often relates to a different period. Period-correct reporting therefore needs correction postings at period end that are undone again later. In SAP this is solved either by a document that carries its own reversal date (manual accrual/deferral document) or by repeating identical postings each period (recurring entry program).

Worked example from the course: warehouse lease

Monthly rent EUR 500; three months are paid in advance on 1 December.

1. 1 Dec – prepayment: occupancy costs 1,500 (debit) / bank 1,500 (credit). The full amount sits in December expense.
2. 31 Dec – deferral document: accrued income (prepaid expenses) 1,000 (debit) / occupancy costs 1,000 (credit). December now shows only 500 of expense; 1,000 is parked on the balance sheet.
3. 1 Jan – automatic reversal: occupancy costs 1,000 (debit) / accrued income 1,000 (credit). The expense re-enters the P&L in the new year, where it belongs.

A second figure in the lesson shows an invoice of 120 received in period 7 for goods consumed all year: six accruals of 10 are needed for periods 1–6 before the invoice arrives, and the remaining 50 is spread over the five periods after receipt.

Method 1: manual accrual/deferral document

Menu: General Ledger → Periodic Processing → Closing → Valuate → Enter Accrual/Deferral Document (FBS1). It is an ordinary G/L document (typically type SA) with two extra header fields:

• Reversal reason – e.g. 05 "accrual/deferral posting"; the reason controls whether the reversal may have an alternative posting date and whether negative postings are produced.
• Reversal date – the posting date of the later reversal, normally the first day of the next period.

No user name has to be entered (a learning-assessment trap). The reversal itself is executed collectively with Reverse Accrual/Deferral Document (F.81): enter company code and reverse posting date, run as test or update. In the exercise the offsetting account is 98000 (accrued income), the expense account is 470000 with cost center T-A20A##, tax code V0 (0%).

Method 2: recurring entry program

If exactly the same amounts are posted to the same accounts every period, a recurring entry original document is created once (FBD1, Document Entry → Reference Documents → Recurring Document). It is not a real accounting document and does not update balances. Its header carries the run schedule:

The recurring entry program (F.14, Periodic Processing → Recurring Entries → Execute) selects all recurring documents whose next run date falls in the settlement period and writes a batch input session (name chosen on the selection screen). Processing the session (System → Services → Batch Input → Sessions, "display errors only") creates the actual accounting documents.

Accounting treatment of accruals via recurring entries: each period posts expense / other payables (if the reason and amount are certain) or expense / provisions (if only an estimate is possible). The credit balance on the payables/provision account grows each period until the invoice arrives and is cleared against it.

In the exercise the prepaid rent is first moved in full from the expense account to accrued income (98000) on 1 Dec with a G/L document (FB50), and the recurring document then releases EUR 500 per month from 98000 back to 470000 for December, January and February.

Comparison

Unit 10: Technical, Organizational and Documentary Closing Activities

Lesson 1: Managing Technical Steps During the Period-End Closing Activities

Learn the sequence of general ledger closing operations and the three technical tools that support them: the balance carryforward program, the posting period table (including period interval 3 for CO-triggered postings) and the technical reconciliation report.

General ledger closing operations in order

1. Run the balance carryforward at the start of the new fiscal year (G/L accounts).
2. Block the normal posting periods of the old year and open the special periods for closing postings.
3. Run the technical reconciliation to prove that documents and transaction figures agree.
4. Perform the valuation work: foreign currency valuation, accruals/deferrals, GR/IR clearing account analysis and regrouping.
5. Close the special periods.
6. Produce the documentation: balance audit trail and financial statements.
7. Create the messages/reports for statutory reporting.

As in the AR/AP unit, the course notes that country-specific steps may be added.

Balance carryforward

• For every balance sheet account the program computes the opening balance of the new year.
• The balances of P&L accounts are not carried forward as such; they are rolled into the retained earnings account (P&L carryforward account) assigned through the P&L statement account type in the account master. Since release 4.6C you can display which P&L account balances went into a particular retained earnings account, which explains how its total arose.
• If P&L accounts are kept in several currencies, set Only balances in local currency on the retained earnings account so that all currencies are translated and summed.
• The program may be run as often as desired, even before the old year is finished: any subsequent posting to the old year automatically updates the carried-forward balance. SAP nevertheless recommends running it as late as possible, after all other updates.
• Programs: SAPF010 (F.07) for customer and vendor balances; for the New G/L (and whenever additional ledgers such as FI-SL or parallel currencies are involved) use transaction GVTR / FAGLGVTR.

Posting periods and the fiscal year variant

The posting date entered on a document decides the period it lands in. The fiscal year variant assigned to the company code defines: the start and end of the fiscal year, the number of normal posting periods (up to 16), the number of special periods (the remainder up to 16), and the length of each period.

Posting period control (OB52)

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

Rules:

• The + line defines the maximum open range; lines for individual account types can only restrict it further. Course example: + allows 13–16 of 2009 and 1–2 of 2010, while the A and D lines keep period 1 of 2010 closed for assets and customers.
• Periods not listed are closed.
• Authorization group: users holding F_BKPF_BUP for the group may post in interval 1 (typically the closing team posting into the old period); everyone may post in interval 2. The group is entered on the + line for the document header and, if needed, on account type lines for line items.

Period interval 3 (since EhP4)

With real-time integration CO→FI, a CO posting that changes an FI characteristic (e.g. a repost across company codes or profit centers) creates an FI follow-on document, which fails if the FI period is already closed. Because CO typically still allocates after FI has closed, SAP introduced interval 3: a separate open range used only for CO-triggered FI postings, maintainable only for account type +. If interval 3 is empty the system behaves as before EhP4. Even with interval 3, FI and CO still have to be reconciled at period end.

Technical reconciliation

Menu: Periodic Processing → Closing → Check/Count → Reconciliation (FAGLF03 for New G/L; SAPF190 / F.03 for classic G/L). Two comparisons are run:

1. Debit/credit transaction figures of customers, vendors and G/L accounts in the totals table FAGLFLEXT against the debit/credit totals of the posted documents (BSEG).
2. The same transaction figures against the totals of the application (secondary) indexes BSIS/BSAS, BSID/BSAD, BSIK/BSAK, which serve the line item display and open item management.

Results are stored in a history so that you can prove when reconciliation ran and whether it was clean.

Lesson 2: Executing the Balance Audit Trail

Understand why account balances must remain explainable after documents have been archived, and how the balance audit trail and compact document journal provide that documentation.

Purpose

Legal requirements demand that any account balance can be justified from its document items for several years. As long as the documents are in the database this is trivial (line item display). To keep the database small, old documents are archived and deleted; afterwards a balance audit trail is the only way to show how a balance arose. Therefore the audit trail must be run before archiving. It produces, for a chosen period, a list that starts with the opening balance of each account, shows all changes (the compact journal) and ends with the closing balance.

Report variants

Besides the "from the document file" variants, SAP also offers the "accumulated" balance audit trail that first extracts the data to a dataset (so that archived documents can be included) and then prints it.

Lesson 3: Posting Ledger Group-Specific FI Documents

Learn how parallel accounting is modelled with ledgers in the New G/L, what a ledger group is, and how to post a document that updates only selected (non-leading) ledgers.

Parallel accounting

Companies increasingly have to report under more than one set of rules, for example local GAAP plus IAS/IFRS or US GAAP, because international lenders and investors expect a recognised standard. The New G/L offers two equivalent ways to do this (SAP Note 779251):

The New G/L ledger solution must not be confused with FI-SL special ledgers of R/3 Enterprise, which are far less integrated. The leading ledger is the only one integrated with CO; existing customers upgrading to ERP are advised not to change their leading valuation view except in a dedicated project.

Entry view and general ledger view

Every FI document has an entry view (as posted, identical for all ledgers) and a general ledger view that is specific to a ledger and shows the document as it appears in that ledger (with document splitting, ledger-specific periods, etc.).

Ledger groups

• IMG: Financial Accounting (New) → Financial Accounting Global Settings (New) → Ledgers → Ledger → Define Ledger Group.
• A ledger group bundles ledgers so that a posting can address several ledgers at once. Nobody is forced to create groups: the system automatically creates a group with the same name for every ledger, containing only that ledger.
• If a document specifies a ledger group, it is posted only to the ledgers in that group; without a ledger group it goes to all ledgers.
• If a group contains only non-leading ledgers, the document type used must be set up for the entry view in a ledger: … Document → Document Types → Define Document Types for Entry View in a Ledger (with its own number range), because the leading ledger's number assignment is not used.

Posting to a ledger group

Transaction FB50L (General Ledger → Document Entry → Enter G/L Account Document for Ledger Group) is the ledger-group variant of FB50; FB01L is the general posting equivalent. The header contains the Ledger Grp field. Typical use: provisions or valuation differences required only under one accounting principle. In the exercise a provision of EUR 1,000 is posted in company code 1000 to ledger group L5 (debit 239000 provision for unrealised costs, credit 79000 provisions for missing costs, profit center PRCTR## via screen variant ZPPROFITCENTER). Displaying the document shows ledger group L5 in the header of both the entry view and the general ledger view, proving that only that ledger was updated.

Unit 11: Financial Closing Cockpit

Lesson 1: Managing the Financial Closing Cockpit

Learn to set up and operate the FCC: when it pays off, which objects it consists of (hierarchy, template, task types, task list, dependencies, monitor), how to configure it in CLOCOC, and how to run and track closing tasks in CLOCO or in the browser-based cockpit.

What the FCC is and when to use it

The FCC is a structured, central interface for executing the transactions and programs that make up a complex, recurring process such as period-end closing. It maps the process onto the organizational structure (company codes, controlling areas, plants) and can span several organizational units. It is worth using when:

• the activities recur every period;
• several people are responsible for different steps;
• the steps have a fixed chronological order or technical/business dependencies;
• everybody involved should work from one uniform interface;
• the status of all steps must be transparent and documented for everybody, and for later audits.

Features and release history

All stakeholders can start their own tasks, monitor automatically scheduled jobs, report problems, set a manual status, document that a task was checked and confirm manual steps. From the task list you reach job logs, spool lists and application logs whether a task ran automatically or manually.

SAP Central Process Scheduling by Redwood

When closing is run as a shared service for many companies, tasks must often be triggered in other systems (a production system where orders are settled, a system on an older release, even non-SAP systems). The FCC alone cannot do that. SAP Central Process Scheduling is a solution extension that offers cross-system, cross-client and event-based job scheduling with parallel process chains. You download it to NetWeaver, connect the systems that deliver closing-relevant figures, define remote tasks in the FCC and activate business function FIN_ACC_LOCAL_CLOSE. It can coexist with another scheduler (NetWeaver 7.0 SP14 or higher).

Building blocks of the FCC

Prerequisites before the FCC can be used: a template exists and is assigned to an organizational structure; tasks (subfolders, transactions, programs, flow definitions, notes) are assigned to it; a task list has been derived from it and released.

Step 1: organizational levels

Standard levels are controlling area, company code and (from EhP5) plant. Each level has these properties:

• Selection variables for program variants are derived from the organizational type and stored automatically in table TVARV/TVARVC, e.g. SAP_FAST_CLOSE_BUKRS_P (company code parameter), SAP_FAST_CLOSE_BUKRS_S (company code select-option), SAP_FAST_CLOSE_LDAY_P (last day of period). Variants that use these variables adapt automatically to each task list.
• The Superordinate Org. Level field decides where the level sits in the hierarchy; without one it can only be a root node.
• Data can be summarised across levels by chart of accounts, fiscal year variant, currency or valuation area.
• Default subfolders can be stored per level and are proposed for every object at that level.

Step 2: template

1. In CLOCOC (Closing Cockpit – Manage Templates and Task Lists) choose Template/Task List → Create Template (or open a delivered template such as 1-FC-MONTH and Save As).
2. Give a 10-character technical key, choose the closing hierarchy (e.g. Controlling Area/Company Code) and a description.
3. The time-dependent selection variables relevant for the template appear in its header.
4. The system proposes a structure containing all organizational objects of the system (all controlling areas with their company codes and default subfolders). Via the context menu you restrict the values (e.g. only controlling area 1000 and company code AC##), delete or add hierarchy levels and folders, and cut/insert folders.
5. Task folders group tasks into substructures below an organizational level.

Template scope should follow the whole process and the organizational units involved, not application boundaries.

Step 3: task types

When creating a task you enter description, person responsible and person processing, the task type with program/variant or transaction, and the assignment to closing types (month-end, quarter-end, year-end…). Assign every task to at least one closing type, because the closing type chosen for a task list filters which tasks are copied from the template. Planned start/duration allow the monitor to show the planned runtime and mark the critical path.

Step 4: dependencies

Dependencies are maintained on the Dependencies tab from the successor's viewpoint: select the successor and drag the predecessor(s) below it; a task may have several predecessors. From EhP5 a whole task folder can be a predecessor. At run time a dependent task can only be scheduled or executed once all predecessors have finished without errors; when a predecessor completes the system offers to schedule the dependent tasks automatically.

Step 5: task list

1. Template/Task List → Create (Periodic) Task List creates a task list of the same name as the template.
2. Enter key date, description, closing type, fiscal year and posting period. The time-related parameters of all variants are filled from this header; only tasks allowed for the closing type are transferred.
3. Set status Released; only released task lists can be used in CLOCO. You may decline the offer to schedule all tasks immediately.
4. Task lists are listed under their template by key date.

Compliance aspect: with EhP5 the roles of group-level closing planner (maintains templates in CLOCOC) and local closing responsible (creates task lists only, CLOCOT) can be separated.

Executing and monitoring (CLOCO)

• Open the released task list, navigate the organizational structure to a folder, select tasks and choose Schedule Selected Tasks (background) or execute online tasks directly.
• The monitor shows tasks on a time axis with a vertical blue line for "now"; connecting lines are predecessor→successor dependencies. Status colours:

• The list display (toggle with the monitor) shows name, report and variant, processor and responsible person, start and end time, and status. From the detail area you open spool request, job log and batch input session directly.
• Manual status changes write change documents, so the history of the close is auditable.
• Notes and documents can be attached to tasks; tasks can be filtered by processor or responsible person; mails can be sent to the people assigned.
• When all tasks are green the task list is set to Completed (Edit → Basic Data), the "safe landing" in the course's flight metaphor.

Web access: NetWeaver Portal and Business Client

• The FCC business package is in the Portal Content Directory under Content provided by SAP → Specialist → Worksets for reuse in Roles → Closing Cockpit; access is role-based and the portal integrates SAP and non-SAP sources in one UI.
• SAP NetWeaver Business Client (version 3.0 in 2010) unifies classic GUI transactions and Web Dynpro applications. Variants: NWBC for Desktop (installed rich client) and NWBC for HTML (URL only, no installation); from EhP5 it is started from ERP with transaction NWBC (role SAP_FAGL_CLOCO_WD_15 in the exercise).
• In the web cockpit you choose a released task list, start the cockpit, switch between hierarchy and graphics (with a selectable timeframe), use Action → Schedule Task(s) or Execute Task, set status via Set Status For, and view job logs and spool under Task-related Files.

Summary of FCC benefits: one central tool for everybody involved, organizational structure embedded in the task list, graphical display with the ability to correct tasks, dependency control, direct links to spool and job logs, and logged status changes.