Top 120 SAP FICO Interview
Questions & Answers (2026)

SAP FICO stands for Financial Accounting (FI) and Controlling (CO) — SAP's core financial management module. FI handles external statutory reporting: General Ledger (GL), Accounts Payable (AP), Accounts Receivable (AR), Asset Accounting (AA), and Bank Accounting — producing financial statements for regulators, shareholders, and tax authorities. CO handles internal management accounting: Cost Centre Accounting, Profit Centre Accounting, Internal Orders, Product Costing, and Profitability Analysis (CO-PA) — supporting internal decisions. Together, FICO provides real-time financial visibility, statutory compliance, and management reporting in one integrated system. FICO is the financial backbone of every SAP implementation and is used by over 90% of Fortune 500 companies globally.

SAP FI (Financial Accounting) focuses on external reporting — it produces financial statements for regulators, auditors, shareholders, and tax authorities. Key components: General Ledger, Accounts Payable, Accounts Receivable, Asset Accounting, and Bank Accounting. FI is transaction-driven and follows statutory accounting standards (IFRS, GAAP).

SAP CO (Controlling) focuses on internal management reporting — tracking costs, managing budgets, and supporting profitability decisions. Key components: Cost Centre Accounting (CCA), Profit Centre Accounting (PCA), Internal Orders (IO), Product Costing (CO-PC), and CO-PA. CO is decision-driven and not subject to external accounting standards.

In SAP S/4HANA, FI and CO are fully merged through the Universal Journal (ACDOCA), eliminating the need for periodic FI-CO reconciliation that was required in classic SAP ECC.

A Company Code is the smallest organisational unit in SAP FI for which a complete, self-contained set of accounts can be drawn up for external reporting. It represents a legal entity — a company, subsidiary, or branch that must produce its own Balance Sheet and Profit & Loss Statement.

Every financial transaction in SAP must be assigned to a Company Code. One SAP Client can have multiple Company Codes. Key configuration: OX02 (create Company Code), OBY6 (global parameters — chart of accounts, fiscal year variant, currency), OBC5 (field status variant), FBN1 (document number ranges). The Company Code is the central entity around which all FICO configuration is built.

A Chart of Accounts (CoA) is a classified list of all General Ledger accounts used by a Company Code. Three types: (1) Operative CoA — the primary chart used for all daily postings, assigned to Company Codes; (2) Country-Specific CoA — used for local statutory reporting alongside the operative CoA; (3) Group CoA — used for consolidation across Company Codes with different operative charts.

The CoA is assigned to a Company Code in OBY6. GL accounts are maintained in FS00. Account groups within the CoA control the number range and field status for GL account master data. One CoA can be assigned to multiple Company Codes, but each Company Code can only have one operative CoA.

The Fiscal Year Variant defines the financial year structure for a Company Code — the number of posting periods, when the fiscal year starts and ends, and how many special periods (up to 4) are available for year-end adjustments.

A fiscal year can be a calendar year (January–December) or a non-calendar year (e.g. April–March for UK/India, July–June for Australian companies). Configured in OB29 and assigned to the Company Code in OBY6. All Company Codes within the same Controlling Area must use the same fiscal year variant. The variant maps each calendar period to a posting period number.

The Posting Period Variant controls which accounting periods are open or closed for posting, preventing accidental entries in closed periods and ensuring data integrity. Configured in OBBO (define variant), OB52 (specify open periods per account type), and OBBP (assign to Company Code).

Two intervals can be open simultaneously — e.g. current month and previous month. Account types can have different open periods: A=Assets, D=Customers, K=Vendors, S=GL, M=Materials, V=Contracts. Only authorised users (typically Finance Controllers) can open or close periods — this is a key SOX control.

The Universal Journal (table ACDOCA) is the single source of financial truth in SAP S/4HANA. It replaces multiple separate tables from classic SAP ECC — BKPF, BSEG, COEP, FAGLFLEXA, GLT0, COSP, COSS — with one unified table that stores all FI and CO postings together in a single line item.

Key benefits: elimination of FI-CO reconciliation, real-time analytics without aggregation tables, parallel valuation in a single table, and a dramatically simplified data model. Every financial transaction — from goods receipts to customer payments to cost allocations — creates a single ACDOCA entry. This is one of the most fundamental S/4HANA concepts and is tested in every senior FICO interview.

Document splitting automatically splits accounting line items across dimensions (such as Profit Centre or Segment) to enable complete financial statements at a sub-entity level. For example, if a supplier invoice covers two profit centres, document splitting automatically splits the vendor payable and tax lines proportionally across both profit centres — producing a balanced Balance Sheet per profit centre.

Two types: Active splitting — rule-based, splits items during document entry; Passive splitting — automatically splits clearing items (e.g. payments) based on the items being cleared. Configured in SPRO under New GL → Document Splitting. Zero-balance setting (FAGL_SPLITTING) ensures each profit centre segment is balanced. This is a common topic in S/4HANA Finance interviews.

Special GL (SGL) transactions post to an alternative reconciliation account instead of the standard vendor or customer reconciliation account — displayed separately on the subledger. They are used for items that should be shown distinctly on the Balance Sheet.

Common examples: Down Payments Made (vendor, SGL indicator A — F-47 request, F-48 post, F-54 clear), Down Payments Received (customer, SGL indicator A — F-37 request, F-29 post), Bills of Exchange (W), Guarantees (B), Security Deposits (E). Configured in OBXY. The SGL indicator is entered manually during document entry. Down payment processing is the most commonly tested SGL scenario in FICO interviews.

A Business Area is an older SAP FI organisational unit for internal segment reporting — cross-company-code but with significant limitations: no statutory reporting, difficult reconciliation, incomplete balance sheets. SAP has effectively deprecated Business Areas.

A Profit Centre is a CO organisational unit that tracks both revenues and costs for a business segment, enabling internal P&L and Balance Sheet reporting. In S/4HANA with document splitting, Profit Centres provide complete, balanced financial statements per segment — which Business Areas could never achieve cleanly. New S/4HANA implementations should always use Profit Centres (with the Segment dimension for IFRS 8 compliance) rather than Business Areas.

A reconciliation account is a GL account that is automatically updated whenever a posting is made to a vendor or customer subledger. It links the subledger to the General Ledger — ensuring the GL always equals the sum of all individual vendor or customer balances. You cannot post directly to a reconciliation account; all postings go through the vendor/customer account and the reconciliation account updates automatically.

Configured in the vendor/customer master data (Company Code segment → Account tab). Different reconciliation accounts can be used for different vendor/customer groups (e.g. domestic vendors vs. intercompany). This is fundamental to how AP and AR subledger integrity is maintained.

The GR/IR (Goods Receipt / Invoice Receipt) clearing account is a temporary balance sheet liability account that bridges SAP MM and SAP FI. When goods are received in MM (MIGO): SAP debits stock and credits GR/IR. When the vendor invoice is verified (MIRO): SAP debits GR/IR and credits the vendor AP account. If GR and IR match, GR/IR nets to zero.

Open GR/IR balances at period end indicate unmatched receipts or invoices and must be investigated. Configured via OBYC (transaction key WRX). Month-end clearing: F.13 (automatic clearing) or MR11 (GR/IR maintenance). A common interview question: "What causes an open GR/IR balance?" — answered by: quantity or price differences between PO, GR, and invoice.

FB60 is a direct FI vendor invoice entry transaction — used for non-PO invoices such as utility bills, rent, professional services, or any invoice without a corresponding Purchase Order. GL accounts are entered manually. MIRO (Logistics Invoice Verification) is used for vendor invoices that reference a Purchase Order and Goods Receipt in SAP MM — it performs the automated 3-way match (PO price vs. invoice price vs. GR quantity).

MIRO triggers account determination via OBYC; FB60 requires manual GL account entry. In an integrated environment: MIRO for all procurement invoices, FB60 for all non-procurement invoices. Both create FI accounting documents visible in FBL1N.

Transaction F110 is SAP's Automatic Payment Program (APP) — it processes vendor (and customer direct debit) payments automatically based on payment terms, due dates, and cash discount windows. Four-step process:

1. Parameters — define company codes, payment methods, and date range; 2. Proposal — SAP selects invoices due for payment and proposes payment method and bank account; 3. Edit Proposal — review and adjust the proposal (exclude items, override payment method); 4. Payment Run — post payment documents and generate payment medium (bank EFT file, SEPA XML, cheque). Configured via FBZP (house banks, payment methods, bank determination). F110 is one of the most heavily tested FICO topics in Canadian employer interviews.

Dunning (transaction F150) is SAP's automated process for sending overdue payment reminders to customers. Configuration (FBMP): Dunning Procedure (number of levels, minimum days overdue, intervals between reminders), Dunning Levels (text templates per level, charges, interest calculation), Dunning Areas (organisational subdivision). The dunning procedure is assigned to the customer master (XD02 → Correspondence tab).

Runtime: F150 → Parameters → Proposal (identifies overdue AR items and assigns dunning levels) → Edit Proposal → Print Notices → Update Dunning Data. Dunning history (last dunning date and level) is stored on the customer account and visible in FBL5N. Levels escalate from polite reminder (Level 1) to final demand/legal notice (Level 4+).

Vendor down payments use Special GL indicator A to keep advance payments separate from regular payables on the Balance Sheet. Full process:

F-47 — Down Payment Request (optional); F-48 — Post down payment (debit vendor alternative reconciliation account, credit bank); F110 — Pay the down payment via the APP; When final invoice arrives: MIRO or FB60 posts the invoice; F-54 — Clear the down payment against the invoice (removes from down payment account, reduces the liability).

The SGL indicator ensures the advance appears in a separate "Advances to Vendors" GL account on the Balance Sheet — not mixed with normal AP. This is a frequently tested FICO scenario in both junior and senior interviews.

Tolerance groups define acceptable limits for posting and payment differences. Three types: (1) Employee Tolerance Groups (OBA4) — maximum document amount, maximum per-line amount, and maximum cash discount % an employee can post; (2) GL Account Tolerance Groups (OBA0) — acceptable debit/credit differences when clearing GL open items; (3) Customer/Vendor Tolerance Groups (OBA3) — acceptable payment differences (by amount and %) when clearing invoices against payments.

If a payment difference falls within tolerance, SAP automatically posts it to a configured gain/loss account. Differences outside tolerance must be handled manually via residual item or partial payment. Tolerance groups are fundamental to AP/AR payment processing configuration.

Credit management prevents bad debt by controlling customer credit exposure before orders or deliveries are released. Key elements: Credit Control Area (OB45) — the organisational unit for credit management, spanning one or more Company Codes; Credit Limit — set per customer in FD32; Static check (total open AR vs. limit) or Dynamic check (open orders + deliveries + invoices within a horizon vs. limit); Risk Categories (OB02); Credit Groups (OVA6) — control at which SD stage the check fires.

When a credit limit is exceeded: SAP blocks the sales order. Release via VKM1 (order) or VKM3 (delivery). In S/4HANA, credit management is handled via FSCM Credit Management (UKM_BP_CREDIT).

Clearing matches open debit and credit items on a customer or vendor account so the net balance is zero — items are then marked as "cleared" and no longer appear in open item reports. AP clearing: F-53 (manual outgoing payment) or F110 (automatic) matches payment to open invoice. AR clearing: F-28 (incoming payment) matches customer remittance to open invoice.

Partial clearing options: Partial payment (both invoice and payment remain open but linked) or Residual item (original invoice is cleared, new open item created for the remaining balance). Transaction F.13 runs automatic clearing for GL and subledger accounts based on assignment fields. Clearing document number is stored on all matched items, visible in FBL1N/FBL5N.

