SAP FICO Interview Questions: 50 Real Questions Senior Consultants Get Asked

Most SAP FICO interview question lists will not get you the job. They'll get you to the second round, where a senior interviewer will ask you why the GR/IR account isn't clearing and watch you recite the textbook answer — and then ask the follow-up that reveals whether you've actually been in that room at 11pm trying to fix it before the close.

Senior interviewers are not grading your recall. They're testing your judgment under realistic pressure. They want to hear that you know what breaks, what the trap is, what you'd tell a nervous CFO two days before period-end. Textbook definitions are the minimum. What distinguishes a ten-year consultant from a three-year one is the scar tissue — the configuration decisions they've gotten wrong and learned from, the edge cases they've seen in production, the instinct for when something technically correct is operationally risky.

These 50 questions are grouped by domain: FI-GL, FI-AP, FI-AR, FI-AA, CO, and integration. For each one, I've included what the interviewer is actually probing for — because that's the part the standard prep guides skip — and what a strong answer at the senior level sounds like. You don't have to memorize these word for word. The goal is to train your thinking so that when the real version of these questions lands, you respond from understanding, not from a flashcard.

FI-GL: Where S/4HANA Has Moved the Goalposts

The GL questions are where ECC-trained consultants get exposed fastest. If you learned SAP before S/4HANA and haven't updated your mental model, the architecture questions will surface it quickly.

Q1. Walk me through what actually changes in the General Ledger when you move from ECC classic GL to the S/4HANA Universal Journal (ACDOCA).

The interviewer wants table-level architecture, not marketing copy. In ECC, FI (BSEG/BKPF), CO (COEP), Material Ledger, and Asset Accounting lived in separate tables that required reconciliation. S/4HANA collapses them into ACDOCA — a single line-item table — making FI and CO reconciled by design. The reconciliation ledger (COFI) becomes obsolete, and totals tables like GLT0 and FAGLFLEXT become CDS-view compatibility layers. The trap: candidates assume it "just works." Document splitting, parallel ledgers, and migration of historical balances still demand careful design.

Q2. A user posts a document and FI/CO values don't reconcile. In S/4HANA, where do you start?

The textbook says reconciliation gaps can't happen in ACDOCA. A senior knows the real culprits: secondary cost postings (allocations, assessments) that hit CO-only objects, statistical postings, or top-down distributions in CO-PA that never generate an FI line. You trace the document through ACDOCA line items, check the ledger and apportionment, verify the allocation cycle. If it's a genuine break, it's almost always a config gap in the real-time integration variant or a custom posting bypassing the standard interface.

Q3. Explain document splitting and how you'd decide whether to activate it. What breaks mid-year?

Document splitting produces zero-balance financial statements per dimension — profit center and segment — by splitting offsetting lines across splitting characteristics. You activate it when a client needs balance-sheet-level reporting below company code. The hard truth the interviewer wants to hear: it's one-way and you can't cleanly switch it on mid-year. Activation requires open items carrying the splitting characteristics before clearing and FX valuation work. Push it to a year-end boundary and run a parallel validation cycle before cutover.

Q4. IFRS and local GAAP in parallel — ledger approach vs accounts approach?

Default to the ledger approach in S/4HANA: a leading ledger (0L/IFRS) plus non-leading ledgers for local GAAP. It keeps valuations cleanly separated, scales to multiple GAAPs, and aligns with New Asset Accounting. The accounts approach works only for a single secondary GAAP with very few differences and tight reporting constraints — it clutters the chart of accounts and doesn't scale.

Q5. FAGL_FCV produced wrong FX valuation values. How do you troubleshoot?

Check four things in order: exchange rate maintenance for the rate type (TCURR), OB09 account determination for the valuation area, the valuation method and area config (lowest value vs always-valuate), and whether items are open at key date. Always reverse the run cleanly before fixing and re-running — the valuation is delta-based.

Q6–Q7. Parallel ledger posting differences and SPL migration deserve careful prep. For parallel ledgers, the classic divergence is IFRS capitalizing a right-of-use asset while local GAAP expenses it — each ledger books independently via non-leading ledger config. For SPL migration, the question is whether the SPL is delivering reporting now native to ACDOCA — if so, retire it rather than lift-and-shift.

