How to Screen SAP Consultants: Verifying Real Implementation Experience Beyond Module Names

An SAP CV is one of the hardest documents in technology recruitment to read honestly. Two consultants can both write “SAP FI/CO, S/4HANA” in their skills section. One of them designed a chart of accounts, configured document splitting, ran a parallel ledger migration and stood on a go-live floor at 4am. The other sat in a support queue on a single project, resolving tickets against a configuration someone else built.

Hire Proven SAP Consultants with Prism HRC

Nothing on either CV distinguishes them. The difference surfaces about three weeks into your implementation, usually in a workshop where the business asks a question nobody can answer.

This is the central problem in SAP staffing. Module names are necessary but almost useless as a screen, because they describe an area of exposure rather than a depth of experience. Screening well means asking a different set of questions entirely.

Why SAP CVs are especially hard to read

Three things make SAP harder to assess than most technology hiring.

First, the ecosystem rewards listing breadth. A consultant who touched MM while working on SD learns quickly that listing both gets more calls. Over a few years, a CV accumulates modules the way a passport accumulates stamps, and the depth behind each one varies enormously.

Second, the word “experience” covers a vast range. Supporting a live system, testing someone else’s configuration, configuring under supervision, and owning a workstream through a full implementation are four genuinely different jobs. All four get written as experience.

Third, project phase matters more than project count. Someone who joined three projects at hypercare has a very different skill set from someone who ran one project from blueprint to go-live, even though the first CV looks busier.

So the screening questions that work are the ones that force specificity about which of these a candidate actually did.

The five things to establish about every SAP consultant

Before module-specific questions, establish the shape of the experience. These five probes do most of the work.

1. Which project phases did they work on?

Ask them to walk through one project by phase: blueprint, realisation, testing, cutover, hypercare, support. Then ask what they personally did in each. People who’ve only joined late can describe hypercare in detail and go thin on blueprint. That’s not disqualifying, but you need to know it.

A useful follow-up: “What were the biggest decisions taken during blueprint on that project, and who made them?” Someone who was in the room can tell you. Someone who wasn’t will generalise.

2. Configuration or testing?

This is the single most important distinction, and it’s the one CVs blur most. Ask directly: “Which settings did you configure yourself, in which client, and who approved the transports?” Configuration experience comes with specifics, transaction codes, config paths, the arguments they had about a particular setting. Testing experience comes with test scripts and defect logs.

Both are legitimate. Hiring one when you need the other is not.

3. Greenfield or brownfield?

A greenfield implementation builds from scratch and demands design thinking. A brownfield conversion carries existing data, custom code and twenty years of decisions that nobody documented, and demands a completely different kind of problem-solving. Selective data transition sits between them.

Ask which they’ve done, and then ask what was hard about it. Brownfield people talk about data cleansing, custom code remediation and surprises in the existing config. Greenfield people talk about workshops, design decisions and change management.

4. Cross-module integration work

Real SAP implementations fail at the seams between modules, not inside them. A consultant who has only worked within their own module boundary will struggle the moment FI meets MM.

Ask: “Describe a problem you solved that crossed module boundaries. Who else was involved?” The best consultants light up at this question, because integration issues are the memorable ones.

5. Scale and complexity

How many company codes? How many plants? How many countries, legal entities, currencies? A single-entity domestic rollout and a multi-country, multi-currency implementation are different universes of complexity.

Sample SAP consultant interview questions by area

FI/CO

• “Walk me through how you’d configure document splitting for a client with multiple profit centres. What questions would you ask the business first?”
• “A month-end close is running long and finance is escalating. How do you approach it?”
• “Explain a time the business asked for something in CO that you pushed back on. What was your reasoning?”
• “What changed in FI when you moved from ECC to S/4HANA?” This last one is a quick test of whether their S/4HANA consultant skills are genuine. Anyone who has actually worked in S/4HANA will reach for the Universal Journal and what it collapsed together. Someone who has only read about it tends to talk in generalities about “simplification.”

