SAP Consultant interview questions, with worked answers

How to use these questions

Many SAP interviews mix a module deep dive with a project story. For the module, walk through a process from start to end and say where each step posts. For the story, say which phase you were in, what you decided, what went wrong and how the go-live went. Interviewers check quickly whether you did the work or watched it.

What an SAP consultant is expected to know

• The system: SAPAsked in 100% of SAP consultant ads (as of 5 Nov 2026).Know your SAP modules well enough to configure them and to explain to users why the system behaves as it does. and at least one module in depth, such as SAP FI/COAsked in 12% of SAP consultant ads (as of 5 Nov 2026).Set up financial accounting and controlling: the chart of accounts, cost centres, closing and reports., SAP MMConfigure purchasing, inventory and invoice checks, and know where each step posts in finance. or SAP SDConfigure orders, pricing, deliveries and billing, from the quote to the invoice the customer receives..
• The settings: customizingAsked in 53% of SAP consultant ads (as of 5 Nov 2026).Change the standard system through its own settings first, and keep a record of every change. and when the standard is enough.
• The project: requirementsAsked in 41% of SAP consultant ads (as of 5 Nov 2026).Turn what the business says into requirements a developer can build and a tester can check., testing, data migrationAsked in 38% of SAP consultant ads (as of 5 Nov 2026).Plan, map, load and check the data that moves from the old system, with the business signing it off. and the go-live.
• The people: key users, process owners and adoptionHelp key users and teams adopt new processes, with training and support after go-live. after go-live.

Tools come up side by side and none is a must: SAP Solution Manager or SAP Cloud ALM for project and test management, SAP Signavio or other modelling tools for process maps, Jira for tasks, and Excel for mapping and migration files. Panels want the process sense more than the tool.

Fit, settings and requirements

What does fit-to-standard mean, and how do you run a fit-to-standard workshop?

What they check: that you start from the standard, not from the old system.

Short answer: "Fit-to-standard means showing the business how SAP's standard process works and agreeing where it fits, rather than copying the old way. In the workshop I demo the process in a prepared system with the client's kind of data, collect the gaps, and ask for each one whether it is a real need, a habit, or a rule from law or tax. Only the real needs become requirements."

The full answer: Every gap you accept adds cost to every later upgrade.

A weak answer: "I ask the users what they want and build it." Follow-up: "The finance director insists on the old report layout." Say what you do.

How do you decide between customizing the standard and asking for an ABAP development?

What they check: restraint and judgement.

Short answer: "Customizing is changing the system through its own settings, which SAP supports through upgrades. I check first whether a setting, a standard report or a small process change can meet the need. Only then do I write a specification for a development, and I say what it will cost to build, test and keep. In S/4HANA I also ask whether the extension can sit beside the core so that it does not block updates."

The full answer: The cheapest development is the one the business agreed it did not need.

A weak answer: "Developers can build anything, so I ask them." Follow-up: "The development is already built and causes problems in the upgrade." Say what you do.

How do you turn a business requirement into a specification that a developer and a tester can use?

What they check: clear, testable writing.

Short answer: "I write what the business needs and why, the input and output, the rules with examples, the error cases and who approves. I add the test cases that prove it works, agree them with the process owner, and walk the developer through it before they start."

The full answer: If the tester cannot write a test from the specification, the developer cannot build from it either.

A weak answer: "I forward the user's email." Follow-up: "The developer built exactly what you wrote, and it is wrong." Say what you learn.

The processes and the data

Walk us through how FI and CO work together in SAP finance.

What they check: the link between the books and the management view.

Short answer: "FI records every business transaction in the legal books, by company code and account. CO takes the costs and revenues that matter for management and assigns them to cost centres, orders or profitability segments. In S/4HANA both read one table of journal entries, so they reconcile by design. I would show it with a supplier invoice that posts in FI and lands on a cost centre in CO."

The full answer: A finance consultant who knows both sides can explain a month-end difference before the controller asks.

A weak answer: "FI is accounting and CO is controlling." Follow-up: "A cost centre report does not match the general ledger." Say where you look.

How does the procure-to-pay process run through MM, and where does it touch finance?

What they check: a process across modules.

Short answer: "A request becomes a purchase order, approved by the rules set up for it. The goods receipt raises the stock and posts in finance against a clearing account. The supplier invoice is checked against the order and the receipt, and the difference rules decide whether it is blocked. Payment runs from finance. I check the account settings that link each step to the ledger."

The full answer: Most purchasing complaints in finance trace back to one setting in this chain.

A weak answer: "MM is for purchasing; finance is someone else's." Follow-up: "Many invoices are blocked for price differences." Say what you check.

What makes master data so important in an SAP project, and how do you keep it clean?

What they check: respect for the unglamorous part.

Short answer: "Master data is the data every process reads: customers, suppliers, materials, accounts. If a supplier has two records or a material the wrong unit, every order and invoice carries the error. I agree owners for each kind of data, clear rules for creating it, checks for duplicates, and a clean-up before migration, not after."

The full answer: Clean master data is the cheapest way to a quiet go-live.

A weak answer: "The business will fix the data later." Follow-up: "Ten thousand supplier records, many unused." Say how you decide what moves.

How would you plan the data migration from an old system to S/4HANA?

What they check: a plan with checks and sign-off.

