Functional vs technical SAP consultants

Written by an SAP Finance & Treasury practitioner working with SAP since 2008 · how the guides are written · Updated 10 October 2026 · facts checked against SAP Learning and the SAP News Center, October 2026

The functional vs technical SAP consultant split is the oldest division in SAP work: functional consultants fit the standard system to a business process, mostly through configuration, while technical consultants build and run what configuration cannot reach. It shapes your tools, the background you are hired from and your interviews, but not your whole career.

What does a functional SAP consultant do?

A functional SAP consultant decides how a business process should run in the system and sets the system up to run it that way. Each one owns an area — finance, sales, procurement, manufacturing and the rest — and spends the project in fit-to-standard workshops, deciding what the standard already covers and implementing most of the answer as customizing: organisational structure, document types, pricing procedures, account determination, output control. Where the standard stops, the functional consultant writes the specification a developer builds from, and later tests the result against the process it was meant to serve. The value they bring is process knowledge — what a month-end close involves, why a three-way match fails — and that knowledge ages slowly, because the process outlives the release (the functional role in depth).

What does a technical SAP consultant do?

A technical SAP consultant builds or runs the parts of the solution that are not settings. The largest group are developers working through the RICEF inventory — reports, interfaces, conversions, enhancements, forms — in ABAP inside the system and, more and more, as side-by-side extensions on SAP BTP and Fiori apps over CDS views (the developer's career). Clean-core practice pushes that work outward, beside the core rather than inside it, which changes what developers build rather than how much. Around them sit specialists whose subject is the platform: Basis for the landscape, transports and upgrades; security and authorizations for who may do what; and integration for the IDocs, APIs, events and middleware that connect SAP to everything else.

How do the two roles compare side by side?

They differ on almost every practical dimension except the project they share. The comparison below holds for implementation work on S/4HANA in any edition: on premise, private cloud or public cloud. On support teams the same split applies with tickets in place of workshops.

How does the split work on a real SAP project?

It works as a hand-off chain that repeats for every gap the standard does not close. A workshop records a decision; the functional consultant writes the specification; the developer builds it in the development system; the transport moves through quality to production; the functional consultant tests it against the process. When a defect arrives in integration testing, the first triage question is the one this page is about — configuration or code? — because nobody can assign the ticket until it is answered. That is why both sides sit in the same rooms through every project phase.

Where does the line between them blur?

It blurs wherever settings behave like programs or a process can only be understood through the code. Four places come up on most projects:

• Debugging. A functional consultant who can step through standard code traces a problem to its cause before handing it on, and is trusted for it.
• Specifications. A spec is only as good as its author's sense of what is expensive to build, and a developer who understands the process challenges the wrong request before building it.
• Configuration with consequences. Pricing procedures, workflow and rule-based determination are settings, yet changing them safely needs a developer's caution about side effects.
• Techno-functional areas.Data & Analytics, Master Data and integration ask for both at once, and job ads use the word techno-functional plainly (the combinations the market rewards).

What is a techno-functional SAP consultant?

A techno-functional consultant configures an area and also builds part of what configuration cannot do. The title is not an SAP job classification. It is market shorthand, and what it covers depends on the advert. Usually it means a functional consultant who writes simple reports, debugs standard code and builds small enhancements, or a developer who runs the workshop for the process their code serves. The role is most common on small teams and in support, where one person per area has to cover both halves, and in the areas in the list above, where the data model is the configuration. On a CV, say which half is the stronger one, because an interviewer will test both.

Do SAP functional consultants need to know coding?

No. Configuration is done in the Implementation Guide and in Fiori apps, not in a programming language, and many functional consultants never write a line of ABAP. What the work does ask for is the ability to read: a table in SE16N, a short dump in ST22, a breakpoint in the debugger when a posting does something the settings do not explain. In the public cloud edition the functional consultant works without the SAP GUI debugger, and the nearest skill is key-user extensibility: adding a field or a rule in the Custom Fields and Custom Logic apps. A consultant who can do that much writes better specifications and waits less for developers.

Which side should you start on?

Start on the side your existing experience already half-covers. Domain work in finance, logistics or HR points functional; a development background points technical; time in Oracle or another ERP or in data work can go either way (how those switches play out). Neither side is the safe one. Technical work is more exposed to tooling shifts, including automation of routine code; functional work is more exposed to clients deciding the process should simply follow the standard. The getting-started guide lays out the entry doors on both sides.

Can you move from technical to functional, or back?

Yes, and many senior people have. Developers cross to functional work once they have read enough posting logic to follow the business behind it; functional consultants cross the other way through integration, analytics or workflow; and plenty of architects and leads did it at least once. Make the crossing easy to read for a hiring manager by naming the projects where you already worked on the other side — the specification you wrote as a developer, the debugging you did as a functional consultant. The umbrella title both sides share is unpacked in what an SAP consultant does.