SAP S/4HANA rewrote the core ERP application to fully exploit the capabilities of the SAP HANA database. Key pillars:

• In-memory computing: The entire database fits in RAM, eliminating disk I/O bottlenecks. Both OLTP and OLAP run on the same data in real time (HTAP – Hybrid Transactional/Analytical Processing).
• Simplified data model: Aggregate tables (FAGLFLEXT, BSAD, etc.) are eliminated. All data flows into the Universal Journal (ACDOCA), reducing storage by up to 70%.
• Intelligent Enterprise: Embedded machine learning, AI, and robotic process automation (RPA) are built into business processes.
• Deployment options: Cloud (Public / Private Edition) or On-Premise. One code line ensures consistency.

SAP Fiori is the user experience layer for SAP S/4HANA. It follows five design principles:

• Role-based: Each user sees only the applications relevant to their role.
• Responsive: Works across all screen sizes – desktop, tablet, and mobile.
• Simple: 1 user, 1 use case, 3 screens maximum per app.
• Coherent: Consistent look and feel across all SAP products.
• Instant Value: Low barrier to adoption with minimal training needed.

The Universal Journal enables continuous accounting – postings flow through Accounting → Compliance → Entity Close → Intercompany → Consolidation → Disclosure in one integrated flow.

• FI line items (previously BSEG): now in ACDOCA
• CO line items (previously COEP): now in ACDOCA
• Asset Accounting values: now in ACDOCA
• COPA actual values: now in ACDOCA
• Plan data: stored in ACDOCP

A G/L account is created at two levels (FS00 maintains both centrally; FSP0 = chart of accounts segment only; FSS0 = company code segment only).

G/L Account Types (S/4HANA)

Important Control Fields

• Reconciliation account for account type (D / K / A): Subledger postings (customer, vendor, asset) update this account automatically. Direct manual posting is blocked.
• Open item management: Account items must be cleared by offsetting postings (bank clearing, GR/IR, salaries payable). Enables F-03 clearing and open item lists.
• Line item display: In S/4HANA, always technically available via ACDOCA; the flag controls the classic FBL3N behaviour.
• Only balances in local currency: Required for clearing accounts posted in multiple currencies (e.g., GR/IR) so differences do not arise from exchange rates.
• Tax category: “-” input tax only, “+” output tax only, “*” all tax types, “<” input tax account, “>” output tax account; “Posting without tax allowed” permits tax-free postings.
• Field status group: Determines which fields are Suppressed / Required / Optional on the posting screen. Linked to the Field Status Variant assigned to the company code (OBC4).
• Sort key: Fills the “Assignment” field automatically (e.g., 001 posting date, 009 external document number, 031 customer number).

Account Groups (OBD4)

Account groups classify G/L accounts (e.g., SAKO liquid funds, ERG P&L, ANL fixed assets, MAT materials) and control (1) the number range interval and (2) the field status of the master record. The number range of the account group must be respected when creating an account.

Retained Earnings Account (OB53)

Each P&L account is assigned a P&L statement account type (usually “X”) which points to a retained earnings account. At balance carryforward, the P&L balances are transferred to this account. More than one retained-earnings account is possible (e.g., for different equity presentations).

Every posting creates an FI document consisting of a header (document date, posting date, document type, period, currency, reference, header text) and 2 – 999 line items (posting key, account, amount, tax code, cost object, text). In S/4HANA the complete journal entry is stored in table ACDOCA; BKPF remains the header, BSEG is kept for compatibility (compatibility views for BSIS/BSAS/BSID/BSAD/BSIK/BSAK).

Document Types (OBA7)

Document type controls: number range, allowed account types, reversal document type, “net document type” (cash discount deducted at invoice), required reference / header text, exchange rate type for FX, and authorization group. Number ranges (FBN1) are defined per company code and fiscal year (year-dependent or “9999” year-independent), internal or external.

Posting Keys (OB41)

The posting key controls debit/credit, account type, and field status of the line item (combined with the account’s field status group – the stricter of the two wins, except “Required” + “Suppressed” is an error). In Fiori / Enjoy transactions (FB50, FB60, FB70) the posting key is derived automatically from the Debit/Credit indicator.

Posting Periods (OB52)

The posting period variant has one row per account type (+ all, A, D, K, M, S) with ranges of accounts and two (in S/4HANA three) period intervals: Interval 1 (normally the current period, can be restricted by authorization group), Interval 2 (usually special periods 13–16 for year-end adjustments), and Interval 3 (for CO postings only). The system derives the period from the posting date and the fiscal year variant and checks that it is open.

Reference Documents and Posting Aids

• Post with reference (FB50 → Post with reference / FBR2): Copy an existing document, optionally reversing or generating a new one.
• Account assignment model (FKMT): Template with fixed accounts and equivalence numbers to distribute amounts.
• Sample documents (F-01): Stored under number range X2, never update balances; used as templates.
• Recurring entries (FBD1 create, FBD3 display, F.14 execute, F.15 list): Document stored in number range X1; the recurring entry program posts it on scheduled dates (interval or run schedule), e.g., rent, insurance, leasing.
• Hold (F-02 → Hold) vs Park (FBV1 / FV50): Held documents are personal and have a temporary ID; parked documents receive a real document number, can be reported, changed by others, released via workflow, and posted with FBV0.

Reversal

Individual reversal FB08, mass reversal F.80. The reversal reason (OBXK) controls whether (a) a negative posting is allowed – reducing the transaction figures instead of inflating debit and credit – and (b) an alternative posting date may be used. Accrual/deferral documents (FBS1) are reversed with F.81 on the reversal date stored in the document.

• Account clearing (F-03 G/L, F-32 customer, F-44 vendor): Select open items with a zero balance – generates a clearing document without line items (unless differences or exchange rate differences arise).
• Post with clearing (F-28 incoming / F-53 outgoing payment, F-30): Enter a payment line and simultaneously clear the open item(s).
• Automatic clearing (F.13 / F13E): Clears items with identical values in the criteria defined in OB74 (e.g., assignment, reference, business area) – typical for GR/IR and bank clearing accounts.
• Payment differences: within tolerance → cash discount adjustment or expense/revenue posting (OBXL reason codes); outside tolerance → residual item (new open item for the remainder) or partial payment (original item stays open, payment posted with reference) or posted on account.
• Resetting clearing (FBRA): Reverses the clearing; optionally reverses the clearing document as well.
• Exchange rate differences on clearing: Realised FX gains/losses are posted automatically to the accounts defined in OBA1 (KDF) per reconciliation / G/L account.

Ledger Types

Ledger groups let you post to a subset of ledgers (ledger-group-specific postings FB50L / FB01L). A ledger group with the same name as the ledger is created automatically. Documents with ledger group get a representative ledger that determines period checks.

Currency Types

Translation uses exchange rate types (M average, B bank buying, G bank selling, EURX for euro cross rates) with validity date, maintained in OB08 / TCURR. Translation ratio (OBBS) and direct vs indirect quotation are defined per currency pair.

Accounting Principles and Valuation

An accounting principle (e.g., IFRS, LGAAP) is assigned to a ledger group (OB_ACCPRINC). Valuation areas (foreign currency valuation, asset depreciation areas) are linked to accounting principles so that valuation results post only to the ledgers of that principle.

In S/4HANA, vendor master data is managed as a Business Partner (BP) with role FLVN01 (FI Vendor).

• General Data: Name, address, bank details, communication.
• Company Code Data: Payment terms, payment methods, reconciliation account, withholding tax, dunning data.
• Purchasing Data (MM): Purchasing organization, incoterms, order currency.

The reconciliation account links the vendor subledger to the GL automatically: every AP posting generates a corresponding GL entry to the reconciliation account.

Business Partner transaction BP replaces FK01/FK02/FK03 (and XK01). BP categories: Person, Organization, Group. Relevant BP roles: 000000 General, FLVN00 Supplier (purchasing), FLVN01 FI Supplier. Customer–Vendor Integration (CVI) synchronizes the BP with the classic tables LFA1 / LFB1 / LFM1, which remain as the technical persistence.

• One-time vendors (CPD): Account group with only generic data; address and bank entered at invoice time.
• Alternative payee: Payment goes to another BP (defined in general data for all company codes, or in company-code data; “Individual spec.” allows entry per document).
• Head office / branch: Postings on the branch are automatically recorded on the head office account; “Decentralized processing” lets dunning/payment still address the branch.
• Sensitive fields (dual control): Changes to defined fields (e.g., bank details) block payments until confirmed by a second user (FK08 / FK09).
• Blocking / deletion flags: Posting block (per company code or all), purchasing block, payment block, flag for deletion (archiving).

Direct FI Invoice (FB60 / Fiori “Create Supplier Invoice”)

• Enter vendor, invoice date, posting date, reference (external invoice number), amount, tax code (or “Calculate tax” flag), payment terms (defaulted from master), baseline date.
• Line items: G/L account, D/C indicator, amount, cost center / internal order / WBS, text. System derives posting keys 31 (vendor) and 40 (expense) and generates the tax line and the reconciliation account line.
• Document check “Check double invoice” warns if reference, date and amount already exist for the vendor.
• Credit memo FB65 (posting key 21) – reference to invoice can be entered in “Invoice reference” so that payment terms and due date are taken over.
• Net vs gross procedure: with net document type (KN) the cash discount is deducted immediately and posted to the clearing account; with gross (KR) the discount is realised at payment.

