SAP FI interview questions

An SAP FI interview tests whether you can make the finance design decisions a project will put in front of you. Those decisions are how a company is represented as an organisational structure, how ledgers and document splitting serve the reports the business needs, where finance meets purchasing and sales, how a period is closed, and how the old system's balances get into the new one. This guide goes through it as scenarios, because that is how the good interviews are run.

How is an FI interview different from a finance quiz?

Lists of questions and answers circulate for every SAP area, and interviewers know them. That is why the interviews worth passing are not quizzes on what a field is called. They give you a company and ask you to design for it, then change one fact and ask what you would change. The finance area lends itself to this because nearly every decision in it has a consequence that shows up later, in a report or at a close, and the interviewer wants to see whether you can see that far ahead. The functional interview guide describes the general structure; what follows is the finance-specific content that fills it.

Which organisational structure decisions get tested?

"A group has legal entities in several countries, two of them sharing one management team. How many company codes, how many charts of accounts, how many controlling areas, and why?" This is the opening scenario in many FI interviews because it exposes whether you know what each object is for. A company code is a legal entity that produces its own statutory accounts; a chart of accounts is a list of accounts that can be shared, with a country-specific one alongside for local reporting and a group one above for consolidation; a controlling area binds company codes together for management reporting, with conditions on what they must share. The follow-ups test the edges: what happens to fiscal year variants when one country closes on a different date, what a change of currency at group level implies, and what is expensive to change after go-live — which is the real question, since organisational structure is the one design you cannot easily undo.

How do document splitting and parallel ledgers come up?

As reasoning, not definitions. "The CFO wants a balance sheet by business segment. What do you need to switch on, and what does it cost the business?" Document splitting is the mechanism that gives every line of a posting a segment or profit centre so that balance-sheet accounts can be reported by that dimension; the cost is that every posting must be able to derive that dimension, which means master data discipline and rules for the lines that have no natural owner. "The group reports under one accounting standard and each entity under its local one. How do you keep both sets of books?" Parallel ledgers are the answer most projects give now — the same postings, valued differently where the standards differ — and the interviewer wants to hear you weigh that against the older approach of parallel accounts, and say when a ledger-specific posting is needed. Answers that mention the closing implications, and the controlling side of the same decision, are the ones that sound like a consultant who has lived with the consequences.

Which integration questions test MM and SD?

Finance is where the other areas' postings land, so FI consultants are expected to know the mechanisms that turn a goods receipt or an invoice into accounting entries. "A goods receipt for a stock item posts to the wrong account. Where do you look?" tests whether you understand automatic account determination on the procurement side — valuation classes, the movement, the account grouping — and the clearing account that sits between receipt and invoice. "Revenue for one product line is landing in the general revenue account" tests the sales equivalent, where accounts are derived from customer and material groupings. Interviewers are also fond of "the purchasing team wants to change a setting; what do you ask before you agree?", because the honest answer — where does that posting go, and who reads it — shows that you see finance as the downstream owner of everyone else's configuration.

What does the period-end scenario look like?

"Take me through a month-end close in a company you supported." The interviewer is listening for order and for ownership: what runs automatically and what a person must trigger, what depends on what, and where the close usually stalls. Recurring entries and accruals, the clearing of the goods-received-not-invoiced account, foreign currency valuation of open items and balances, the depreciation run in assets, allocations coming across from controlling, then the checks before the period is locked. The follow-up is nearly always "and what went wrong the time it went wrong" — the posting in the closed period, the valuation run that had to be reversed, the sub-ledger that did not reconcile to the general ledger and the way you found the difference. A candidate who has sat with a finance team on the last working day of a period sounds different from one who has read the closing checklist.

How is the data-migration scenario asked?

"We go live at the start of a period. What finance data do you migrate, in what order, and how do you prove it is right?" The answer has a structure: master data first — accounts, customers, suppliers, assets, cost objects — then balances as at the cutover date, with open items for customers and suppliers loaded item by item so that they can be cleared later, assets loaded with their accumulated depreciation so the future runs are correct, and general-ledger balances loaded against a migration clearing account that must be zero at the end. Proof is reconciliation: the trial balance of the old system against the new one, the open-item lists agreeing in count and value, the auditors' sign-off. The migration stream does the loading, but the finance consultant owns the answer to "is it right", and interviewers want to hear that you know it.

What are interviewers really testing?

Whether you think in consequences. Every scenario above has a decision at the front and a report, a close or an audit at the back, and the interviewer is watching for the moment you connect them unprompted. Whether you can talk to accountants in their language and to developers in theirs. Whether your knowledge of the standard process is deep enough that you can tell a genuine gap from a habit. And whether your stories have the texture of real projects — the client's name withheld but the shape of the mess intact — which is how experience is read across the ecosystem.

Which FI scenarios should you rebuild before the interview?

• Rebuild one organisational structure from memory — a real one you configured — and be ready to defend each object and say what you would do differently.
• Walk a close end to end, in order, with the failure story at the step where it happened.
• Trace one posting from each neighbour — a goods receipt, a billing document, a payroll run — through to its accounts, and know which setting on the other side controls it.
• Refresh the accounting behind the configuration: what a segment balance sheet is for, why parallel valuation exists, what an auditor checks at cutover. Interviewers can tell when the accounting is understood rather than configured.
• Read the general pattern in the general interview guide, then come back to the scenarios: an FI interview is won on the consequences you see coming, not on the format.