Q8. How does ACDOCA change month-end sub-ledger reconciliation?

Be honest with the CFO framing here: internal reconciliations (FI-CO, FI-AA) are effectively eliminated because postings land in one table. But external reconciliation — bank, intercompany, GR/IR, clearing accounts — still requires the full close discipline. Close gets faster on internal items; it doesn't disappear.

Q9. Validation vs substitution — when would you use a BAdI or BTE instead?

Move to a Business Transaction Event or BAdI when the logic needs data not available in the standard validation call point, cross-document checks, or external lookups. The discipline: exhaust standard validation and substitution first because they're transparent to auditors.

Q10. Cross-company-code postings — setup and reconciliation issues?

You configure clearing accounts per company-code pair (OBYA) so a single cross-code document generates the automatic intercompany payable/receivable lines. The failure modes: one-sided reversals, currency rounding, and FX differences on intercompany open items creating imbalances that surface at consolidation. Enforce a monthly intercompany reconciliation and keep OBYA accounts reconciliation-only — no manual postings.

FI-AP: The Two Problem Areas Every Production Support Consultant Has Lived

F110 and GR/IR are the highest-frequency production support issues in AP. Interviewers know it, and they weight these heavily.

Q11. F110 picked the wrong house bank or payment method. Walk me through the determination logic.

Determination flows in this sequence: payment method must be allowed in vendor master and invoice, valid for country and company code, present in ranking. House bank selection runs through bank determination config (FBZP) — ranking order, available amounts per bank/account, value-date optimization. Common mismatch causes: bank ranking order, exhausted available amounts, payment method supplement on the line item, or a house bank specified directly on the invoice. The F110 proposal log tells you exactly why each item routed where it did.

Q12. How do you prevent duplicate invoice postings?

The standard duplicate check compares company code, vendor, currency, reference, invoice date, and amount. Its limits: it only fires when the reference field is populated and matched exactly — a transposed or absent invoice number slips through. Senior mitigations: enforce reference-field entry as mandatory, deduplicate the vendor master, and add BAdI/fuzzy-match checks. Treat duplicate prevention as a process and master-data problem, not a checkbox.

Q13. Classic vs extended withholding tax — when do you migrate?

Extended WHT supports multiple withholding types per vendor, accumulation, and reporting that classic cannot. Migration is not a simple config switch — it requires a conversion program and careful handling of open items. Open invoices, recurring entries, and down payments with classic WHT need conversion, and country-specific reporting (1099, certificates) must be re-tested. Scope it as a mini-project with a clean cutover.

Q14. A vendor is also a customer. How do you net AP and AR?

Link the accounts by entering the customer number in the vendor master and ticking "Clearing with customer/vendor" in both masters. F110 and dunning then consider the net position. Critical watch-out: confirm the legal right to offset before enabling it — netting without a netting agreement is a control risk.

Q15–Q17. Down payments via special GL indicators, GR/IR clearing mechanics, and installment payment terms are all reliable senior/junior separator questions. The underlying theme: configuration decisions that look simple but have significant clearing, aging, and balance-sheet implications if misconfigured.

FI-AR: Dunning, Credit, and the Cash Application Rate That Matters

Q18. A customer isn't being dunned despite clearly overdue items. Troubleshoot.

Work the determinants in order: dunning procedure assigned in the customer master, dunning block on master or line item, items actually overdue given grace days and payment terms, minimum-days-between-runs blocking, and whether the customer falls under the minimum-amount floor. The dunning run log shows why each account was skipped.

Q19. Classic SD credit vs FSCM Credit Management in S/4 — migration?

Classic credit management (FD32/OVA8) is not the strategic path in S/4HANA. FSCM Credit Management — with its credit segment model, scoring rules, and centralized limits — is the successor. The migration pitfall: treating it as like-for-like. FSCM exposure update and check logic differ from classic, so order-blocking behavior must be re-tested end-to-end. Sales gets blocked or, worse, unblocked incorrectly.