Logistics Invoice Verification (MIRO) – Three-way match

Purchase Order (quantity/price) → Goods Receipt (MIGO, posts Dr Stock / Cr GR/IR clearing) → Invoice Receipt (MIRO, posts Dr GR/IR / Dr Input tax / Cr Vendor). Variances within tolerance (OMR6) are posted to price difference accounts; outside tolerance the invoice is blocked for payment (payment block R) and released with MRBR. The GR/IR account is cleared automatically (F.13) when quantities match; remaining balances are regrouped at period end with F.19 / MR11 (maintain GR/IR clearing).

Payment Terms (OBB8)

• Baseline date default: no default / document date / posting date / entry date; optional fixed day and additional months.
• Up to three instalments: e.g., 3% within 14 days, 2% within 30 days, net 45 days.
• Instalment payment terms (OBB9) split one invoice into several due items with percentage shares.
• Payment terms can be flagged for customer, vendor, or both; day limits allow different terms depending on the day of the month.
• Cash discount base: gross or net of tax (company-code setting OBY6 “Discount base is net”).

Down Payments (Special G/L transactions)

1. Down payment request F-47 (noted item, special G/L indicator F) – no balance update, triggers payment program.
2. Down payment made F-48 or via F110 (special G/L indicator A, posted to alternative reconciliation account “Down payments made”).
3. Invoice received FB60 / MIRO.
4. Clearing of down payment F-54 transfers the down payment to the normal reconciliation account against the invoice; remaining amount paid with F110.

Configuration (FBZP)

Execution Steps

1. Parameters – run date and identification; posting date; documents entered up to; company codes; payment methods (sequence = priority); next payment date (items that would become overdue before the next run are included); vendor / customer ranges; free selection (e.g., document type, payment block); additional log; payment medium variants.
2. Proposal run – creates the payment proposal (REGUH / REGUP). Exception list shows items not paid with error reasons (e.g., 003 payment block, 006 account blocked, 007 no valid payment method, 017 bank details missing). Proposal can be edited: change payment method, house bank, block / unblock items, re-allocate.
3. Payment run – posts payment documents (document type ZP), clears open items, creates payment data for the medium.
4. Payment medium – Payment Medium Workbench (PMW) creates files (DME / XML e.g. pain.001.001.03 for SEPA) via format and format supplement, mapped by payment medium format → variant (SE38 program SAPFPAYM); classic RFFO* programs print checks (RFFOUS_C) or create DME; payment advices and payment summary are spooled.
5. Automatic scheduling – F110S / Schedule Manager batch-input; Fiori “Manage Automatic Payments” and “Schedule Payment Proposals”.

Payment Logic

• Due date determination: baseline date + days of the payment term; the program pays with the maximum cash discount if the item is still within discount period at next run date, otherwise at net due date (“Pay immediately” tolerance days).
• Payment method selection: document payment method (manually in the item) > payment method list in master record > payment program parameters – checked in the order of the parameter sequence.
• Grouping: items of one vendor are normally paid together; “Single payment” flag in master or document pays separately; “Payment per due day” option.
• Payment block keys (OB27): A blocked for payment (set by down payment), R invoice verification, * skip account, blank free for payment; flags “changeable in payment proposal” and “not changeable”.
• Cross-company-code payments: the paying company code pays on behalf of sending company codes; intercompany clearing accounts (OBYA).

Check Management

Check lots per house bank/account (FCHI); print and assign check numbers (FCH5 manual, F110 automatic); check register FCHN; void checks (FCH3 unused, FCH8 reverse payment + void, FCH9 void issued check); cashed-check update via EBS. Reasons for voiding (FCHV).

In S/4HANA, customer data uses the Business Partner (BP) with role FLCU01 (FI Customer).

• General Data: Name, address, bank details, tax registration.
• Company Code Data: Payment terms, dunning area, reconciliation account, tolerance group.
• Sales Data (SD): Sales organization, shipping data, pricing procedures.

• Customer Invoice (DR): Debit customer, credit revenue. Usually posted automatically from SD billing.
• Incoming Payment (DZ): Debit bank/cash, credit customer. Clears open invoice items.
• Down Payment (F-29): Special GL transaction for customer advance payments. Posted to a special reconciliation account.

The dunning program automatically identifies overdue customer invoices and generates dunning notices:

• Dunning Levels: Up to 9 levels with escalating fees and interest charges.
• Dunning Procedure: Configured with dunning intervals, minimum amounts, and texts per level.
• Dunning Run (F150): Selects overdue items, creates dunning proposals, and generates notices.
• In S/4HANA, dunning notices can be sent digitally as PDFs via email or printed.

When customers dispute an invoice or pay short, dispute cases can be created:

• Dispute cases link to AR open items and track the resolution workflow.
• Reason codes categorize disputes (e.g., pricing error, goods not received).
• Integrated with Collections Management for proactive outreach.

• Billing documents in SD automatically create FI customer invoices via account determination (Account Key).
• Revenue is posted per revenue account, taxes per tax account — all determined by the SD pricing procedure.
• Credit management in SD checks credit exposure (open orders + deliveries + AR open items) against the customer credit limit.

BP roles: FLCU00 Customer (sales) and FLCU01 FI Customer; classic tables KNA1 / KNB1 / KNVV remain via CVI. Sales area data (sales org / distribution channel / division) holds shipping, billing, partner functions (SP sold-to, SH ship-to, BP bill-to, PY payer), incoterms, and pricing procedure. The payer partner determines the FI account posted by billing.

• Company code data: reconciliation account, payment terms, payment methods (incoming: direct debit D, SEPA DD), dunning procedure, dunning block, dunning recipient, dunning clerk, accounting clerk, interest indicator, tolerance group, credit memo payment terms, head office, alternative payer, lockbox.
• Credit management: in S/4HANA the credit segment data (credit limit, risk class, check rule, score) is maintained in BP role UKM000 (SAP Credit Management, FSCM) – FD32 of classic credit control area is replaced.
• Correspondence: periodic account statements (indicator for monthly / weekly), bank statement, payment advice notes.

Invoice sources

• SD billing (VF01 / VF04 collective): Billing document → accounting document RV with posting key 01 to the payer, revenue accounts determined via account determination (VKOA: condition tables with chart of accounts, sales org, account assignment group of customer and material, account key ERL revenue / ERS sales deductions / MWS tax). Billing number = FI document number (external numbering) when number ranges match.
• Direct FI invoice FB70 (posting key 01) and credit memo FB75 (posting key 11); F-22 / F-27 classic.
• Down payment request F-37 (noted item F), down payment received F-29 (special G/L A), clearing F-39; in SD via billing plan with down payment request billing type FAZ.

Incoming payments

• Manual F-28 (posting key 15 / 40 bank): select open items by document, reference, amount; cash discount granted automatically if within discount period; payment differences → tolerance (OBA3 customer tolerance group / OBA4 employee tolerance), reason codes (OBBE) for residual items, charge-off to expense, or partial payment.
• Payment advice notes (FBE1) hold remittance information before the payment arrives; the EBS or lockbox uses them for clearing.
• Electronic bank statement / lockbox clears customer items automatically using note-to-payee interpretation (document number, reference, amount).
• Direct debit via F110 for customers with payment method D/SEPA DD and valid mandate.
• Payment cards: Authorization in SD, settlement run FCC1 creates the receivable on the clearing house account.

Interest Calculation

Item interest calculation (FINT / F.2B) on overdue items or balance interest (F.26); interest indicator in master record; interest rates, reference interest rates (OB81/OB83), calculation period, minimum amounts, posting via account determination (OBV1). Produces interest letters / documents.

Dunning procedure (FBMP)

Dunning run steps

1. Parameters: run date / identification; dunning date; documents posted up to; company codes; customer / vendor ranges; free selection.
2. Dunning selection (schedule): Program determines overdue items (due date + grace days < dunning date), the dunning level per item (days in arrears vs level definition; level can only rise by one per run unless “always dun”), the account dunning level (highest item level), checks minimum amounts, dunning interval and blocks → dunning proposal.
3. Edit proposal: Change dunning level, block items/accounts, display dunning history; sample printout.
4. Print / dispatch: Dunning notices printed or sent via e-mail/fax (BTE 1040), dunning charges and interest shown; the dunning level and last dunned date are updated in the item (MANSP / MABER) and account (KNB5).
5. Dunning history F150 → Dunning history or S_ALR_87012085; dunning via Collections Management (FSCM) in S/4HANA provides worklists instead of letters.