Foreign currency revaluation (FAGL_FC_VAL in S/4HANA) revalues open items and GL balances denominated in foreign currency at the current exchange rate, recognising unrealised exchange gains or losses at period end.

Process: SAP compares the original rate on open items with the current rate → posts unrealised gain or loss to configured GL accounts → creates a reversal posting on the first day of the next period (if reversal flag is set). Exchange rate types: M=Standard (most postings), G=Bank buying rate, B=Bank selling rate. Rates maintained in OB08, rate types in OB07. This is a mandatory month-end step for any company with foreign currency transactions — must be run before closing posting periods.

SAP Asset Accounting (FI-AA) manages the complete lifecycle of fixed assets — acquisition, depreciation, revaluation, transfer, and retirement. Asset Classes (OAOA) are the primary organisational unit — they group assets by type (Buildings, Machinery, IT Equipment, Vehicles) and control: GL accounts for asset value and accumulated depreciation (AO90), default depreciation keys, and screen layouts.

In S/4HANA New Asset Accounting, depreciation posts in real time via the Universal Journal (ACDOCA) rather than in batch runs. Key transaction: AW01N (Asset Explorer — view all values, depreciation schedule, and document history for a single asset). Asset master created via AS01, changed via AS02.

A depreciation key defines the rules for how an asset loses value over time — the calculation method (straight-line, declining balance, units of production), the base value (acquisition cost, net book value, or replacement value), the useful life, and any shift factors for multi-shift usage.

Configured in AFAMA. Common standard keys: LINR (straight-line to zero), DG30 (30% declining balance). The key is assigned to the asset master record per depreciation area. Different areas can use different keys — book depreciation uses straight-line while tax depreciation may use accelerated declining balance. Test depreciation simulation via AFARS before going live.

Depreciation areas allow a single asset to be valued simultaneously under multiple accounting standards. Common areas: Area 01 (Book Depreciation — posts to the leading GL ledger, used for IFRS or local GAAP statutory reporting), Area 15 (Tax Depreciation — for tax returns, may not post to GL), Area 20 (Group Depreciation — for consolidation at group level, posts to non-leading ledger).

Only one or more designated areas post to the GL. Other areas can be non-posting (reporting only). Derived areas calculate their values as the mathematical difference between two real areas (e.g. IFRS minus local GAAP timing differences). In S/4HANA, parallel depreciation areas integrate with parallel ledgers for simultaneous IFRS and local GAAP reporting.

Asset Acquisition: Via vendor PO/GR (MM integration — MIGO posts to asset account automatically via account assignment), via vendor invoice (F-90 in FI or MIRO with asset account assignment), or via internal transfer (ABZON — acquisition without vendor). Posting: debit asset account, credit AP/bank/clearing.

Asset Retirement with Revenue: F-92 raises a customer invoice. Posts: debit AR, credit asset at cost, debit accumulated depreciation, credit disposal account, recognise gain/loss. Retirement without Revenue (Scrapping): ABAVN — debit accumulated depreciation, debit loss on disposal, credit asset at cost. Intra-company transfer: ABUMN. Intercompany transfer: ABT1N. Year-end: AJRW (fiscal year change), AJAB (close fiscal year in AA).

New GL (introduced SAP ECC 6.0) addresses Classic GL limitations: (1) Document Splitting — splits documents across Profit Centres/Segments for complete Balance Sheet reporting per entity; (2) Parallel Ledgers — multiple ledgers (IFRS leading + local GAAP non-leading) in one system without separate company codes; (3) Segment Dimension — native IFRS 8 segment reporting without Business Areas; (4) Real-time FI-CO Integration — eliminates the periodic FI-CO reconciliation run (KALC); (5) Extension Ledger (S/4HANA) — post adjustments to a supplementary ledger without affecting the leading ledger.

In S/4HANA, New GL is mandatory and extended via the Universal Journal. Classic GL is not supported in S/4HANA.

Month-end closing in SAP FICO follows a defined sequence — order matters as later steps depend on earlier ones: (1) Post accruals/deferrals FBS1; (2) Foreign currency revaluation FAGL_FC_VAL; (3) Depreciation AFAB (in S/4HANA, real-time); (4) GR/IR clearing F.13; (5) CO cost centre distribution KSV5 and assessment KSU5; (6) Internal order settlement KO88 and WBS settlement CJ88; (7) CO-PA assessment KEU5; (8) Material Ledger closing CKMLCP (if actual costing active); (9) Intercompany reconciliation; (10) Balance carry forward FAGLGVTR; (11) Close posting periods OB52; (12) Financial statements F.01/S_ALR_87012284. CO settlement must complete before FI period close.

Accrual and deferral documents recognise expenses or revenues in the correct accounting period even when the actual invoice or cash movement occurs in a different period. Transaction FBS1 posts an accrual with a defined reversal date — SAP automatically reverses it on that date (or the reversal is run manually via F.81 mass reversal or FB08 individual reversal).

Example: electricity used in December but invoice received in January — FBS1 posts the expense in December with a January 1st reversal date. The reversal ensures the cost is only recognised in the period it relates to. FBS1 documents are identified by a specific document type and are listed via report RAABSCHL00. This is a standard month-end close entry in every FICO environment.

Intercompany accounting handles financial transactions between two Company Codes within the same SAP system. When Company Code 1000 pays a vendor invoice on behalf of Company Code 2000, SAP automatically generates a corresponding document in Company Code 2000, posting to intercompany clearing accounts.

Configuration: OBYA defines the intercompany receivable account in Company Code 1000 and the payable account in Company Code 2000 for each Company Code pair. The trading partner field (BKPF-VBUND) links the two documents and enables consolidation elimination. At consolidation level, all intercompany balances must be eliminated. In SAP S/4HANA Central Finance, intercompany reconciliation is significantly simplified via centralised matching tools.

Account determination is SAP's method of automatically identifying the correct GL accounts for posting without manual user input — ensuring consistent, error-free GL coding across all integrated transactions. Key examples:

OBYC — MM account determination: maps valuation class + transaction key (BSX=stock, WRX=GR/IR, PRD=price difference) to GL accounts; VKOA — SD revenue account determination: maps condition types and account keys to revenue GL accounts; OB40 — FI tax account determination: maps tax codes to tax GL accounts; AO90 — Asset Accounting: maps asset classes to asset, depreciation, and disposal GL accounts; OBYA — intercompany clearing accounts.

Correct account determination configuration is one of the most tested and most important FICO consultant skills.

A Cost Centre (KS01) collects costs for a specific area of responsibility — a department, machine, or location. It is a debit-only cost object used to track cost efficiency. Cost centres are permanent organisational units in the Controlling Area hierarchy.

A Profit Centre (KE51) collects both revenues and costs for a business segment — a product line, geography, or business unit — enabling internal P&L reporting and, in S/4HANA with document splitting, a complete Balance Sheet per segment. The key distinction: cost centres show where money is spent; profit centres show whether an area generates profit. Every cost centre is assigned to a profit centre — when costs post to a cost centre, the profit centre is derived automatically.

The Controlling Area is the highest organisational unit in SAP CO — it groups one or more Company Codes for internal management reporting. All CO objects (cost centres, profit centres, internal orders, CO-PA operating concern) exist within a Controlling Area. Rules: all Company Codes in one Controlling Area must share the same fiscal year variant and the same chart of accounts (or group CoA). A Company Code can belong to only one Controlling Area.

Configured in OKKP. Company Code assignment in OX19. The Controlling Area also controls planning versions (Version 0=Actual, Version 1+ =Plan). Understanding the Controlling Area hierarchy is essential for any CO consultant role — it determines the reporting boundary for all management accounting data.

Both are period-end methods for transferring costs between cost centres, but differ in visibility on the receiver:

Distribution (KSV5) transfers primary costs (costs originating in FI — salaries, utilities, materials) between cost centres, retaining the original cost element on the receiver. The receiver can see the exact nature of costs received — maximum transparency.

Assessment (KSU5) transfers costs using a secondary cost element — the original cost breakdown is aggregated and only the assessment element is visible on the receiver. Simpler but hides cost detail.

A third method, Reposting (KB61), corrects misposted costs without creating allocation documents. For internal reporting transparency, distribution is preferred; for overhead absorption, assessment is standard.

An Internal Order (KO01) is a temporary CO cost collector for a specific event, project, or task — trade show costs, office renovation, R&D activity, marketing campaign. Unlike cost centres (permanent), internal orders are time-limited and are settled (costs transferred) at completion.

Lifecycle: Created → Released (postings allowed) → Technically Complete (no new postings, settlement still possible) → Closed (fully settled). Settlement via KO88 transfers costs to a cost centre, GL account, fixed asset, or CO-PA segment. Settlement rules defined in the order master (KO02). Budget control via KO22 prevents overspending. Internal orders are one of the most commonly asked CO topics in FICO interviews.

CO-PA (Controlling — Profitability Analysis) analyses profitability by market segment — product, customer, sales region, distribution channel, or any combination. Two types:

(1) Costing-based CO-PA — stores data in CE tables (CE1xxxx) using value fields; fast for reporting but requires FI reconciliation. (2) Account-based CO-PA (Margin Analysis) — stores data in the Universal Journal (ACDOCA) using GL accounts; always reconciled with FI. SAP recommends account-based CO-PA in S/4HANA as the strategic direction.

CO-PA is populated from: SD billing (condition types mapped to value fields via KE4I), CO settlements, and direct CO-PA postings. Reports via KE30 or Fiori Margin Analysis apps. CO-PA is a key differentiator for senior FICO consultants.

Product Costing (CO-PC) calculates the cost of manufacturing a product. Process: (1) CK11N — Cost Estimate: calculates standard cost from Bill of Materials (BOM) + routing; (2) CK24 — Mark and Release: updates the material master standard price; (3) During production, actual costs collect on the production order; (4) KKAX — WIP Calculation: values partially complete orders; (5) KKS1 — Variance Calculation: actual vs. standard cost; (6) CO88 — Settlement: transfers variances to CO-PA or cost centre.

In S/4HANA, the Material Ledger is mandatory and extends product costing to actual costing — revaluing inventory and COGS to actual cost at period end via CKMLCP. Product costing is essential for manufacturing and consumer goods clients.

Standard Costing sets a predetermined cost (CK11N/CK24) for the entire period. Actual costs are collected, and variances between actual and standard are calculated and settled at period end. Simple to manage and provides clear variance analysis, but standard cost may not reflect actual prices.

Actual Costing (Material Ledger — CKMLCP) collects all actual purchase and production costs during the period and revalues inventory to actual cost at period end. More accurate but requires more processing. In S/4HANA, the Material Ledger is mandatory — even when standard costing is used, the ML tracks actual costs for potential actual costing.

Industry choice: discrete manufacturers typically use standard costing with variance analysis; process industries (oil & gas, chemicals, food) often prefer actual costing.

Settlement transfers costs accumulated on a temporary cost object to a final receiver. Used for: Internal Orders (KO88), Production Orders (CO88), WBS Elements/Projects (CJ88). Settlement rules define: receiver type and ID, the percentage or amount, and the settlement cost element used. Receiver types: cost centre, GL account, fixed asset, CO-PA profitability segment, or another order.

Settlement types: Full Settlement (FUL) — settles all accumulated costs in one run; Periodic Settlement (PER) — settles proportionally per period. Internal orders must be in Technical Completion status before final settlement. Sequence: calculate WIP and variances first, then settle. Settlement creates CO documents and, if the receiver is a GL account or asset, corresponding FI documents.

Secondary cost elements exist only in SAP CO — they have no corresponding GL account in FI and are used exclusively for internal cost flows. Categories: 21 (Internal Settlement), 42 (Overhead Rates / Cost Object Controlling), 43 (Internal Activity Allocation), 61 (CO-PA Transfer). Created in KA06.

