What an SAP consultant interview really checks, beyond the module trivia
An SAP interview has a tell, and it shows up in the first ten minutes. The interviewer asks what you configured on your last project, and the candidate answers with what the project did rather than what they personally touched. That gap is what the whole loop is built to find. Most sap consultant interview questions are less about whether you know a transaction code and more about whether you were in the room when the decisions were made.
The screening question that sorts everyone
Describe your last implementation. Give the shape in about ninety seconds: industry, scale, which modules, greenfield or brownfield, your role, and the phase you joined at. Then stop.
What separates candidates here is specificity about their own scope. “I owned the procure-to-pay configuration for two plants, including release strategy and the interface to the legacy warehouse system” is a real answer. “I worked on MM” invites a follow-up you may not enjoy. If you joined at support rather than build, say so. Support experience is legitimate and pretending it was greenfield build is the fastest way to fail round two.
Lifecycle and methodology
Walk me through the phases of an implementation. Prepare, explore, realise, deploy, run, in SAP Activate terms. What matters is what happens to you in each: fit-gap workshops in explore, configuration and unit testing in realise, cutover and hypercare around deploy.
What’s fit-to-standard, and what do you do when the client won’t fit? This is a judgement question. The answer they want acknowledges that every enhancement is a permanent cost carried into every future upgrade, and then describes how you’d test whether the requirement is real or inherited from how the old system happened to work. Consultants who say “we build what the client asks” are marked as order-takers.
Explain cutover. Data migration sequencing, the freeze, dry runs, reconciliation, and the fallback plan. Having actually done a cutover weekend shows immediately in how someone answers this, so don’t invent one.
What went wrong on a project? Pick something real and own your part. Master data quality discovered late is the honest and extremely common answer.
S/4HANA migration questions
These come up in almost every loop now, because a large share of current work is conversion rather than new build.
Brownfield, greenfield or selective: what drives the choice? Brownfield keeps history and existing configuration, which is cheaper and carries the accumulated mess forward. Greenfield is a clean redesign and a bigger change-management problem. Selective moves chosen entities. The right answer names the deciding factors: how much custom code exists, how good the current data is, and whether the business actually wants its processes changed. SAP’s own S/4HANA pages are worth rereading before an interview since the positioning shifts.
What breaks in a conversion? Custom code that touches changed tables, output determination, anything relying on structures that were simplified. Mentioning the simplification list and custom code analysis by name signals you’ve been through one.
What’s the Universal Journal and why does it matter? A single line-item table bringing finance and controlling together, which removes a class of reconciliation work. If you’re interviewing on the finance side, expect this and expect a follow-up about what it changed in period close.
Module-level sap consultant interview questions, and how deep they go
Depth depends on the role, but the pattern is consistent: a configuration question, then a scenario, then a troubleshooting question.
On the finance side, expect document splitting, parallel ledgers, and the configuration behind automatic account determination. On materials management, release strategies, split valuation, and the three-way match. On sales and distribution, pricing procedure determination and the copy control chain. On the supply chain side, availability check and planning strategies.
The troubleshooting question is the one to prepare, because it’s the least fakeable. “A goods receipt is posting to the wrong account, find it” wants a method: check the movement type, then the valuation class on the material, then the account determination configuration, then whether a substitution is interfering. Saying the order out loud is the answer.
Integration and custom code
Consultants who only know their own module get filtered at this point, because almost nothing in a live system stops at a module boundary.
What happens across modules when you post a goods receipt? Materials management creates the document, stock updates, and finance posts the accounting entry through account determination. Being able to narrate one transaction across all three areas is a strong signal, and it’s a fair question even for a specialist.
How do you decide between an enhancement, a BAdI and a full custom development? Least invasive option that meets the requirement, with upgrade cost as the deciding factor. Naming who maintains it afterwards helps.
How do interfaces to non-SAP systems usually go wrong? Error handling and reprocessing, mostly. An interface that works on the happy path and has no monitoring is the one that ruins a go-live weekend. If you’ve used SAP Support notes to resolve a live integration issue, that experience is worth mentioning specifically.
How much custom code did your last landscape carry, and did anyone measure it? A candidate who knows the rough number, and knows it was measured before a conversion, is telling you they were close to the migration decision rather than adjacent to it.
Client-facing rounds
Consultancies interview for this properly and candidates underprepare it.
A key user insists on a workaround you think is wrong. Understand the underlying need first, then present the cost of the enhancement in terms they hold: upgrade effort, testing burden, who maintains it. Escalate through the process owner rather than over their head.
The project is behind and the client wants scope kept. They’re testing whether you’ll quietly absorb it. Name the trade explicitly, propose what moves to a later phase, and put it in writing.
How do you handle a requirement you don’t understand? Ask for the business scenario end to end, and repeat it back before designing anything. Consultants who configure from a one-line requirement generate rework, and the interviewer has paid for that rework before.
How to prepare in a week
Write out two projects in detail: your scope, three configuration decisions you personally made, one thing that went wrong, and the numbers, meaning plants, company codes, users, go-live date. Interviewers probe numbers because they’re hard to invent under follow-up.
Refresh the troubleshooting order for your module rather than memorising transaction codes, since the codes are searchable and the order is the skill. If you’re on an older release, spend an evening on what changed in S/4HANA for your area, because that question is coming.
Then rehearse aloud with interruptions. The failure mode in these loops is answering the project question for four minutes when the interviewer wanted ninety seconds. Craqly’s mock interview mode runs that on your desktop, cutting in when an answer runs long, pushing on the parts you skimmed, and giving you a transcript so you can see where the time went. The free Starter plan is 20 credits a month, one credit being a minute of live session, resetting monthly, with paid plans from $19 a month billed yearly, checked on 6 September 2026.
Our notes on structuring project stories with STAR fit the client rounds directly, and how to answer questions you don’t know matters more here than in most fields, because SAP is wide enough that admitting the edge of your experience is normal and bluffing is quickly exposed.
Get the numbers from your last two projects written down before anything else. Everything in this interview hangs off being specific about work you actually did.