• SAP Credit Management (FIN-FSCM-CR): Credit segments, credit limit per BP, scoring rules, credit exposure from SD orders / deliveries / FI open items (credit exposure categories 100 open orders, 200 deliveries, 300 billing, 400 receivables), credit checks in SD (static / dynamic, horizon), blocked documents released with UKM_CASE / VKM1. Replaces FD32 / OVA8 classic credit control area.
• Dispute Management (UDM_DISPUTE): Dispute case created from a residual / partial payment or manually from FBL5N; case attributes (reason, processor, status, disputed amount), linked to FI documents; resolution via credit memo, write-off (automatic write-off program UDM_AUTOWRITEOFF) or payment. Cases visible in Fiori “Manage Dispute Cases”.
• Collections Management (UDM_SUPERVISOR / UDM_SPECIALIST): Collection strategies with rules (overdue amount, dunning level, promise to pay broken), worklists for collection specialists, customer contacts, promises to pay, and resubmissions – an alternative to dunning letters.

• Chart of depreciation (OADB / EC08 copy): Country-specific collection of depreciation areas (e.g., 0DE Germany, 0US USA, 1DE…). Copied from a reference chart and assigned to a company code (OAOB). One company code = one chart of depreciation; several company codes may share one.
• Depreciation areas (OADB): Typical set – 01 book depreciation (leading ledger / local GAAP), 15 tax balance sheet, 20 cost-accounting depreciation (CO), 30/31/32 group valuation in group currency / consolidated, 60 IFRS. Each area has a posting indicator (0 no posting, 1 post real time, 2 post APC periodically / 3 depreciation only, 4 APC immediately and depreciation periodically, 5 APC only), a target ledger group, an accounting principle, value-management rules (positive/negative APC, net book value allowed), and currency type.
• Derived depreciation areas: Calculated as formula from other areas (e.g., 03 = 02 – 01 special reserves), optionally posted.
• Asset classes (OAOA): Classification (buildings, machinery, vehicles, IT, low value assets, AuC); hold account determination, screen layout rule, number range (external / internal, AS08), default depreciation keys and useful life per depreciation area (OAYZ), status of AuC (none / line-item / summary settlement), low-value-asset check (maximum amount OAY2), inventory indicator, history sheet group.
• Account determination (AO90): Per chart of accounts, account determination key and depreciation area: APC account, accumulated depreciation, ordinary / special / unplanned depreciation expense, revenue from asset sale, clearing account for asset sale, gain / loss on retirement, down payments / AuC, revaluation accounts.
• Screen layout rules (AO21): Field status of asset master (required / optional / suppressed / display), maintenance level (asset class / main asset / sub-number), copying rules.
• Transaction types (AO73 / OAXE): 100 external acquisition, 110 in-house production, 120 goods receipt, 130 AuC acquisition, 200 retirement without revenue, 210 retirement with revenue, 250 retirement by scrapping, 300 intra-company transfer prior-year acquisition, 310 current-year, 320 complete transfer, 330 partial, 331–3xx intercompany transfers, 400 post-capitalisation, 500/600 write-up, 640/650 unplanned depreciation, 700/730 settlement of AuC. Transaction type groups define debit/credit, prior-/current-year, and asset history sheet position. Transaction types can be restricted to depreciation areas.

• Sub-numbers (AS11): Subsequent acquisitions or components managed separately (e.g., engine replacement); own depreciation terms possible per sub-number.
• Group assets (AS21): Several assets depreciated as a group (US tax ADR).
• Mass changes (AR31 / AR01 → worklist with substitution OA02): Change e.g. cost center for many assets via substitution rules.
• Legacy data transfer (AS91 / AS92; S/4HANA: ABLDT, LTMC/Migration cockpit, transfer date OAYC): Takeover of APC and accumulated depreciation per area; cumulative values transferred to G/L separately (OASV).

Acquisitions

• With vendor, integrated (F-90 / FB60 with asset): Dr Asset (posting key 70, TTy 100) / Cr Vendor 31. Capitalisation date = asset value date. Depreciation start date determined by the period control of the depreciation key.
• Via purchasing (ME21N with account assignment category A → MIGO goods receipt → MIRO): Valuated GR posts to the asset immediately; non-valuated GR capitalises at invoice receipt.
• Automatic offsetting (ABZON): Acquisition with automatic offsetting entry to a clearing account (asset acquisition clearing, e.g., when the invoice is entered separately by AP).
• In-house production / AuC settlement: Costs collected on an internal order or WBS → settlement (KO88 / CJ88) to AuC (TTy 130) → final settlement to the completed asset (AIAB distribution rules, AIBU settlement; TTy 336/339 → 100).
• Post-capitalisation (ABNAN): Capitalise values that should have been capitalised in a prior year (TTy 400) with catch-up depreciation.
• Subsequent acquisition in a later year to the same asset – the depreciation key period control decides whether depreciation starts at the beginning of the year or at the acquisition period.

Transfers

• Intra-company transfer (ABUMN): Move an asset (complete or partial, by amount / percentage / quantity) to another asset in the same company code (e.g., reclassification to another asset class, or AuC → final asset). Transfer variants (OAYZ / AO75) determine which values are transferred (gross = APC + accumulated depreciation; net = net book value) and which transaction types are used (300/310 → 320/330).
• Inter-company transfer (ABT1N): Between company codes; the “relationship type” (01 legally independent, 02 same company) and transfer method (gross / net / new value) define whether a sale with revenue or a transfer at NBV is posted; cross-company clearing accounts used.

Retirements

• Sale with customer (F-92 / ABAON with revenue): Dr Customer 01 / Cr Revenue from asset sale (50) + asset retirement flag → system posts: Dr Accumulated depreciation, Dr Clearing asset sale, Cr Asset APC, gain or loss (TTy 210). Proportional depreciation up to the retirement period is posted automatically.
• Retirement without customer (ABAON): Revenue posted to clearing account.
• Scrapping (ABAVN): No revenue, NBV written off to loss (TTy 200).
• Partial retirement: By amount, percentage or quantity; prior-year and current-year acquisitions distinguished (TTy 200/250 vs 260).
• Mass retirement: Worklist via AR01 / AR31 with retirement as the purpose.

Other Transactions

• Write-up (ABZU): Reverses excessive depreciation of prior years (TTy 700 ordinary, 710 special, 730 unplanned).
• Unplanned depreciation (ABAA): Manual, TTy 640 (prior-year) / 650 (current-year) – posted by the next depreciation run.
• Manual depreciation / transfer of reserves (ABMA / ABSO): For keys with manual depreciation method; special reserves (e.g., investment subsidies).
• Investment support (ABIF): Government grants managed as negative values on a separate depreciation area or as reduction of APC (investment support measure in OAYM / ANVA).
• Revaluation (AR29 / ABAW): Index-based or manual revaluation of APC and depreciation (inflation accounting).
• Reversal (AB08): Reverses an asset document together with the FI document.

Depreciation key (AFAMA) = combination of calculation methods

Additional key settings: change-over method (e.g., from declining balance to straight-line when SL is higher – “changeover when NBV < …”), multiple-shift usage (shift factor increases depreciation), scrap value handling (consider or not, cut-off value key AFAMS), “depreciation below zero / NBV negative allowed”, acquisition only allowed in capitalisation year, period control according to fiscal years. Common SAP standard keys: LINR straight-line from remaining life to book value zero, LINK straight-line from APC, DG20/DG30 declining balance 2×/3×, GWG immediate (low value assets), 0000 no depreciation, MANU manual, STCK units of production.

Depreciation types

• Ordinary depreciation: Planned wear and tear over useful life.
• Special depreciation: Tax-based depreciation in addition to ordinary (e.g., accelerated allowances), usually only in tax area.
• Unplanned depreciation: Unusual decline in value (damage, obsolescence), posted manually (ABAA).
• Transfer of reserves / revaluation / interest (imputed interest for cost accounting area 20 – posted to CO).

Depreciation posting run (AFAB / Fiori “Schedule Asset Accounting Jobs – Depreciation Posting Run”)

• Parameters: company code, fiscal year, posting period, reason for run – planned posting run (next period in sequence), repeat run (post differences for the same period again, e.g., after new acquisitions), restart (after termination), unplanned posting run (skip periods – S/4HANA: allowed, periods in between are posted together).
• Test run with error list; update run must be executed in background (ECC) – in S/4HANA can run online for small volumes.
• Posting: per depreciation area that posts depreciation, one document per company code / period / ledger group (document type AF), Dr Depreciation expense (cost center from asset master, via account assignment objects ACSET) / Cr Accumulated depreciation. Posting cycle per area: monthly, quarterly, semi-annual, annual (OAYR) – with smoothing or catch-up for differences.
• In S/4HANA the planned depreciation is calculated and stored immediately at every asset transaction (table FAAT_PLAN_VALUES); AFAB only posts – no separate recalculation (AFAR) needed except after customizing changes.
• Log: ACDOCA line items per asset (S/4HANA posts at asset level, not summarised), posting totals per account; depreciation forecast via Fiori “Depreciation Lists” / S_ALR_87012936.

Parallel valuation

In S/4HANA New Asset Accounting the ledger approach assigns each depreciation area to an accounting principle / ledger group (01 → 0L IFRS, 32 → L1 local GAAP); each area posts its own APC and depreciation values in real time to its ledger — no delta areas needed. The accounts approach keeps parallel values in separate G/L accounts within one ledger (area 01 posts to the regular accounts, area 32 to a second account set via a separate account determination). Transaction ABSO with “limit posting to a depreciation area / accounting principle” allows differing values (e.g., IFRS component approach vs tax).

