A value-ledger workbook for turning delivered capability into accepted business results
Altivate | Published 19 July 2026 | Updated 27 July 2026
1. Give every benefit a state
Most SAP value reporting fails before measurement begins. The business case contains a total, the programme contains a scope, and the operating business contains dozens of process changes. No durable record connects the three.
Use five states:
| State | The evidence required | What it does not prove |
|---|---|---|
| Potential | A credible opportunity, benchmark or local hypothesis | That the design will enable it |
| Enabled | The required process, data and system capability is delivered | That people will use it |
| Adopted | The intended population uses the changed process correctly | That the process outcome moved |
| Measured | A stable process or operating indicator changed against baseline | That Finance accepts a financial effect |
| Realised | The outcome is accepted under the agreed recognition rule | That it will persist without sustaining cost |
A benefit can move backward. Adoption can fall after hypercare. A workaround can restore an old cycle time. A supplier change can invalidate the baseline. A contract thought to be retired can renew. The ledger must show current state, not the most flattering state ever reached.
The SAP Implementation Business Case creates the first version of this ledger. Value realisation begins when scope, baseline and ownership are still changeable, not when the first post-go-live report is due.
Keep two result classes separate throughout the ledger:
- realised financial value, accepted by Finance under an agreed cash-flow, budget, margin, working-capital or risk-loss rule; and
- validated nonfinancial outcome, evidenced in service, quality, resilience, control, employee or customer measures without being presented as booked return.
A benefit can pause or move backward. The ledger reports its current evidence state.
2. Write the value hypothesis before design
For each material benefit, complete one sentence:
If the sentence cannot be completed, the benefit is not ready for the model.
| Ledger field | Definition |
|---|---|
| Benefit ID and name | Stable identifier and outcome-oriented label |
| Business outcome | Cash, capacity, service, quality, risk or strategic option affected |
| Process and population | Exact workflow, transaction set, user group or customer cohort |
| Baseline value, period and source | Reproducible pre-change measure with date and system of record |
| Enabling process and capability | Operating change and SAP capability required together |
| Adoption behaviour | Observable behaviour that must change for value to occur |
| Leading indicator | Early evidence that the new behaviour is taking hold |
| Lagging process measure | Outcome measure expected to move after adoption |
| Financial recognition rule | Finance-approved calculation and evidence threshold |
| Disbenefit or counter-metric | Quality, service, risk or workload measure that must not deteriorate |
| Benefit owner | Executive accountable for the operating outcome |
| Data owner | Person accountable for measure definition and reproducibility |
| Finance approver | Person authorised to accept value into reporting |
| First review and expiry date | First evidence checkpoint and date the hypothesis must be refreshed |
Do this before design because it changes design. A working-capital benefit may require a different exception process, data field and operating cadence from a generic inventory improvement. A decommissioning benefit requires migration, archive, access and contract-exit work. A faster close requires the new close behaviour, not merely a new finance system.
3. Establish the baseline while the old process still exists
A baseline reconstructed after go-live is vulnerable to selective memory, changed definitions and missing data.
For each measure, preserve:
- its business definition;
- source system and extraction logic;
- eligible population and exclusions;
- observation window and seasonality;
- data-quality limitations;
- owner and validation date;
- events likely to change it independently of SAP.
Use more than one measure where the behaviour can be gamed. Faster order entry is not value if corrections increase. Lower inventory is not value if service falls. Fewer manual controls are not value if exceptions move outside the control environment.
Baseline test
- Can the number be reproduced?
- Is the comparison population stable?
- Does the period include normal operational variation?
- Is there a counter-metric for quality, service, risk or workload transfer?
- Has the process owner accepted the definition?
- Has Finance accepted how any monetary effect will be recognised?
SAP Signavio Process Insights can support baselines, performance indicators, blockers and process flow analysis when the required source data and metric are available. It is a measurement aid, not a substitute for a local definition or owner.
4. Build the benefit calculation from operating mechanics
The calculation should be simple enough to challenge and detailed enough to expose double counting.
Realised benefit in a period
verified unit change x actual eligible volume x adoption x recognition factor
Eligible volume is the total pre-adoption population meeting the agreed scope criteria in the period. Adoption is the measured fraction of that population using the intended process. Separating them prevents the same adoption reduction being counted twice.
Then subtract:
disbenefits + incremental run cost + sustaining change cost
The terms answer different questions:
- Did the unit outcome change?
- How much real business volume was eligible?
- How much of that volume followed the intended process?
- What portion meets the agreed recognition rule?
- What did the result cost to sustain?
Efficiency
eligible volume x verified effort reduction x loaded rate x adoption x recognition
Released capacity is not automatically a cash saving. State whether it was removed from budget, redeployed to named work, used to absorb growth, or remains only a capacity indicator.
Working capital
validated change in inventory, receivables or payables x approved financial treatment
Separate a balance-sheet release from recurring profit. Confirm seasonality, growth and policy effects.
Avoided run cost
retired contract + retired infrastructure + avoided support - replacement run cost
Do not recognise it while the contract, interface or retained platform is still active.
Revenue or margin
qualified incremental volume x attributable effect x contribution margin x recognition
When several initiatives contribute, agree attribution before the result appears.
Use a pre-agreed attribution method: a matched process or site where practical, phased rollout, before-and-after analysis adjusted for volume and seasonality, or an explicit contribution share approved by Finance. Record concurrent initiatives and external changes. Correlation after go-live is not enough.
No formula should contain a hidden SAP benchmark or an assumed industry improvement. Start with local inputs and record the source beside every number.
Worked example in the calculator: a staged AP exception rollout
The downloadable calculator opens with a deliberately non-round, illustrative accounts-payable example. It is not an Altivate client result, benchmark or forecast. Its purpose is to show the mechanics and the questions a polished total can hide.
| Evidence field | Illustrative worked value | What it prevents |
|---|---|---|
| Processed volume | 17,680 to 19,610 invoices a month | A smooth forecast standing in for actual demand |
| Eligible process share | 78% | Out-of-scope volume inflating the benefit |
| Measured adoption | 34% to 79% over twelve months | A 100% adoption assumption from day one |
| Verified minutes saved | 2.2 to 4.3 minutes | Treating the design target as observed performance |
| Recognition factor | 45% to 72% | Treating every operating movement as accepted financial value |
| Full monthly burden | AED 18,700 run cost, plus sustaining cost and disbenefits | Reporting gross benefit while the operating burden sits elsewhere |
| Counter-metric | On-time payment falls 0.3 percentage points before recovering | Hiding value transfer during rollout |
Across the twelve illustrative months, the model calculates AED 928,430 of gross recognised capacity and quality value, AED 413,630 after recurring costs and disbenefits, and AED 23,630 after the AED 390,000 one-time implementation cost. The indicative payback is 11.3 months. Those outputs are useful because every input can be challenged; they are not automatically Finance-accepted value.
Worked example: faster close without double counting
Suppose close falls from eight to five working days for twelve entities, but only nine use the new reconciliation process and two simultaneously add finance staff. Report the five-day outcome for the full close population, measure adoption on the nine eligible entities, and isolate or disclose the staffing effect. Recognise financial value only for an accepted mechanism such as avoided overtime or redeployed capacity; retain the faster close itself as a validated nonfinancial outcome if no booked financial effect exists.
5. Use four views, not one dashboard total
Adoption
Is the intended population using the new process, role and decision path?
Process performance
Did cycle time, quality, service, exception rate, control effort or throughput change?
Financial recognition
Has Finance accepted a cash-flow, budget, margin, working-capital or risk-loss effect?
Sustainability
Is the result holding after stabilisation, releases, organisational change and operating cost?
A red adoption measure can explain a flat process measure. A green process measure with no financial recognition can reveal an enabled operating benefit rather than a booked return. A green financial result with a deteriorating counter-metric can reveal value transfer, not value creation.
The executive view should show the chain, the break and the owner. A single green percentage hides all three.
6. Treat vendor tools as instruments, not adjudicators
SAP Signavio value analysis can help teams identify potential value, calculate scenarios and monitor progression. SAP’s own documentation says monetary values may depend on configured cost assumptions rather than monetary values collected from a connected source. Validate those assumptions with the business and Finance.
SAP Cloud ALM adoption potential can help identify unused, outdated or high-value SAP S/4HANA capabilities. That can create a useful investigation list. It does not prove adoption, process movement or financial value.
Use platform diagnostics to ask better questions:
- Which capability is available but unused?
- Which process blocker is visible in operational data?
- Which population or region is not following the target path?
- Which expected value depends on an unvalidated cost assumption?
- Which result can be reproduced outside the presentation layer?
Programme closure does not close the ledger. Transfer each open benefit, baseline extract, recognition rule, review date and decision right to the relevant operational process owner, data owner and Finance approver. The transformation office may facilitate the cadence; operations owns the continuing result.
Download the formula-driven SAP value-realisation calculator. It includes the worked example, a twelve-month evidence ledger, decision outputs, an interpretable trend and definitions. Use the open CSV ledger when a portable tabular format is preferable.
The value ledger remains the governing record because it carries local ownership, definitions, recognition and decisions.
7. Run a value cadence from design through steady state
Before design sign-off
- complete benefit hypotheses;
- lock baseline definitions and data sources;
- map benefits to process and design decisions;
- identify counter-metrics and disbenefits;
- agree Finance recognition rules.
Before each rollout wave
- confirm the eligible population;
- confirm measurement and adoption instrumentation;
- validate local process and statutory differences;
- assign first-review dates;
- refresh assumptions affected by scope or delay.
During hypercare
- protect service, quality and controls;
- distinguish stabilisation from value movement;
- log workarounds that undermine the target process;
- avoid declaring a benefit from an incomplete comparison window.
Thirty to ninety days after stabilisation
- validate adoption and process movement;
- investigate the break in each value chain;
- recognise only results meeting the agreed rule;
- reopen actions, timing or the benefit estimate.
Quarterly
- review realised, at-risk and retired benefits;
- reconcile double claims across programmes;
- update sustaining cost;
- close benefits that no longer have a credible mechanism;
- identify the next improvement cycle.
This cadence turns value management into part of the operating model, not a programme-close ceremony.
8. Put named people around the ledger
| Role | Accountable for |
|---|---|
| Executive benefit owner | Business outcome, decisions and corrective action |
| Process owner | Target process, behaviour and performance |
| Product or platform owner | Enabling capability and operating backlog |
| Data owner | Definition, quality and reproducibility |
| Change lead | Adoption plan and evidence |
| Finance | Recognition rule, attribution and accepted value |
| Transformation office | Ledger integrity, cadence and cross-programme reconciliation |
The programme manager can coordinate the ledger. The programme manager should not own every benefit. If the business owner disappears after approval, the number was sponsorship theatre.
9. Challenge the value claim
For every benefit reported as realised, ask:
- Is the baseline dated, reproducible and still comparable?
- Is the eligible volume actual rather than forecast?
- Is adoption measured at the behaviour level?
- Did the process result move, with a counter-metric?
- Is attribution separated from other initiatives?
- Are transition effects and disbenefits included?
- Is incremental run and sustaining cost deducted?
- Has Finance accepted the recognition treatment?
- Is the result durable after the last release or wave?
- Is there an owner and next decision?
If one answer is no, report the earlier state. An enabled or measured benefit is still useful. It just is not realised yet.
10. Make scope decisions with value evidence
The value ledger is not only for reporting. It should influence the backlog.
When a design choice changes, show which benefit mechanism moves. When a rollout slips, show which value and cost move with it. When adoption stalls, direct investment at the process constraint. When a benefit becomes implausible, retire it instead of lowering the evidence threshold.
This is the deeper discipline: the SAP programme is not finished when all capabilities are delivered. It is finished when the business has either realised the intended result or made a conscious decision to stop pursuing it.
Altivate advises and implements SAP programmes. Finance should own recognition, test attribution independently and retain the right to retire a benefit that the evidence no longer supports.
Build the investment case with The SAP Implementation Business Case, or return to White Papers.
Sources and verification status
Checked 26 July 2026. SAP sources are vendor documentation. No SAP benchmark, suggested improvement or Altivate client result is treated as a guaranteed outcome.
- SAP Help Portal, Getting Started with Value Analysis – current vendor guidance on identifying potential value and monitoring progression.
- SAP Help Portal, Calculation Formulas for Value Analysis – current vendor documentation for value-analysis calculations and cost assumptions.
- SAP Help Portal, Process Flow Visualization – current vendor documentation for process-flow and performance investigation.
- SAP Help Portal, Adoption Potential – current vendor documentation for diagnosing SAP S/4HANA capability adoption potential.
- SAP, Business Transformation Management – current vendor overview of process, enterprise architecture and transformation capabilities.