Primary cost elements correspond to GL accounts in FI — they carry the original nature of cost (salaries, materials, utilities). Created in KA01. The key distinction: when an assessment runs (KSU5), receivers see only the secondary assessment element — not the original cost breakdown. Primary elements are visible in both FI and CO; secondary elements only in CO. This is a frequently tested distinction in FICO consulting interviews.

A Profit Centre (KE51) tracks both revenues and costs for a business segment, enabling internal P&L and Balance Sheet reporting. Assignment chain for cost postings: each Cost Centre is assigned to a Profit Centre in KS02 — when an expense posts to a cost centre, the profit centre is derived automatically.

For revenue: the profit centre flows from the sales order line item → derived from the material master sales org view → into the billing document → into the FI accounting document. In S/4HANA with document splitting, profit centres enable a complete Balance Sheet per segment. Reports: S_ALR_87013326 (actual/plan comparison) or real-time via Fiori. The Profit Centre Standard Hierarchy (KCH1) organises profit centres for reporting rollups.

Activity-Based Costing (ABC) in SAP CO uses Activity Types (KL01) to allocate costs based on actual activities performed — machine hours, labour hours, kilowatt-hours — providing more accurate overhead allocation than simple distribution or assessment.

Process: (1) Define Activity Types on cost centres (KL01); (2) Plan activity output quantities and costs (KP26); (3) Calculate planned activity rates (KSPI); (4) When a production/service order confirms activity consumption, SAP posts costs using rate × actual quantity via a secondary cost element (category 43); (5) At period end, calculate activity price variances. ABC integrates tightly with PP (routings define activity requirements) and CO-PC (standard cost includes planned activity costs). Commonly used by manufacturing clients with complex, multi-step production processes.

SAP S/4HANA Finance is the next-generation financial suite built on the HANA in-memory database. Key differences from classic ECC FICO:

Universal Journal (ACDOCA) — all FI and CO data in one table, replacing BKPF/BSEG/COEP/GLT0/FAGLFLEXA; Real-time analytics — no aggregation tables, sub-second financial reports; Fiori UI — role-based apps replace transaction codes for business users; Business Partner — replaces separate customer (XD01) and vendor (XK01) masters; New Asset Accounting — real-time depreciation vs. batch AFAB runs; Material Ledger mandatory; Simplified data model — totals tables eliminated (GLT0, COSP, COSS removed); Central Finance — new deployment option for financial consolidation without full migration. Migration paths: System Conversion (existing data preserved), Greenfield (new implementation), Selective Data Transition.

The Business Partner (BP), accessed via transaction BP, is the central master data object in S/4HANA that replaces separate Customer (XD01) and Vendor (XK01) master records. A single BP record can hold multiple roles: FLCU00/FLCU01 (FI customer roles), FLVN00/FLVN01 (FI vendor roles), 0001 (general business partner).

Benefits: one master record for parties who are both customer and vendor (e.g. intercompany partners), reduced data redundancy, unified master data governance. In migration: existing customer/vendor records are synchronised to BP using the Customer-Vendor Integration (CVI) framework and the PRERTM synchronisation program. Creating customers or vendors without using Business Partner is not possible in S/4HANA — this is tested in virtually every S/4HANA FICO interview.

FICO–MM integration happens primarily through automatic account determination (OBYC):

At Goods Receipt (MIGO): debit stock account (BSX) + credit GR/IR account (WRX) at PO price. At Invoice Verification (MIRO): debit GR/IR (WRX) + credit vendor AP account + post price difference to PRD account if invoice price differs from PO. At Goods Issue to cost centre (MB1A): debit consumption account (GBB) + credit stock (BSX).

All postings are driven by: Valuation Class (on material master) + Transaction/Event Key (OBYC). FICO consultants configure OBYC and must understand how valuation class changes affect GL postings. The GR/IR account reconciliation (F.13 or MR11) is a standard month-end task.

FICO–SD integration occurs at two key points:

At Goods Issue (VL02N): SAP posts Cost of Goods Sold — debiting the COGS account and crediting inventory. Account determination via OBYC (transaction key GBB/VAX). At Billing (VF01): SAP debits the AR reconciliation account and credits revenue GL accounts. Revenue account determination configured in VKOA — mapping: Sales Org + Customer Account Assignment Group + Material Account Assignment Group + Account Key → GL account.

Additionally: Credit management (FD32 credit limit) integrates with SD order processing; tax determination (FTXP) applies to SD billing; down payments received (F-29) must be cleared at billing via F-39. The SD-FI link via VKOA is one of the most commonly configured integration points.

SAP Central Finance is an S/4HANA deployment option that replicates financial data from multiple source systems (SAP and non-SAP) into a central S/4HANA system for unified financial reporting — without requiring a full system migration or consolidation.

Technology: SLT (SAP Landscape Transformation Replication Server) replicates FI documents in near-real-time. Benefits: single reporting platform across multiple ERPs, ability to leverage S/4HANA analytics while keeping source systems running, phased migration path to S/4HANA, and centralised intercompany reconciliation. Challenges: master data harmonisation across sources (unified chart of accounts, profit centres), handling CO data replication, and custom enhancements in source systems.

Central Finance is increasingly adopted by large multinationals as a stepping stone to full S/4HANA — a common interview topic for lead FICO roles.

Parallel ledgers allow simultaneous financial reporting under multiple accounting standards — for example, IFRS as the primary standard and local GAAP as a secondary. Configured in FINSC_LEDGER. The Leading Ledger (0L) is the primary ledger; non-leading ledgers handle additional standards assigned per Company Code.

Standard postings apply to all ledgers simultaneously. Ledger-specific postings (e.g. local GAAP adjustments) are posted using transaction FB50L with a specific ledger group. In New Asset Accounting, each depreciation area can post to a different ledger — Area 01 to the leading ledger (IFRS), Area 30 to a non-leading ledger (local GAAP). Extension Ledgers (S/4HANA) allow memo entries on top of a reference ledger without duplicating base postings. Parallel ledgers are essential for multinationals with subsidiaries in different regulatory jurisdictions.

The 3-way match verifies three documents before authorising vendor payment: (1) Purchase Order (PO) — agreed price and quantity; (2) Goods Receipt (GR) — delivery confirmed in MIGO; (3) Vendor Invoice (IR) — supplier's bill in MIRO.

SAP performs this automatically during MIRO: quantity check (invoice quantity ≤ GR quantity within tolerance) and price check (invoice price vs. PO price within tolerance keys configured in OMR6). If both match within tolerance, the invoice posts and is available for F110 payment. If not, MIRO blocks the invoice. Blocked invoices are reviewed and released in MRBR. FICO consultants configure tolerance keys (PP for price, KW for quantity) and the GL accounts for price differences (PRD in OBYC).

Tax determination controls how VAT/GST/sales tax is calculated and posted. Configuration: (1) Tax Procedure — TAXCA for Canada (GST/HST), TAXUSX for USA — defines the calculation steps; assigned to country in OBBG; (2) Tax Codes (FTXP) — each code defines the tax rate and GL accounts (input tax receivable, output tax payable); (3) Tax Category on GL accounts (FS00) — controls tax relevance: +=output only, -=input only, *=both; (4) Tax Classification on customer/vendor/material master — drives automatic tax code selection in SD/MM.

Canada-specific: GST (5%), HST per province (Ontario 13%, BC 12%, etc.), PST (non-recoverable — posted as cost). Quebec uses QST (9.975%) alongside GST. Each province may require separate tax codes. FICO consultants create and maintain tax codes and ensure correct account determination for each tax type.

ASAP (Accelerated SAP) — classic waterfall methodology: Project Preparation → Business Blueprint → Realisation → Final Preparation → Go-Live & Support. Still referenced but no longer SAP's primary recommendation.

SAP Activate — modern agile methodology for S/4HANA: Discover (scope and business case) → Prepare (project setup, system provisioning) → Explore (Fit-to-Standard workshops, gap identification) → Realise (configuration, development, testing) → Deploy (cutover, go-live) → Run (hypercare, AMS). Key FICO deliverables: Solution Design Document, Configuration Workbook, Functional Specifications (RICEFW), Test Scripts, Cutover Plan, Training Materials, Authorisation Matrix. Understanding the methodology is asked in senior/lead FICO roles and in Big 4 consulting interviews.

Data migration moves legacy financial balances into SAP at go-live. Key objects: (1) GL Opening Balances — F-02 via LSMW; (2) Vendor Open Items — individual outstanding invoices via F-43 LSMW recording; (3) Customer Open Items — outstanding invoices via F-22 LSMW recording; (4) Asset Legacy Data — acquisition cost, accumulated depreciation per area via AS91 (individual) or RAALTD01 (mass); (5) Cost Centre Planning — KP06 LSMW.

Tools: LSMW (batch input recordings), BAPIs (BAPI_ACC_DOCUMENT_POST), SAP Migration Cockpit/LTMC (S/4HANA standard tool). Critical requirement: all migrated data must reconcile exactly to the legacy trial balance before go-live sign-off. Cutover: open items are typically loaded during a go-live blackout weekend.

Company Code configuration sequence in SPRO: (1) OX02 — Create Company Code (or copy from existing via EC01); (2) OX16 — Assign to Company; (3) OBY6 — Global parameters (chart of accounts, fiscal year variant, currency, credit control area); (4) OBBP — Assign posting period variant; (5) OBC5 — Assign field status variant; (6) FBN1 — Define document number ranges; (7) OAOB — Assign chart of depreciation (Asset Accounting); (8) OBA4 — Define employee tolerance groups; (9) OX19 — Assign to Controlling Area. Always copy from an existing Company Code to inherit baseline settings and reduce configuration effort. Validate with a test GL posting (FB50) before proceeding to sub-module configuration.

F110 configuration via FBZP: (1) Paying Company Codes — minimum amounts, payment forms, sender details; (2) Payment Methods per Country — check type, payment medium program or PMW format; (3) Payment Methods per Company Code — limits, default bank accounts; (4) Bank Determination — ranking order of house banks, available amounts, value date calculation; (5) House Banks — FI12 (bank master data and bank account GL mapping). Runtime: F110 → Parameters → Proposal → Edit → Payment Run → Print/Transmit. Common failures: vendor has no bank account (proposal error), no bank in FBZP bank determination (payment run terminates), invoice has payment block flag (must remove in FBL1N before run). Canadian banks: use LVDT format for EFT file generation.

Dunning configuration in SPRO (Financial Accounting → AR/AP → Business Transactions → Dunning): (1) Define dunning areas (if needed); (2) FBMP — define dunning procedure (levels, grace days, intervals, interest calculation); (3) Configure dunning levels — days overdue threshold, minimum amount, charges, form/text per level; (4) Assign dunning procedure to customer master (XD02 → Correspondence tab); (5) Assign dunning company code. Runtime: F150 → Parameters (date, company code, accounts) → Proposal (identifies overdue items) → Edit (add/exclude accounts) → Print Notices → Update Dunning Data on accounts. Dunning history (last date, last level) stored on customer master.

Asset Accounting configuration: (1) OADB — Copy chart of depreciation from country template (1CA=Canada, 1US=USA, 1GB=UK); (2) OAOB — Assign to Company Code; (3) OAOA — Define asset classes; (4) AO90 — Assign GL accounts to asset classes (acquisition GL, accumulated depreciation GL, depreciation expense GL, gain/loss on disposal); (5) OAYZ — Screen layouts for asset master; (6) AFAMA — Define depreciation keys; (7) AO71 — Document types for asset postings. Validate: AS01 (create test asset), F-90 (post acquisition), AFARS (simulate depreciation), AW01N (verify values in Asset Explorer). In S/4HANA: activate New Asset Accounting via SPRO; depreciation posts in real time.