1. Create AuC asset in an AuC asset class (depreciation key 0000, status “line item settlement” for individual tracking).
2. Collect costs: direct postings to the AuC (F-90 with TTy 130), or on an investment order / WBS element (IM investment profile OITA assigns an AuC class; the AuC is created automatically when the order is released) with periodic settlement (KO88) to the AuC.
3. At completion: AIAB define distribution rules per line item (percentage / amount / equivalence numbers to one or more final assets or cost centers), AIBU settle – TTy 336 (AuC retirement) / 339 and 100-type capitalisation on the final assets; the capitalisation date of the final asset = settlement asset value date.
4. Summary settlement AuC class: whole balance transferred with ABUMN.
5. Investment Management (IM): investment programs (IM01) with program positions and budget, appropriation requests (IMA11) for approval, measures (orders / WBS), availability control against budget, reporting (IM Information System).

Asset Explorer (AW01N)

Central display per asset: planned and posted values per depreciation area and fiscal year (APC, depreciation, NBV), transactions, parameters (dep. key, useful life, start dates), comparisons between areas, and depreciation simulation with changed parameters; direct navigation to FI documents and master record.

• Bank Master Record (FI12): Contains bank key, name, address, SWIFT/BIC code. Each house bank has one or more bank accounts.
• House Bank: A bank account used by the company code for outgoing payments. Assigned a bank ID and GL account for the bank balance.
• Bank Determination: Configured in the payment program to select the optimal bank for each payment based on currency, amount, and payment method.

• EBS processing imports the bank's MT940/CAMT file and automatically posts the bank's debit/credit entries.
• Posting Rules: Map bank transaction codes to G/L accounts and clearing rules.
• Automatic Clearing: The system attempts to match bank entries against open items in AR/AP using search algorithms (amount, reference number).
• Unmatched items go to a bank clearing account for manual processing.

• Cash Position: Shows bank balances by value date — inflows from AR and outflows to AP vendors.
• Liquidity Forecast: Combines open AR/AP items with expected cash flows to project future bank balances.
• In S/4HANA, the SAP Cash Management application provides advanced cash pooling, bank connectivity (SWIFT), and real-time position monitoring.

• Bank directory (FI01/FI02/FI03, BNKA): Bank country + bank key (national bank code / SWIFT), name, address, SWIFT/BIC, bank group (for payment optimisation). Can be imported from national bank files (BAUP) or created on the fly when entering BP bank details.
• House banks (FI12 / Fiori “Manage Banks”): The company’s own banks; house bank ID (5 char) + bank key; EDI partner profiles, data medium exchange details, communication data.
• Bank accounts (ECC: FI12 account ID; S/4HANA: Bank Account Management – “Manage Bank Accounts”): Account ID, bank account number, IBAN, currency, control key, G/L account (main bank account) and connectivity path to house bank/account ID. S/4HANA BAM adds: account type, opening/closing date, signatories, overdraft limit, workflow-based approval of changes, revision history, account technical ID, bank account hierarchy, and the “bank account hierarchy view”. Lite version (without FSCM Cash) still mandatory for F110.
• G/L account structure per bank account: Main bank account (reconciled with the statement) + bank sub-accounts / clearing accounts for outgoing checks, outgoing transfers, incoming payments, cash receipt — items move from sub-account to main account when the statement confirms them. Sub-accounts are open-item managed; main account is not.
• Business partner bank details: Bank type (partner bank type) allows several accounts per BP; selected in the document via “Partner bank”; IBAN-only entry possible.

Formats

• MT940 (SWIFT, structured field :86: with national subfields), MultiCash (AUSZUG.TXT + UMSATZ.TXT), BAI / BAI2 (USA), CAMT.053 (ISO 20022 XML, standard for SEPA; CAMT.052 intraday, CAMT.054 debit/credit notifications), country formats (e.g., DTAUS, CSB43). Imported via FF_5 (SAPMF40S) or Fiori “Manage Incoming Payment Files”; intraday statements FF.5 / FEB_FILE_HANDLING.

Configuration (OT83 / Fiori “Manage Bank Statement Reprocessing Rules”)

1. Account symbols – abstract names for G/L accounts (BANK, CHECK-OUT, TRANSFER-OUT, INCOMING, FEES, INTEREST).
2. Assign accounts to account symbols – with masking (e.g., ++++++++++ for the bank G/L account taken from the house bank account; +++++++++1 sub-account suffix) and currency.
3. Posting rules – keys (e.g., 0001 outgoing check, 0002 outgoing transfer, 0003 incoming payment, 0004 bank fees) with posting area 1 (bank accounting: Dr/Cr account symbols, document type SA, posting type 1 post to G/L / 4 clear debit G/L / 5 clear credit G/L) and posting area 2 (subledger: posting type 7 clear debit subledger / 8 clear credit subledger, document type DZ/KZ).
4. Transaction types – a set of external transaction codes per bank format (e.g., MT940 business transaction code 051 transfer, 020 cheque, NTRF, NCHK; CAMT bank transaction code domain/family) mapped to posting rules with +/− sign and interpretation algorithm (000 none, 001 standard document number, 011 outgoing check number, 012 reference number, 015 clearing via assignment, 019 reference to DME, 020 document number search, 021 reference document number, 031 DME management, 901–999 customer-defined BTE).
5. Assign bank accounts to transaction types.
6. Search strings (OTPM) – regular-expression patterns on the note-to-payee to derive posting rule, cost center, or clearing information.

Processing

• Import creates bank statement in buffer tables (FEBKO header, FEBEP items) and batch input / direct posting of area 1 (bank) and area 2 (subledger). “Post immediately” or via batch session (FEBP).
• Post-processing (FEBAN; S/4HANA: Fiori “Reprocess Bank Statement Items”): Items with status “to be post-processed” (no match found): manual assignment of open items, residual / partial payment, posting on account, or posting to G/L with reason; proposal from machine learning (Cash Application add-on).
• Bank statement list FF.6 / FEBA_BANK_STATEMENT; reconciliation of main account balance to statement closing balance.
• Returns / rejects (CAMT.054 / direct debit returns): Reverse the clearing (FBRA) and reopen the customer item; return reason codes; dunning may continue.

Manual Bank Statement (FF67)

Enter statement header (house bank, account ID, statement number, dates, opening/closing balance) and line items with business transaction codes defined per variant; same posting rules; used where no electronic file is available.

• Petty cash for a company code: one cash journal per cash desk and currency (FBCJC0: number, G/L cash account, document types for G/L / vendor / customer postings, cash journal name). Cash journal number range (FBCJC1).
• Business transactions (FBCJC2): Types C receipts from bank, B payment to bank, R revenue, E expense, D customer posting, K vendor posting; each with G/L account, tax code, flag “account modifiable”, “tax modifiable”, “business transaction blocked”.
• Tabs for cash receipts, cash payments, check receipts; save (document is only in the cash journal) and post (FI document created); print receipts (FBCJC3 print parameters); split of a receipt into several lines; display balance per day, cash forecast; deletion only of unposted entries; reversal of posted items.
• Fiori: “Manage Cash Journal” / “Post Cash Journal Entries”.

• Lockbox (FLB2 import, FLB1 post-process): Bank collects customer checks and sends BAI/BAI2 file with MICR data, check amount and invoice references. Lockbox configuration (OBAY destinations, OBAX control parameters: document types, posting keys, G/L and clearing accounts, posting type “partial payments”, invoice number matching logic, tolerance). Statuses: applied, partially applied, on account, unprocessed; batch input for post-processing; payment advice created for each check.
• Check deposit (FF68): Manual list of received checks (check number, drawer, bank, amount, customer / invoice); posts Dr Check clearing / Cr Customer (area 2) and bank receipt when statement confirms. Variants defined in OT45.
• Bill of exchange (special G/L W): receivable from bill of exchange, discounting (F-33), presentation (F-34), contingent liability and reversal at due date.

• Cash position (FF7A / Fiori “Cash Position”) – short-term view (days) of bank accounts and bank clearing accounts based on planning levels (e.g., F0 posted bank, B1 outgoing checks, B2 outgoing transfers, C1 incoming) derived from G/L accounts and payment processing; includes memo records (FF63) for expected flows.
• Liquidity forecast (FF7B / “Liquidity Forecast”) – medium-term view based on open items of customers / vendors grouped by planning groups (BP master: cash management group, e.g., E1 domestic customers, A1 domestic vendors) and purchase / sales orders (if integrated), with planned dates derived from payment terms and payment history.
• S/4HANA Cash Management (FSCM-CLM): One Exposure from Operations (FQM_FLOW) collects all actual and forecast flows from FI, MM, SD, TRM; apps: Cash Flow Analyzer, Bank Account Management, Make Bank Transfers (payment requests), Cash Operations, Liquidity Planning (with SAC). Classic FF7A/FF7B are superseded.
• Bank transfers / payment requests (F111, FIBLFFP): Treasury-type payments between own accounts without an invoice; payment program for payment requests.

For companies with multiple company codes, intercompany transactions must balance. In S/4HANA:

• Every intercompany posting generates mirror entries in both company codes via a central clearing account.
• The Intercompany Matching and Reconciliation app identifies differences between intercompany receivables and payables.
• Eliminates intercompany profit/loss for consolidated group reporting.