Q20. When is Dispute and Collections Management worth implementing?

This is a business judgment question, not a config question. It adds value when receivables volume and complexity justify structured workflows — high invoice counts, frequent disputes, dedicated collections teams. For a smaller client with clean payment behavior, the configuration overhead outweighs the benefit. Size it against DSO pain, dispute frequency, and whether there's an actual collections function to work the cases.

Q21. Electronic bank statement and auto-clearing — why do items land in postprocessing?

Items go to postprocessing (FEBA/FEBAN) when the interpretation algorithm can't confidently match: missing or wrong reference, partial or lump-sum payments, deductions, or unidentified payers. The KPI to track is auto-match rate. You drive it up by improving the interpretation algorithm, reference capture, and note-to-payee parsing — not by manually clearing postprocessing queues indefinitely.

Q22–Q24. FI-AR to SD billing (the billing document creates the receivable; RAR handles compliant revenue recognition), the customer down payment noted-item flow, and doubtful receivables provisioning (individual value adjustment via special GL indicator E, plus flat-rate portfolio provisioning for IFRS 9 expected-loss requirements) round out the AR domain.

FI-AA: The Module Where ECC Knowledge Actively Works Against You

New Asset Accounting is the single biggest knowledge gap in consultants who trained on ECC. If you can't articulate what changed, it's a red flag in any S/4 implementation.

Q25. New Asset Accounting in S/4 — what fundamentally changed?

New AA makes every depreciation area post in real time to its own ledger/accounting principle — no more delta depreciation areas or periodic APC reconciliation. Asset values live in ACDOCA. The classic "area 01 posts real-time, others periodically" model is gone. Multi-GAAP asset reporting is now real-time and reconciled to FI — but it requires a mandatory migration step and a redesigned depreciation-area-to-ledger mapping.

Q26. AFAB failed for a subset of assets. How do you troubleshoot?

Read the error log first — it isolates failing assets and reason. Typical causes: missing depreciation terms, period/fiscal-year mismatch, closed period in the target ledger, account determination gap (AO90), or assets with errors from a prior incomplete run requiring restart in "repeat" mode. Never re-run blindly over a partially posted run.

Q27–Q30. Parallel valuation across depreciation areas, AuC settlement to final assets (the common failure: wrong capitalization/depreciation start date, items stranded on the AuC), mid-year asset migration (the transfer date and last-closed-period settings must be exactly right, and you always reconcile migrated sub-ledger totals to GL balances before unlocking), and unplanned depreciation/write-ups (post them ledger-specifically and document the accounting justification — the transaction code is the easy part).

CO: The Questions That Reveal Whether You Think Like a Designer

Q31. Account-based vs costing-based CO-PA in S/4 — where do you come down?

Recommend account-based (margin analysis). It reconciles to FI by design because it uses GL accounts in ACDOCA, with real-time profitability reporting and no separate reconciliation ledger. Costing-based CO-PA still exists, but its value-field contribution-margin granularity is increasingly replicable in account-based plus attributes. Choose costing-based only if the client has a hard requirement for value-field reporting that account-based genuinely cannot replicate — and that list shrinks every year.

Q32. Cost center vs internal order vs WBS element?

The decision is granularity and lifecycle. Cost centers capture permanent, responsibility-based overhead for a department. Internal orders capture cost for a specific, time-bound activity — a marketing campaign, a trade fair, a repair — and settle to a cost center, asset, or CO-PA. WBS elements capture cost for structured projects with hierarchy, milestones, scheduling, and budgeting. Use them for capital projects or complex deliverables needing a work breakdown. Getting this wrong means either over-engineering the cost object structure or losing the cost transparency that drives decisions.

Q33–Q34. Assessment vs distribution cycles (distribution preserves original cost element detail; assessment uses a secondary cost element and hides it — use distribution when receivers need the original nature, assessment when a summarized allocation suffices) and standard cost estimate roll-up (BOM explosion plus routing activities valued at activity-type rates; variance categories at actuals — input price, quantity, resource, lot-size, scrap, output price) are essential CO configuration knowledge.