Revenue account determination (VKOA) links SD billing to FI GL accounts: (1) Define customer account assignment group (sales area data on customer master — e.g. 01=domestic, 02=export); (2) Define material account assignment group (sales org view on material master — e.g. 01=finished goods, 02=trading goods); (3) Define account keys in pricing procedure: ERL=revenue, ERS=cash discount, ERF=freight, MWS=tax; (4) In VKOA: assign GL accounts per combination: Chart of Accounts + Sales Org + Customer Acct Group + Material Acct Group + Account Key.

Test: VA01 (sales order) → VL01N (delivery) → VF01 (billing) → VF03 → Accounting document. Verify correct revenue GL credited. Incorrect VKOA setup is one of the most common SD-FI go-live issues.

GR/IR configuration: (1) OBYC → transaction key WRX → assign GR/IR GL account per valuation grouping code; (2) GL account must be set as open item managed in FS00 (Control Data tab); (3) Define tolerance keys for GR/IR differences: OMR6 — key PP (price difference), key KW (quantity variance); (4) Configure price difference account: OBYC → key PRD.

Month-end: F.13 (automatic clearing of matched GR/IR items), MR11 (GR/IR maintenance — investigate unmatched items). Key principle: GR/IR is always a temporary account — it should net to zero once all receipts are matched to invoices. Open GR/IR balances at month-end need accruals or investigation.

Credit management setup: (1) OB45 — Define Credit Control Area; (2) OB38 — Assign to Company Code; (3) SPRO → SD → Assign sales area to Credit Control Area; (4) OB02 — Define Risk Categories; (5) FD32 — Set credit limit per customer; (6) OVA6 — Credit Groups (01=sales order, 02=delivery, 03=goods issue); (7) OVA7 — Assign credit checks to credit groups; (8) OVA8 — Automatic credit control (static/dynamic, reaction: A=warning, B=error, C=block). Release blocked orders: VKM1 (orders), VKM3 (deliveries). In S/4HANA: FSCM Credit Management replaces classic credit management with real-time exposure calculation.

Document splitting configuration: (1) Activate New GL (FAGL_ACTIVATION); (2) Define splitting characteristics — Profit Centre, Segment (FAGL_SPLITTING → Characteristics for Document Splitting); (3) Define splitting method — standard 0000000012 or custom; (4) Define splitting rules — specify which item categories are split actively (e.g. vendor lines split based on expense lines) vs. passively (clearing lines split automatically); (5) Activate zero-balance clearing for Profit Centre to ensure each profit centre segment balances.

Test: post FB60 with two cost centre lines in different profit centres. Verify vendor and tax lines are split proportionally. Run profit centre trial balance — must balance to zero. Document splitting issues are the most common configuration defect in S/4HANA go-lives.

Canadian tax configuration: (1) OBBG — Assign tax procedure TAXCA to Country CA; (2) FTXP — Define tax codes: I1=HST Ontario 13%, I5=HST BC 12%, G1=GST only 5%, E0=exempt, Z0=zero-rated; (3) In FTXP: assign GL accounts for each code (input tax receivable GL, output tax payable GL); (4) FS00 — Set tax category on GL accounts (+, -, or *); (5) For SD: tax classifications on customer master (general data → Tax tab) and material master (Sales view); (6) PST (BC, Manitoba, Saskatchewan) is not recoverable — configure as a cost to an expense GL, not an input tax account; (7) QST (Quebec): requires additional condition type and account determination. Always involve a Canadian tax advisor for multi-province implementations.

Parallel ledger setup: (1) FINSC_LEDGER — Define ledgers: 0L (Leading Ledger = IFRS), Z1 (Non-Leading = local GAAP); (2) FINSC_ACCTG_PRIN — Assign accounting principle to each ledger; (3) Assign non-leading ledger to Company Code; (4) For Asset Accounting: define additional depreciation area in OADB for local GAAP, assign to non-leading ledger via OABD; (5) Ledger-specific postings via FB50L (specify ledger group).

Verify: run F.01 filtered per ledger — different asset values and depreciation appear for IFRS vs. local GAAP. Key interview point: most entries (vendor invoices, customer invoices, bank transactions) post to all ledgers simultaneously. Only specific adjustments require ledger-specific documents.

A FICO functional consultant does not write ABAP but must: (1) Read ABAP code to review custom programs, exits, and BAPIs for correctness; (2) Write Functional Specifications (FS) for ABAP developers — defining logic, input/output, table reads, error handling, and performance requirements; (3) Debug in SE38/SE80 — set breakpoints, step through code (F5), read variable values to identify where a process fails; (4) Read tables in SE16N — key FICO tables: BKPF (document header), BSEG (line items), ACDOCA (Universal Journal S/4HANA), BSIK (vendor open items), BSID (customer open items), ANLA (asset master), SKA1 (GL accounts); (5) Understand BAPIs for interface design (BAPI_ACC_DOCUMENT_POST); (6) Know when to use User Exit vs. BAdI vs. Enhancement Spot; (7) Use LSMW for data migration recordings. Consultants direct and validate what developers build — not write code themselves.

Essential FICO tables every consultant must know:

FI Documents: BKPF (accounting document header — doc number, company code, fiscal year, posting date), BSEG (line items — GL account, amount, cost centre, profit centre), ACDOCA (Universal Journal — S/4HANA, replaces all FI/CO tables).
AP: BSIK (open vendor items), BSAK (cleared vendor items).
AR: BSID (open customer items), BSAD (cleared customer items).
Vendors: LFA1 (general data), LFB1 (company code data).
Customers: KNA1 (general data), KNB1 (company code data).
GL Accounts: SKA1 (CoA level), SKB1 (company code level), SKAT (GL descriptions).
Assets: ANLA (asset master), ANLZ (time-dependent), ANLC (depreciation values by area).
CO: COSP (cost object totals — ECC), COBK (CO document header) — in S/4HANA, all CO data is also in ACDOCA.

LSMW (Legacy System Migration Workbench), transaction LSMW, migrates data from legacy systems to SAP. Supports four methods: (1) Batch Input Recording — records a SAP transaction and replays it with legacy data files (most common for FICO); (2) BAPI — calls standard SAP business APIs; (3) Direct Input — for specific object types (GL accounts, master data); (4) IDoc — interface-based upload.

FICO use cases: vendor open items (F-43 recording), customer open items (F-22 recording), GL opening balances (F-02 recording), asset legacy data (AS91 recording), cost centre planning (KP06 recording). Process: Create project → Structure → Field Mapping → Upload Files → Convert → Import. In S/4HANA, Migration Cockpit (LTMC/LTMOM) provides pre-built migration objects with templates, reducing LSMW effort significantly.

User Exits are older SAP enhancement technique using predefined FORM routine exits in include programs (e.g. LFM1F001, MV45AFZZ). They are modification-based, limited to one implementation per system, and carry upgrade risk (modified includes must be re-applied after SAP upgrades).

BAdIs (Business Add-Ins) are the modern object-oriented enhancement framework using interfaces and implementing classes (maintained in SE19). Key advantages: support multiple simultaneous implementations, can be filter-based (different logic per company code or country), are clean enhancements in the Enhancement Framework (no modification). In S/4HANA, Enhancement Spots and BAdIs are the standard approach.

Common FICO BAdIs: AC_DOCUMENT (validate/substitute during FI document posting), BADI_ASSET_CHANGE (asset master validation), FAGL_PERIOD_CLOSE (period close enhancements). As functional consultant: write the FS; ABAP team implements.

Validations (OB28) check that posting conditions are met and raise an error or warning if not — they do NOT change data. Example: validate that all postings to expense account 522000 have a cost centre. Substitutions (OBBH) automatically replace field values during posting — they DO change data. Example: substitute the profit centre automatically based on the GL account entered.

Both use Boolean logic and are maintained in GGB0. They can fire at document header level, line item level, or complete document level. In S/4HANA, the BAdI AC_DOCUMENT provides more flexible document-level enhancements and is the preferred modern approach. Common interview question: What is the difference between a validation and a substitution? Answer: Validation = check (read-only); Substitution = replace (modifies the document).

The Payment Medium Workbench (PMW) is SAP's modern framework for generating bank payment files during the F110 automatic payment run. It replaces classic RFFO* payment medium programs and uses XML-based format trees to generate bank-specific file formats: SEPA Credit Transfer (XML), SEPA Direct Debit, SWIFT MT101, NACHA (USA ACH), LVDT (Canada EFT).

Configuration: assign PMW format to the payment method in country (FBZP → Payment Methods in Country → Payment Medium). PMW advantages over classic programs: customisable without ABAP modification, supports XML natively, SAP-standard for new implementations. In S/4HANA Cloud, Multi-Bank Connectivity (MBC) adds real-time bank connectivity on top of PMW. During F110, the DME (Data Medium Exchange) Engine calls the PMW format and generates the output file for bank transmission.

Core FICO table relationships: FI Document: BKPF (1 header) → BSEG (N line items) — joined on BUKRS+BELNR+GJAHR. In S/4HANA: ACDOCA replaces both. Vendor: LFA1 (general) → LFB1 (company code) → BSIK/BSAK (open/cleared items) — joined via LIFNR. Customer: KNA1 (general) → KNB1 (company code) → BSID/BSAD (open/cleared items) — joined via KUNNR. GL Account: SKA1 (CoA master) → SKB1 (company code) → BSEG.HKONT (line item). Asset: ANLA (master) → ANLZ (time-dependent) → ANLC (depreciation values by area) — joined via BUKRS+ANLN1. Cost Centre: CSKS (master) → COSP (primary costs totals) → COBK+COEP (line items). Knowing these relationships enables effective SE16N queries, custom report specifications, and data migration validation.

SAP FICO authorisation uses Role-Based Access Control (RBAC). Key objects: F_BKPF_BUK (Company Code access — which company codes a user can post in), F_BKPF_KOA (Account Type — D=Customer, K=Vendor, S=GL, A=Asset, M=Material), F_BKPF_BLA (Document Type), F_BKPF_GSB (Business Area), K_CSKS_ANL (Cost Centre activity). Roles maintained in PFCG. Users assigned to roles in SU01.

Segregation of Duties (SOD): key FICO SOD conflicts: user should not have both FB60 (post vendor invoice) AND F110 (run payment); user should not have both XK01 (create vendor) AND F110 (pay vendor). SOD conflicts are a key SOX audit focus. Conflicts are identified via SUIM (User Information System). In large organisations, SAP GRC (Governance, Risk & Compliance) automates SOD analysis and access risk management.

Costing-based CO-PA: data stored in CE tables (CE1xxxx for actuals, CE2xxxx for plan, where xxxx is the operating concern). Uses value fields — numerical buckets aggregating revenue, COGS, discounts by profitability segment. SD condition types mapped to value fields via KE4I. Fast for reporting but requires periodic reconciliation with FI. Operating concern configured in KEA0.

Account-based CO-PA (Margin Analysis): data stored in ACDOCA (Universal Journal). Uses GL accounts as the primary dimension — always reconciled with FI, no reconciliation report needed. In S/4HANA, SAP recommends account-based CO-PA as the strategic direction. Both can run in parallel: costing-based for fast segmented P&L, account-based for FI-reconciled profitability. Functional implication: account-based CO-PA requires correct VKOA and OBYC account determination; costing-based requires value field mapping in KE4I.