Inventory (MM) valuation

• Price control: S standard price (variances to price difference accounts) vs V moving average price; material ledger with actual costing in S/4HANA (mandatory ML, optional actual costing CKMLCP) allows parallel valuation in multiple currencies and revaluation at period end.
• Balance sheet valuation (MRN0 lowest value by market price, MRN1 by range of coverage, MRN2 by movement rate, MRN3 loss-free valuation, MRF1/MRF3 FIFO, MRL1 LIFO): Results are stored as tax / commercial prices in the material master and posted via MR21 / MR22 or as devaluation postings to the inventory and P&L.
• GR/IR clearing account analysis (F.19 / Fiori “Regroup GR/IR Clearing Account”): Items not fully cleared at period end are regrouped: goods received not yet invoiced → “Delivered but not invoiced” liability; invoiced not yet received → “Invoiced but not delivered” asset; posted with automatic reversal on day one of the new period.
• Physical inventory: Count (MI01/MI04), differences posted (MI07) to inventory difference accounts.

Receivables / Payables valuation summary

• Foreign currency valuation of open items (see below) → unrealised gains / losses.
• Value adjustments for doubtful receivables: flat-rate (F103/F104) and individual (special G/L E).
• Regrouping by remaining term and credit/debit balance (FAGLF101) – legal requirement in many GAAPs (e.g., HGB §268).
• Separate disclosure of receivables/payables to affiliated companies via trading partner (VBUND) – transferred from BP master (company ID) into the document line.

Valuation methods (OB59)

Valuation scope

• Open items (customers, vendors, G/L accounts with OI management in foreign currency): each item’s FC amount is translated at the closing rate; the difference to the current local currency amount is posted to the balance sheet adjustment account (per reconciliation account, OBA1 transaction KDF) and to unrealised exchange rate gain/loss. The item itself keeps its original local currency amount; the valuation difference is stored in the item (BSEG-BDIFF) so that the realised difference at payment is split into realised vs reversal of unrealised.
• Balance sheet G/L accounts without OI management (bank accounts, loans in FC): the account balance in FC is valued; the difference is posted directly to the account (or to an adjustment account) and P&L (OBA1 transaction KDB – exchange rate difference key in G/L master).
• Reversal / delta logic: Classic: valuation posted on the key date and reversed on key date + 1 (“reverse postings” flag). S/4HANA alternative: delta posting – only the change since the last valuation is posted and nothing is reversed (“Valuation with update of valuation difference / posting of deltas”), used together with the “Year-end valuation” option in which the last valuation of the year remains.

Translation of balances (FAGL_FCV / Fiori “Perform Foreign Currency Valuation” with “Currency Translation”)

For group reporting, local currency balances are translated into the group currency (currency type 30) at the closing rate for balance sheet accounts and average rate for P&L – translation differences posted to equity; configured via translation method and FS version.

Realised exchange rate differences

Arise at payment / clearing when the rate differs from the invoice rate; posted automatically to realised gain/loss accounts (OBA1 KDF “Exchange rate difference realized” per reconciliation account or G/L account). Rounding differences (KDR) and translation differences for parallel currencies (KDW) also use OBA1.

Manual accrual/deferral documents (FBS1 / F.81)

FBS1 posts a document with a reversal reason and reversal date; F.81 (reverse accrual/deferral documents) mass-reverses them after the key date. Used for: accrued expenses (expense incurred not yet invoiced: Dr Expense / Cr Accrued liabilities), deferred income (Dr Revenue / Cr Deferred income), prepaid expenses (Dr Prepaid / Cr Expense), accrued revenue. Alternative: recurring entries for equal monthly amounts (e.g., spread an annual insurance premium with 12 recurring documents).

Accruals Management (Accrual Engine – FI-GL ACE; S/4HANA “Manual Accruals” and “Purchase Order Accruals”)

• Accrual object = item to be accrued (contract, PO item) with accrual type (costs, revenues, prepaid), start/end date, total amount, accrual method (linear by days / periods, custom BAdI), accounting principle and ledger group → accrual item types (P planned / periodic accruals, O opening posting, I inception, C closing).
• Periodic accrual run (ACACACT / Fiori “Post Accruals Periodically”) posts the planned amounts for the period to G/L, with full traceability per object and reversal/adjustment on change (e.g., contract shortened); simulations; review and approval workflow (“Review Accruals”).
• Purchase order accruals (S/4HANA 1809+): Purchase orders with services / consumables are automatically transferred to the Accrual Engine (transfer run ACEPSOT), the planned cost per period is derived from delivery schedule / PO validity; actual GR/IR values reduce the accrual; proposals can be reviewed by the requester / cost center manager (“Review Purchase Order Accruals”) before posting – replaces manual estimation of “received not invoiced” services.
• Posting: Dr Expense (CO object from PO) / Cr Accrued liabilities; reversed/adjusted automatically in the next period.

Provisions

Posted manually (FB50) or via Accrual Engine / Liability Management; for IFRS, long-term provisions discounted; separate G/L accounts per provision type; often ledger-specific (local GAAP vs IFRS).

• Sort method (OBBU): Defines remaining-term intervals (e.g., ≤ 1 year, 1–5 years, > 5 years) separately for receivables and payables; for each reconciliation account the target accounts (OBBV receivables sorted, OBBW payables sorted, OBBX changed reconciliation account for credit/debit) and adjustment accounts are assigned.
• Vendors with debit balances / customers with credit balances: Regrouped to receivables / payables adjustment accounts (“changed reconciliation account”).
• Affiliated companies: Items with trading partner are regrouped to “receivables / payables from affiliated companies” accounts for consolidation and legal disclosure.
• Investments / inventory ratios: Sort by remaining term for loans; special G/L items included or excluded.
• Postings are made on the key date with automatic reversal on the next day; valuation area / ledger group selection for parallel accounting; results displayed per account with target accounts.
• Fiori: “Regroup Receivables/Payables”.

• Programs SAPF130D (customers) / SAPF130K (vendors) create letters, reply slips, check lists (which accounts were selected and with which balance) and results tables (for entering replies).
• Procedures: Balance confirmation (reply requested in any case – positive method), Balance notification (reply only in case of disagreement – negative method), Balance request (customer is asked to state the balance without the company disclosing its figure).
• Selection: account ranges, reconciliation accounts, random sample (number or percentage), amount thresholds, items up to key date, head office/branch handling, one-time accounts, exclude blocked accounts.
• Reply address: company code or alternative (auditor) address; form set (SAPscript F130_CONFIRM_01 etc., OB90 form selection, OB89 reply addresses); correspondence sent via print, e-mail or PDF.

Financial statement version (FSV) – OB58 / Fiori “Manage Global Hierarchies” (type Financial Statement Version)

• Hierarchy of items (nodes) with texts, to which G/L accounts (ranges, with debit / credit indicator – an account can appear under “Assets” when debit and “Liabilities” when credit) or functional areas are assigned; several charts of accounts possible (group account numbers) in one version.
• Special items: Assets, Liabilities + Equity, Net result: profit, Net result: loss (calculated as difference), P&L result, Not assigned (accounts not yet assigned – should be empty at close), Financial statement notes.
• Options: item keys automatic or manual, maintain language, display totals, contra items.
• Several versions for legal (local GAAP), IFRS, tax, management formats; used by RFBILA00 (F.01 / S_ALR_87012284), Trial Balance, Display Financial Statement (Fiori, ledger and FSV selectable, comparison periods, drill-down to line items), Group Reporting, Report Painter and SAP Analytics Cloud.

Reports

• Balance sheet / P&L (F.01 RFBILA00): Key date, comparison year, FSV, ledger, business area / profit center / segment, output as ALV, classic list, or structured balance list; variants for scaled values.
• Cash flow statement: Via financial statement version with cash flow items (indirect method) or Report Painter; Fiori “Cash Flow Statement” based on ACDOCA with the semantic tag of FSV items (semantic tags like CASH, RECEIVABLES allow KPIs).
• Balance audit trail (RFKLET00 open-item accounts, RFKKBU00 / RFHABU00 / RFBELUGA0 accumulated): Legally required chronological list of all documents per account; in S/4HANA available as “Audit Journal” Fiori app (journal entries by posting date, with changes and deletions) and “Balance Audit Trail” extraction.
• Compact document journal (S_ALR_87012287 RFBELJ00), document journal, G/L account list (RFSKPL00), chart of accounts (RFSKVZ00), account assignment manual.
• Audit Information System (AIS): Role-based collection of audit reports (SECR) for external auditors; data extraction via DART (RFUMSV00 data retention tool) for tax authorities.

Cost of sales accounting and functional areas

P&L structured by function (cost of goods sold, selling, R&D, administration) instead of by nature. Requires functional areas (OKBD) derived via substitution (OBBZ) from cost center category, order type, G/L account, or entered manually; activation per company code; the FSV uses the functional area as the characteristic in ACDOCA. Period accounting (nature of expense) and cost of sales accounting can be reported in parallel from the same journal entries in S/4HANA.