Q35. Material Ledger in S/4 — actual costing and why it matters.

ML is mandatory in S/4, but active ML doesn't mean actual costing is switched on — that's a separate decision with real period-close runtime implications. Actual costing computes a periodic actual cost per material and can revalue inventory and COGS from standard to actual. It matters where standard costs drift materially from reality — volatile raw materials, significant production variances, multi-currency group reporting. Don't recommend it to every client; size it against the actual gap between standard and actual.

Q36–Q40. Settlement receivers (the receiver type determines whether you're building balance sheet or profitability transparency — get it wrong and your AuC or project costs land in the wrong bucket), statistical key figures vs activity types (SKFs are reference quantities for proportioning allocations; activity types drive actual cost flows with rates and should only be used where you can measure and confirm the output), Profit Center Accounting in ACDOCA vs classic EC-PCA (EC-PCA is obsolete in S/4 — native PCA in ACDOCA handles it, and candidates who still reference EC-PCA table structures signal they haven't worked a recent implementation), overhead costing sheets, and variance analysis on production orders complete the CO domain.

Integration: End-to-End Flows and the Config Objects Behind Them

Q41. Order-to-Cash financial postings, end to end.

Sales order: no FI posting. Delivery/goods issue: inventory credit, COGS debit via OBYC (GBB/VAX). Billing: receivable debit, revenue credit, tax via VKOA — revenue recognition timing governed by RAR for IFRS 15. Payment: bank debit, receivable cleared, cash discount and FX difference posted. A senior answer names every config object: VKOA, OBYC, OB40 for tax.

Q42. Procure-to-Pay financial postings, end to end.

PO: no FI posting. Goods receipt: inventory debit, GR/IR credit via OBYC (BSX/WRX). Invoice receipt (MIRO): GR/IR debit, vendor payable credit, price differences to PRD under tolerances. Payment (F110): vendor payable debit, bank credit, SKE for cash discount, FX differences. GR/IR cleared/maintained via MR11. Senior detail: OBYC transaction-key knowledge and tolerance/price-difference handling.

Q43. Wrong GL account on a goods movement — where do you look?

Automatic account determination via OBYC/OMWB. The path: movement type → transaction/event key (BSX, WRX, GBB, PRD) → valuation class on the material master → valuation grouping code. Wrong account is almost always a wrong valuation class on the material, a missing OBYC entry for that key/class/modifier combination, or an account modifier mismatch for GBB. Use the OMWB simulation to see exactly which key and modifier resolved to the bad account.

Q44–Q50. VKOA revenue account determination (account-assignment groups on customer and material masters are the usual culprit — always check the master data before touching the config table), Payment Medium Workbench and DMEE (RFFO programs are deprecated; PMW with DMEE-based formats and BCM for approval and transmission is the current standard — if a candidate is still referencing RFFO without qualification, they haven't run a recent payment implementation), tax procedure and cross-border reverse-charge mechanics, Migration Cockpit vs LSMW (Cockpit is the default for S/4; LSMW for edge cases the Cockpit's object list doesn't cover — know which objects those are), and Fiori embedded analytics (the shift is real-time ACDOCA-based reporting and exception-based working — frame it to clients as an operating-model change, not a UI reskin, or they'll undersize the change management).

What to Actually Do with This List

Read it once for coverage. Then close it and ask yourself: for each domain, what's the question I'd least want to be asked right now? That's where you spend the next hour. The ones that made you hesitate are the ones worth preparing a concrete story for — a real situation, even a sanitized one, where that question came up in a project.

The Q50 question — "tell me about an implementation that went wrong" — is the one that most candidates prepare last and that interviewers weight most heavily. Strong answers share three traits: a specific failure, clear personal ownership rather than blame-the-client, and a concrete lesson that changed how you work. What interviewers screen out is a vague story or a failure that's secretly a humblebrag.

You've spent years building this knowledge in production. The interview is a conversation about work you've already done. Go in prepared to be specific about what broke, what you did, and what you'd do differently — that's the answer that closes the room.