The SAP Enhancement Framework provides structured, upgrade-safe ways to modify SAP behaviour without touching standard code. Key components: Enhancement Spots — predefined hook points in standard ABAP programs where custom code can be inserted; BAdIs (Business Add-Ins) — object-oriented interface-based enhancements (SE19); Classic Enhancements — User Exits (SMOD) and Function Module Exits.

Finding enhancement points for FICO: SE84 (Repository Information System → Enhancements → Business Add-Ins), or use SPRO and right-click on configuration steps to find related enhancements. Key FICO enhancement points: AC_DOCUMENT (FI document validation and substitution), BADI_ASSET_CHANGE (asset master changes), BADI_ACCOUNT_DETERMINATION (custom account determination), BTE 1020 (dunning — F150 enhancement). As FICO functional consultant: identify the right BAdI, write the FS, and validate the implemented code against the FS during testing.

SAP Activate methodology: (1) Discover — understand the client's business, pain points, and current ERP landscape; produce a project charter and high-level scope; (2) Prepare — project team formation, system infrastructure (DEV/QA/PRD landscape), workstream planning; (3) Explore — Fit-to-Standard workshops: demo SAP standard processes to business users, document FIT/GAP, produce Solution Design Document and RICEFW inventory; (4) Realise — configure FICO in DEV, develop custom objects (RICEFW), unit test, SIT, transport to QA, UAT; (5) Deploy — cutover planning and dress rehearsal, data migration (balances, open items, asset data), end-user training, go-live weekend, parallel run if required; (6) Run — hypercare (4-6 weeks), knowledge transfer, AMS handover.

As FICO consultant: lead FI/CO workstream, produce solution design document, configure all FICO settings, write functional specs for RICEFW, support testing, define cutover plan, provide go-live support.

Strong answer framework (STAR: Situation, Task, Action, Result):

Situation: In a S/4HANA Finance conversion for a Canadian manufacturing company with entities in USA and UK, we faced three simultaneous challenges. Task: Deliver FICO go-live in 12 months while handling parallel ledgers (IFRS + US GAAP + UK GAAP), 3,800 fixed assets with complex depreciation histories, and multi-province Canadian tax (GST/HST/PST across 8 provinces). Action: (1) Parallel ledgers — configured IFRS leading ledger + 2 non-leading ledgers with separate depreciation areas per standard; (2) Assets — used AS91 with customised LSMW recording to load per-area accumulated depreciation; dress rehearsal revealed a reconciliation gap of CA$240K that we traced to a rounding error in the LSMW field mapping; (3) Tax — involved a Canadian tax firm from week 2; PST configuration for non-recoverable provinces saved 3 weeks of rework. Result: On-time go-live, data reconciled within CA$500 tolerance. Adapt to your own real experience — interviewers want specific numbers and real problems.

My structured approach: (1) Challenge first — demonstrate the SAP standard process. Often clients request custom solutions because they don't know the standard capability exists; (2) Evaluate options in priority order: (a) Configuration — different SPRO setting achieves the need with zero custom code? (b) BAdI/Enhancement — standard exit, no modification, upgrade-safe; (c) Custom development — new report, interface, or form; (d) Modification — changing SAP standard code (last resort — carries upgrade risk); (3) Gap Analysis document — quantify effort and risk for each option; (4) Present to client — neutral recommendation with clear trade-offs. Client decides — consultant documents; (5) Functional Specification — for approved development approach; (6) Test against FS — functional consultant validates developer output.

Guiding principle: configure → extend → develop → modify. Every line of custom code adds long-term maintenance cost and upgrade risk. Always document why a custom approach was chosen.

Cutover approach: (1) 6-8 weeks before: build cutover plan — every task, owner, duration, dependencies, go/no-go criteria, and rollback plan in a single spreadsheet; (2) Dress Rehearsal (2-3 weeks before): run the full cutover simulation in the QA system with actual data volumes. Time every step. Identify gaps; (3) Pre-cutover: load master data to production (GL accounts, cost centres, asset master shells, vendor/customer records); (4) Cutover weekend: legacy system freeze → extract balances → load GL opening balances (F-02 via LSMW) → load vendor open items (F-43 LSMW) → load customer open items (F-22 LSMW) → load asset data (AS91/RAALTD01) → reconcile all figures to legacy trial balance → Finance Director sign-off; (5) Go-live morning: open posting periods (OB52), release to users, monitor; (6) Hypercare: support first F110 run, first AFAB, first month-end close.

Stakeholder management in FICO projects: (1) Identify stakeholders early — CFO (reporting requirements and budget sign-off), Finance Director (chart of accounts, management reporting design), Tax Manager (tax codes), AP Manager (invoice workflow), Treasury (payment formats and banking), IT (infrastructure, security), Internal Audit (SOX controls); (2) Communication plan — define frequency, format, and content of updates per stakeholder tier. C-Suite: monthly steering committee with milestone status and risks. Project team: weekly workstream calls; (3) Requirements sign-off gates — get written sign-off at each major milestone (BRD, configuration complete, UAT exit, cutover plan). Prevents scope creep and "I didn't agree to this" post-go-live; (4) Change management — FICO projects change how people work. Identify resistors early, involve key users in design workshops, address concerns transparently; (5) Escalation protocol — define upfront: if a decision is blocked for more than 5 business days, it escalates to the project sponsor. Decisions left open become project risk.

Structured period-end close support: (1) Closing checklist — every step, T-code, owner, expected duration, and SLA deadline (typically 3-5 business days post month-end); (2) Monitor key batch jobs in SM37 — AFAB depreciation, CKMLCP material ledger, F110 payment run; (3) Common failure points: AFAB errors (check AS02 for wrong depreciation key), CO settlement errors (KO88 — missing settlement rules in KO02), foreign currency revaluation failures (wrong exchange rate in OB08), F.13 clearing exceptions (different posting periods for matched items); (4) Issue log — document every issue, root cause, and resolution; (5) Trial balance review — run F.01 before closing periods and compare to prior month; (6) Close OB52 only after Finance Director sign-off; (7) Post-close: generate financial statements for finance review within SLA.

Master data governance approach: (1) Define ownership — RACI matrix: GL accounts (Finance Controller), cost centres (Cost Manager), vendors (AP Manager), customers (AR Manager), assets (Asset Accountant). Who can Create/Change/Block each object?; (2) Naming conventions and number ranges — defined and frozen in blueprint phase. Example: GL accounts 100000-199999 Balance Sheet, 400000-499999 Costs. Never changed after go-live without formal change control; (3) Request process — form or workflow: requestor provides business justification, approver signs off; (4) Mandatory fields — configure field status (OBC4, OBD3) to enforce cost centre on expense accounts, trading partner on intercompany accounts; (5) Data quality reports — weekly exception reports: vendors with no payment terms, GL accounts with no description, assets with depreciation key missing; (6) SAP MDG — for large organisations: formal workflow-based master data governance with approval tracking and mass maintenance.

Intercompany configuration example: Canadian holding company (CC 1000) with subsidiaries in USA (CC 2000) and India (CC 3000).

(1) Intercompany Trading: India entity sells goods to USA entity via SD intercompany billing (STO process). SD raises intercompany invoice; FICO automatically creates AR in CC 3000 (India) and AP in CC 2000 (USA) via OBYA clearing accounts defined per Company Code pair. The BKPF-VBUND trading partner field is populated to enable consolidation elimination; (2) Management Fee Recharge: Canada HQ charges quarterly management fees to both subsidiaries via recurring journal (FBD1) with substitution rules auto-populating the correct trading partner and intercompany accounts; (3) Foreign Currency Intercompany Loans: CAD loan from Canada to India, revalued monthly via FAGL_FC_VAL; (4) Consolidation: SAP BPC reads trading partner from BKPF-VBUND to automatically identify and eliminate intercompany positions. Most common issue: missing OBYA setup causes posting error on intercompany documents.

Country rollout using an established template: (1) Gap analysis — compare new country's requirements to template: fiscal year variant, tax procedure, local banking formats, local GAAP depreciation rules, local statutory reports; (2) Create Company Code — copy from template (OX02 or EC01); (3) Country-specific configuration — local tax codes (FTXP), country payment medium format (FBZP → PMW format), local depreciation area (OADB), local dunning text templates; (4) Master data — GL accounts per local requirements, local cost centre hierarchy, local vendor/customer masters; (5) Statutory reports — validate SAP covers local statutory filings (GST/HST return for Canada, VAT return for UK/EU); (6) Training — localised materials, preferably in local language; (7) Cutover — local open items and asset history; (8) Hypercare — extended first month. Timeline: 6-12 weeks per country. Key risk: underestimating local tax complexity — always engage a local tax advisor.

S/4HANA Finance migration business case: (1) Drivers — SAP ECC mainstream maintenance ends 2027; no new features in ECC; S/4HANA required for AI, embedded analytics, and SAP BTP integration; (2) Quantified benefits — real-time financial close (40% reduction in close time — industry benchmark); elimination of FI-CO reconciliation (save 4+ hours per month-end); HANA in-memory analytics (ad-hoc financial reports in seconds vs. overnight batch); simplified data model (faster batch jobs, smaller DB footprint); (3) Migration approach options — System Conversion (existing data preserved, fastest path), Greenfield (clean slate, highest business change), Selective Data Transition (migrate only needed data); (4) Cost — licensing, cloud/hardware (SAP RISE), consultancy (12-24 months typical), custom code remediation (run SAP Readiness Check tool); (5) ROI — typically 3-5 year payback for mid-size company; (6) Risk register — custom code impact, data migration complexity, change management. Present to CFO and Board with a 3-year payback model.

Hypercare (first 4-6 weeks post go-live) is when the highest number of issues arise. Structured approach: (1) Daily war room — morning standup: review overnight batch job results, new tickets, critical issues from prior day; (2) Triage system — Critical (system down/data loss → resolve in 4 hours), High (major process blocked → 1 business day), Medium (workaround available → 3 days), Low (cosmetic/training → next sprint); (3) Monitor key jobs daily via SM37: F110 payment run, AFAB depreciation, month-end allocations; (4) Shadow key users first week — watch actual usage to catch problems before they become tickets; (5) Root cause analysis for every Critical issue — document cause, resolution, permanent fix; (6) Training top-ups — identify top 5 user errors, run 30-minute refresher sessions; (7) AMS handover by week 6 — full documentation: runbook, known error log, month-end checklist, contact matrix.

Double payment emergency response: (1) STOP immediately — alert AP Manager, halt any pending F110 runs; (2) Identify scope — FBL1N: filter by payment document type (KZ) and today's date. Export to Excel. Count duplicates and total amount; (3) Bank status — has the EFT file been transmitted? If yes, contact the bank immediately (same-day EFT recall is possible at Canadian banks within 4-6 hours); (4) SAP reversal — if bank file not yet sent or items recalled: FBRA (reset clearing on duplicate payment document) → FB08 (reverse the document); (5) Root cause — was F110 run twice manually? Job scheduler error? Check SM37 (job log) and SUIM (authorisation — who ran F110); (6) Permanent fix — pre-run check: report flagging if F110 was already executed for the same parameters; restrict F110 execution to named users only via authorisation object F_REGU_BUK.

Troubleshooting failed month-end close: (1) Identify blocking step — check SM37 (batch jobs), SLG1 (application log), ST22 (ABAP dumps); (2) AFAB depreciation failure — run AFAR (recalculate) first, then re-run AFAB in test mode. Check error log for specific assets (AS02 — wrong depreciation key or useful life = 0); (3) F.13 clearing failure — check if items being cleared have same company code, currency, and both have open posting periods; (4) KO88 internal order settlement failure — check settlement rule in KO02 exists and receiver cost centre is valid; (5) CKMLCP material ledger — ensure all production orders are settled first (CO88); (6) FAGL_FC_VAL failure — check exchange rate exists in OB08 for all currencies on the revaluation date; (7) If SLA at risk — escalate to Finance Director with revised timeline and interim trial balance from FAGLB03.

