Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 2 of 5

The decision framework

9 min

A process owner needs a consistent way to decide on gaps, otherwise the loudest voice in the workshop wins. The framework in this lesson scores each gap on four questions and turns the answer into a recommended option. It is simple enough to use in the room and strong enough to defend later.

Four questions for every gap

  1. Is it required? Is there a legal, regulatory, tax or contractual obligation that the standard cannot meet? If so, doing nothing is not an option.
  2. Does it differentiate? Does this way of working win customers, protect margin or create advantage Contoso's competitors do not have? Most finance and procurement processes do not; some customer-facing and manufacturing processes do.
  3. What does it cost over its life? Build, test, upgrade regression and support effort, not just the build estimate (lesson 3).
  4. What is the risk? How exposed is the extension to change, and what breaks if it fails: a report, or billing?
Adopt or change the businessLow need, no advantage. Use the standard and adjust the process.
Extend cleanly, fund itDifferentiating but optional. Extend only if the value case covers lifecycle cost.
Configure or use a released compliance optionRequired but generic. Look for SAP localization, configuration or a partner-neutral standard approach first.
Extend on released interfaces and add to regressionRequired and differentiating. Build cleanly and test every release.
Plot each gap on need and differentiation to get a starting recommendation.
The Sign-Off Table · thesignofftable.com/academy/sap-pow-202

The matrix gives a starting point, not a verdict. Lifecycle cost and risk then confirm or overturn it. A low-need, low-differentiation gap with a trivial configuration fix can simply be configured; a differentiating gap whose extension would touch SAP internals may still be rejected.

Choosing the cleanest way to extend

If the answer is "extend," the next question is how. SAP S/4HANA offers several extension styles, from cleanest to least clean:

Key user (in-app) extensibilityCustom fields and custom logic added through Fiori apps, without a developer system. Upgrade-stable.
Developer extensibility (on-stack ABAP Cloud)Custom code in the S/4HANA system using only released APIs and extension points.
Side-by-side extensibility on SAP BTPSeparate apps that talk to S/4HANA through released APIs and events. Decoupled from the core.
Classic extensibility (private cloud and on-premise only)User exits, classic BAdIs, direct table access, modifications. Allowed, but the least upgrade-safe.
Extension styles from cleanest (top) to least clean (bottom).
The Sign-Off Table · thesignofftable.com/academy/sap-pow-202

SAP's 2025 clean core guidance adds a grading scale for extensions. Level A uses only released, stable interfaces (ABAP Cloud or side-by-side). Level B also uses classic APIs that SAP documents and treats as generally stable. Level C accesses SAP internal objects and is only partially compliant. Level D covers modifications, writing to SAP tables or implicit enhancements and is not considered clean. A process owner does not need to know the code, but should ask the architect which level a proposed extension will be, and should expect a strong reason for anything below B.

Practice: three Contoso requests

RequestNeed / differentiationRecommendation
Print the fleet contract number on invoices to Great Lakes Fleet Services (the customer's contract requires it)Contractual / low differentiationExtend with a key-user custom field on the sales order passed to billing output. Level A. Add to the billing regression set.
A custom approval screen for purchase orders over $25,000Internal policy / low differentiationConfigure the standard purchase order approval (flexible workflow or release strategy, depending on your setup). No extension.
Real-time warranty claim scoring based on alternator serial historyOptional / high differentiationExtend side-by-side on SAP BTP using released APIs, if the value case covers lifecycle cost. Level A.

Applying the framework to three Contoso gaps.

Work the table from left to right. For each request, first decide whether there is a real need, then whether the standard or configuration meets it, and only then talk about building something. In the first case the contract leaves no choice but the standard has no field for it, so a clean extension is justified. In the second, the requirement is real but generic, and SAP already provides approval mechanisms. In the third, the requirement is optional, so the decision rests on a value case that Dan and the sales leadership must own.

What would you do?

Contoso's PMO lead Grace asks Dan to approve 40 open finance gaps by Friday. Most are "the old ECC report did this." What is the best approach?

Key points
  • Score each gap on need, differentiation, lifecycle cost and risk.
  • Use the need/differentiation matrix for a starting recommendation, then confirm with cost and risk.
  • If you extend, choose the cleanest style: key user, ABAP Cloud, side-by-side, and only then classic.
  • Ask which clean core level (A–D) an extension will be and expect strong reasons below B.

Check your understanding · not graded

Lesson check

  1. 1. Which four factors does the framework score?

  2. 2. Which extension style is cleanest?

  3. 3. In SAP's clean core levels, what characterizes Level D?

  4. 4. A gap is required by contract but gives no competitive advantage. What is the first thing to look for?