💰 What is SAP FICO?
In SAP FICO is the mixture of FI (Financial Accounting) and CO (Controlling) modules. FI works external financial reporting - General Ledger, Accounts Payable, Accounts Receivable, Asset Accounting, and Bank Accounting. CO works internal management accounting - Cost Centres, Profit Centres, Internal Orders, Product Costing, and Profitability Analysis (CO-PA).also Together they form the financial foundation of every SAP ERP ECC 6.0 and S/4HANA system.This tutorial or document breaks down the process step by step, using simple language and real-world examples to help you master the skill.
FI - Financial Accounting
GL, AP, AR, Asset Accounting, Bank Accounting, Tax, Legal & Statutory Reporting.
CO - Controlling
Cost Centre Accounting, Profit Centre, Internal Orders, Product Costing, CO-PA.
Deep Integration
FICO integrates with MM, SD, PP, PS, HR - every financial transaction flows through FICO.
Interview Strategy: For every FICO answer, use the format: Definition → Configuration path → Real example. Interviewers expect you to name transaction codes, table names, and give business scenarios - not just textbook definitions.
🔴 Top 50 Advanced SAP FICO Interview Questions
These 50 questions cover the deepest and most tested areas of SAP FICO - from Universal Journal and document splitting to dunning, asset depreciation, CO-PA reporting, and S/4HANA migration. Each answer includes a concise real-world example.
The Universal Journal (table ACDOCA) is the single source of truth in S/4HANA FICO. It merges FI, CO, Asset Accounting, ML, and Profit Centre postings into one table, eliminating reconciliation between FI and CO. Every financial posting creates one line per account assignment in ACDOCA with all dimensions - company code, cost centre, profit centre, segment, WBS - in a single row.
Example: In ECC, a vendor invoice posted in FI created records in BKPF/BSEG (FI) and COEP (CO) separately, requiring period-end reconciliation. In S/4HANA, the same invoice creates one ACDOCA entry containing GL account, cost centre, profit centre, and segment simultaneously - zero reconciliation needed.
Document splitting distributes balance sheet line items (like payables, receivables, bank) across multiple account assignment objects (segment, profit centre) proportionally, enabling a complete and balanced P&L and balance sheet per segment. Required for segment reporting under IFRS 8. Configured in FAGL_SPLITTING.
Example: Invoice of ₹1,00,000 split across Segment A (60%) and Segment B (40%). Without document splitting, the payable of ₹1,00,000 sits at company code level only - no segment balance sheet. With splitting, ₹60,000 payable posts to Segment A and ₹40,000 to Segment B - full balance sheet per segment is possible.
A Company Code is the smallest legal entity for which a complete set of accounts is drawn up - it produces a legally required balance sheet and P&L. A Business Area is an internal organisational unit (e.g., a division or product line) for which internal financial statements can be generated, but it is not a legal entity. Business areas are cross-company-code.
Example: Company XYZ Ltd has Company Code IN01 (India legal entity). Within IN01, Business Areas BA-RETAIL, BA-WHOLESALE, BA-EXPORT track divisional performance. The India statutory accounts file under IN01 (legal). Divisional P&L reports use Business Areas (internal). Note: In S/4HANA, Profit Centres are preferred over Business Areas.
A Chart of Accounts (CoA) is the structured list of G/L accounts. SAP supports three types: Operating CoA - used for daily postings (assigned to company code), Group CoA - for consolidated financial statements across company codes, Country CoA - for local statutory requirements (alternative accounts). One company code uses one operating CoA but can have group and country CoA mapped.
Example: Global company uses Operating CoA "INT" for all postings. Group CoA "GROUP" used for IFRS consolidation. Indian subsidiary maps its accounts to Country CoA "IND" for MCA filing. GL account 400000 (Sales) in INT maps to GRP-7000 in GROUP CoA and IND-400 in Country CoA - all maintained in the GL master.
A Posting Key is a 2-digit code that determines: debit/credit indicator, account type (G/L, vendor, customer, asset), and field status (required/optional/hidden fields) for each line item in a document. Standard keys: 40 (GL debit), 50 (GL credit), 31 (vendor invoice), 01 (customer invoice), 70 (asset debit).
Example: Posting vendor invoice in FB60: Line 1 uses posting key 31 (vendor credit) → vendor account selected, amount ₹50,000 credit. Line 2 uses posting key 40 (GL debit) → expense account 420000 selected, ₹50,000 debit. Posting key 31 forces the account type to vendor - you cannot accidentally post to a customer account.
A Parked Document is saved incompletely, updates totals in FI, is visible in reports, can be changed by others, and triggers workflow for approval. A Held Document is a temporary save for the same user only - it does NOT update account balances or totals, is not visible in reports, and has no document number assigned permanently.
Example: AP clerk parks a vendor invoice FB60 - the payable appears in the vendor balance report and triggers a manager approval workflow. The clerk holds a partial journal entry FB50 for lunch break - no impact on balances, no one else can see it. On return, the clerk retrieves and completes the held document.
A Reconciliation Account is a G/L account assigned to a subledger (vendor, customer, or asset) in the master data. All postings to the subledger automatically update the reconciliation account, keeping GL and subledger always in balance. Direct posting is blocked to maintain this automatic synchronisation - posting directly would break the GL-subledger reconciliation.
Example: Vendor master has reconciliation account 160000 (Accounts Payable). When invoice of ₹1L is posted to vendor V-1001, SAP automatically credits GL 160000 for ₹1L - no separate GL posting needed. If you try to post directly to GL 160000 via FB50, SAP gives error "Account 160000 is a reconciliation account."
The GR/IR (Goods Receipt / Invoice Receipt) clearing account is a temporary suspense account that bridges the gap between goods receipt and vendor invoice. On GR, expense Dr / GR-IR Cr. On invoice, GR-IR Dr / Vendor Cr. The 3-way match compares PO quantity/price, GR quantity, and invoice quantity/price before clearing.
Example: PO: 100 units @ ₹100. GR: 100 units received → Expense Dr ₹10,000 / GR-IR Cr ₹10,000. Invoice arrives for 100 units @ ₹100 → GR-IR Dr ₹10,000 / Vendor Cr ₹10,000. GR-IR clears to zero. If invoice is for ₹105/unit → ₹500 price variance posts to a variance account during MIRO.
Dunning is the automated process of sending payment reminders to customers for overdue items. Configuration: Define dunning procedure (levels, intervals, charges, interest), assign to customer master. Run via F150 - SAP checks overdue items, assigns dunning level, generates dunning letters. Each level can have different charges and interest rates.
Example: Dunning procedure DP01: Level 1 (10 days overdue) → polite reminder, no charge. Level 2 (25 days) → reminder + ₹500 charge. Level 3 (40 days) → final warning + 18% interest. Level 4 (55 days) → send to legal. Customer C-1001 has invoice overdue 30 days → F150 assigns Level 2, generates letter with ₹500 dunning charge posted automatically.
The Automatic Payment Program (F110) selects due vendor/customer open items, applies payment methods (bank transfer, cheque), respects cash discount terms, generates payment documents, and creates payment files for bank upload. Configuration: payment methods per country/company, bank ranking, house bank assignment.
Example: Run F110 on 15-Mar: parameters = company code IN01, payment run date 15-Mar, next payment date 22-Mar. APP selects all invoices due up to 22-Mar. Vendor V-200 has ₹5L due, payment method T (bank transfer), house bank HDFC. APP generates payment doc, clears open items, creates NEFT file for upload to HDFC internet banking.
Cash discount is a reduction in invoice value for early payment, controlled by Payment Terms (configured in OBB8). Two methods: Net method (discount posted at invoice time, reversed if not taken), Gross method (discount posted at payment time). Most companies use gross method. Discount G/L accounts assigned in OBB1.
Example: Payment terms ZB14: 2% discount if paid within 14 days, net 30. Invoice ₹1,00,000. Paid on day 10 → APP calculates 2% = ₹2,000 discount. Payment document: Vendor Dr ₹1,00,000 / Bank Cr ₹98,000 / Cash Discount Income Cr ₹2,000. Discount account 390000 credited automatically.
A Special G/L indicator redirects a posting from the normal reconciliation account to an alternative G/L account. Used for: down payments (indicator A), bill of exchange (W), guarantees (G), security deposits. This keeps down payments separate from normal payables/receivables - essential for correct balance sheet presentation under accounting standards.
Example: Vendor requires 30% advance before supplying machinery. Post down payment using F-47 / F110 with special GL indicator A. Instead of posting to reconciliation account 160000 (Accounts Payable), SAP posts to alternative account 170000 (Down Payments to Vendors). Balance sheet shows advances separately from trade payables - per AS/IFRS requirements.
A depreciation area holds a parallel set of asset values and depreciation rules. Companies maintain multiple depreciation areas for different reporting purposes: Area 01 (book - posts to GL), Area 15 (tax - for income tax depreciation), Area 30 (IFRS - different useful life/method). Only area 01 (or the leading area) posts to FI.
Example: Machine costing ₹10L. Area 01 (Indian GAAP): SLM 10 years = ₹1L/year depreciation - posts to GL. Area 15 (Income Tax): WDV 15% = ₹1.5L/year - used for tax computation only, no GL posting. Area 30 (IFRS): Component-based, useful life 8 years = ₹1.25L/year. Each area gives different asset values for different regulatory requirements.
Ordinary depreciation is regular planned depreciation per the depreciation key (SLM/WDV) - posted automatically by the depreciation run AFAB. Special depreciation is an additional statutory depreciation (e.g., investment allowance) on top of ordinary - planned in the depreciation key. Unplanned depreciation is a one-time manual write-down for impairment, posted via ABAA.
Example: Asset value ₹5L. Ordinary: SLM 5 years = ₹1L/year automatic via AFAB. Special: Government allows 20% additional in year 1 = ₹1L extra - configured in depreciation key. Unplanned: Flood damages asset, impairment of ₹50,000 → post manually via ABAA with transaction type 640. All three types appear separately in the asset explorer AW01N.
An Asset Class is a grouping of assets with the same nature and depreciation rules (e.g., 1000-Buildings, 2000-Plant & Machinery, 3000-Vehicles, 4100-AuC). It controls: G/L accounts for acquisition, depreciation, and accumulated depreciation; default depreciation key and useful life; screen layout; and number range for asset master.
Example: Asset Class 2000 (Plant & Machinery): acquisition account = 121000, accumulated depreciation = 121100, depreciation expense = 621000. Default depreciation key = WDV15 (15% WDV). When asset 200045 (CNC Machine) is purchased, SAP automatically knows which GL accounts to use and which depreciation key to apply - no manual configuration needed per asset.
In S/4HANA New Asset Accounting, each depreciation area posts in real time to the Universal Journal (ACDOCA) - no more periodic depreciation posting runs for leading areas. Parallel valuation for IFRS and local GAAP is fully supported. The leading depreciation area directly drives the FI document. Period-end runs via AFAB still run for non-leading areas.
Example: In ECC, depreciation posting ran monthly via AFAB for all areas - delayed G/L updates. In S/4HANA, when asset acquisition is posted, Area 01 (IFRS) immediately posts to ACDOCA - the balance sheet reflects the new asset value instantly. No month-end wait. Area 15 (tax) still runs via AFAB as it is non-leading.
The Controlling Area is the organisational unit for cost accounting in CO. One controlling area can contain multiple company codes (cross-company-code cost accounting). The controlling area defines the CO currency, fiscal year variant, and chart of accounts used in CO. All CO objects (cost centres, internal orders, WBS) belong to one controlling area.
Example: Group has 3 company codes: IN01 (India), SG01 (Singapore), AU01 (Australia). All assigned to one controlling area CORP. A cost centre WC-IT can receive postings from all three company codes. CO reports show group-wide IT costs in one view. Each company code still files its own statutory accounts - controlling area handles the management view.
A Cost Centre is an organisational unit in CO that collects costs for a specific area of responsibility. It only holds cost postings - no revenue. Used for cost control and allocation. A Profit Centre is a management accounting unit that holds both revenues and costs, enabling an internal P&L per business segment. Profit Centre is in EC-PCA (or New GL) and integrates with the balance sheet via document splitting.
Example: Department "IT Support" = Cost Centre CC-IT (only costs: salaries, hardware, software licences). Product line "Smartphones" = Profit Centre PC-SMART (revenue from smartphone sales + all associated costs). The IT Support costs get allocated to Profit Centres including PC-SMART so the true profitability of Smartphones is visible after absorbing IT overhead.
Distribution transfers primary costs from a sender cost centre to receivers using the original cost elements (cost element detail preserved). Assessment transfers primary + secondary costs using a single assessment cost element (cost element detail lost, absorbed into one line). Distribution = transparent, Assessment = summarised. Both run via KSV5 (distribution) and KSU5 (assessment).
Example: IT Cost Centre has ₹5L costs: ₹3L salaries (420000), ₹2L software (430000). Distribution to 3 product cost centres: receivers see ₹3L on CE 420000 and ₹2L on CE 430000 - full transparency. Assessment: receivers see ₹5L on a single assessment CE 990000 "IT Overhead" - detail hidden. Finance teams prefer distribution; simple overhead allocation uses assessment.
An Activity Type is a unit of work performed by a cost centre (e.g., machine hours, labour hours). The activity rate = planned cost of the cost centre ÷ planned activity quantity. Actual cost postings occur when a receiver (order/WBS/cost centre) confirms consumption of the activity type. Rate calculated during planning via KP26, actual allocation via confirmation transactions.
Example: Production Cost Centre CC-MACH: planned costs ₹12L/year, planned machine hours = 10,000. Rate = ₹120/hour (set in KP26). Production Order PO-500 uses 200 machine hours → CO posts ₹24,000 (200×120) to the order and credits CC-MACH. At period-end, actual rate may differ - variance analysis compares planned vs actual rate.
An Internal Order is a temporary cost collector for a specific event, project, or task - it has a defined start/end. A Cost Centre is a permanent organisational unit. Internal orders allow detailed tracking of costs for specific purposes (marketing campaign, trade show, machine repair) before settling to cost centres, assets, or GL accounts.
Example: Annual Sales Conference: Internal Order IO-1234 created for the event. All costs (venue ₹2L, catering ₹1L, travel ₹50K) posted to IO-1234 during the year. After the event, settlement rule settles 100% to Cost Centre CC-SALES. Cost centre reports show the conference cost as a settled allocation - IO provides the detailed audit trail.
Product Costing (CO-PC) calculates the cost to manufacture a product using BOM (materials), routing (work centre activities), and overhead. A standard cost estimate (run via CK11N) rolls up all cost components to give a standard price. This standard price is used to value inventory and measure production variances.
Example: Product FG-500 (Finished Goods). Cost estimate rolls up: Raw material RM-100 = ₹50, RM-200 = ₹30; Labour (1 hr @ ₹80) = ₹80; Machine (0.5 hr @ ₹120) = ₹60; Overhead 25% on labour = ₹20. Total standard cost = ₹240. Released via CK24. GR of FG-500 from production values inventory at ₹240/unit.
CO-PA provides multi-dimensional profitability analysis using characteristics (customer, product, region, channel) and value fields (revenue, COGS, discount). Two types: Costing-based CO-PA (uses value fields, not linked to GL directly - fast, flexible), Account-based CO-PA (uses cost elements, always reconciled with GL - standard in S/4HANA). S/4HANA mandates account-based CO-PA.
Example: Sales invoice to customer C-500 for product P-100, region North, channel Online. Account-based CO-PA captures: Revenue ₹10,000, COGS ₹6,000, discount ₹500, freight ₹200 - all linked to GL accounts. Report shows contribution margin by product+region+channel. Management can see that Online/North/P-100 has 33% margin vs Offline/South/P-200 at 28%.
Profit Centre Accounting (PCA) generates an internal P&L and balance sheet per profit centre (organisational segment). CO-PA analyses profitability by market-facing dimensions (customer, product, channel). PCA answers "How profitable is our Northern Division?" CO-PA answers "How profitable is product P-100 sold through the online channel?" They complement each other.
Example: Profit Centre PC-NORTH = Northern Division - shows revenues, costs, assets, and liabilities attributed to North. CO-PA operating concern = shows margin per customer segment/product. A single sale contributes to PC-NORTH (PCA) AND to the Customer A / Product X / North segment row in CO-PA simultaneously - two different analytical views of the same transaction.
A costing sheet defines the rules for applying overhead to cost objects. It contains: Base (which primary cost elements trigger overhead), Overhead Rate (percentage or fixed amount), Credit (cost centre receiving the credit). Applied via transaction KGI2 (orders) or CO43 (production orders). Overhead calculation adds indirect costs to products/orders.
Example: Costing sheet OH-MFG: Base = direct material costs (CE group 40xxxx), Rate = 15%. Internal Order IO-800 has ₹4L direct materials. Overhead run posts ₹60,000 (15% × ₹4L) to IO-800 using secondary CE 990010 "Manufacturing Overhead". Cost centre CC-INDIRECT credited ₹60,000 - overhead fully absorbed into the order cost.
Variance = Actual cost – Standard cost of confirmed quantity. Types: Price variance (material bought at different price than standard), Quantity variance (more/less material used than BOM), Resource-usage variance (different activity type used), Remaining variance (unassigned). Calculated via KKS1/KKS2 and settled to CO-PA or a variance G/L account.
Example: Standard cost for 1 unit = ₹200 (material ₹120 + labour ₹80). Actual production of 100 units: material cost = ₹13,000 (standard ₹12,000) → price variance = ₹1,000. Labour = ₹7,500 (standard ₹8,000) → favourable usage variance = ₹500. Net unfavourable variance = ₹500 settled to CO-PA to show true product profitability.
Standard FICO period-end sequence: 1) Post all FI documents (invoices, GRs, payroll), 2) Run overhead calculation (CO43/KGI2), 3) WIP calculation for production orders (KKAX), 4) Variance calculation (KKS1), 5) Settlement of orders to cost centres/CO-PA (CO88/KO8G), 6) Assessment/Distribution (KSU5/KSV5), 7) Asset depreciation run (AFAB), 8) Profit Centre transfer prices, 9) Close CO period, 10) Close FI period (OB52).
Example: March month-end: 1-Apr post all invoices → 2-Apr run CO43 (overhead ₹3L posted) → run KKAX (WIP ₹8L for in-progress orders) → KKS1 (variance ₹50K) → CO88 (settle orders to CO-PA) → KSU5 (assess IT costs to product lines) → AFAB (₹2L depreciation) → OB52 (close March in FI). CFO gets P&L by 5-Apr.
A Validation checks a posting against defined rules and either allows it or rejects it with an error/warning - it does NOT change data. A Substitution automatically replaces or fills in a field value during posting based on defined conditions - it DOES change data. Both use ABAP Boolean rules (prerequisites + checks/substitution values). Configured in GGB0 (substitution) and GGB4 (validation).
Example: Validation: If company code = IN01 and GL account = 420000, then cost centre MUST be filled → post without cost centre gives error. Substitution: If GL account starts with 42 (expense), automatically fill profit centre = PC-DEFAULT from the cost centre's assigned profit centre - saves manual entry and prevents blank profit centre postings.
Foreign currency revaluation adjusts the local currency value of open items (receivables, payables, bank balances) denominated in foreign currency to the current exchange rate at period-end. Required by accounting standards (AS11, IFRS 21). Run via FAGL_FC_VAL. Posts unrealised forex gain/loss. Reverses on the first day of the next period.
Example: USD invoice of $10,000 posted at rate 82.00 = ₹8,20,000. At 31-Mar, USD rate = 83.50. Revaluation run: new value = ₹8,35,000. Unrealised forex loss of ₹15,000 posted (vendor Cr ₹15,000 / Forex Loss Dr ₹15,000). On 1-Apr, reversal entry automatically posts ₹15,000 back - only the realised gain/loss at actual payment date is permanent.
Clearing matches open debit and credit items in a subledger account (vendor/customer) and marks them as cleared - reduces the open item list. It does not create a new accounting entry. Reversal creates a mirror-image document to cancel an incorrect posting - both the original and reversal documents remain visible. Clearing = settlement, Reversal = correction.
Example: Vendor V-100 has open invoice ₹50,000 (doc 1800001). Payment of ₹50,000 posted (doc 1900001). Clearing via F-44 matches these two - both show as "cleared", open item list is zero. For a wrong posting, Reversal via FB08 creates doc 1900002 (exact mirror). Both 1900001 and 1900002 remain in the system - full audit trail preserved.
Accruals recognise expenses/revenues incurred but not yet invoiced (e.g., electricity bill not yet received). Deferrals postpone recognition of prepaid expenses/revenues to future periods. In SAP, the Accrual Engine (ACACTREE02) or recurring entry (FBD1) automates periodic accrual postings with automatic reversals.
Example: Annual insurance premium ₹1,20,000 paid in January. Deferral: post ₹1,20,000 to Prepaid account. Each month, recurring entry in FBD1 debits Insurance Expense ₹10,000 and credits Prepaid ₹10,000 automatically. Accrual: December electricity bill not yet received → post estimate ₹15,000 (Expense Dr / Accrual Cr). Auto-reverses 1-Jan when actual bill arrives.
Intercompany posting allows a single document to span two company codes. SAP automatically generates the due-to / due-from clearing entries in both company codes. Configuration: define intercompany clearing accounts per company code pair in OBYA. Posted via FB50 (GL) or via the MM/SD intercompany process.
Example: Company IN01 pays rent ₹1L on behalf of Company SG01. One document in IN01: Rent Expense Dr ₹1L (for IN01) / Bank Cr ₹1L (IN01). SAP auto-creates in SG01: Rent Expense Dr ₹1L / Due to IN01 Cr ₹1L. Clearing account 198000 (Due from/to group companies) used in both entities. Consolidated statements eliminate these intercompany balances.
Bank reconciliation matches SAP bank GL postings with bank statement entries. SAP uses Electronic Bank Statement (EBS) uploaded via FF_5 or FEBAN. The system automatically matches and clears transactions using matching rules (amount, reference, date). Unmatched items are flagged for manual clearing. The bank clearing account (interim) is used as a bridge.
Example: 50 outgoing payments made via APP (F110) - SAP posts Bank Clearing Cr ₹50L. Bank statement uploaded via FF_5: system matches all 50 payments automatically → Bank Clearing Dr ₹50L / Bank Main GL Cr ₹50L. Bank statement shows 52 entries - 2 unmatched bank charges → manually post in FEBAN. Bank GL = bank statement balance confirmed.
The Fiscal Year Variant defines the number of posting periods (12 regular + up to 4 special) and whether the fiscal year aligns with the calendar year. Types: V3 (April to March - India), K4 (January to December), V6 (July to June). Assigned to the company code and controlling area. Special periods are used for year-end audit adjustments.
Example: Indian company uses fiscal year variant V3 (Apr-Mar). Period 1 = April, Period 12 = March. Special periods 13-16 allow auditors to post adjustments after 31-Mar while March is "closed" for normal postings. System date 15-Apr = Period 1 of new year. Posting to previous March requires special period 13 - controlled via OB52 open/close periods.
WIP calculation capitalises costs accumulated on production orders not yet delivered (still in process). It prevents recognising costs as P&L expenses until the goods are delivered. WIP = actual costs on order – standard cost of confirmed deliveries. Run via KKAX (individual) or KKAO (collective). Posts to a WIP balance sheet account.
Example: Production Order 800001 for 100 units. By month-end, costs incurred = ₹18,000 but only 60 units delivered (standard cost ₹200 each = ₹12,000). WIP = ₹18,000 – ₹12,000 = ₹6,000. KKAX posts: WIP Asset (BS) Dr ₹6,000 / Change in WIP (P&L) Cr ₹6,000. P&L impact deferred until remaining 40 units are completed and delivered.
Transfer pricing assigns an internal price to goods/services transferred between profit centres or company codes. Allows profit centres to simulate external market conditions. In SAP, configured via material ledger and profit centre valuation. Goods movements between profit centres post at both cost (legal) and transfer price (management) simultaneously using parallel valuations.
Example: Profit Centre PC-MFG manufactures a component at cost ₹100. It "sells" to PC-RETAIL at transfer price ₹130 (market price). PC-MFG shows ₹30 internal profit. PC-RETAIL gets the component at ₹130 in its P&L. Consolidated P&L eliminates the ₹30 internal margin. Management can assess the true profitability of each division independently.
The Material Ledger (ML) records all goods movements at actual cost in addition to standard cost. With Actual Costing (ML activated), price variances from purchasing and production are rolled up through the BOM structure and revalue inventory to actual cost at period-end. This gives the most accurate inventory valuation for management reporting.
Example: Standard cost of FG-500 = ₹240. In March, raw material prices increased → actual cost = ₹258. ML actual costing run: ₹18 variance rolled up to FG-500. Inventory revalued from ₹240 to ₹258 at period-end. COGS also adjusted. Month-end P&L reflects true material cost - not the potentially outdated standard price set 6 months earlier.
A Tolerance Group defines the limits within which a user can post documents: maximum document amount, maximum amount per open item (line), maximum cash discount percentage, and permitted payment difference (underpayment/overpayment tolerance). Assigned in the user master. Used to enforce segregation of financial authority - junior staff post small amounts, senior staff approve large ones.
Example: Tolerance group JUNIOR: max document ₹1L, max per line ₹50,000, max discount 3%. Tolerance group SENIOR: max document ₹50L, max per line ₹25L. AP clerk (JUNIOR) tries to post ₹1.5L invoice → SAP error "amount exceeds tolerance". Manager (SENIOR) posts same document successfully. Also, ₹2 underpayment within tolerance → auto-cleared as trivial difference.
A Field Status Group (FSG) is assigned to each G/L account and controls which fields are Required, Optional, or Suppressed during document entry for that account. The final field status = strictest setting among FSG of the G/L account, the posting key, and the transaction. Configured in OBC4.
Example: Expense G/L 420000 has FSG G004: Cost Centre = Required, Profit Centre = Optional, Assignment = Suppressed. Posting key 40 has Cost Centre = Optional. Final rule = Required (strictest). When posting a debit to 420000 via FB50, SAP forces entry of cost centre - blank cost centre blocks the posting. This ensures all expense postings are properly attributed to a cost centre.
A Lockbox is a bank-managed collection service where customers send payments directly to a bank PO box. The bank processes cheques and sends an electronic BAI2 file to the company. SAP uploads this file via FLB2, automatically matching payments to open invoices using customer number, invoice number, and amount. Reduces manual AR clearing significantly.
Example: 200 customer cheques received at bank lockbox in one day. Bank processes all and sends BAI2 file. FLB2 uploads and auto-matches 190 payments (95%) to open invoices → automatic clearing. 10 unmatched (cheques without remittance) go to exception list for manual review. AR team clears 200 items in 1 hour instead of 2 days of manual posting.
CO versions allow multiple sets of planned costs to coexist. Version 0 is the operative version - actual postings and the main planning version. Versions 1, 2... are used for alternative plans (budget scenarios, re-forecasts). Actual costs always go to version 0 regardless. Planning can be maintained in any version. Reports compare actuals (v0) vs plan (v0 or other versions).
Example: Annual planning: Version 0 = approved budget. Version 1 = optimistic scenario (+15% growth). Version 2 = conservative scenario (-10%). Actual costs post to Version 0. Monthly report compares: Actual (v0) vs Budget (v0) vs Optimistic (v1). Management sees budget variance and can also assess how far from the optimistic case they are - without affecting live postings.
A Credit Control Area groups company codes for credit management. Each customer gets a credit limit per credit control area. When a sales order is created, SAP checks the customer's open AR + open deliveries + open sales orders against the credit limit. If exceeded, the order can be blocked (warning/error) - managed via FD32 (customer credit master).
Example: Customer C-500 has credit limit ₹10L in CCA IN01. Current exposure: Open invoices ₹6L + Open deliveries ₹3L = ₹9L used. New sales order of ₹2L created → total = ₹11L → exceeds limit by ₹1L. SAP blocks the sales order. Credit manager reviews in VKM1 and either releases the order or contacts customer for payment before releasing.
The Leading Ledger (0L) is the primary ledger - it receives all FI postings, drives financial statements, and is used for legal consolidation. A Non-Leading Ledger is an additional parallel ledger used for alternative accounting principles (e.g., IFRS vs local GAAP). Non-leading ledgers only receive postings that differ from the leading ledger (e.g., different depreciation).
Example: Indian company: Leading Ledger 0L (Indian GAAP / Companies Act). Non-Leading Ledger L1 (IFRS for Group consolidation). Most transactions post identically to both. Differences: IFRS lease accounting (Ind AS 116 vs Indian GAAP) → lease liability entry posts to L1 only. IFRS financial statements use L1; Indian statutory accounts use 0L.
An Account Assignment Model (FKMT) is a template with predefined line items (GL accounts, cost centres, amounts/percentages) for frequently recurring entries. A Sample Document (F-01) is a reference document that can be called up to pre-fill a posting. Both save time and reduce errors for recurring journal entries like rent allocation or utility cost distribution.
Example: Monthly office rent ₹1,20,000 split: CC-SALES 40%, CC-HR 30%, CC-ADMIN 30%. Account Assignment Model RENT created with 3 lines: CC-SALES ₹48K, CC-HR ₹36K, CC-ADMIN ₹36K. Each month, AP clerk calls up model RENT in FB50 → all lines pre-filled → enter rent invoice amount → post. 5-minute posting instead of 15 minutes of manual entry.
FI-MM integration is driven by the Account Determination configuration in MM (transaction OBYC). Every goods movement and invoice triggers automatic FI postings based on valuation class, movement type, and transaction key. Key flows: PO → GR (stock Dr / GR-IR Cr), Invoice (GR-IR Dr / Vendor Cr), Payment (Vendor Dr / Bank Cr).
Example: Material valuation class 3000 (Finished Goods). OBYC: transaction key BSX (stock account) = 130000, WRX (GR-IR) = 191100. GR of 100 units at ₹200 standard: Stock 130000 Dr ₹20,000 / GR-IR 191100 Cr ₹20,000. No manual FI entry - fully automatic. The FI document is created simultaneously with the material document in MIGO.
FI-SD integration: Goods Issue in SD (delivery) triggers inventory reduction and COGS posting. Billing document in SD (VF01) creates FI document with AR (customer Dr) and Revenue (Cr). Revenue account determination via SD Account Key in pricing procedure mapped to GL in VKOA. Tax accounts also auto-determined from tax codes.
Example: Sales order delivered and billed. GI (VL02N): COGS Dr 500000 ₹8,000 / Stock Cr 130000 ₹8,000. Billing (VF01): Customer Dr 110000 ₹11,800 / Sales Revenue Cr 400000 ₹10,000 / GST Output Tax Cr 175000 ₹1,800. All three FI documents created automatically - no manual GL posting needed. CO-PA also updated simultaneously with revenue and COGS.
The Tax Procedure defines how tax is calculated and which GL accounts receive tax postings. For India (TAXIN / TAXINN), GST has CGST, SGST, IGST components. Configuration: Tax procedure assigned to country (OBBG), tax codes created (FTXP), GL accounts assigned (OB40). Tax codes assigned to vendors/customers/materials control which tax rates apply.
Example: Purchase invoice for intra-state supply. Tax code V1 = CGST 9% + SGST 9%. Invoice ₹1,00,000 + tax. MIRO posts: GR-IR Dr ₹1,00,000 / CGST Input Dr ₹9,000 / SGST Input Dr ₹9,000 / Vendor Cr ₹1,18,000. Tax GL accounts 154000 (CGST) and 155000 (SGST) updated. GSTR-2A reconciliation done from these tax accounts.
A Segment in New GL is an account assignment dimension for reporting operating segments as required by IFRS 8 (Operating Segments). It is derived from the Profit Centre master. Document splitting ensures balance sheet items (AR, AP, assets) are split by segment, enabling a complete segmental balance sheet and P&L. Segment reporting is mandatory for listed companies under IFRS.
Example: Listed company has 3 reportable segments per IFRS 8: Pharma, Chemicals, Agri. Each Profit Centre is assigned a segment. Sales invoice to a Pharma customer → segment PHARMA auto-derived → revenue, COGS, AR all tagged to PHARMA. Annual report Note 5 (Segment Reporting) directly populated from SAP segment dimension - no Excel consolidation needed.
Step-by-step: 1) Note the transaction key in the error (e.g., WRX = GR/IR, BSX = stock). 2) Check OBYC for that transaction key - is the GL account assigned for the valuation grouping code + valuation class? 3) Check if the GL account exists and is not blocked in the company code (FS00). 4) Check if the GL account has a valid field status group. 5) Check if CO assignment is missing.
Example: MIRO error: "G/L account for transaction WRX not found." Check OBYC → WRX → Valuation grouping code 0001, Valuation class 3000 → blank GL account. Root cause: new valuation class added for imported goods but OBYC not updated. Fix: assign GL 191100 to WRX/0001/3000 in OBYC. Re-post MIRO → succeeds. Always transport OBYC changes to production carefully - wrong account = misstated financials.
Key ECC→S/4HANA FICO changes: Universal Journal (ACDOCA) replaces BKPF/BSEG/COEP/FAGLFLEXA. New Asset Accounting - real-time depreciation. Account-based CO-PA mandatory (costing-based still available). Profit Centre mandatory on all postings. Business Partner replaces vendor/customer masters. Reconciliation ledger removed. Material Ledger mandatory. Fiori apps replace SAP GUI transactions.
Example: ECC consultant moves to S/4HANA project. Key adjustments needed: 1) Custom ABAP reports querying BSEG must be rewritten to use ACDOCA. 2) Costing-based CO-PA reports need account-based equivalents. 3) Vendor master (LFA1/LFB1) data migration to Business Partner (BUT000/BUT020). 4) Reconciliation ledger jobs removed from month-end schedule. 5) Learn Fiori apps like Manage Journal Entries (F0717), Post Outgoing Payments.
🗄️ Important SAP FICO Database Tables
A solid knowledge of FICO tables is essential for reporting, ABAP development, and system troubleshooting. These are the most important tables every FICO consultant must know.
| Table | Description | Key Fields |
|---|---|---|
| BKPF | Accounting Document Header | BUKRS + BELNR + GJAHR |
| BSEG | Accounting Document Line Items (ECC) | BUKRS + BELNR + GJAHR + BUZEI |
| ACDOCA | Universal Journal (S/4HANA) - all FI+CO line items | RLDNR + RBUKRS + GJAHR + BELNR + DOCLN |
| BSIS | G/L Open Items | BUKRS + HKONT + GJAHR + BELNR |
| BSAS | G/L Cleared Items | BUKRS + HKONT + GJAHR + BELNR |
| BSIK | Vendor Open Items (AP) | BUKRS + LIFNR + GJAHR + BELNR |
| BSAK | Vendor Cleared Items | BUKRS + LIFNR + GJAHR + BELNR |
| BSID | Customer Open Items (AR) | BUKRS + KUNNR + GJAHR + BELNR |
| BSAD | Customer Cleared Items | BUKRS + KUNNR + GJAHR + BELNR |
| SKA1 | G/L Account Master (Chart of Accounts) | KTOPL + SAKNR |
| SKB1 | G/L Account Master (Company Code) | BUKRS + SAKNR |
| T001 | Company Codes | BUKRS |
| ANLA | Asset Master - General Data | BUKRS + ANLN1 + ANLN2 |
| ANLZ | Asset Master - Time-Dependent Data | BUKRS + ANLN1 + ANLN2 + ADATU |
| Table | Description | Key Fields |
|---|---|---|
| CSKS | Cost Centre Master Data | KOKRS + KOSTL + DATBI |
| CSKT | Cost Centre Texts | MANDT + SPRAS + KOKRS + KOSTL + DATBI |
| CSKA | Cost Elements (Controlling Area) | KTOPL + KSTAR |
| COEP | CO Actual Line Items (ECC) | KOKRS + BELNR + BUZEI |
| COSP | CO Cost Totals - External Postings | OBJNR + WRTTP + GJAHR + KSTAR |
| COSS | CO Cost Totals - Internal Postings | OBJNR + WRTTP + GJAHR + KSTAR |
| AUFK | Internal Order Master | AUFNR |
| CE1xxxx | CO-PA Line Items (costing-based, xxxx=op. concern) | PALEDGER + PERIV + PERDE |
| CEPC | Profit Centre Master Data | PRCTR + DATBI + KOKRS |
| GLPCA | EC-PCA Actual Line Items (ECC) | RYEAR + DOCNR + POSNR |
S/4HANA Tip: In S/4HANA, always query ACDOCA first - it replaces BSEG, COEP, GLPCA, and the old FI/CO line item tables. Field PRCTR (profit centre), KOSTL (cost centre), SEGMENT, and PS_PSP_PNR (WBS) are all available directly in ACDOCA - no joins needed.
⚡ Key SAP FICO Transactions
| Transaction | Description | Area |
|---|---|---|
| FB50 | Enter G/L Account Document | GL |
| FB60 | Enter Vendor Invoice | AP |
| F110 | Automatic Payment Program | AP |
| MIRO | Enter Incoming Invoice (MM-based) | AP/MM |
| FB70 | Enter Customer Invoice | AR |
| F150 | Dunning Run | AR |
| F-44 | Clear Vendor Account | AP |
| F-32 | Clear Customer Account | AR |
| FB08 | Reverse Document | GL |
| AFAB | Asset Depreciation Run | FI-AA |
| AW01N | Asset Explorer | FI-AA |
| AIAB / AIBU | AuC Settlement / Capitalisation | FI-AA/PS |
| KSU5 | Execute Assessment Cycle | CO-CCA |
| KSV5 | Execute Distribution Cycle | CO-CCA |
| KO8G | Settle Internal Orders (collective) | CO-IO |
| CO88 | Settle Production/Process Orders | CO-PC |
| KKS1/KKS2 | Variance Calculation | CO-PC |
| KKAX/KKAO | WIP Calculation (individual/collective) | CO-PC |
| CK11N | Create Standard Cost Estimate | CO-PC |
| CK24 | Mark and Release Standard Cost Estimate | CO-PC |
| FAGL_FC_VAL | Foreign Currency Revaluation | GL |
| OB52 | Open and Close Posting Periods | FI Config |
| F-02 | Enter General Posting (manual GL) | GL |
| S_ALR_87012168 | G/L Balance Display | GL Reporting |
Interview Ready?
Work through all 50 questions. For each answer, always mention the transaction code, relevant table, and a business context. Interviewers value hands-on knowledge - saying "I have configured this in..." is far more powerful than theory alone.
📘 Related SAP Tutorials
SAP PS Interview Questions
Top 50 advanced SAP Project Systems interview questions with answers and real examples for senior consultants.
Read TutorialWhat Are SAP OSS Notes
What Are SAP OSS Notes? Complete Guide for Beginners.
Read Tutorial