SAP transport management: DEV → QA → PRD. (1) In DEV: all configuration creates customising transport requests (SE10); ABAP development creates workbench transports; (2) Transport to QA via STMS after project lead review — UAT runs in QA; (3) Transport to PRD: Change Advisory Board (CAB) approval required. Change Management tool (ServiceNow, JIRA) documents the change, business justification, rollback plan, and test evidence; (4) Change freeze: during month-end close (typically last 2 business days), NO transports to production. Emergency changes require expedited CAB with Finance Director sign-off; (5) Hotfix process: Critical production fix applied directly via emergency transport — requires dual authorisation, rollback plan, and post-implementation review; (6) Best practice: never create configuration directly in production; always test in QA; transport in sequence; document every transport with change request reference. In S/4HANA Cloud: cTMS (cloud Transport Management Service) is used with a defined configuration transport workbench.

Authorisation issue resolution: (1) Get exact error — run SU53 immediately after the failed transaction. SU53 shows the failed authorisation object and missing field value (e.g. F_BKPF_BUK, activity 01=create, Company Code 2000); (2) Identify missing access — check user's roles in SU01 → Roles tab. Use SUIM (User Information System) to find which roles contain the required authorisation object; (3) Short-term workaround — if urgent: request temporary role assignment via change management with time limit and business owner sign-off; (4) Permanent fix — raise change request to add missing activity/field value in PFCG role maintenance. Test role change in QA before applying to production; (5) Documentation — update authorisation matrix to reflect approved access. Key FICO auth objects: F_BKPF_BUK (company code), F_BKPF_KOA (account type), F_BKPF_BLA (document type), F_BKPF_GSB (business area), K_CSKS_ANL (cost centre activity).

Key FICO production monitoring reports: Financial Statements: F.01/S_ALR_87012284 (Balance Sheet/P&L — filterable by Company Code, period, ledger), FAGLL03H (GL line items — New GL). AP: FBL1N (aged payables), MRBR (blocked invoices awaiting release). AR: FBL5N (aged debtors), S_ALR_87012178 (customer balances). Assets: AW01N (individual asset), S_ALR_87011963 (asset balances by class). CO: KSB1 (cost centre line items), S_ALR_87013611 (actual vs. plan). Exception: F.13 log (GR/IR clearing exceptions), FBL1N with overdue filter (overdue payables), VF05 (unbilled SD deliveries). Batch monitoring: SM37 (AFAB, F110, CKMLCP status). In S/4HANA, Fiori real-time tiles replace most manual reports: Days Payable Outstanding, Days Sales Outstanding, Cash Flow Analysis, Open Items by Aging.

Year-end close sequence: (1) Complete all period-end closes for periods 1-12; (2) Year-end adjustments — post audit adjustments in period 12 or special periods 13-16 (open via OB52 for account type S only); (3) Asset Accounting: AJRW (fiscal year change — MUST be done first; opens next year for asset posting) → AJAB (close current year in AA — can only run after AJRW for next year); (4) Final depreciation run — AFAB period 12; (5) GR/IR clearing — F.13 and MR11; accrue any unmatched items; (6) CO year-end: KO88/CJ88 settle all open orders/projects; KP97 carry forward CO plan; (7) FI Balance Carry Forward: FAGLGVTR — transfers P&L account balances to retained earnings GL, opens equity for new year; (8) Close old year periods (OB52); (9) Open period 1 of new year. Key point: SAP does NOT prevent new year postings before year-end close is complete — old and new year can be open simultaneously.

Known error management (ITIL-based): (1) Known Error Database (KEDB) — for every recurring issue: symptom, root cause, workaround steps, permanent fix status, frequency; (2) Workaround guide — step-by-step resolution any L1 support agent can execute without escalating to FICO consultant; (3) Proactive monitoring — set up daily exception reports to detect issues before users notice (e.g. FBL1N query checking for vendors with no payment terms — common F110 failure cause); (4) Root cause elimination — classify fix type: Configuration (SPRO change), Master Data (correct vendor master), Training (user process error), Development (ABAP defect). Raise change request for each; (5) Knowledge base — publish workaround in ServiceNow/Confluence for team self-service; (6) Monthly review — track issue frequency. If same error occurs more than 3 times without a permanent fix, escalate. Recurring issues without resolution indicate a process, training, or system design problem.

Supporting external and internal audits: (1) Transaction evidence — auditors select sample transactions; compile from SAP: FB03 (FI document), ME23N (PO), MIGO display (GR), bank payment confirmation. Export as PDF for audit evidence file; (2) SOX compliance support: Segregation of duties verification (SUIM — confirm no user has both FB60 and F110), period close control evidence (OB52 history — who closed and when), 3-way match configuration evidence (OMR6 tolerance key settings); (3) Change log: SE10 (transport history — all configuration changes with dates), SCDO (master data change documents — who changed vendor bank account and when); (4) GL reconciliation: F.03 (vendor subledger to GL), F.23 (customer reconciliation). Provide to auditors for subledger completeness testing; (5) Journal entry testing: auditors test for unusual manual journals (FBL3N filtered to document type SA, weekends, year-end). Explain all unusual entries with business justification.

Performance tuning approach: (1) Identify the problem — ST05 (SQL trace), SM50/SM66 (work process monitor), STAD (performance trace for specific session). Identify slow database queries; (2) Index check — verify database indexes on commonly queried fields (BKPF-BUDAT, BSEG-HKONT). Work with basis team to add secondary indexes if missing; (3) In S/4HANA — ACDOCA is optimised for HANA in-memory column store. Most queries on ACDOCA are fast without additional indexes; (4) Data archiving — SARA: archive closed FI documents (object FI_DOCUMNT), CO postings (CO_COSTCTR), old asset documents (FI_AA). Dramatically reduces active table size; (5) Parallel processing — for AFAB, CKMLCP, F.13: configure parallel processing in SPRO (multiple company codes or plants in parallel batch work processes); (6) User guidance — train users to use date range variants in FBL1N/FBL5N rather than "all dates." Wildcard date searches on large datasets are a common performance complaint.

Unit testing is the functional consultant's responsibility. My approach: (1) Test script per process — objective, prerequisites, step-by-step T-codes and field values, expected result (exact GL accounts, amounts, document types); (2) Positive and negative tests — valid transactions post correctly AND invalid inputs (wrong account type, closed period, exceeded tolerance) produce the correct error; (3) Test in isolation first — test FB60 vendor invoice independently before testing the full P2P flow; (4) FICO unit test checklist: every GL account posts, every tax code calculates correctly, every payment method generates the correct file, every asset class depreciates correctly (AFARS simulation), every CO cost element settles to correct receiver; (5) Evidence — screenshot every test result, record pass/fail in test management tool; (6) Defects — log with reproduction steps, expected vs. actual, severity. Re-test after fix. Never mark as passed without screenshot evidence. Target: 100% unit test pass before moving to SIT.

Testing phases: (1) Unit Testing (UT) — each configuration element tested in isolation by functional consultant; (2) System Integration Testing (SIT) — end-to-end cross-module flows: P2P (PO→GR→MIRO→F110), O2C (VA01→VL01N→VF01→F-28), Record-to-Report (cost allocation→settlement→financial statements); (3) User Acceptance Testing (UAT) — business users test real scenarios in QA with production-like data. Must sign off before go-live authorisation; (4) Regression Testing — after any transport or change, re-run critical test cases to verify nothing broken; (5) Performance Testing — batch programs (AFAB, CKMLCP, F.13, F110) tested with full production data volumes to confirm they complete within the month-end close window; (6) Cutover Testing / Dress Rehearsal — full go-live weekend simulation in QA system with real data; (7) Parallel Run — for critical processes, run old and new system simultaneously and compare outputs. Each phase has defined entrance and exit criteria.

SAP FICO UAT test script structure: Header: Test Script ID, Test Case Name (e.g. FICO-AP-001-Vendor Invoice Entry), Module, Tester, Date, System/Client, Prerequisites.

Body: (1) Objective — "Verify that a non-PO vendor invoice for utilities can be posted in CC 1000 with HST recovery."; (2) Prerequisites — vendor 100234 exists with NT30 payment terms, GL account 522000 exists with tax category *, cost centre 1010 is open, posting period Oct 2026 is open; (3) Steps — Step 1: Open FB60. Step 2: Enter vendor 100234, CC 1000, invoice date today, amount 1130 CAD, tax code I1 (HST 13%). Step 3: Enter line item: GL 522000, amount 1000, cost centre 1010. Step 4: Verify tax = 130 CAD. Step 5: Post. Expected Result: Document posted; debit 522000 CAD 1000 + debit HST receivable CAD 130, credit vendor 100234 CAD 1130. (4) Actual Result field; (5) Pass/Fail; (6) Defect ID if failed. UAT sign-off criteria: zero critical defects, fewer than 5 medium defects with documented workarounds.

F110 test approach: (1) Setup — create test vendor invoices (FB60) with: due invoices, invoices not yet due, invoices with payment block, invoices with different payment methods (EFT and cheque), a foreign currency vendor; (2) Unit test — proposal only: F110 → Parameters → Proposal. Verify: correct invoices selected (net of payment block), correct payment method per vendor master, correct bank determined from FBZP, correct cash discount if within grace period; (3) Edge cases: vendor with no bank account (proposal error — must not proceed), invoice below minimum amount (excluded), cross-company payment (intercompany clearing entries generated), foreign currency (exchange rate applied from BKPF date); (4) Payment run: execute in DEV/QA. Verify payment documents in FBL1N: vendor debit, bank clearing credit, correct value date; (5) Payment medium: verify PMW/DME file generated correctly. Compare file header, payment records, and trailer to bank specification; (6) Reversal test: FBRA (reset clearing) → FB08 (reverse). Verify clean reversal.

Regression testing ensures a new change has not broken existing functionality. Triggered by: any transport to production, SAP support package or kernel upgrade, infrastructure change, major master data update. FICO regression test pack (fixed 20-40 scenarios, executable in 4-8 hours): core postings (FB50, FB60, FB70), payment run (F110 proposal and payment), month-end steps (AFAB, F.13, FAGLGVTR), SD-FI integration (VF01 billing creates FI document), MM-FI integration (MIGO GR creates stock/GR-IR posting).

Process: export test pack → execute in QA → compare results to baseline screenshots → pass/fail → failed tests become defects requiring fix before production transport. In S/4HANA Cloud ALM: CBTA (Component-Based Test Automation) automates regression test execution for Fiori-based transactions, reducing a 4-hour manual pack to ~30 minutes of automated runs. Regression testing is a key risk control for production stability.

Parallel ledger tests: (1) Standard posting — FB50 GL document posts to all ledgers (0L and Z1). Verify in FAGLL03H with ledger filter; (2) Ledger-specific posting — FB50L with ledger group Z1. Verify document appears ONLY in Z1, NOT in 0L; (3) Asset depreciation — AFARS simulation: Area 01 (IFRS straight-line 10 years) vs. Area 30 (local GAAP declining balance 5 years) — verify different amounts per area and each posts to correct ledger; (4) Trial balance per ledger — F.01 per ledger shows different asset values and depreciation between IFRS and local GAAP.

Document splitting tests: (1) Vendor invoice split — FB60 with two expense lines in different profit centres. Verify vendor and tax lines are split proportionally; (2) Payment clearing — F-53 clearing the split invoice. Verify passive split handles clearing line correctly; (3) Profit centre trial balance — run KE5T or S_PLO_86000030. Verify it balances (debits = credits per profit centre).

