S4F13 – Additional Financial Accounting (S/4HANA)

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

Unit 1: Automatic Payments

Lesson 1: Executing an Automatic Payment Run

Get the big picture of what the automatic payment program does and the five processing steps every payment run goes through.

Why a payment program?

Paying invoices one by one is not feasible for a company with thousands of open items. The payment program is SAP's mass-processing tool for payables (and for collecting receivables). It runs in Financial Accounting at intervals the business decides (daily, weekly, ...) and, from a set of open items, decides what is due, how it is to be paid, posts the payment documents, and hands the data to the print/DME/EDI programs that produce the payment media.

From a business point of view, the life cycle of an invoice in the payment process is: invoice is entered, open invoices are analysed for due date, due invoices are prepared for review, payments are approved or rejected, invoices are paid.

Characteristics

• Designed for both domestic and international payment transactions.
• Works for vendors and customers, for outgoing and incoming payments (e.g. direct debits).
• Country-specific flexibility: payment methods, forms and data-carrier formats differ by country and are all configurable.
• Three things happen automatically: selection of open items to pay/collect, posting of payment documents, and output of payment media (print forms, Data Medium Exchange files, or Electronic Data Interchange).

The five processing steps

1. Maintain the parameters. The parameters answer: which open items are evaluated, which payment method(s), when payment is made (posting date), which company codes, and when the next run is scheduled (so items that would be overdue by then are included now).
2. Schedule the proposal run. The system builds a list of business partners and open items that are due, grouped into payments.
3. Revise the proposal. Clerks review it, drill into each proposed payment, change payment terms/discount, set or remove payment blocks.
4. Schedule the payment run. After the list is verified (and the debit balance check performed), the payment documents are posted and G/L plus subledger accounts are updated.
5. Schedule printing. A separate print step produces the payment media (forms, DME files, IDocs).

Lesson 2: Using Bank Accounts

Learn the bank master data the payment program needs: the bank directory, house banks, house bank accounts and their link to G/L accounts, and bank details of business partners.

Basic Cash Management capability

Customers without a licence for the full SAP Cash Management can still use a "basic cash management" scope (formerly called Bank Account Management light). Anyone running SAP S/4HANA Finance may use it. It lets a cash manager centrally:

• Manage banks and house banks (only the subset of fields needed for the payment process).
• Define bank accounts and house bank accounts (common attributes only).
• Show bank accounts in a list view, import/export them.
• Replicate house banks, house bank accounts and bank accounts via IDoc.
• Monitor cash position and liquidity forecast.
• Manage memo records (app or FF63 / FF65).

The bank relationship management flow uses "direct revision activation": when a bank account is opened at the external bank, its data is created in S/4HANA in one harmonised step; the bank account master is identified as house bank information and tied to a G/L account in FI.

Manage Banks (bank directory)

Every bank that appears anywhere in the system (your own banks, your customers' and suppliers' banks) has one bank master record in the bank directory. The Fiori app Manage Banks is the central place to display/create/change this data. It stores address, risk and general data, lets you link house banks, contact persons and business partners to a bank, and supports bank hierarchies. A bank master record is uniquely identified by bank country + bank key. Report RFBKABL0 lists changes to bank master data.

House banks

A house bank is a bank at which your own company holds accounts. The house bank record carries the bank master data, data for electronic payment transactions, and the EDI partner profile / DME details. The payment program uses the house bank ID to decide from which bank to pay.

House bank accounts (Manage Bank Accounts app)

Each account is identified by house bank ID + account ID. The bank account master record offers: general data (account number, holder, IBAN, control key, customer-defined attributes), bank relationship data (internal and bank contacts, bank statement data), connectivity to house bank accounts in the central or remote systems, overdraft limits, multilingual descriptions and attachments.

To pay from an account, it must be assigned to a G/L account. Two approaches exist, chosen per house bank account through the master data:

Example from the course: a company paying through several domestic and several foreign banks needs only two sets of accounts — one reconciliation account with one clearing sub-account per payment method for all local house bank accounts, and the same for the foreign ones. No migration is forced: because the approach is set per house bank account, both approaches can run side by side and a company can move gradually.

Business partner bank accounts

When bank details are entered in a BP master record, you only type bank country and bank key; name and address come from the bank directory. If the bank does not exist yet, it can be created on the fly during BP maintenance. Other ways to get bank master data in: import a country's bank directory with program RFBVALL_0, or (lockbox users) a batch-input session that updates customer bank data.

Lesson 3: Modifying Master Records and FI Documents

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

Master record fields — client (general data) level

Master record fields — company code level

• Terms of payment — cash discount percentages and periods; defaulted into purchase/sales orders and invoices.
• Payment methods — the default list of permitted methods; a method entered directly in the invoice item overrides them.
• Payment block — blocks the whole account; a block can also be set at line-item level or in the proposal.

Customer/vendor clearing

If a business partner is both supplier and customer, payment and dunning can net the two accounts. Prerequisites: enter the customer number in the vendor general data and the vendor number in the customer general data, and tick Clearing with vendor / Clearing with customer in the company code data of both — so each company code decides for itself. Partner relationships can be listed with the apps Display Customer List / Display Supplier List or reports RFDKVZ00 / RFKKVZ00 (Account Control and Status selection).

Alternative payer / payee

An alternative payer (customer side) or payee (vendor side) can be maintained at client and at company code level; the company code entry wins. With the Payer/Payee in document indicator, a one-off payer/payee who is not in the system can be typed into the invoice; alternatively, existing accounts can be listed as permitted payers/payees in the master record and picked at document entry. Effect: the open item is cleared on the original account, but the money is collected from / paid to the alternative partner (classic example: payments to an insolvent vendor go to the bankruptcy administrator). Reports: same customer/vendor lists with the Payment Data selection.

Head office / branch

Some customers order locally through branches but pay centrally. Items posted to a branch account are automatically carried to the head office account, which is dunned and paid. If Local processing is set in the head office master, payment and dunning use the branch account instead. The head office of each branch is visible in RFDKVZ00 / RFKKVZ00.

FI document fields that influence payment

Lesson 4: SEPA Direct Debit

Understand what a SEPA direct debit is, the role of the mandate, and how SAP mandate management supports it.

SEPA Direct Debit (SDD)

SDD is the instrument for collecting euro amounts throughout the SEPA area from accounts that accept collections. Both debtor and creditor need an account at a bank located within SEPA. The creditor initiates the collection via its own bank, based on an agreement with the debtor; the debtor's authorisation for the creditor and the debtor bank is the mandate.

