SAP FICO Interview Questions

FI-AA is a sub-ledger: assets belong to classes that determine GL accounts (APC, accumulated depreciation); postings through asset transactions update both asset values and GL reconciliation accounts. Differences come from manual GL postings to asset reconciliation accounts, acquisitions without asset assignment, or migration gaps. Missing depreciation usually comes from missing capitalization date, wrong depreciation key/useful life, or failed AFAB runs. Compare asset history with GL per account, correct via asset transactions, block direct postings, and recheck with AW01N.

Each country has a tax procedure with condition types and account keys; tax codes (FTXP) carry rates and type (input/output); account keys map to GL tax accounts in OB40. Invoices carry tax codes entered or determined (SD condition records, MM PO defaults); FI posts tax lines to those accounts and tax reports read them. Investigate wrong tax codes on invoices (master data classification, PO defaults), rate changes applied to existing codes, missing or wrong OB40 accounts, and manual tax lines.

Create a profit center per store in the controlling area's standard hierarchy (region nodes) with segment where segment reporting is required. Assign profit centers to store cost centers, material/plant data for store stock, and sales documents so revenue and COGS derive the store; activate document splitting for balance sheet lines if store balance sheets are needed. Profit center is a field in ACDOCA, so reporting is real-time. Monitor the dummy profit center and fix master data gaps.

Foreign currency documents are translated at posting using the maintained rate type (typically M, OB08). When an open item is cleared (e.g. payment) at a different rate, a realized difference posts. At period-end, FAGL_FCV valuates open items and FC balances at the key-date rate, posting unrealized differences to adjustment and gain/loss accounts; open item valuations are reversed next period (or handled by delta logic) so that only the realized difference remains when paid. Volatility often comes from missing/late rates or valuation without reversal.

The residual item created by the payment posting carries forward the same tax code and tax base proportionally reduced only if configured to recalculate tax on the residual; by default the residual item is simply the unpaid difference and does not automatically re-trigger tax recalculation, since the original invoice's tax was already posted and reported in the period it was created. When SD later issues a credit memo to formally resolve the dispute, that credit memo generates its own tax line reducing the previously reported output tax, which must reconcile with the residual item being cleared in FI. This means the AR team must ensure the residual item is cleared against the SD credit memo rather than left open, otherwise the VAT return may show a mismatch between invoiced and adjusted tax amounts for that period.

Parallel accounting in S/4HANA is typically implemented using the ledger approach: you define multiple ledgers—leading ledger for group/IFRS, non-leading ledger(s) for local GAAP or tax—each linked to an accounting principle, and assign them to the relevant company codes. Where valuation genuinely differs, such as different depreciation methods for tax purposes, you configure separate depreciation areas in Asset Accounting posting to the corresponding ledger group, so only the ledger-specific document carries the differential posting. Governance-wise, GL account master data must be carefully controlled so accounts used for principle-specific adjustments, such as a local-GAAP-only provision account, are correctly flagged for the right usage, and changes to key fields like account type or field status require a change-control process since master data is shared across ledgers, not duplicated. Regular reconciliation of ledger balances against source documents helps confirm parallel postings are landing correctly.

First, trace the SD document flow to identify which condition type and account key in the pricing procedure determined the GL account via account determination (VKOA), and verify whether the account posted actually matches the intended revenue account in the operational chart of accounts. Then check its assignment in the Financial Statement Version hierarchy. If the account is correctly a revenue account but placed under the wrong FSV node, the fix is at the FSV mapping level, and simply correcting the node reference resolves the reporting distortion without touching posted data. If instead the wrong GL account was actually posted due to a VKOA condition table error, correct the account determination going forward and consider a manual reclassification journal entry for the amounts already misposted. Any correction found this late must be documented, reviewed for materiality, and approved as part of the close checklist, with tightly controlled access to FSV and account determination changes to prevent recurrence.

The bill of exchange is posted against the customer using a Special GL indicator (e.g., W) that redirects the posting from the standard reconciliation account to a bill-of-exchange receivable GL account while keeping it linked to the original customer open item for reporting. When the bill is discounted with the bank before maturity, a contingent liability posting (often another Special GL transaction) is created to reflect the bank's recourse until the bill's maturity, and the house bank clearing account receives the discounted proceeds net of bank charges/interest. At maturity, when the bill is honored or collected, the special GL item is cleared, the contingent liability is reversed, and the actual bank account is updated through electronic bank statement or manual bank posting, tying the AR subledger back to bank accounting.

I would first identify the validation's call point and boolean structure in the validation/substitution configuration, checking whether the prerequisite condition references cost center attributes without also filtering on controlling area or company code, which is the likely root cause of the rule firing too broadly. I'd reproduce the failure by simulating the posting for both the affected and unaffected controlling areas, tracing which check statement evaluates true incorrectly. The fix typically involves tightening the prerequisite logic to include controlling area or a more specific cost center category check rather than a blanket cost center attribute test, and testing this in a non-production client against representative postings from all impacted controlling areas before transport. For performance, I'd avoid overly complex nested boolean logic at the line-item call point, and consider whether the check truly needs to run at that call point versus header level, since validations execute for every relevant posting and unnecessary complexity adds overhead at scale.

I'd group company codes sharing the same fiscal year variant and closing calendar into common posting period variants rather than creating one variant per company code, to reduce maintenance overhead, while still allowing country-specific variants where statutory year-ends genuinely differ. For Asset Accounting, the depreciation run must complete for a period before that period is locked in FI for asset-relevant account types, so I'd sequence closing tasks: run depreciation first, validate no errors, then close the prior period specifically for asset account types while potentially keeping other account types open longer for adjustments. Where a country needs a different fiscal year variant via a non-leading ledger, I'd ensure the ledger-specific posting period control is genuinely independent so its closing calendar isn't blocked by the leading ledger's period lock. Key architecture decisions: minimize variant proliferation for maintainability, sequence Asset Accounting closing before the FI period lock, and use ledger-specific period control where fiscal years genuinely diverge.

First confirm whether the tax jurisdiction requires cash discount to proportionally reduce the tax base; if so, cash discount base amount configuration (OBB8/tax base for discount) must be set so the system recalculates tax on the discounted amount rather than leaving tax untouched. Where unauthorized deductions create genuine underpayments rather than valid discounts, use residual/partial payment logic instead of discount clearing so original tax remains intact on the open item. Standardize a payment difference tolerance and reason code framework centrally, and route exceptions above tolerance to collections for manual review rather than automatic discount posting.

Before conversion: readiness and simplification checks, finance consistency checks, clean period close and reconciliation of GL with AR/AP, assets and material ledger, custom code analysis. Decide ledgers, currencies and asset accounting upfront. Execute technical conversion and the finance migration steps (cost elements, line items, balances, assets, ML) with reconciliation after each; run at least two mock conversions with finance sign-off. Plan phased company code rollouts consistently and govern master data dimensions afterwards.