• FAGLGVTR (Fiori “Carry Forward Balances”): Per ledger and company code: balance sheet accounts carry their balance into period 0 of the new year; P&L accounts are set to zero and the result is carried to the retained earnings account (OB53, per P&L statement account type). Can be run repeatedly – subsequent postings to the old year automatically update the carryforward (no re-run needed in S/4HANA when the “automatic carryforward” is active, otherwise re-run). Customer / vendor carryforward (F.07 classic) is included in S/4HANA.
• Number ranges for the new year: Year-dependent document number ranges must be created (FBN1) – or use “9999” year-independent ranges; AA number ranges (AS08).
• Posting period variant: Open the new year’s periods (OB52) – authorization group for interval 1 lets only closing staff post into the old period.
• Special periods 13–16: Audit adjustments posted with posting date = last day of the fiscal year and period manually set to 13–16; financial statements can be produced per special period (e.g., 13 = adjustments, 14 = audit, 15/16 = group).
• Asset fiscal year change (AJRW) and year-end close (AJAB) – see FI-AA.
• Tax reporting: Advance return for tax on sales / purchases (RFUMSV00 / S_ALR_87012357), EC sales list (S_ALR_87012400), withholding tax reporting (S_P00_07000134), SAP Document and Reporting Compliance (formerly ACR) for electronic statutory reports in S/4HANA.

• Classic ICR (FBICS3 select, FBICA3 assign automatically, FBICR3 reconcile manually): Processes 001 G/L open items, 002 G/L accounts, 003 customer/vendor open items; data selected from all company codes (also remote systems via RFC), automatically matched by reference / amount / trading partner; unmatched items processed in a reconciliation UI; results communicated to partners.
• SAP S/4HANA Intercompany Matching and Reconciliation (ICMR, 1909+): Real-time matching on ACDOCA and ACDOCU (group reporting) with matching methods, rules, reason codes, auto-adjustments, Fiori apps “Manage Assignments”, “Reconciliation Status Overview”, “Define Matching Methods”; variance adjustments can post journal entries; supports continuous close.
• Prerequisite: trading partner (VBUND) in BP master and documents; intercompany clearing accounts (OBYA) for cross-company postings (a cross-company document creates one FI document per company code linked by the cross-company document number).

Financial Closing Cockpit (FCC, ECC and S/4HANA on-premise, CLOCOC / CLOCO)

• Template (per closing type: month-end, quarter-end, year-end) with organizational hierarchy (controlling area → company codes → plants) and task hierarchy: folders and tasks.
• Task types: Program with variant (e.g., AFAB with variant), transaction (manual task, user records completion), flow definition (job chain of several programs), note / remote task (other systems via RFC), workflow.
• Each task: responsible person / processor, planned start (offset in days from key date, e.g., “–2” or “+3”), duration, critical path flag, dependencies (predecessor must be finished – the system schedules successors automatically), authorizations, documentation.
• Task list = instance of the template for a specific key date (e.g., period 03/2026); release → tasks scheduled and started in background; monitoring with Gantt chart, status (planned, running, completed with/without errors), spool / job log access, completion statistics, audit trail of who completed what when.
• Benefits: standardisation across entities, transparency, workflow approvals, reduced closing time (from days to hours), documentation for auditors.

SAP Advanced Financial Closing (AFC) – cloud (SAP BTP), successor of FCC

• Closing task templates and task lists orchestrating jobs across multiple S/4HANA (on-premise and cloud) systems via communication arrangements; tasks: automated job (with variant), manual, approval, verification, remote; dependencies, service-level monitoring, closing KPIs.
• Fiori apps: Manage Closing Task Lists, Process Closing Tasks, Approve Closing Tasks, Analyze Closing Progress, Define Closing Task Templates; integration with SAP Analytics Cloud and e-mail notifications; audit-compliant log.
• Related S/4HANA closing apps: “Manage Journal Entry Verification Workflow” (approval before posting), “Closing Cockpit – Overview”, “Schedule General Ledger Jobs”, “Schedule Asset Accounting Jobs”, “Schedule Accounts Receivable/Payable Jobs”.

• Purpose: produce complete balance sheets per profit center / segment / business area (IFRS 8 segment reporting, management reporting) by splitting lines that have no account assignment (vendor, customer, tax, bank) according to the lines that have one (expenses / revenues).
• Passive split: Payments and clearings inherit the split of the original invoice. Active split: Based on splitting rules – business transaction (0000 unspecified, 0200 customer invoice, 0300 vendor invoice, 0400 bank account statement, 1000 payment…), business transaction variant, item categories (01000 balance sheet account, 02000 customer, 03000 vendor, 05100 taxes, 20000 expense, 30000 revenue, 04000 cash account), splitting method (0000000012 standard with inheritance), splitting rule = which item categories are split based on which base item categories. Zero balance clearing lines (account from OBXM, item category 01001) create balanced documents per characteristic; inheritance copies the characteristic to all lines when a document has only one; default account assignment (constant) for lines where nothing can be derived.
• Splitting characteristics (profit center, segment, business area) are flagged zero balance and/or mandatory; validation at posting ensures every line has the characteristic. Documents posted before activation are not split – migration needed.
• Closing relevance: FX valuation, regrouping, depreciation, and payment program postings are all split so that segment balance sheets remain complete; FSV reports by segment (Trial Balance by profit center / segment); segment derived from profit center master (CEPC-SEGMENT).
• Diagnosis: FB03 → General ledger view; simulation “Expert mode” shows the applied splitting rule; error “Balancing field … not filled” indicates missing derivation.

The automatic payment program selects due open items and generates payment documents:

• Payment Methods: Check, bank transfer, SEPA credit transfer, SEPA direct debit. Configured per country and company code.
• Bank Selection: Rules determine which house bank account is used for each payment based on currency, available balance, and bank ranking.
• Digital Payments: Modern payment connectors (credit cards, real-time payments) are handled via the SAP Digital Payments add-on.
• SEPA: The Single Euro Payments Area standard — SEPA Credit Transfer (SCT) and SEPA Direct Debit (SDD) core/B2B are fully supported.

Special GL (SpGL) transactions post to alternative reconciliation accounts instead of the standard AR/AP reconciliation account:

• Down Payment Requests (F-37/F-47): Statistical posting — notifies AR/AP of an expected advance payment without affecting GL balances. Creates a noted item.
• Down Payments (F-29/F-48): Real posting — debit/credit bank, credit/debit a special reconciliation account (e.g., "Down Payments Received").
• Guarantees: Contingent liabilities recorded as statistical items.
• Bill of Exchange: Used in some European countries for time-limited payment instruments.

• A parked document is saved in the system but not yet posted — no impact on GL balances.
• Used to enter incomplete documents for completion/approval before posting (workflow integration).
• Document Holding: A temporary save that reserves the transaction code but does not create a document number (internal hold).
• Parked documents appear in AP/AR open item lists but are excluded from financial statements until posted.

Validations and substitutions are user-defined rules that execute during document entry:

• Validation: Checks a condition and issues a message (warning or error) if it is not met. For example: "If G/L account = 600xxx, cost center must be filled."
• Substitution: Automatically fills or replaces a field value based on conditions. For example: "If company code = 1000 and business area = 9000, set profit center = 90001."
• Configured in GGB0/GGB4 using ABAP Boolean/arithmetic syntax.

• FI documents are subject to legal retention periods (typically 10 years in many countries).
• After the retention period, documents can be archived from the live database to an archive server, reducing the active database size.
• Archived documents remain accessible via SAP's archive information system (AS).
• In S/4HANA, SAP ILM (Information Lifecycle Management) handles archiving policies.

Special G/L transactions post customer/vendor items to an alternative reconciliation account instead of the one in the master record, so that e.g. down payments or bills of exchange are shown separately on the balance sheet. Controlled by the special G/L indicator (OBXR customers, OBXT vendors; account determination per chart of accounts and reconciliation account; posting keys 09/19 customer, 29/39 vendor).

Properties of a special G/L indicator: noted item flag, relevant for credit limit, commitments warning, target special G/L indicator (for down payment request → down payment), posting key, description. Down payment integration with SD (billing plan, FAZ) and MM (purchase order down payment, ME2DP, F-47 from PO; S/4HANA “Manage Supplier Down Payment Requests” linked to PO).

• Park (FV50 G/L, FV60 vendor, FV70 customer, FBV1; MIR7 logistics): Document number is assigned, but no transaction figures are updated (except, optionally, commitment / CO funds). Parked documents can be displayed (FBV3), changed (FBV2), deleted (FBV0 → delete), and posted (FBV0 individually or FBV0 list / Fiori “Manage Journal Entries → parked”). Reports can include parked documents (e.g., FBL1N with “parked items”).
• Holding (F-02 → Hold): Temporary user-specific number, no document number, not visible for other users or reports; completed later via “Get held document”.
• Completion workflow: Workflow variant (OBWA) assigned to company code (OBWJ) with release approval groups (OBWE, from BP master) and release approval paths / amount limits (OBWF, OBWC) – e.g., documents > 10,000 need second release. SAP Business Workflow templates WS10000051 (completion) / WS10000052 (release). Agents receive work items; after release the document is posted automatically.
• S/4HANA Journal Entry Verification: Fiori “Verify General Journal Entries” – flexible workflow (Manage Workflows for Journal Entry Verification) with preconditions (amount, company code, account), approvers (users / teams via Manage Teams and Responsibilities), and “Request / Approve” apps; parked entries submitted for verification and posted on approval.
• Document change rules (OB32): Which fields of a posted document may be changed (e.g., text, assignment, payment block, payment terms – only if item not cleared, posting period open). Change documents (FB04) record all changes.