Short answer: "I agree which data moves: master data, open items, balances, open orders, and usually little history. Then the mapping from old to new fields, the clean-up, and several test loads into a test system, each checked against totals and samples with the business. The last load sits in the cutover plan, and the business signs off the result."

The full answer: A migration is finished when the business trusts the numbers, not when the load runs without errors.

A weak answer: "IT moves everything over." Follow-up: "The open item totals are off by a small amount." Say what you do before go-live.

Greenfield or brownfield: how would you advise a client moving from ECC to S/4HANA?

What they check: a balanced recommendation.

Short answer: "Greenfield means a new implementation that starts from the standard and moves only the data that is needed; brownfield means converting the existing system with its history and settings. Greenfield suits a client with many old custom pieces and a wish to change processes; brownfield suits one whose processes work and who wants a shorter move. Many choose a mix. I would look at the custom code, the data and the appetite for change before I recommend."

The full answer: The decision is about the business, not only the technology.

A weak answer: "Greenfield is always right." Follow-up: "The client needs twenty years of history for audits." Say what changes.

Testing, go-live and the people

How do you test an SAP change before it goes live?

What they check: testing that covers the whole process.

Short answer: "I test my settings in unit tests, then the whole process across modules in integration tests, with realistic data, then key users run their own tests to accept it. For later changes I run regression tests of the processes they touch. Each test has a script, an expected result and a record of what happened."

The full answer: A change that works in one module can break the posting in another.

A weak answer: "I check that the screen saves." Follow-up: "The key users have no time for testing." Say what you do.

What happens in the cutover and the hypercare after go-live?

What they check: calm planning of the most stressful days.

Short answer: "A cutover is the planned switch from the old system to the new one, usually over a weekend: the last data loads, the checks, the closing of the old system and a go or no-go decision, all in a plan with times and owners. Hypercare is the first weeks after go-live, when the project team stays close to the users, fixes problems fast and watches the first month-end close."

The full answer: A rehearsed cutover is a quiet one.

A weak answer: "We switch it on and see." Follow-up: "A check fails on Sunday evening." Say who decides and how.

How do you handle an integration between SAP and another system?

What they check: the edges of the system.

Short answer: "I agree with the other system's team which data flows, in which direction, how often, and what happens when a message fails. I write the field mapping and the error handling, and test with real cases, including the failures. Someone must own the monitoring after go-live, or errors pile up unseen."

The full answer: Interfaces fail at the edges: a missing field, a new value, a late file.

A weak answer: "The integration team does that." Follow-up: "Orders from the web shop arrive twice." Say where you look.

How do you work with key users and get the business to adopt the new processes?

What they check: change on the human side.

Short answer: "A key user is the person in the business who knows a process well, tests it, trains colleagues and answers first questions after go-live. I involve them from the first workshop, let them test early, and give them simple guides for their own teams. Their trust carries the change into the departments."

The full answer: Users accept a new process faster when a colleague, not the consultant, explains it.

A weak answer: "We send a manual before go-live." Follow-up: "One department keeps working in spreadsheets." Say what you do.

A stakeholder raises a change request late in the project. What do you do?

What they check: scope control with good relations.

Short answer: "I write it down, find out why it is needed and whether it can wait until after go-live, and estimate what it costs in time, money and risk. Then the project's change process decides, not me alone. If it is truly needed, the plan changes openly."

The full answer: A project that never says no rarely goes live on time.

A weak answer: "I build it quickly to keep the client happy." Follow-up: "The request comes from the board." Say what changes and what does not.

How do you handle authorizations and the separation of duties in SAP?

What they check: controls built in, not added later.

Short answer: "Roles give each user what their job needs and no more. Some duties must stay apart, such as creating a supplier and paying it. I design the roles with the process owners and the security team, test them with real users, and check conflicts before go-live, because auditors will."

The full answer: Each country's audit rules ask for this in their own way; the client's auditors say how.

A weak answer: "We give everyone broad access and tighten it later." Follow-up: "A user needs both duties in a small plant." Say what you propose.

Where can AI help in SAP projects, and where must the consultant decide?

What they check: sober use of new tools.

Short answer: "AI tools can draft specifications and test cases, summarise workshop notes, suggest matches in invoice and payment data, and answer users' first questions. SAP also builds AI features into its products. I would still check what the tool writes against the real settings, keep client data inside approved tools, and keep the design decisions with people."

The full answer: A fast wrong answer about a posting rule costs more than a slow right one.

A weak answer: "AI will configure the system for us." Follow-up: "A generated test case misses a tax rule." Say how you would catch it.

Senior rounds

As a senior SAP consultant or lead SAP consultant, how would you develop a junior SAP consultant?

What they check: building the team.

Short answer: "I give them a clear part of a process to configure, review their settings and test scripts with them, and take them to workshops, first to listen and then to lead a topic. I explain the business reason behind each setting. Once their work needs few corrections, they own a process area."

The full answer: A lead consultant is judged by how the whole workstream goes live, not only by their own settings.

A weak answer: "Juniors do the documentation." Follow-up: "Their configuration works but nobody understands why." Say how you coach them.

Your CV for these questions

Each SAP line on your CV invites the questions above: which module, which phase, what you did yourself. Give each one a line that makes a lead consultant want the story:

Hold your CV against an SAP consultant job with the free score; then prepare the project story for the area it finds thin, from the workshop to the go-live.