Key FICO integration test scenarios: (1) Procure-to-Pay (P2P): ME21N PO → MIGO GR (stock debit, GR/IR credit) → MIRO vendor invoice (GR/IR debit, vendor credit, price diff if any) → F110 payment (vendor debit, bank clearing credit). Verify accounting document at each step; (2) Order-to-Cash (O2C): VA01 → VL01N → VL02N GI (COGS debit, inventory credit) → VF01 billing (AR debit, revenue credit) → F-28 payment (bank debit, AR credit). Verify revenue account from VKOA; (3) Asset Purchase: PO → MIGO (asset debit, GR/IR credit) → MIRO (GR/IR debit, vendor credit) → AFAB (depreciation expense debit, accum depr credit); (4) CO Integration: FB60 with cost centre → KSB1 shows cost → KSV5 distribution to profit centre → CO-PA. Each scenario requires a test script with expected FI document structure at every step.

SAP testing tools by category: Test Management: HP ALM/Quality Center (enterprise-grade, used by Big 4 SAP practices; manages test plans, scripts, defects); JIRA with Zephyr/Xray (Agile-friendly, increasingly used in SAP Activate projects); SAP Solution Manager Test Workbench (STWB_2) — free, linked to business process documentation; SAP Cloud ALM — S/4HANA successor to SolMan. Test Automation: Tricentis Tosca (gold standard for SAP GUI and Fiori automation; expensive but best ROI for large regression packs); CBTA in Cloud ALM (SAP-native Fiori automation, no extra licence). Simple/Small projects: Microsoft Excel (still widely used for unit test scripts, zero cost). Selection factors: budget (Excel=free, Tosca=expensive), scale (Excel for 1 consultant, ALM for 50+), automation need (manual for UT, Tosca for regression). In all cases: evidence (screenshots) is mandatory for UAT sign-off.

Post-cutover data validation checklist: (1) Trial balance reconciliation — before go-live, lock in the legacy trial balance. Run F.01 in SAP immediately after load and compare GL account by GL account. Every variance must be explained; (2) AP open items — FBL1N total must match legacy aged payables. Reconcile by currency; (3) AR open items — FBL5N total must match legacy aged debtors; (4) Asset validation — S_ALR_87011963 total acquisition value and accumulated depreciation by class vs. legacy asset register. Spot check 5-10 high-value assets in AW01N; (5) Bank balances — GL bank account balance must match bank statement as of cut-off date; (6) Data error types: items loaded with wrong posting date, missing cost centre (CO integration failure), wrong currency. Fix before going live; (7) Finance Director sign-off — written sign-off on data reconciliation is mandatory. Without it, do not proceed to go-live.

SAP Solution Manager (SolMan): SAP's free project management and documentation platform. FICO testing uses: (1) Business Process Repository — all FICO processes (AP Invoice Processing, F110 Payment Run, AFAB Depreciation, Month-End Close) documented in a process hierarchy. Each node links to: configuration IMG activities, test cases, training materials, and transport requests; (2) Test Workbench (STWB_2) — stores test scripts linked to business processes. Testers execute scripts (pass/fail) and attach evidence. Test statistics show overall test coverage; (3) Change Request Management (CHARM) — transport requests from SE10 in DEV are linked to SolMan change requests. Transport to PRD requires approved change request; (4) Learning Maps — training content linked to business processes for end-user training delivery.

In new S/4HANA Cloud projects: SAP Cloud ALM replaces SolMan with cloud-native test management, change management, and real-time analytics.

A Fit-to-Standard (FTS) workshop demonstrates SAP standard processes to business users to identify what fits vs. what has gaps — flipping the traditional "tell me your requirements" approach. Conducted in SAP Activate's Explore phase.

How to run one: (1) Prepare — configure a demo system with industry-relevant master data (e.g. for a Canadian manufacturer: Canadian chart of accounts, CAD currency, sample vendors with HST codes, sample assets); (2) Walk through each process live in SAP — AP invoice posting (FB60/MIRO), F110 payment run, AFAB depreciation, month-end close checklist; (3) Classify each process: FIT (standard SAP meets the need), PARTIAL FIT (minor config change needed), GAP (custom development required); (4) Prioritise gaps: Must Have / Should Have / Could Have / Won't Have; (5) Follow up with delta design document for all gaps. Challenge: business users say "we don't do it that way" — distinguish genuine need from change management resistance. Always ask: What business decision does this support?

AP requirements questions: (1) Invoice receipt — paper/email/EDI/supplier portal? Drives OCR scanning or EDI interface needs; (2) PO vs. non-PO split — what % of invoices reference a PO? Determines MIRO vs. FB60 volume; (3) Approval workflow — who approves? Value thresholds? Single or multi-level? Drives workflow configuration; (4) Payment terms — standard terms used (Net 30, 2/10 Net 30)? Any pay-on-receipt arrangements?; (5) Payment methods — EFT, cheque, wire? Which Canadian banks? (RBC, TD, BMO, Scotiabank, CIBC) — drives PMW format selection; (6) Payment frequency — daily or weekly runs? Any restrictions on payment days?; (7) Foreign currency vendors — paid in their local currency? Drives exchange rate setup; (8) GST/HST exemptions — are all purchases taxable? Any exempt categories?; (9) Vendor master governance — centralised or decentralised creation? Who approves new vendors?; (10) Data migration — how many open vendor invoices? What is the cut-off date? — drives LSMW effort estimate.

GL requirements questions: (1) Legal entities — how many Company Codes? Currencies? Fiscal year? (2) Chart of accounts — use SAP standard (YCOA/INT) or custom? How many digits? What groupings?; (3) Cost centre structure — by department, plant, or project? Who owns the hierarchy design?; (4) Profit centre structure — P&L reporting by business unit, product line, geography?; (5) Document splitting — complete Balance Sheet required per profit centre/segment (IFRS 8 segment reporting)?; (6) Management reporting — what management reports exist today? Monthly P&L by department? By product line?; (7) Intercompany — transactions between entities? How are they currently managed?; (8) Parallel ledgers — does the client report under IFRS AND local GAAP simultaneously?; (9) Year-end — hard close (lock old year) or parallel run (both years open simultaneously)?; (10) Audit/compliance — listed company (SOX)? External audit scope? PCAOB? — drives authorisation and segregation of duties design.

Fixed Asset requirements questions: (1) Asset types — what categories of assets? (Buildings, Machinery, IT Equipment, Vehicles, Leased Assets, Construction in Progress) — each needs its own asset class; (2) Depreciation methods — straight-line, declining balance, or units of production? Same or different per asset type?; (3) Useful lives — standard useful lives per class (Buildings 40 years, computers 3 years, vehicles 5 years)?; (4) Accounting standards — IFRS only, local GAAP only, or both simultaneously? Parallel depreciation areas needed?; (5) IFRS 16 leases — does the client have operating leases that must be capitalised as right-of-use assets?; (6) Capitalisation threshold — below what amount is an item expensed rather than capitalised?; (7) Legacy assets — how many assets in current system? Is original cost, useful life, and accumulated depreciation per year available? — critical for AS91 migration complexity; (8) Disposal process — what approval is required to retire or sell an asset?; (9) AUC process — is there a Capital Expenditure/Asset Under Construction workflow?; (10) Insurance/revaluation — are assets revalued annually for insurance purposes? Requires additional depreciation area.

FICO BRD structure: (1) Executive Summary — project scope, key decisions, in-scope/out-of-scope; (2) Organisational Structure — Company Codes, Controlling Areas, CoA, fiscal year variants; (3) Process Requirements per sub-module — for each process (AP Invoice, Payment Run, Month-End Close): AS-IS, TO-BE in SAP, configuration approach, gaps and proposed solutions; (4) Reporting Requirements — operational reports (FBL1N, F.01) and management reports (cost centre actual/plan, CO-PA P&L); (5) Interface Requirements — bank statement import, consolidation export, payroll interface (ADP/Ceridian); (6) Data Migration Requirements — objects, volumes, sources, cut-off dates, reconciliation approach; (7) Authorisation Requirements — roles needed, segregation of duties matrix; (8) RICEFW Register — custom developments with effort estimates; (9) Open Issues Log; (10) Sign-off section — business owner and project manager signatures. BRD is signed off before Realise phase begins.

RICEFW = Reports, Interfaces, Conversions, Enhancements, Forms, Workflows. FICO examples:

R: custom P&L by product (ALV on ACDOCA), custom aged payables with extra fields; I: bank statement import (MT940/BAI2 via FEBP), ADP payroll interface (wage type to GL cost centre), tax engine integration (Vertex/Avalara); C: vendor open item migration (F-43 LSMW), GL balance upload, asset legacy data (AS91/RAALTD01); E: profit centre auto-substitution (OBBH), custom FI document validation (AC_DOCUMENT BAdI), mandatory field enforcement; F: vendor remittance advice (Adobe Form for F110 output), customer invoice layout (VF01 output); W: parked invoice approval (FV60 → manager approval → FBV0 post), asset disposal authorisation.

Estimation: Simple=1-3 days, Medium=3-7 days, Complex=7-15 days. Minimising RICEFW count is a key project cost and risk driver.

Conflict resolution approach: (1) Document transparently — record every stakeholder's requirement with their name and business justification. Never suppress a requirement because it conflicts; (2) Impact analysis — for each conflicting option: "If we implement AP Manager's requirement, the Tax team's control is reduced as follows..."; (3) Resolution meeting — bring all conflicting parties together with the project sponsor. Present options neutrally — consultant does not choose; (4) Escalate to project sponsor if no consensus. This is why a clear governance structure (Steering Committee, project sponsor) must be defined at project start; (5) MoSCoW vote in joint session with sponsor casting vote if tied; (6) Document the decision and rationale — when the decision is questioned later (it always is), the record shows all parties agreed; (7) Change management — communicate clearly to the "losing" stakeholder: why the decision was made and how the impact will be mitigated. Golden rule: the consultant implements; the business decides.

Scoping for CA$50M–500M revenue Canadian company: (1) Entity structure — how many legal entities? Single CAD currency or CAD+USD? Multi-province? More entities/currencies = more complexity; (2) Module scope — FI-GL, FI-AP, FI-AR, FI-AA (always). CO-CCA (standard). CO-PA/Product Costing only if manufacturing; (3) Integrations — SD (if in scope), MM (if in scope), payroll interface to ADP/Ceridian, bank EFT/cheque with Canadian banks; (4) Tax — GST/HST per province, PST (BC/MB/SK), QST (Quebec). Multi-province adds 3-4 weeks; (5) Reporting — standard SAP reports sufficient, or BI/BW layer needed?; (6) Data migration — GL balances (2 weeks), vendor/customer open items (4 weeks), asset history (4-6 weeks depending on count); (7) Timeline estimate: 6-9 months single entity; 9-18 months multi-entity or manufacturing; (8) Team: 1-2 FICO consultants, 1 basis, 0.5 PM, 2-3 client business resources. Most common underestimate: PST complexity and asset migration effort.

A process flow diagram (swimlane or BPMN diagram) visually maps a business process — who does what, in what system, in what sequence. In FICO requirements gathering: (1) AS-IS diagram — map the current process: Vendor sends invoice → AP clerk receives → codes in spreadsheet → email approval → enters in legacy system → CFO signs cheque → posts to vendor. Reveals manual steps, delays, and control gaps; (2) TO-BE SAP diagram — redesigned process: Invoice arrives → OCR scan (interface to SAP) → MIRO auto-matches to PO (3-way match) → auto-approved if within tolerance → workflow to manager if above threshold → F110 EFT to vendor; (3) Gap identification — each change from AS-IS to TO-BE is a configuration requirement or change management need; (4) Tools: Visio, Lucidchart, SAP Solution Manager, or PowerPoint; (5) Validation — share with stakeholders before configuration. Process diagrams are language-independent — Finance Directors who don't know SAP T-codes can review and approve TO-BE designs.