• Call-up points: 1 document header, 2 line item, 3 complete document; for CO: order, cost center, etc. Activation level per company code (OB28 validation, OBBH substitution): 0 inactive, 1 active, 2 active except batch input.
• Validation step = Prerequisite (when the rule applies, Boolean expression e.g. BSEG-HKONT = ‘400000’) + Check (condition that must be true, e.g., BSEG-KOSTL ≠ ‘’) + Message (type I information, W warning, E error, A abort; message class with variables). Example: for travel expense accounts a cost center and a personnel number are required.
• Substitution step = Prerequisite + Substitution (field replaced by constant, another field, or a user exit / Boolean rule; e.g., derive business area from cost center, set text, assign segment). Fields that can be substituted are listed in table GB01 (some, like amount or account, are protected).
• Rules (reusable Boolean conditions) and sets (GS01, value lists like account ranges) make rules maintainable; user exits (program ZGGBR000 / ZGGBS000 registered in GCX2) for complex ABAP logic. Transport via GGB1 / GCT9. Trace: GGB0 → Simulation; validation/substitution log in document.
• S/4HANA additionally offers BRFplus-based validations (Fiori “Manage Substitution/Validation Rules” for journal entries, 1909+) with rule-building UI for key users.

• Classic withholding tax (one code per vendor, at payment) vs Extended withholding tax (EWT): several withholding tax types per BP, at invoice or at payment, for vendors and customers, with accumulation, exemption certificates, minimum / maximum amounts, formulas, and legal reporting. Activated per company code (SPRO → Extended Withholding Tax → Activate).
• Configuration: WHT type (invoice-time / payment-time, base amount = gross / net / tax amount, rounding, accumulation period), WHT code (percentage, posting indicator 1 standard / 2 offsetting / 3 grossing-up, income type), country-specific official keys, recipient types, account determination (OBWW), assignment of types to company code (validity, “subject to WHT” for customers), WHT in the BP master (type, code, liable flag, exemption number / rate / dates).
• Posting: at invoice, Dr Expense / Cr Vendor net / Cr WHT payable; at payment, the vendor item is reduced and WHT posted. Reporting: generic withholding tax reporting (S_P00_07000134 / RFIDYYWT), certificates (1099 / 1042 US, Form 16 India, Modelo 190 Spain, etc.), Document and Reporting Compliance.

• SEPA credit transfer (SCT): Payment method S (or T with PMW format SEPA_CT) producing XML pain.001.001.03 (or .09 ISO 20022 2019 version) via the Payment Medium Workbench; requires IBAN and BIC (BIC optional since IBAN-only) in BP bank details; end-to-end ID, remittance information (structured / unstructured), batch booking, charge bearer SLEV. Urgent / instant payments via separate formats.
• SEPA direct debit (SDD): Payment method D/E with PMW format SEPA_DD, pain.008.001.02 (CORE for consumers with pre-notification and 5 / 2 day lead times; B2B for companies); requires a valid mandate.
• Mandate management (FSEPA_M1 create, FSEPA_M2 change, FSEPA_M3 display, FSEPA_M4 list; Fiori “Manage SEPA Mandates”): Mandate ID (internal / external number range, OBB_SEPA), creditor identifier (per company code, SEPA_CI), debtor BP and bank details, signature date / place, status (entered, active, obsolete, cancelled, completed), type recurring / one-off, B2B indicator, first use / last use dates, amendment history (change of bank account → new “amendment indicator” in the file). Mandate is selected in the document (BSEG-SEPA_MANDATE) or defaulted from BP; mandate becomes obsolete 36 months after last use.
• Sequence type in the file: FRST first use, RCUR recurring, OOFF one-off, FNAL final – derived automatically from mandate status and usage.
• Pre-notification (program SEPA_DD_PRENOTIF / correspondence) informs the debtor of amount and date before collection; returns (R-transactions: reject, refund, return) processed via EBS / CAMT.054 with reason codes (AM04 insufficient funds, MD01 no mandate…).
• Bank communication: SAP Bank Communication Management (BCM, FBPM1 batch and approval of payments, BNK_MONI status monitor), SWIFT / EBICS connectivity, Multi-Bank Connectivity cloud service in S/4HANA.

• PMW (OBPM1 formats, OBPM2 format supplements, OBPM3 payment medium variants / selection, OBPM4 note-to-payee): Generic framework replacing RFFO* programs; formats delivered by SAP (SEPA_CT, SEPA_DD, ACH, CGI_XML_CT…) or built with DMEE/DMEEX tree editor; event modules; output as file, download, or PI; payment medium created in F110 (“Printout/data medium” tab with variant) or separately with FBPM; Data Medium Administration (FDTA) stores files with status, download, repeat, and payment summary; note-to-payee composition rules; grouping of payments into collective files per house bank / format.
• Payment advice notes (RFFOAVIS / RFFOAVIS_FPAYM) and payment summary; EDI payment advices (IDoc REMADV / PEXR2002).
• Correspondence (OB77 types, OB78 program assignment, OB79 call options, OB96 forms): SAP01 payment notice (automatic after payment with differences), SAP06 account statement (periodic, F.27, based on master data indicator), SAP08 open items list, SAP09 internal document, SAP10 individual letter, SAP11/12 bank statement / bill of exchange charges; requested manually (FB12), from line item display, or automatically (payment program, dunning, cash discount difference); printed with F.61 / F.64 (maintain requests), e-mail via BTE 2310/2320 or Output Management (S/4HANA BRF+ output control).

• Tax calculation procedure (OBBG per country: TAXD Germany, TAXUSJ / TAXUSX US jurisdiction with external tax engine) with condition types (MWAS output, MWVS input, NAVS non-deductible, NLXA acquisition tax) and account keys (MWS output tax, VST input tax, NAV non-deductible, ESA/ESE acquisition tax) → G/L accounts (OB40).
• Tax codes (FTXP): Per country: tax type (A output, V input), rates per condition, target tax code (for down payments), check indicator (error if entered tax ≠ calculated), EU code (for EC sales list), tax category restriction on G/L accounts; properties: deductible / non-deductible portion, reverse charge (output + input in one code), tax on tax, jurisdiction codes (US: state / county / city, FTXP with jurisdiction, external tax via Vertex/Taxware/Thomson RFC).
• Tax determination: Manual tax code in FI; automatic in SD (tax classification of customer / material, departure / destination country, condition records MWST) and MM (tax indicators of material / plant / account assignment, condition records in purchasing info record); plants abroad (foreign VAT registration) via plant-abroad functionality.
• Tax base: gross / net cash discount handling (OBY6 “Tax base is net value”), tax on freight, tax in down payments, tax clearing for intra-EU acquisitions. Posting: tax line items with tax code, tax base amount stored in document (BSET), tax reporting dates (VAT date).
• Reporting: Advance return (RFUMSV00) with tax payable posting (F.12 / S_ALR_87012357 “Post tax payable”), EC sales list (RFASLM00), Intrastat (MM/SD), electronic filing via SAP Document and Reporting Compliance (e-invoicing SII/SDI/etc.), deferred tax (tax on payment basis, RFUMSV50).

• Tolerance groups: Employees (OBA4): upper limits for posting amount per document and per line item, cash discount %, permitted payment difference (amount / %) for revenue and expense, blank group = default for all users; users assigned via OB57. Customers / vendors (OBA3): payment differences permitted (gain/loss amount and %, discount adjustment), tolerance days for payment terms, residual item handling (dunning key, payment term for residual). The lower of employee / BP tolerance applies. G/L accounts (OBA0): for automatic clearing differences.
• Interest calculation: Interest indicators (OB46: item interest calculation “P” vs balance interest “S”), interest rate reference (OB81/OB83 reference rates and OB82 time-dependent terms), interest calculation frequency, posting via OBV1 / OBV2 account determination with symbols (0001 interest received, 0002 interest paid, 1000 customer), programs F.2B item interest customers, F.47 vendors, F.52 balance interest G/L, FINT (new). Interest letters as correspondence.
• Cross-company-code transactions (OBYA): Clearing accounts between company codes (receivable/payable pairs) – one entry creates one document per company code with a cross-company document number (company code 1 document no. + company code + fiscal year); reversal via FBU8; tax handled in the first company code.
• Payment cards, payment requests (F111), bills of exchange, cheque / bill of exchange receivable (F-36), lease accounting (RE-FX, SAP Contract and Lease Management – IFRS 16).
• Data archiving (SARA, archiving objects FI_DOCUMNT, FI_ACCPAYB, FI_ACCRECV, FI_ACCOUNT, AM_ASSET, FI_BANKS): Prerequisites: documents cleared, retention periods per account type / document type (OBR7, OBR8), “archive index” for display (FB03 reads archive via AS_AIS / SAP Archive Information System); phases: write, delete, store (content server), reload (not recommended); SAP Information Lifecycle Management (ILM) adds retention rules, legal holds, and destruction (GDPR data privacy – ILM blocking of BP data, end of purpose check).

