Audit ready TCO documentation for RISE contracts.

A RISE with SAP TCO model that produces a clean number for the executive sponsor is only half the deliverable. The other half is the documentation that allows internal audit, external audit, the audit committee, and any subsequent regulatory review to trace every input back to a defensible source. The documentation is often treated as a post hoc exercise, completed after the deal closes for compliance purposes. Treating it that way is a mistake. Documentation that is built alongside the model, with audit grade discipline from the start, produces a stronger model, a stronger negotiation position, and a contract that survives scrutiny three and five years after signing. The work is procedural. The benefit compounds. Most TCO models we review fail audit grade on the documentation, not the math.

01.What audit grade documentation actually requires

Audit grade documentation has four characteristics. Every input has a named source. Every assumption has a written rationale. Every methodological decision has a recorded review and approval. Every revision to the model has a dated change log with the reason for the change.

The four characteristics together produce a model that any qualified reviewer can pick up two years after signing and reconstruct exactly how the numbers were arrived at. The reviewer does not need to know the original analyst. The reviewer does not need access to the original source systems. The reviewer reads the documentation and can confirm or challenge any specific number on its own terms.

Most TCO models fail one or more of the four. Inputs are pulled from spreadsheets that have been deleted. Assumptions are remembered by analysts who have left the company. Methodological decisions were verbal and never recorded. Revisions overwrote the previous numbers without preserving the original. Each failure is recoverable in isolation but creates a model that will not survive audit when the four are combined.

The discipline is to set the audit grade standard at the start of the modelling work and to apply it line by line as the model is built. Retrofitting the discipline after the fact is harder, more expensive, and less complete than building it in from day one.

02.Naming the source for every input

Every input cell in the TCO model needs an associated source. The source can be a vendor invoice, a contract clause, an internal accounting report, a benchmark study, a vendor quote, or an analyst estimate. The source needs to be named explicitly in a separate column on the input sheet, with enough detail that another analyst could retrieve the same number.

Internal sources are referenced by system and report name. For example: SAP estate run rate sourced from the financial management system, report code GLAR123, run date 2026.03.15. The reference allows the original report to be retrieved if the input is questioned.

External sources are referenced by document name and date. For example: hyperscaler reserved instance pricing sourced from the AWS price list dated 2026.02.01. The reference allows the source document to be archived as part of the model package.

Estimates are referenced by the analyst who produced them and the methodology used. An estimate without a named author and methodology is not a defensible input. An estimate with both is acceptable, although the audit committee will typically apply a wider sensitivity range to estimated inputs than to sourced inputs.

03.Documenting assumptions with rationale

Assumptions are the choices the model makes when the source data is incomplete or when multiple interpretations are reasonable. Examples include the assumed inflation rate, the assumed contract term, the assumed FUE growth rate, the assumed depreciation horizon, and the assumed discount rate for present value calculations.

Each assumption needs a written rationale that explains why the specific value was chosen, what alternatives were considered, and what the impact would be if the assumption were varied. The rationale is typically half a page per major assumption, captured in a separate document that accompanies the model.

The rationale matters because assumptions are the part of the model most likely to be challenged. A reviewer who disagrees with an assumption can be persuaded by a strong rationale. A reviewer who finds no rationale will substitute their own assumption, which often produces a different result and undermines the model.

The rationale also creates a paper trail for any subsequent change to the assumption. If the discount rate is revised in year three, the original rationale documents why the original rate was chosen, and the new rationale documents why the change was made. The history allows the audit committee to track the evolution of the model over time.

04.Recording methodological decisions and approvals

Methodological decisions are the structural choices the model makes about how cost categories are defined, how time horizons are treated, how tax effects are applied, and how multi entity allocations are calculated. The decisions are typically made early in the modelling work and rarely revisited, which is why they need to be documented carefully.

Each methodological decision should have a written paragraph explaining the choice, the alternatives considered, the reasoning, and the named person who approved the choice. The approver is usually the finance lead on the project, sometimes with sign off from the controller or CFO depending on materiality.

The approval matters for audit reasons. An auditor reviewing the model wants to confirm that the methodology was approved by an appropriate authority, not invented by the analyst. The approval also matters for accountability. If a methodology produces a result that turns out to be problematic, the named approver can explain the original reasoning rather than the analyst defending a decision they did not make.

Methodological decisions are revisited only when new information requires a change. A revisit is itself a methodological decision and follows the same process: written paragraph, alternatives considered, reasoning, approval. The discipline preserves the integrity of the model across its lifecycle.

05.Change log with dated revisions and reasons

The change log is the running record of every revision to the model. Each entry includes the date, the analyst making the change, the specific cells changed, the old values, the new values, and the reason for the change. The log lives on a separate sheet inside the model file and is never deleted or overwritten.

The change log enables version control. A reviewer can reconstruct the model as it stood on any specific date by walking backward through the log entries from the current state. The reconstruction allows the model to be tested against decisions that were made at earlier points in time.

The change log also enables learning. Over the life of a multi year RISE contract, the model is updated as actual costs come in and as assumptions are validated or revised. The log captures the trajectory, which feeds into the methodology for the next model the team builds.

The change log is reviewed by internal audit on a periodic basis, typically annually. The audit reviews the log for completeness, for appropriate documentation of each change, and for any patterns that suggest the model is drifting away from its original methodology. The review is a normal part of governance and rarely produces findings if the log is maintained with discipline.

06.Producing the audit pack

The audit pack is the compiled documentation that accompanies the TCO model. The pack includes the model file, the input source document, the assumption rationale document, the methodological decision document, the change log, and any supporting analysis that materially affected the model's conclusions.

The pack is produced once when the model is delivered and then refreshed whenever the model is updated. The pack lives in a controlled repository with access controlled appropriately for the sensitivity of the contents. The repository is typically the same one used for other audit grade documentation such as financial statement workpapers.

The pack is what the audit committee actually reviews. The model itself is rarely opened in audit committee meetings. The pack is reviewed in advance, questions are raised, the analyst answers the questions in writing, and the committee approves the model based on the pack rather than on a live walkthrough.

The discipline of producing the pack from day one means the model is review ready at every stage of the RISE engagement. When the audit committee asks for the model in week six of a six week negotiation, the pack is already complete. When internal audit asks for the model two years after signing, the pack is already in the repository. The audit grade discipline is the difference between a model that supports the business and a model that becomes a liability.

Documentation that is built alongside the model, with audit grade discipline from the start, produces a stronger model, a stronger negotiation position, and a contract that survives scrutiny three and five years after signing.

07.Conclusion

The discipline of audit grade documentation is not glamorous and rarely receives attention in RISE negotiation playbooks. The discipline is also the difference between a TCO model that holds up under scrutiny and one that quietly loses credibility over time. Buyer teams who treat documentation as a parallel deliverable from day one, alongside the model itself, end up with a contract that is easier to defend, easier to optimise, and easier to renew. Buyer teams who treat documentation as a post hoc compliance exercise find themselves rebuilding the model under pressure when audit, regulatory, or board questions arrive. The discipline is the work. The work is worth doing once, properly, at the start of every serious RISE engagement.