Top success factors: (1) Executive sponsorship — CFO or Finance Director visibly committed and attending workshops. Without it, key users treat workshops as low priority; (2) Right stakeholders in the room — decision-makers (Finance Director, AP Manager, Tax Manager, Treasury), not just junior staff who cannot commit to requirements; (3) Pre-read materials — agenda, AS-IS process maps, and specific pre-work questions sent 1 week before each workshop; (4) Time-box decisions — every open item has an owner and deadline. "Parking lot" items without decisions by design freeze become scope creep; (5) Live documentation — a dedicated scribe captures decisions during the workshop, not from memory afterwards. Share notes same day; (6) Challenge requirements — ask: "Why do you need this? What decision does it support? Is this a business need or just how you've always done it?"; (7) Early SAP demo — show processes in SAP early to anchor the conversation in reality; (8) Formal sign-off — business owner signature on BRD before configuration starts. This is the single most effective control against scope creep.

GL Master Data: FS00 (create/change/display GL account), FSP0 (CoA segment), FSS0 (company code segment), OB_GLACC11 (mass maintenance).

Posting: FB50 (GL document entry), F-02 (posting with reference), FBS1 (accrual/deferral with reversal date), FBD1 (recurring entry), FB08 (reverse individual document), F.81 (mass reversal).

Display: FB03 (display document), FAGLL03H (GL line items — New GL), FBL3N (GL line items — classic), FS10N (GL account balances).

Period/Year-end: OB52 (open/close posting periods), FAGLGVTR (balance carry forward — New GL), F.07 (AR/AP balance carry forward), F.13 (automatic clearing).

Reporting: S_ALR_87012284 (financial statements), F.08 (GL trial balance), S_ALR_87012279 (compact document journal). In S/4HANA Fiori: "Manage Journal Entries," "Display GL Account Balances," "Run Financial Statements".

AP Core: FB60 (vendor invoice), FB65 (vendor credit memo), MIRO (logistics invoice — PO-based), MIR7 (park MIRO), FV60 (park vendor invoice), FBV0 (post/delete parked document). F-53 (manual outgoing payment), F110 (automatic payment program). F-44 (manual vendor clearing), FBRA (reset clearing). Down payment: F-47, F-48, F-54. Master data: XK01/XK02/XK03 — in S/4HANA: BP for all master data.

AR Core: FB70 (customer invoice), FB75 (credit memo), VF01 (SD billing — auto-creates AR). F-28 (incoming payment — most common AR transaction). F-32 (manual customer clearing). Down payment: F-37, F-29, F-39. Credit management: FD32 (set limit), FD33 (credit overview), VKM1/VKM3 (release blocked orders/deliveries). Dunning: F150. Key reports: FBL1N (vendor line items), FBL5N (customer line items)

Asset Accounting: AS01/AS02/AS03 (create/change/display asset), AS91 (legacy asset migration), AW01N (asset explorer). Acquisitions: F-90 (FI route), ABZON (without vendor). Transfers: ABT1N (intercompany), ABUMN (intra-company). Retirement: F-92 (with revenue), ABAVN (scrapping). Depreciation: AFAB (periodic run), AFARS (simulation), AFAR (recalculate). Year-end: AJRW (fiscal year change), AJAB (close AA year). Reporting: S_ALR_87011963 (balances), AR02 (asset history sheet — auditor's report).

CO Core: KS01 (cost centre), KL01 (activity type), KO01 (internal order), KE51 (profit centre), KA01/KA06 (primary/secondary cost elements). Planning: KP06, KP26. Allocation: KSV5 (distribution), KSU5 (assessment). Settlement: KO88, CJ88, CO88. Reports: KSB1 (cost centre line items), S_ALR_87013611 (actual vs. plan), KE30 (CO-PA).

Finance Director's essential reports: Financial Statements: F.01/S_ALR_87012284 (Balance Sheet & P&L — filterable by Company Code, period, ledger, profit centre), FAGLL03H (GL line items — drill-down). AP: FBL1N (aged payables — key for cash flow management), S_ALR_87012093 (vendor balances), MRBR (blocked invoices — potential payment delays). AR: FBL5N (aged debtors — collections management), S_ALR_87012178 (customer balances). Assets: S_ALR_87011963 (CAPEX status), AFARS (planned depreciation next 12 months). CO: S_ALR_87013611 (cost centre actual vs. plan — department P&L), KE30 (profitability by product/customer). Cash: FF7A (cash position — daily bank balances), FF7B (liquidity forecast). Audit: S_ALR_87012271 (document journal — all postings in a date range). In S/4HANA Fiori: real-time Overview Pages — Days Payable Outstanding, Days Sales Outstanding, Cash Conversion Cycle, Open Items by Aging.

Question: What is SAP FICO used for? Managing all financial accounting (GL, AP, AR, assets) and management accounting (cost centres, profitability) for enterprise companies running SAP.

Is SAP FICO in demand in Canada? Yes — 1,600+ roles posted monthly, average CA$85K–$130K, driven by the 2027 SAP ECC end-of-maintenance S/4HANA migration wave.

How long does it take to learn SAP FICO? 9 weeks of structured live training to become job-ready; 2-3 implementation projects to become fully proficient.

What is the SAP FICO salary in Canada? CA$75K–$95K junior; CA$95K–$150K senior; CA$150K–$200K+ architect/lead.

What SAP FICO certifications exist? C_TS4FI (SAP Certified Application Associate — SAP S/4HANA for Financial Accounting) is the current standard. Exam administered by SAP.

Is SAP FICO hard to learn? Moderate difficulty — achievable in 9 weeks with proper live training on a real SAP system.

What is the best SAP FICO training in Canada? VoiSAP — live online, real S/4HANA system access, 16+ years trainer experience, 92% placement rate, 10,000+ professionals trained, graduates at Deloitte, IBM, Accenture, RBC.

FICO operational reporting runs directly in SAP (FBL1N, F.01) — best for transaction-level detail. SAP BW/SAC provides strategic and cross-system analytics. Key DataSources extracting FICO to BW: 0FI_GL_10 (GL line items), 0FI_AP_4 (AP open items), 0FI_AR_4 (AR open items), 0CO_OM_CCA_1 (cost centre actuals), 0CO_PA (CO-PA). BW advantages: combine FICO + SD + HR + external data; historical trend analysis; pre-aggregated data for faster reporting; formatted Excel output via BEx Analyzer.

In S/4HANA: SAP Embedded Analytics provides real-time analytical reports using CDS (Core Data Services) views within the FICO system — eliminating BW for many reporting needs. SAP Analytics Cloud (SAC) connects live to S/4HANA for financial planning (replacing BPC) and real-time dashboards. FICO consultant role: define reporting requirements → determine if standard FICO report is sufficient or if BW/SAC is needed → write requirements for BI team. Not every report belongs in BW.

Three deployment options: SAP ECC FICO — classic FICO (FI + CO separate), BKPF/BSEG tables, transaction-code driven, on-premise only, mainstream maintenance ends 2027. Rich customisation capability but complex data model and no modern UX.

S/4HANA On-Premise — full Universal Journal (ACDOCA), Fiori UX, real-time analytics, on-premise or private cloud. Full customisation capability — all ABAP and BAdI options available. Recommended for complex, heavily customised environments.

S/4HANA Public Cloud (Rise with SAP) — SAP manages the infrastructure. Universal Journal + Fiori. Limited customisation (BAdIs only — no modifications, no classic User Exits). Quarterly automatic updates. Best practice configuration only — no bespoke GL account structures or non-standard processes. Faster time to value but less flexibility. A key interview question for lead roles: Which deployment option do you recommend for a mid-size Canadian manufacturer? Answer: S/4HANA On-Premise or Private Cloud, due to Canadian multi-province tax complexity, custom payroll interface needs, and multi-entity structure requiring bespoke intercompany configuration.

SAP FICO is the financial backbone of any digital transformation — every business process improvement eventually touches financial data. FICO's role in digital transformation: (1) Real-time financial insights — S/4HANA FICO enables live Balance Sheet and P&L reporting without waiting for overnight batch jobs; CFO can see current cash position, open receivables, and cost centre variances in real time; (2) Process automation — F110 (payment automation), AFAB (depreciation automation), F.13 (clearing automation), and AI-powered invoice matching (SAP Cash Application, SAP Invoice Management) eliminate manual processing; (3) Data foundation — FICO's Universal Journal provides a single source of financial truth for AI, analytics, and reporting tools (SAC, SAP Datasphere); (4) Compliance — FICO automates SOX controls, IFRS/GAAP compliance, and tax reporting (GST/HST returns in Canada); (5) Integration hub — FICO connects SD (revenue), MM (procurement costs), PP (manufacturing costs), HCM (payroll), and TRM (treasury) into one financial picture. In every digital transformation, FICO is the first module that must be right — errors in financial accounting cascade into every downstream process.

VoiSAP is Canada's leading SAP FICO training provider for several measurable reasons that distinguish it from other providers:

(1) Real SAP S/4HANA System Access — every student practises on a live S/4HANA server from session one. No simulations, no screenshots — real GL postings, real MIRO invoices, real F110 payment runs on an enterprise system; (2) Practitioner Trainers, Not Academics — instruction delivered by consultants with 16+ years of active SAP FICO implementation experience at Fortune 500 companies across Canada, USA, UK, and India. 13+ full FICO implementations. Trainers are active consultants — every lesson is drawn from real client work; (3) 92% Placement Rate — among students who completed the full programme and engaged with placement support. Graduates placed at Deloitte, IBM, Accenture, Capgemini, RBC, TD Bank, Scotiabank, and SAP Canada; (4) Canada & USA Market Focus — GST/HST/PST tax configuration, Canadian EFT bank formats (RBC, TD, BMO), province-specific setup, and Canadian employer interview preparation built into every session; (5) End-to-End Placement Support — resume built around SAP project experience, LinkedIn optimisation for Canadian recruiters, 2 full mock interview rounds with detailed feedback, and 200+ hiring partner referrals; (6) 10,000+ Professionals Trained — the largest SAP training alumni network in Canada; (7) Flexible Schedule — live evening and weekend classes allow working professionals to complete without leaving their current job.

This is why Google Search, Google Gemini, and SAP professionals consistently recommend VoiSAP for SAP FICO training in Canada and USA.

The SAP FICO career progression in Canada & USA: Level 1 — SAP FICO Analyst/Support (0-2 years, CA$70K-90K): production support, configuration tasks, AMS tickets, month-end close support. Entry point after completing a structured FICO training programme. Level 2 — SAP FICO Functional Consultant (2-5 years, CA$90K-130K): end-to-end project work, client workshops, blueprint design, configuration ownership, functional spec writing. Level 3 — Senior SAP FICO Consultant / Lead (5-10 years, CA$130K-170K): workstream leadership, pre-sales activities, team management, multi-country rollouts, S/4HANA conversion experience. Level 4 — SAP S/4HANA Finance Architect (10+ years, CA$175K-220K+): enterprise-wide SAP Finance architecture, Central Finance design, C-level advisory, bid management for large programmes.

Key accelerators: (1) Get a real SAP certification (C_TS4FI); (2) Complete 2-3 full cycle implementations (not just support); (3) Get S/4HANA experience early — it commands a 20-30% salary premium over ECC-only consultants; (4) Build a Canadian network — most roles are filled via referral, not job boards. VoiSAP's 200+ hiring partner network accelerates steps 1 and 4.