Payment terms (OBB8) define the structure of payment conditions:

• Baseline Date Calculation: Document date, posting date, entry date, or from invoice date.
• Payment Terms Block: Three payment blocks with day limit, percentage discount, and number of days.
• Example: "2% within 14 days, 1% within 30 days, net 60": If paid by day 14 → 2% discount; by day 30 → 1% discount; by day 60 → no discount.

• SAP Readiness Check analyzes your ECC system and identifies required changes.
• Simplification List documents all features removed or changed in S/4HANA.
• Custom Code Migration Guide helps adapt ABAP programs to the new data model.
• SAP Best Practices provide pre-configured content for accelerated implementations.

• Define company code (OX02 / EC01 copy): 4-char key, name, city, country, currency, language; copying from a reference (e.g., 0001 or 1010) with all dependent customizing is the recommended approach.
• Company code global parameters (OBY6): Chart of accounts, country chart of accounts, company (consolidation unit, OX15), credit control area, fiscal year variant, field status variant, posting period variant, workflow variant, VAT registration number, business area financial statements, propose fiscal year, define default value date, negative postings permitted, cash management activated, tax base is net value, discount base is net value, financial assets management active, purchase account processing, no forex rate difference when clearing in local currency, max. exchange rate deviation %.
• Additional data: Company (OX15) for consolidation, address (SADR), parallel currencies (OB22: 2nd/3rd local currency with currency type, exchange rate type, source currency, translation date type); in S/4HANA: ledger settings (FINSC_LEDGER) per company code – fiscal year variant, posting period variant per ledger, currency types per ledger, accounting principle.
• Controlling integration: Assign company code to controlling area (OX19), real-time integration CO→FI (variant OBXL / ledger settings), account assignment objects (OKB9 default cost center per G/L account / company code / business area / profit center).

• Fiscal year variant (OB29): Calendar year (K4 = 12 periods + 4 special), year-dependent vs year-independent, number of posting periods (max 16 incl. special), shortened fiscal year (e.g., change of year-end – flag year-dependent, fewer periods; AA requires separate handling of depreciation for shortened year), period texts, period determination table (month / day / period / year shift –1/0/+1 for non-calendar years, e.g., V3 April–March, V6 July–June, WK week-based with 52/53 periods). Assigned to company code (OB37) and, in S/4HANA, possibly different per non-leading ledger.
• Posting period variant (OBBO) and periods (OB52): See FI-GL; assign to company code (OBBP). Authorization group in interval 1 (object F_BKPF_BUP). Fiori “Manage Posting Periods”. CO periods opened separately (OKP1).
• Special periods 13–16 for closing postings; posting date must lie in the last period of the fiscal year.

• Chart of accounts (OB13): Key, description, maintenance language, length of G/L account number (max 10), group chart of accounts (for consolidation – accounts then require “group account number”), integration with CO (manual / automatic creation of cost elements – in S/4HANA merged), blocked indicator. Types: operating (assigned to company code, OB62), country-specific (alternative account number in company code segment; one-to-one mapping), group (consolidation).
• Account groups (OBD4): Number range interval + field status of the master record (company code segment fields).
• Retained earnings (OB53), reconciliation accounts, account determination for automatic postings (FBKP / OBYC MM, VKOA SD, OBA1 FX, OBXK bank charges, OBXU cash discount received, OBXI cash discount granted, OBXL payment differences, OBYA cross-company, OBXM zero-balance clearing, OB40 taxes, OBXZ bill of exchange, OBXR/OBXT special G/L).
• Field status variant (OBC4): Set of field status groups (G001 general, G003 material consumption, G004 cost accounts, G005 bank, G006 material accounts, G067 reconciliation accounts, G029 revenue…), each listing field groups (general data, additional account assignments, payment transactions, taxes, asset accounting, materials management, consolidation, real estate, financial assets) with Suppress / Required / Optional; assigned to company code (OBC5); the G/L master points to a group.
• Sample accounts / data transfer rules (OB15 / FSM1), account creation by copying (FS15/FS16 transfer between company codes), mass maintenance (OB_GLACC11/12/13), G/L account deletion (OBR2 reset transaction data in test systems).
• Posting keys (OB41), document types and number ranges (OBA7, FBN1), document change rules (OB32), reversal reasons (OBXK is bank charges – reversal reasons are in SPRO “Define Reasons for Reversal”), fast entry screens (O7E6), line layout variants (O7Z3/O7Z4), sort variants, text keys (OB56), reference / header text mandatory via document type.

• Currency codes (OY03, TCURC) with decimals (OY04 – e.g., JPY 0, BHD 3); exchange rate types (OB07): M standard (mandatory, used for translation at posting), B bank buying, G bank selling, EURX euro cross rates with reference currency, P planning, with options “inversion allowed”, “reference currency”, “buying / selling rate type”; translation ratios (OBBS) per currency pair and rate type (1:1, 1:100 etc., direct / indirect quotation); exchange rates (OB08, TCURR) valid from date, direct (1 USD = 0.92 EUR) or indirect quotation (prefix “/”); worklist maintenance (TCURMNT), automatic upload from ECB / Reuters via Market Rates Management (S/4HANA cloud service) or RFC.
• Document translation: local currency amount = document amount × rate of type M on the translation date (posting date by default; document date via OBY6 “foreign currency translation date”); manual rate entry allowed within maximum deviation; exchange rate difference keys for G/L accounts (OBA1 KDB).
• Parallel currencies per company code / ledger (OB22 / FINSC_LEDGER): group currency 30 translated from document or local currency (“source currency” setting), hard currency 40 (country T005), index currency 50, global company currency 60.

• BP groupings (BUCF / SPRO Cross-Application Components → BP → Number Ranges and Groupings): Number range (internal / external, e.g., BP01 internal 1000000–1999999), link to customer account group (OBD2) and vendor account group (OBD3) via CVI mapping (SPRO → Customer/Vendor Integration: BP role → account group, number assignment “same numbers” recommended, field mapping of industries, payment cards, tax categories).
• Account groups (OBD2 customers, OBD3 vendors): Number range (XDN1 / XKN1), field status for general / company code / sales or purchasing data, one-time account indicator, output determination procedure; typical groups: 0001 sold-to, 0002 ship-to, 0003 payer, 0004 bill-to, CPD one-time; 0001 vendors, 0002 goods supplier, 0003 alternative payee, 0004 invoicing party, 0006 plant, 0007 plant, CPD one-time.
• Reconciliation accounts (G/L accounts with reconciliation type D / K, alternative reconciliation accounts allowed via OBXR/OBXT and “reconciliation account ready for input” – OBBY/OBBW), sort keys (OB16), accounting clerks (OB05), payment terms (OBB8), instalments (OBB9), payment block reasons (OB27), dunning (FBMP / OB61 / OB17 / OB18), tolerance groups (OBA3), interest indicators (OB46), cash management groups (OB10 / FDFD), head office / branch, alternative payer, release approval groups (OBWE), credit management (UKM / OB45 credit control areas), correspondence (OB77 / OB78), payment methods (FBZP), house banks (FI12), bank account management, lockbox (OBAY/OBAX), EBS (OT83), check lots (FCHI), withholding tax.
• Sales / purchasing integration: Account assignment groups (OVK8 / OVK5) and account determination (VKOA) for SD revenue; MM account determination (OBYC: valuation class, transaction key BSX inventory, WRX GR/IR, GBB offsetting, PRD price difference, KDM exchange rate difference, FRL external service) and purchasing organization assignment.

• Mandatory: Business Partner / CVI synchronisation (MDS_LOAD_COCKPIT, CVI_FS_CHECK_CUSTOMIZING); New Asset Accounting (ledger approach / accounts approach, FAA_CMP_LDT); New G/L with document splitting optional but migration required for classic G/L; material ledger activation; cost element = G/L account merge (FINS_CUST_CONS_CHK consistency check); credit management via FSCM (classic credit control area obsolete); new cash management or BAM lite; Universal Journal migration (FINS_MIG_STATUS, cockpit MIG).
• Ledger settings (FINSC_LEDGER): One place for ledgers, company code assignment, currency types, fiscal year / posting period variants per ledger, accounting principles; extension ledgers; “ledger for CO version”.
• Simplification items (Simplification Item Check report /SDF/RC_START_CHECK) list obsolete transactions: FK01/FD01 → BP, FD32 → UKM_BP, F.07 → FAGLGVTR, ASKB obsolete, AFBP log, S_ALR tax reports → Document and Reporting Compliance, FF7A/FF7B → Cash Management apps, classic EBS → still available plus new apps, FBL*N → Fiori line item apps with compatibility.
• Fiori launchpad configuration: Business roles (SAP_BR_GL_ACCOUNTANT, SAP_BR_AP_ACCOUNTANT, SAP_BR_AR_ACCOUNTANT, SAP_BR_ASSET_ACCOUNTANT, SAP_BR_CASH_MANAGER), business catalogs, spaces and pages (/UI2/FLPD_CUST, Manage Launchpad Spaces), app finder; Fiori Apps Reference Library for app-to-transaction mapping.