• Pre-notification: unless a shorter period is agreed, the debtor must be informed at least 14 calendar days before the due date. For recurring debits of a constant amount (rent, insurance premiums), one notification listing all due dates is enough.
• Goal: fully electronic straight-through processing, including exception handling (rejects, returns, reversals, refunds, refusals, revocations).
• Between banks, mandate data is exchanged only electronically; between debtor and creditor the mandate can be paper or electronic.

SEPA mandates

The mandate form contains field identifiers followed by space for the data. Identifiers must be in at least one language of the debtor's country of residence; if the creditor cannot determine the language in advance, English identifiers are added. The creditor can personalise the layout. In SAP, mandate management derives most fields from the customer and company code master data, assigns the mandate reference from a mandate-specific number range, and records in the Type of payment field whether the mandate covers a one-off or recurring collection.

Lesson 5: Configuring the Payment Program

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

Configuration entry points

Transaction FBZP (Maintain Payment Program Configuration) presents one button per configuration area; working through the buttons top to bottom guarantees completeness. The same activities are in the IMG under Financial Accounting → Accounts Receivable and Accounts Payable → Business Transactions → Outgoing Payments → Automatic Outgoing Payments → Payment Method/Bank Selection for Payment Program. The first areas (company codes, paying company codes, payment methods per country) normally need little change because SAP delivers many country payment methods with forms.

All company codes

Paying company codes

• Minimum amounts for incoming and outgoing payments — anything smaller is not paid.
• Forms (SAPscript or PDF) for payment advice and EDI accompanying sheet.
• Bill of exchange settings: number of bills per account per run and the due-date window for selecting bill-of-exchange items.
• Sender details: company-code-dependent standard texts for the forms.

Payment methods — country level

For each country you define the valid methods (check, bank transfer, direct debit, ...). Each method specifies: payment type (outgoing/incoming), classification characteristics, master record requirements that must be met (e.g. bank details present), document types for payment and clearing documents, payment medium format for the Payment Medium Workbench, and permitted currencies (empty list = all currencies allowed).

Payment methods — company code level

These company-code-specific settings may differ from one company code to another for the same method.

Lesson 6: Configuring the Bank Selection

Configure how the payment program chooses the paying house bank and account: ranking order, available amounts, accounts, value dates and charges, including the differences under the bank reconciliation account approach.

Bank selection folders

The Bank Selection (bank determination) screen of FBZP is organised in folders per paying company code: ranking order, amounts, accounts, charges and value date. The configuration is complete when all are maintained.

Account determination with the Bank Reconciliation Account approach (self-initiated payments)

When the bank account uses the Cash Account approach, the bank sub-account is no longer taken from the ranking order/accounts folders (IMG: ... Payment Method/Bank Selection for Payment Program → Set Up Bank Determination for Payment Transactions). Instead:

1. Define account symbols for self-initiated payments in Financial Accounting → Bank Accounting → Business Transactions → Payment Transactions → Electronic Bank Statement → Make Global Settings for Electronic Bank Statement.
2. Assign an account symbol to country + payment method under ... Automatic Outgoing Payments → Payment Method/Bank Selection for Payment Program → Assign Account Symbol to Payment Methods.
3. In the EBS global settings, assign G/L accounts to the symbols using masked entries. The clearing account is derived from the G/L account in the house bank account data combined with the mask — e.g. bank account 11000000 and mask +++++++020 give clearing account 11000020.

Lesson 7: Running the Payment Program

Maintain payment run parameters, run and read the payment proposal and exception list, understand payment blocks and edit the proposal.

Payment run parameters

A run is identified by run date + identification (several runs per day are possible). The parameters needed before anything can start:

• Posting date of the payment documents (defaults to the run date).
• "Documents entered up to" date (defaults to the run date) — both can be set in the future when payments are not posted daily.
• Company codes — all must belong to the same country.
• Payment methods — the order typed is the priority order; the first feasible method is used.
• Next payment run date — items that would become due (or lose discount) by then are picked up now.
• Customer/supplier account ranges; optional free selections on document or master fields; optional exchange rate type.

Proposal run

1. Open items are selected according to the parameters.
2. Items are grouped into payments; payment method and bank details are assigned.
3. Items for which no valid method or bank data can be found go to the exception list.
4. Proposal and exception lists are generated for online review or export.

A vendor item is proposed if, by the next run date (including tolerance days), its discount period will have expired, it would only receive a lower discount, or its net due date will have passed.

The proposal list shows partners and amounts (document numbers and discounts depending on line layout) and allows drill-down to change items. The exception list contains items that matched the parameters but cannot be paid; the additional log explains why.

Payment blocks

Additional block reasons can be defined, each with a flag whether it can be changed during payment proposal processing. The debit balance check after the proposal automatically blocks accounts with a debit balance.

Editing the proposal

From the list of proposed payments a clerk can: display the open items in a payment, change payment block and cash discount per item, reassign an item to another existing payment, or create a new payment with a different method/house bank. The saved proposal is then the basis for the actual payment run, in which documents are posted, items cleared and G/L/subledgers updated.

Lesson 8: Executing a Payment Run

Understand what the payment run posts, how bank sub-accounts and payment documents work, how the Payment Medium Workbench creates payment media, and how to schedule runs automatically.

The payment run

Until the payment run nothing has been posted; the items in the proposal are locked so they cannot be paid manually or in another run. The payment run then: posts payment documents and clears the open items, posts related items (taxes, discounts, exchange rate differences), identifies payments for EDI, and hands the data to the media creation/print programs.

Country note: where payment documents may only be posted once the bank has settled, the payment method flag Generate payment order only produces a payment order instead; the payment document is created when the order appears on the bank statement, and the items stay blocked for other clearing in the meantime.

Bank sub-accounts

Separate sub-accounts per flow (outgoing checks, outgoing transfers, incoming checks, incoming transfers) hold the payments until the bank actually debits/credits the account (value date); the bank statement (manual or electronic) then moves them to the main bank account. Benefit: the bank G/L account can be reconciled with the bank at any time.

The payment document