What strong answers sound like: they ask clarifying questions before answering. They reference the business process, not just the config screen. They mention reconciliation and period-end impact.

MM/SD

• “A purchase order isn’t generating the expected accounting entry. Walk me through your diagnosis.”
• “How would you configure pricing for a client with regional discounts, customer-specific rates and promotional pricing?”
• “Describe how you handled an integration issue between SD and FI on a past project.”
• “What’s the trickiest master data problem you’ve dealt with in a rollout?”

What strong answers sound like: they trace the process end to end, PO through goods receipt through invoice verification, and they talk about account determination rather than guessing. On pricing, they discuss condition technique and the maintenance burden of what they’re proposing.

ABAP on HANA

• “What changes in how you write ABAP when the database is HANA?”
• “How do you approach code remediation during a brownfield conversion?”
• “Describe a performance problem you diagnosed and fixed.”
• “When would you use CDS views instead of traditional reporting?”

What strong answers sound like: they talk about code pushdown, moving logic into the database rather than looping in the application layer. They mention the custom code analysis tools used in conversions. On performance, they describe the diagnosis, not just the fix.

How to verify SAP certifications

Certifications are a baseline filter, not proof of implementation capability, but they’re worth confirming because certification claims are a common place for CVs to inflate.

SAP issues digital badges through Credly, so the simplest approach is to ask the candidate for their Credly profile link or the specific badge URL. A genuine badge page shows the issuing organisation, the exact certification name, the issue date and any expiry.

A few things to check beyond existence. Confirm the certification version matches what the candidate claims, an ECC-era certification is not an S/4HANA certification. Check the status, since SAP has moved toward requiring periodic recertification for many credentials. And watch for the training-versus-certified gap, attending an SAP course is not the same as passing the exam, and CVs blur this constantly.

The practical approach is to ask for the badge link during screening. It’s a routine request, a genuine holder produces it in minutes, and reluctance is informative in itself.

CV red flags worth noticing

None of these is disqualifying on its own. Several together warrant a harder conversation.

• Too many modules. Five or more listed at apparently equal depth usually means breadth of exposure, not depth of capability.
  No project phases named. A CV that lists clients and modules but never says blueprint, realisation, cutover or hypercare is hiding the shape of the work.
• “Worked on” and “involved in” everywhere. Vague verbs doing heavy lifting. Strong SAP CVs say configured, designed, led, migrated.
• Implementation counts without duration. “8 implementations” sounds impressive until you learn they were three-month support engagements.
• S/4HANA claimed with no conversion detail. Anyone who genuinely worked on a conversion remembers the pain and can describe it.
• No mention of integration. A consultant who only ever worked inside one module boundary is usually telling you something.
• Certification claimed without a version. “SAP Certified” with no specification is worth probing.
• Gaps between listed projects. Not sinister, but worth asking about, SAP work is project-based and bench time is normal, though its pattern tells you something.

Get Pre-Screened SAP Talent from Prism HRC

Reference checks that actually work

Most SAP reference checks waste the opportunity by asking whether the candidate was good. A better question: “Tell me about a specific problem that arose on that project and what their role was in resolving it.”

Also worth asking the referee directly: “What did they configure themselves?” It’s a question that produces either a precise answer or a revealing pause.

Where Prism HRC fits in

As a specialist SAP recruitment agency, we look at SAP candidate searches from the side that doesn’t appear on a CV, the candidates who look interchangeable on paper and prove to be nothing alike once a project starts. Screening past module names is where most of the value sits: establishing which phases someone actually worked, whether they configured or tested, what they’ve done on greenfield versus brownfield, and how they handle the integration points where implementations genuinely fail.

We verify certification authenticity as standard, and then go further, because an authentic certificate and an authentic implementation record are two different things. For companies looking to hire SAP consultants India wide, across functional, technical and leadership roles, that distinction is usually what separates a project that lands from one that stalls in month four.