• Document type comes from the country payment method; cross-company-code payments need a second type for clearing postings; both use internal numbering.
• Header text contains run date and identification (e.g. YYYYXXXX-TA##).
• Value date = posting date + days to value date (depends on method, bank account, currency, amount limit); a check-cashing time in master data overrides it for checks.

Payment media and the Payment Medium Workbench

The print run transfers forms, advices and payment summary to print administration, DME data to DME administration and creates IDocs for EDI payments. The PMW is the uniform, generic payment medium program: variants per format are set in Customizing, formats can be changed or created (with the DME Engine, without ABAP), all advices come out in one print file with better sorting, the note to payee is freely defined and assigned per origin and method, and mass performance is improved.

PMW process: SAPFPAYM_SCHEDULE performs the pre-service (sorts payments by format, builds payment groups according to granularity, generates notes to payee), then SAPFPAYM creates the media, accompanying sheets, error log and payment summary, and RFFOAVIS_FPAYM creates advice notes and zero-balance notices. Mapping of system data into the format is done by function modules or by the DME Engine, which lets you build bank-specific file formats where no standard exists.

Granularity: the format defines which fields split the output into payment groups (one file per group) — e.g. company code + house bank gives one file per combination. At least one SAPFPAYM variant per payment group is required. Delivered formats' granularity can be refined but not coarsened.

Note to payee: every PMW format has three reference text types — invoice information (classic note), internal reference (for returned media), external reference (for the partner). Contents come from a format-independent, language-specific content template defined in Customizing or via function module.

Automation

The Fiori app Schedule Accounts Payable Jobs with template "Automatic Scheduling of the Payment Program" lets you define scheduling options (recurrence) and the payment run parameters, so runs happen without manual triggering.

Lesson 9: Explaining Digital Payments

Describe the SAP digital payments add-on: its purpose as a payment hub to payment service providers, its architecture, and the end-to-end credit card payment scenario.

Purpose

The add-on connects SAP (and non-SAP) consumer applications with external payment service providers (PSPs) for secure end-to-end processing of digital payments, mainly incoming credit card payments. It allows credit card payment methods in S/4HANA for incoming payments, covering tokenised settlement, PSP advice and bank statement automatically. A contract with the chosen PSP is required.

It also handles external payments (online/mobile payment systems rather than cards), either as one-step "direct capture" (charge without prior authorisation) or two-step "charge with authorisation".

Architecture

• Consumer application (several S/4HANA apps, listed on the SAP Help Portal) sends the request.
• SAP digital payments add-on on SAP Cloud Platform processes it with a core adapter plus one adapter per PSP, mapping the request into the PSP format.
• PSP communicates via web services, mostly synchronously.

End-to-end example (S/4HANA Cloud for Customer Payments)

1. Card registration: the customer logs on and stores a card; later pays open items by card.
2. Payment run: the AR accountant clears the invoice via automatic or manual credit card payment.
3. Settlement: settled card payments get status In Transfer; the message goes to the PSP and on to the clearing house, whose reply updates the settlement status automatically.
4. Advice: the credit card advice records taxes/charges in the cash position as a memo item.
5. Bank statement: standard FI-AR processing; because statements are highly aggregated, the advice is what gives Finance the detail.

Unit 2: Dunning Program

Lesson 1: Executing the Dunning Program

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

Why dunning?

When a customer does not pay by the net due date, the company sends reminders: a first, friendly one, followed by increasingly firm notices. S/4HANA automates this. The dunning program looks at customer and vendor accounts whose overdue items produce a debit balance, selects the overdue open items, determines the dunning level of the account and produces a dunning notice. Vendors can be dunned too, typically when a credit memo leaves them with a debit balance. If a partner is both customer and vendor, the two balances can be offset against each other before dunning.

The four steps

1. Maintain parameters — define how the run behaves; parameters can be copied from an earlier run and only the dates adjusted.
2. Schedule the dunning run — the program determines accounts and items to dun, dunning levels and all other data, and decides whether a payment reminder or a dunning notice is needed. Everything is stored in one dunning proposal.
3. Change the dunning proposal — the proposal can be edited, deleted and regenerated as often as necessary.
4. Start the printout — notices are printed (or e-mailed) and, in the same step, the dunning data in master records and documents is updated.

It is also possible to print directly after the run without touching the proposal.

Lesson 2: Updating Master Records and FI Documents

Know the fields in the business partner master and in FI documents that control whether and how an account is dunned.

Master record fields (general and company code level, Correspondence tab)

FI document fields

At line-item level you can maintain the dunning area, dunning key (restricts the maximum level or forces separate display), dunning block (blocks only this item) and payment terms (drive the item's due date).

Lesson 3: Configuring the Dunning Program

Walk through every part of a dunning procedure — general settings, levels, charges, minimum amounts, texts and special G/L transactions — and the surrounding environment settings.

Configuration structure

The dunning configuration menu shows one icon per area: dunning procedures, dunning levels, expenses/charges, minimum amounts, dunning texts, special G/L indicator. Work left to right. SAP delivers common procedures with forms; copying one and adjusting the company-code-specific parts is usually enough.

Dunning procedure — general settings

Dunning levels (up to nine)

Expenses / charges

Per procedure and currency, charges are defined by dunning level: fixed amount or percentage of the dunned amount, optionally with a minimum charge; the charges can be printed on the form via text variables.

Minimum amounts

To stop trivial amounts from escalating to high levels, each level has a minimum amount and/or minimum percentage of the overdue items, plus a minimum amount before interest is calculated. If a level does not reach its minimum, its items drop to the next lower level and the check repeats there.

Dunning texts

Per procedure and level you name the form; the program can produce dunning notices, payment advices and payment forms using SAPscript, Smart Forms or Adobe PDF forms.

Special G/L transactions

Special G/L transactions (down payments, bills of exchange, guarantees...) are shown separately in the balance sheet or for internal reasons. The procedure offers a list of special G/L indicators; tick those that should be dunned.

Environment settings

Lesson 4: Running the Dunning Program

Follow a dunning run in detail: parameters, the three internal steps (account selection, line-item dunning, account dunning), due-date and clearing rules, proposal editing, and printing with grouping options.

Parameters

A run is identified by run date (recommended but not required to be the execution date) and identification. The open item selection parameters say which company codes, documents and accounts are scanned. An additional log can be switched on to trace the run, but only for test/training because it is resource-hungry. Parameters can be copied from earlier runs.

The dunning run

The run produces a proposal that can be edited, deleted and recreated. Printing can be triggered immediately after the run, at the cost of not being able to edit. Internally there are three steps:

1. Account selection. An account qualifies if it has a dunning procedure and its last-dunned date plus the dunning interval has been reached.
2. Dun line items. For each selected account, overdue items are identified and given a dunning level.
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 netted against due debit items, starting with the debit items of the highest dunning level. If customer/vendor clearing is active (same dunning procedure on both), due vendor credits are netted as well. After netting, the account must still have a debit balance to be dunned — unless the procedure flag "dun even if balance positive" is set. Each notice must have a debit balance; cleared items are listed on the notice.

Dunning date, grace period, blocks and payment methods

• Due date = day the money was owed; dunning date = day the item is dunned. Every dunned item is overdue, but not every overdue item is dunned — the line-item grace period excludes items that only just became overdue.
• Items with a dunning block go to the blocked items list; accounts with a block go to the blocked accounts list.
• Items or accounts with an incoming payment method are skipped (the payment program collects them) unless they carry a payment block.

Determining dunning levels

• An item's level follows its days in arrears according to the procedure (max. nine levels); the higher the level, the sterner the text.
• Invoice-related credit memos inherit the invoice's level. A level can increase only by one per run — no skipping.
• Procedures with a single level are payment reminders, used for key accounts and public bodies.
• Dunning keys cap the level an item may reach.
• Minimum amount/percentage per level: if the total of items at a level is too small, they fall to a lower level (higher levels normally have higher minimums).
• Minimum days in arrears (account): at least one item must reach it. Course example: items 1, 3 and 4 are overdue beyond the grace period, item 2 is within the grace period; because item 4 reaches the account minimum, items 1, 3 and 4 are dunned and item 2 is not.
• The account receives the highest level of its dunned items and the text is chosen accordingly. Levels are only written to items and accounts at print time, although they are already determined in the run.

Is a notice necessary?

An account is dunned only if the dunning data changed since the last run or the level has the Always dun flag (normal for the last level and for payment reminders). Accounts with a legal dunning procedure start date in the master record follow a different rule: they are dunned if postings occurred since the last run or Always dun in legal dunning procedure is set; the output is an internal note on a special form for the legal department rather than a letter to the customer, and the flag makes sure items posted before the legal procedure started are not overlooked.

Editing the proposal

Supporting lists: dunning statistics, dunning list, blocked accounts, blocked line items, dunning history; a sample printout can be previewed. The clerk can block/unblock accounts and items in the proposal and lower an item's level. Changes to master data or documents do not affect the current run — the proposal must be deleted and recreated. A proposal that will not be printed must be deleted, otherwise its items stay locked for other dunning runs.

Printing

The print program groups items into notices, generates one notice per group, and writes dunning date and level into items and accounts, printing in the order given by sort criteria. For one-time customers only the item data is updated. SAP Note 6591 describes how to undo dunning data changes.

Grouping rules: items go on the same notice when company code, dunning area and account match (one-time accounts: same address). Special groupings:

• Dunning by level — company-code setting for one notice per level, text chosen per level.
• Grouping key — in the master record; groups items with equal values in fields of BSID/BSIK.
• Local processing — head office normally gets one notice for all branches; if set in the branch accounts, branches are dunned locally.
• Cross-company-code dunning — assign company codes to a dunning company code; one notice combines a customer's items from all of them using the procedure in the dunning company code, while interval and blocks are checked per company code. A legal dunning date in the dunning company code also applies to dependent codes.

Payment forms and advices: a bank transfer form (Germany) or ESR form (Switzerland) can be attached or printed on a separate page (requires a form window or separate form); the notice may contain only company code currency items. The payment program can create a payment advice (type 08, 10-digit number starting with 08, type must be configured) listing the dunned items so the incoming payment can be assigned; its number can be printed on notice and form.

Unit 3: Correspondence

Lesson 1: Explaining Correspondence

Define correspondence and explain why a company automates it.

What correspondence is

Correspondence is any formal communication between the company and a customer or vendor that relates to the financial transactions recorded in the system. The correspondence function can automate most periodic mailings, run on demand, or be triggered automatically after specific transactions (for example a payment with a difference). Typical outputs: 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 formally performs and documents communication with third parties. By sending a partner your view of the account, you verify that both sides have a consistent picture of all transactions, so errors and misunderstandings surface early and can be corrected proactively.

Lesson 2: Modifying Master Records

Identify the fields in the customer/vendor master record that correspondence uses.

Structure of the account segments

The master record is split into general data (address, control data, payment transactions) and company code data (account management, payment transactions, correspondence, insurance, withholding tax). Correspondence draws on both.

Lesson 3: Configuring Options for Correspondence Types

Distinguish the ways correspondence can be triggered and the two-step request/print process.

Ad-hoc versus automatic

Three kinds of correspondence

• Periodic — triggered at a regular interval specified in the master record (weekly, monthly...), e.g. account statements.
• Online — requested by the user while manually processing payments or from the line item display.
• Correspondence for postings — configured in Customizing to be generated for specific postings, typically payment differences.

The creation process

1. Request. The system records which correspondence types are to be produced (a correspondence request).
2. Print. Periodic correspondence (dunning letters, account statements) is printed at a fixed rhythm (daily, weekly); individual requests can be printed on demand. The print request goes to the spool and then to the chosen printer, or is transmitted electronically (e-mail).

Lesson 4: Creating a Correspondence

Configure correspondence types, their print programs and variants, and link them to online transactions and to payment-difference reason codes.

Correspondence types

A correspondence type represents one kind of letter; every letter you need requires its own type. Users can choose a type manually during a transaction, or rules can pick it automatically. SAP delivers standard types; to adapt one, copy it first, because standard types are overwritten by upgrades.

Properties of a correspondence type: which data is required (account number, document number), whether additional free text may be added to the form, whether the type may be used cross-company-code (requires assigning company codes to a correspondence company code in Customizing), and how many date fields are needed. Required data is either typed by the user or derived automatically once the type is chosen. Payment notices, account statements, bill of exchange charges statements, internal documents, individual letters and document extracts can be used in all company codes.

Print program and variant

Each correspondence type gets a print program and a selection variant (per company code if desired); the variant also selects the printer. A type can have several form letters distinguished by form ID; the form ID is placed in the variant so the correct form is printed. Forms can be adapted with logo, address and additional text.

Linking to transactions

You define which correspondence types are offered in which online functions (e.g. payment notices in payment transactions; account statements in document entry, payment processing, document display/change and account editing). This assignment also makes new types visible in the Fiori app Create Correspondence. Assignments can be company-code-specific; if none exists for a company code, the company-code-independent entries apply.

Linking to reason codes (payment differences)

For each tolerance group you can set a default correspondence type for payment differences:

• Enter a type in Message required to always send the same notice; leave blank to choose during payment settlement.
• Tick According to reason code to let each reason code carry its own correspondence type (e.g. reason code MD "miscellaneous deduction" sends a letter asking for an explanation of a short payment).

Decision logic: the reason-code type is used only if all reason codes in the document point to the same type. If line items carry reason codes with different types, or reason codes without a type, the system falls back to the type of the tolerance group.

Example from the course: tolerance group type SAP01; a customer pays part of an invoice two months late. During manual processing you create a residual item with a reason code and request SAP01, post the document, then process the correspondence request — the system prints the payment notice from master data and line item information.

Unit 4: Special General Ledger Transactions

Lesson 1: Managing the Application View for Special G/L Transactions

Explain the concept of special G/L transactions, their classes and types, and work through the business processes for down payments, individual value adjustments and guarantees of payment.

Reconciliation accounts

Every customer or vendor master record holds a reconciliation account in its company code segment. Each subledger posting (invoice, credit memo, payment) is simultaneously posted to this G/L account, so totals for receivables and payables are available in the general ledger at any time and financial statements can be produced without reading the subledger. The reconciliation account number appears in the FI document, and its transaction figures are updated with each posting.

Alternative reconciliation accounts

Some AR/AP transactions must be shown separately in the G/L and subledger — for internal reasons or for reporting rules; for instance, down payments may not be shown in the balance sheet together with trade receivables/payables. When a line item is posted with a special G/L indicator, the system does not use the reconciliation account from the master record but an alternative reconciliation account (special G/L account) assigned in Customizing. These postings are called special G/L transactions.

Special G/L classes (business purpose)

Special G/L types (technical posting behaviour)

Example of a statistical posting: you guarantee EUR 10,000 for a customer. The liability appears on the customer account and on the special G/L account "guarantees of payment made", with the automatic offsetting entry on the clearing account for guarantees made. When the liability ends, the guarantee is cancelled (reversed). Guarantees made are reported in the notes; guarantees received are not displayed.

Example of a free offsetting entry: the customer answers a down payment request by paying EUR 11,000. The payment is recorded on the customer account and on the alternative reconciliation account "down payments received"; the bank account to be debited is chosen during entry. Because the customer paid before the service was delivered, the amount is a payable, so it must not touch the receivables reconciliation account; the special G/L account is reported under payables. After invoicing, the down payment is transferred/cleared.

Down payment procedures

Customer side:

1. Down payment request (noted item; no balance change; can be dunned and collected automatically — collection authorisation needed).
2. Down payment received (shown as a payable on the "down payments received" alternative reconciliation account).
3. Customer invoice for the goods/services.
4. Down payment cleared against the invoice — it ceases to be a down payment and becomes a payment on the normal reconciliation account.
5. Remaining balance is paid and cleared.

Vendor side: post the down payment request, enter the down payment made, receive the vendor invoice, clear the down payment, clear the final payment. Vendor down payment requests exist so that the payment program can execute down payments.

Individual value adjustment

At year-end, disputed or doubtful receivables are recorded as individual value adjustments. Because the entry hits both the customer account and the special G/L account "individual value adjustments for receivables", the special G/L procedure applies:

1. The receivable exists on the customer account.
2. The adjustment (without tax) is posted; the expense lands on "expense for individual value adjustment" for the income statement.
3. After the balance sheet key date the adjustment is cleared (reversed).
4. If the receivable turns out to be uncollectable, the final write-off is posted to "expenses for uncollectable receivables" — on the regular reconciliation account, not the special G/L account.

Guarantees of payment

Customer: a guarantee made (EUR 10,000) is posted on the customer and automatically on the special G/L account, offset against the clearing account "guarantee made"; posting (1) creates, posting (2) cancels. Vendor: a guarantee received from a vendor is shown on the vendor account and a special G/L account in the same way. Both are stored as transactions with automatic offsetting entries.

Lesson 2: Maintaining Special G/L Transactions

Configure special G/L transactions: posting keys, special G/L accounts, indicator properties and account determination for the three types.

Posting keys

Special G/L transactions are entered with dedicated posting keys that carry the "special G/L" flag, always together with a special G/L indicator:

Special G/L accounts

The alternative accounts are created as G/L accounts in FI and defined as reconciliation accounts for account type D (customers) or K (vendors). Their field status group controls the entry screen layout. Special G/L transactions are never posted to the reconciliation account from the master record.

Properties of a special G/L indicator

The indicator is defined per account type (customer and vendor down payments are configured separately). Standard content is delivered; adjustments can be: different reconciliation/special G/L account numbers, other posting keys or indicators, and other automatic-posting settings (accounts, posting keys, account assignment rules).

Account determination

Per chart of accounts, the special G/L account is stored against the combination of reconciliation account (from the master record) and special G/L indicator; at posting time the system reads the master record's reconciliation account and substitutes the special G/L account. For statistical postings, the automatic offsetting account is defined per account type + indicator in the table of accounts for automatic postings.

Setting up your own indicators

• Noted item — e.g. to track which customer currently holds a returnable container: create an indicator flagged as noted item and assign an alternative reconciliation account; only the customer/vendor account shows the reminder.
• Statistical with automatic offsetting — assign the alternative account and additionally a clearing account in the automatic postings table (as for guarantees).
• Manual (free) offsetting — assign the alternative account; the user keys in the offsetting account during posting.

Lesson 3: Understanding Purchasing (MM Integration)

Understand the three-way match in procurement and how down payments linked to purchase orders are posted and cleared in Logistics Invoice Verification.

Three-step reconciliation (three-way match)

1. Purchase order — created only in MM; no FI posting.
2. Goods receipt — material document in MM updates stock; an FI document debits the stock account (or consumption account for consumables) and credits the GR/IR clearing account.
3. Invoice receipt — the vendor invoice posted in MM creates an FI document: debit GR/IR, credit vendor.

Goods receipt and invoice receipt may arrive in either order. The GR/IR account is managed on an open item basis so that every invoice can be matched to a receipt and vice versa. FI document types for these postings are set in configuration.

Down payments with purchase orders

Business function LOG_MMFI_P2P must be active. Since EhP4 down payments/requests can be controlled from the purchase order and cleared in the vendor invoice; since EhP5 this also works with active document splitting. Process:

1. Create the purchase order and enter the down payment information (the vendor wants a down payment).
2. Post the down payment via the Down Payment Monitor (ME2DP).
3. Post the goods receipt with reference to the PO as usual.
4. Post the invoice in Logistics Invoice Verification with PO reference; the system warns that a down payment exists for this order and allows clearing the down payment inside the invoice transaction.

Lesson 4: Understanding Sales and Distribution Integration

Follow the sales process from order to billing and see how down payment requests and down payments agreed in a sales order flow into FI as special G/L transactions.

Phases of a sales transaction

1. Sale — the sales order is created; it is an SD document with no FI posting.
2. Shipping — a delivery document is created; picking via a transfer order in warehouse management; the goods issue creates an MM material document and an FI document (debit cost of goods sold, credit stock). Billing is possible only after the goods issue.
3. Billing — the billing document is created in SD, the customer gets the invoice, and an FI document posts debit customer / credit revenue.

The document flow shows all documents belonging to one transaction.

Down payments in SD

• A down payment agreement is entered in the sales order as a billing plan. When the billing date is reached, a down payment request is created with billing type FAZ, a letter with amount and due date goes to the customer, and FI receives a noted item with special G/L indicator F.
• When the customer pays, the incoming payment is assigned to the request (select the open request, "Add Down Payment") and posted with special G/L indicator A; it appears among the AR open items and the request shows as cleared in the SD document flow.
• With partial or final invoices, the down payments are transferred as "down payments to be cleared": they leave the special reconciliation account and move to the customer's normal reconciliation account, so they appear among the customer's open items and reduce total receivables.

Unit 5: Parking Documents

Lesson 1: Managing Document Parking Basics and Document Holding

Distinguish holding a document from parking a document and know when each is appropriate.

The problem

An accountant is keying a ten-line document and cannot determine the cost centre for line nine. The document is incomplete, so it cannot be posted; if entry is abandoned, everything typed so far is lost. The department needs a way to save the data entered so far and resume later. SAP offers two mechanisms: Hold Document and Park Document.

Holding documents

• Temporarily saves the data entered; the document may be incomplete.
• No document number is assigned — the user gives the held document a name and retrieves it under that name.
• No account balances are updated and the data is not available for any evaluation.
• Later the user can complete, post or delete it. Risk: held documents are easily forgotten because they are invisible to everyone else.

Parking documents

• Also saves incomplete documents without the full input checks, but the system assigns a real document number from the document type's number range (an externally assigned number must be supplied).
• Transaction figures are not updated, yet the data is available for real-time evaluations — e.g. amounts in parked documents can be included in the advance return for tax on sales/purchases.
• Available for classic posting transactions and for the new posting screen.
• Parked documents can be completed, changed, posted or deleted later; they must be complete before they can become proper FI documents; unneeded ones should be deleted.
• Substitutions are not supported for parked documents — they apply only once the document is turned into an accounting document.
• Parking is the more powerful tool and is widely used to implement the dual-control principle (one person enters, another checks and posts), with authorisations modelling areas of responsibility.

Lesson 2: Processing Parked Documents

Create, change, post and delete parked documents, and understand what changes when a parked document becomes a posted one.

Creating parked documents

• Possible for customer accounts (invoices, credit memos), vendor accounts (invoices, credit memos) and G/L account postings.
• Account assignment templates can be used; reference documents (post with reference) cannot.
• Cross-company-code transactions can be parked: only one parked document is created in the initiating company code; on posting, two documents linked by a cross-company-code number are created.
• On saving: no transaction figures, asset values or control totals are updated, no automatic postings are generated, and the balance is not checked — although the document overview shows the current balance.

Uses: temporary storage of input, multi-level models (dual control, approval procedures), and work distribution through worklists to speed up processing. The usual path is edit → post; deletion is the exception.

Editing

Header and line item fields and amounts can be changed as often as needed — dates, amounts, accounts, account assignment objects. The document change rules that restrict posted documents do not apply. Fields that cannot be changed: currency, document type, document number, company code.

Posting

Parked documents are posted individually or via a selection list; after a mass post the system lists which ones succeeded, and those that failed (e.g. missing cost assignment) can be post-processed from the list. A batch input session can also be generated. On conversion to a regular document:

1. All normal posting checks run.
2. A complete FI document is written to the document database.
3. The change history of the parked document is kept.
4. The document number is retained — the parked number becomes the posted number (a deleted parked document's number cannot be reused).
5. Transaction figures are updated and the parked document is deleted.
6. The original entering user is recorded in the document header.

Reporting

Parked documents are integrated into account display and FI reporting: many reports can include them, they can be shown in the document journal and in the line item display.

Lesson 3: Managing Document Parking and Workflow

Understand SAP Business Workflow basics, the release procedure for parked documents (workflow variants, release groups, approval paths, subworkflows) and the Flexible Workflow for general journal entry verification with its Fiori apps.

SAP Business Workflow

Workflow automates the hand-over between people in a business process, even across systems, and delivers to each participant the information needed for the next step. SAP ships workflow templates that can be adapted or replaced by custom ones. Designing a step means answering three questions: what has to be done (object type and method), who does it for dialog steps (possible processors), and what text the recipient sees in the inbox (the task text). Typical workflow uses: posting invoices, releasing purchase requisitions, changing material masters, approving leave, creating customer accounts, deleting purchase orders, Internet requirement requests.

Work items appear in the Fiori app My Inbox, where they can be released, rejected, suspended or forwarded, and the workflow log can be inspected.

Release procedure for parked documents (classic workflow)

1. Define workflow variants in FI Customizing, stating whether document release is active and the minimum amount from which release is required.
2. Assign company codes to workflow variants — one variant may serve several company codes; a company code without a variant has no release.
3. Use the release group field in customer/vendor master records to apply different procedures to different partners (blank = initial release group).
4. The release approval path is derived from workflow variant + document type + release group.
5. Approval path + amount determine the subworkflow and the responsible releasers.

The subworkflow is triggered when the parked document is first entered. Tasks can normally have several possible processors.

General journal entry verification (Flexible Workflow)

S/4HANA supports both the classic SAP Business Workflow and the Flexible Workflow, which lets key users define approval processes without development. Status flow of a journal entry:

The requester creates/edits entries and tracks their status in a worklist (can copy, edit and resubmit). The processor — a member of the groups defined in Customizing — approves, rejects or suspends from the inbox. The four-eyes principle is enforced by excluding the requester from verifying their own entry even if they belong to the approver pool. Past approvals are visible in the processor's outbox.

Minimal configuration

1. In Manage Workflows, add a new workflow; give it a name, optional description and validity period.
2. Define start conditions — combinations of account group, threshold amount, cost centre, company code, journal entry type.
3. Define the step sequence (e.g. verify, post), step conditions and exception handling.
4. In Manage Teams and Responsibilities, create teams; members are assigned functions that decide which step they may approve. Recipients of a step can be a role or a team.

Unit 6: Validations and Substitutions

Lesson 1: Understanding the Basics of Validation and Substitution

Understand what validations and substitutions do, where they can be applied (application areas and callup points), how rules are entered in the formula editor, and how they are assigned and activated.

Validation versus substitution

Five steps to implement

1. Decide the application area.
2. Choose the callup point.
3. Define the validation/substitution.
4. Assign it to an organisational unit (company code for FI; company code or company for FI-SL; controlling area for CO). One object may be valid for several company codes.
5. Activate it for the callup point.

Application areas

Each application decides which structures and fields it releases for validation/substitution; the area plus callup point define the pool of fields you may use in prerequisites and checks.

Callup points in FI

Application area + callup point determine the boolean class, which fixes the available fields (dimensions) and the message classes usable for validation messages. Data already known from earlier callup points (user name, header data) can be reused at later points.

Formula editor

Statements are built with buttons for operands (table fields, sets, exits), logical operators (AND, OR, NOT) and comparison operators; each entry is checked step by step, including parentheses, so only syntactically correct statements can be saved. Display settings: Short descriptions (default), Technical names (table-field names), and Expert mode, which shows technical names and lets you type the statement directly.

Assignment and activation

For each combination of organisational unit and callup point only one validation and one substitution can be active. Activation levels:

Lesson 2: Maintaining and Executing Validations

Build validations from steps (prerequisite, check, message) and master the boolean statement syntax, including partial-field checks and pattern matching.

Why custom validations

Most input is already checked by programs, tables and master data, but company-specific rules (only certain accounts for closing entries, only certain cost centres for certain expenses) cannot be standardised. Validations give G/L, AR and AP owners extra control over data consistency.

Step structure

A validation holds up to 999 steps. Each step has:

1. Prerequisite — if true, the check is executed; if false, the step is skipped.
2. Check — a boolean statement; if it evaluates to false, the message is issued.
3. Message — predefined or new; up to four variables filled with field values using & placeholders.

Course example (callup point 2): if account 61003000 is entered, check that the cost centre is not an administration cost centre; otherwise an error message forces a correction. Another example: compare document date and posting date and warn if they differ.

Statement syntax

Simple statements can be combined with AND/OR/NOT into complex ones.

Lesson 3: Maintaining and Executing Substitutions

Define substitutions with prerequisite and replacement, and choose between the constant, exit and field-to-field substitution methods.

Purpose

The system already derives some values automatically (business area or profit centre from a cost centre or internal order). Substitutions add customer-specific derivations — filling the Assignment field or segment text by your own rules, or deriving a profit centre from combinations of expense account, material number and region. FI staff must check case by case whether substitution is appropriate for the field.

Step structure

Up to 999 steps; each has a prerequisite and a replacement. If the prerequisite is true, the replacement is performed and the transaction continues with the substituted value(s); if false, nothing changes. Example: functional area is filled depending on the cost centre type. One step may replace several fields. The prerequisite uses the same syntax as validations and may include rules and sets.

Substitution methods

The target field must be released for substitution. For each chosen field a dialog asks for the method:

Lesson 4: Using Additional Techniques for Substitutions and Validations

Use rules to encapsulate reusable logic and sets (including multisets) to replace long boolean lists and perform cross-validations.

Transport recommendation

Validations, substitutions and rules should be created only in the development or test system and transported to production.

Rules

A rule is a named boolean statement (name up to 11 characters) that can be used inside a prerequisite, a check or another rule. Technically it is nothing more than a stored prerequisite/check, but it lets you summarise complex logic and reuse it — e.g. a long prerequisite needed both in a validation and in a substitution. Example: RULE1 AND BKPF-BLART <> 'SB' — the system evaluates RULE1 first, then the document type condition. Rules may also appear in statements with arithmetic processing and in matrix validations at callup point 3.

Sets

A set is a flexible, centrally maintained data structure holding ordered values or hierarchies; it is used throughout FI-SL — in validation formulas, substitutions and ledger selection, allocations (assessment/distribution), planning, roll-ups and currency conversion. For performance, prefer basic or single-dimension sets over long boolean lists or user exits. Syntax: table-field IN setname.

• Example 1: if the user is in set USER-GROUP, check that the account is in set ACCOUNT-MANAGEMENT.
• Example 2 (multiset): a multiset combines sets for several fields (dimensions) to cross-validate characteristics. If one of the expense accounts 61003000, 61004000, 61005000 or 61006000 is entered, the cost centre must be the corresponding one (TA##1100, TA##1200, TA##1300 or TA##1400).

Unit 7: Data Archiving in FI

Lesson 1: Outlining the Basics and Classifications of Data Archiving

Define data archiving, explain the reasons and legal constraints behind it, the roles involved, and the generic three-step process.

Why archive?

Large database volumes slow down queries for users and increase administration effort. Data that is no longer needed in daily operations should therefore leave the database — but it cannot simply be deleted, because read access must remain possible (auditors, tax authorities, complaints). Archiving moves the data to external storage in a hardware- and software-independent format so it stays readable even after upgrades.

• Technical reasons: better and more stable response times, more efficient database administration, shorter downtimes for upgrades, recoveries and offline backups.
• Legal and business requirements: data privacy and protection, access for auditors, potential reuse of data.
• Retention periods for documents, master data and transaction figures differ by country; the FI application manager agrees them with the department, auditors and other bodies, and they drive the archiving procedures, timing and retention settings.

Roles

The system administrator executes archiving. The FI application manager does not run it but coordinates with the FI department, ensures compliance with regulations, performs the FI-specific Customizing, works closely with Basis and monitors the procedure as the department's representative. Long-term goals: keep database volume roughly constant and archive proactively, not reactively.

The archiving process

1. Write — the write program reads the data to be archived from the database and creates one or more archive files.
2. Store — the archive files are placed in an external document storage system and administered so they can be accessed later.
3. Delete — the deletion program reads the archive file and only then deletes the corresponding records from the database.

Writing and deleting alone is not enough; the files must be stored and managed so they remain accessible.

Lesson 2: Maintaining Data Archiving

Understand the archiving object and the three Customizing levels (Basis, cross-object, object-specific) reached from SARA.

Archiving objects

Data archiving is the consistent transfer of complete data objects from SAP database tables to a storage system outside the database. Because a business object's data is spread over many tables, the archiving object bundles all logically related tables so that everything belonging to the object is removed together. It is the smallest unit that can be archived and deleted in its entirety. Components:

Archiving Customizing

Opened via the Customizing button on the initial screen of SARA (SAP Easy Access → Tools → Administration → Administration → Data Archiving). Usually performed by Basis/system administration.

Lesson 3: Executing Data Archiving for Specific FI Objects

Follow the FI archiving sequence — documents, transaction figures, compression run, master data — including the checks, archiving objects, programs, the special behaviour of ACDOCA in S/4HANA, and how archived data is accessed.

Process flow and dependencies

Because the universal journal (ACDOCA) is the single line item table for all of accounting, archiving objects depend on one another: an object may be archived only after its predecessors. Example: archiving ACDOCA entries without archiving Asset Accounting would leave statistical asset line items with the asset master data and break asset reporting. The course concentrates on FI-GL: FI documents → FI transaction figures → compression run → master data. Normally documents go first; transaction figures and master data follow once the document-based checks no longer block them, although a company may choose to archive only documents long-term. SAP Note 2659820 removes Material Ledger as a prerequisite in the sequence.

Running an archiving procedure (SARA → Write)

Archiving runs as a background job: it selects data objects, checks each one's archivability and writes qualifying objects to the archive file; if configured, deletion starts automatically when a file is closed, otherwise the deletion job is scheduled manually by selecting the archive files to process.

1. Archiving variant — defines the data selection and whether it is a test or production run; variants can usually be reused only after the related jobs are deleted.
2. Execution user — needs authorisation object S_ARCHIVE (restrictable per archiving object), authorisations for the underlying transactions, and background authorisation S_BTCH_JOB.
3. Start time — as for standard background jobs.
4. Spool parameters — logs can be long, so avoid immediate output to a device.

Monitoring: job logs and spool lists, CCMS monitor sets, the Fiori app Monitor Archiving Jobs, SM37 (reachable via Job Overview in SARA) and the short log under Administration in SARA. The default log records archived object count, affected tables, processed entries and file sizes; application-specific logs can go down to document level. Because spool clean-up deletes logs, decide where to keep them (e.g. external storage).

Archiving FI documents (FI_DOCUMNT)

Document type and account type runtimes are set per company code in Customizing. The program checks header and items; if any condition fails, the entire document stays.

Runtimes are measured against a key date given per run (default: execution date). Object FI_DOCUMNT covers FI-GL, FI-AP and FI-AR documents plus their change documents, SAPscript texts and ArchiveLink entries.

S/4HANA specifics:

• ACDOCA rows with BSTAT = C are treated as archived, totals-only entries and are hidden from line item reports (FAGLL03) and document display (FB03).
• In ECC, secondary index tables kept line item data longer for reporting performance. In S/4HANA the indexes are derived at runtime; to keep them longer than the documents, use BAdI FI_DOCUMNT_IDX_DEL with index runtime settings, which fills backup tables such as BSIS_BCK / BSAS_BCK (SAP Note 2519099).
• Customer/vendor transaction figures are computed from BSEG at runtime; since BSEG rows are deleted, the delete job writes totals for the archived documents to KNCX_DIF (customers) and LFCX_DIF (vendors).

Accessing archived documents

Archived data must remain readable for complaints, analyses and audits. Transactions with archive access include FB03 / FB03L, FBL1N, FBL3N, FBL5N and FAGLL03. The line item browsers FBL1H / FBL3H / FBL5H have no standard archive access but can be enabled via a BAdI (SAP Notes 2180685, 2316951). Newer OData/INA-based programs offer no archive access.

Archiving transaction figures

Transaction figures are the debit and credit totals per account. AP/AR figures are derived from unarchived BKPF/BSEG plus the totals in LFCX_DIF/KNCX_DIF; G/L figures come from ACDOCA items including those with BSTAT = C. They must remain for at least two years and can be archived only when all posting periods in the range are closed. Archiving them is not a prerequisite for the compression run; it serves data privacy and protection.

AP/AR: the delete step adjusts the x_DIF totals so that they plus the unarchived ACDOCA documents net to zero; once all underlying documents are gone, the x_DIF entry is removed. G/L: the write job copies ACDOCA records to the archive; the delete job adds an offsetting record with inverted sign, so both BSTAT = C records sum to zero and nothing is displayed — no physical reduction yet.

Compression run

Document archiving only flags ACDOCA rows, and transaction-figure archiving even adds rows. The compression run (FINS_ARC, monitor FINS_ARC_MONITOR) is the first step that actually shrinks ACDOCA, without changing the end-user business view. Qualifying entries (e.g. documents already archived, see SAP Note 2346296) are replaced by an aggregate whose granularity follows the balance carryforward settings (Financial Accounting → General Ledger Accounting → Periodic Processing → Carry Forward → Enter Detail Specifications for Balance Sheet Accounts / for P&L Accounts) combined with the posting period. With SAP Note 2518769 the run writes its identification into ACDOCA-SGTXT. If the aggregate nets to zero (documents and transaction figures both archived), the old entries are deleted and no aggregate is created. After document archiving the effect is memory reduction; after transaction-figure archiving it also fulfils data-protection deletion requirements. The SAP Universal Journal Detailed Analysis Service and DVM Cloud Solutions help analyse ACDOCA content and plan the steps.

Archiving FI master data

G/L accounts, customers, vendors and bank data can be archived once the business agrees and legal requirements are met. Typical path: set a posting block when the record is no longer needed, then manually set the deletion flag; the flag is one of the conditions the archiving program checks (so only responsible staff should be authorised to set it). Other checks for G/L accounts include whether documents and transaction figures still exist. There is no default minimum runtime of 999 days, and master data runs can be restricted to subsets. In S/4HANA customer/vendor data lives in the business partner, so customer/vendor master data must be archived before the business partner object CA_BUPA.