Software Ownership Economics Report 2026

Executive Summary

“Build once, own forever” is a strategic thesis – not a universal rule of calculation. Software built in-house can replace recurring license costs, model specific processes more accurately and create a controllable technical asset. It can at the same time be more expensive, riskier or slower if the scope is unstable, usage is small, operations are underestimated or the organization is not able to actually carry ownership.

This report therefore does not model nominal SaaS spend against a build price alone. It separates:

• avoided SaaS costs,
• initial development,
• operating and maintenance costs,
• delivery delay,
• cost overrun,
• remediation risk,
• the time value of money,
• a 36-month and a 60-month horizon,
• ad hoc, standardized and managed operations,
• the accounting review under IAS 38.

The scenarios are explicitly not client cases and not FW Delta offerings. They are reproducible calculation models with disclosed assumptions.

Citable key findings

1. [CALCULATED] Across the five base scenarios, the nominal break-even lies between 21.3 and 33.3 months.
2. [CALCULATED] Two of the five scenarios show nominally positive savings after 36 months but a negative present value at eight percent. Nominal savings and economic advantage are therefore not identical.
3. [CALCULATED] In the 50,000-run scenario model, the probability of a positive 36-month NPV lies between roughly 24.6 and 99.6 percent, depending on the case.
4. [CALCULATED] Over 60 months the NPV becomes positive in almost every case within the modeled parameter spaces; this is a property of the chosen scenarios, not a statement about the market.
5. [CALCULATED] In the self-hosted operating model, labor costs are the largest TCO block for small and standardized profiles; the server price alone does not explain the economics.
6. [OBSERVED] IAS 38 requires, among other things, identifiability, control and expected economic benefit for an intangible asset to be recognized. Not every development expenditure meets these criteria.
7. [OBSERVED] For SaaS configuration and customization, a customer-controlled intangible asset is frequently not recognized; additional, separately controlled code may be assessed differently.
8. [INTERPRETATION] Ownership becomes economical when the avoided recurring cost base is large, the process is stable and operations are standardized. Small or volatile requirements argue more often for buy or hybrid.

---

1. Results overview

1.1 Deterministic base model

Scenario	avoided SaaS/month EUR	Build EUR	Owned run/month EUR	nominal break-even months	NPV 36M EUR	NPV 60M EUR
A – Small internal tool	1,000	25,000	250	33.3	-968	12,234
B – Team platform	2,500	50,000	625	26.7	10,081	43,084
C – Divisional system	5,000	100,000	1,250	26.7	20,162	86,168
D – Enterprise function	10,000	250,000	2,500	33.3	-9,675	122,337
E – Platform consolidation	25,000	400,000	6,250	21.3	200,812	530,842

1.2 Risk-adjusted scenario model

The Monte Carlo analysis uses disclosed, hypothetical distributions for build costs, operating effort, SaaS growth, delivery delay and remediation. It is not an empirically calibrated market model.

Scenario	P(NPV>0), 36M	NPV P10 36M	Median 36M	P90 36M	Median 60M
A – Small internal tool	24.6%	-7,125	-2,339	1,849	16,257
B – Team platform	83.9%	-2,402	7,973	17,171	54,501
C – Divisional system	83.7%	-4,755	15,634	34,372	108,724
D – Enterprise function	25.1%	-71,254	-23,032	18,586	163,202
E – Platform consolidation	99.6%	97,298	188,984	274,609	655,584

1.3 Why scenarios A and D are weak at 36 months

Both cases carry a high initial outlay relative to the monthly cost base they avoid. The deterministic model shows nominal break-even values of 33.3 months. As soon as discounting, delay and cost risk are added, the remainder of the 36-month window is often not enough to recover the initial cash outflow.

That does not mean these builds are “bad”. Possible additional benefits were not monetized in the base model:

• new revenue capability,
• better data quality,
• lower compliance risk,
• shorter process time,
• greater strategic optionality,
• an avoided future migration,
• ownership of the code.

A business case may add these benefits – but only with its own evidence and its own sensitivity analysis.

---

2. Research design

2.1 Research question

Under which transparent cost, risk and time-horizon assumptions is software built in-house economical compared with continued SaaS procurement or a hybrid model?

2.2 Decision alternatives

Alternative	Typical strength	Typical risk
Buy/SaaS	fast rollout, external operations, broad standard functionality	recurring costs, roadmap and Exit dependency
Build/Owned	exact process fit, code control, no Seat or Task license	initial costs, scope, delivery and operating risk
Hybrid	buy standard functionality, own the differentiation	integration and boundary complexity
Delay	preserve information gain and liquidity	continued inefficiency and rising switching costs

2.3 TCO equation

NPV Ownership =
PV(avoided SaaS costs)
- initial development
- PV(operations)
- PV(maintenance and remediation)
- PV(parallel operation and migration)
- PV(residual risk)
+ PV(optionally quantified additional benefit)

The calculation must show at least three perspectives:

1. nominal cash flow,
2. discounted cash flow,
3. risk-adjusted distribution.

2.4 Monte Carlo assumptions

Parameter	Distribution	Assumption
Build multiplier	triangular	0.90 / 1.00 / 1.35
Owned run multiplier	triangular	0.85 / 1.00 / 1.40
annual SaaS growth	triangular	0% / 7% / 16%
Delivery delay	rounded triangular	0 / 1 / 6 months
major remediation	Bernoulli	20% probability
Remediation cost	triangular	5% / 12% / 30% of the build
Discount rate	fixed	8% p.a.
Simulations	fixed	50,000 per scenario
Seed	fixed	20260729

[LIMITATION] These distributions are transparent stress assumptions. They were not estimated from a representative project portfolio.

---

3. Synthesis: the six economic traps

3.1 The wrong comparison period

A build with a two-year useful life can be unattractive; the same build over five years can be highly profitable. The horizon must not be chosen to suit the desired result. It has to be derived from a realistic remaining useful life, from strategy and from the technology cycle.

3.2 The server price as a distraction

A VM at 30 euros per month says little about productive TCO. The relevant costs arise from:

• updates,
• backups and restore tests,
• monitoring,
• security,
• incident response,
• database maintenance,
• availability architecture,
• documentation,
• ownership and on-call.

3.3 Full SaaS avoidance from day one

Real migrations frequently involve parallel operation. A system can be technically live while data reconciliation, training and rollout are still running. During that phase SaaS and owned costs are incurred at the same time.

3.4 Zero value for risk

A build can be late or more expensive than planned. A SaaS vendor can raise prices or withdraw functionality. Both sides carry risk. An honest business case does not model only the risk of the preferred alternative.

3.5 Capitalization as an automatic saving

Capitalization changes the timing of expense recognition, not the underlying payment. In addition, the specific recognition criteria have to be met. “Source code exists” alone is not an accounting decision.

3.6 Strategic benefit without a measurement plan

Ownership can improve data access, speed, M&A readiness or product differentiation. Such benefits are genuinely possible. Without a baseline, a target metric and attribution, however, they turn into marketing figures.

---

Part I - Ownership TCO and build/buy/hybrid

I.1 Research question

Under which cost and time assumptions does building your own system become economically cheaper than continuing with a SaaS model?

The report does not answer what a specific project will cost. It provides a model into which real quotation, contract and operating costs can be inserted.

---

I.2 Why simple SaaS-versus-build comparisons fail

A common comparison reads:

SaaS: 3,000 euros per month
Build: 60,000 euros one-off
Break-even: 20 months

This calculation omits at least:

• operations
• maintenance
• security updates
• monitoring
• backup
• support
• changes
• outage risk
• internal product ownership
• cost of capital
• migration
• parallel operation
• Exit
• residual value
• differing functional scopes

Conversely, pure critiques of building frequently omit:

• growing Seats
• usage overage
• add-ons
• enterprise gates
• integration costs
• ongoing agency or admin effort
• switching costs
• price change risk
• lost process-specific advantages

A robust comparison must cover the same functional scope, the same period and the same risk boundary.

---

I.3 Model

3.1 Variables

Symbol	Meaning
S	monthly avoided SaaS spend
B	one-off build and rollout costs
O	monthly cost of running it yourself
T	evaluation period in months
r	discount rate
M	one-off migration and parallel operation costs
R	expected residual or reuse value

The simplified core model of this report sets M = 0 and R = 0 so that the central variables remain visible. In real business cases both have to be added.

3.2 Nominal TCO

SaaS TCO(T)  = S × T
Owned TCO(T) = B + O × T
Nominal savings(T) = SaaS TCO(T) − Owned TCO(T)

3.3 Nominal break-even

Break-even in months = B / (S − O)

The formula is only meaningful if S > O. If running the system yourself costs the same as or more per month than the avoided SaaS spend, no break-even arises in this simplified model.

3.4 Present value

The report uses an effective annual discount rate of eight percent. The equivalent monthly rate is:

r_m = (1 + 0.08)^(1/12) − 1

The present value of the monthly net savings:

NPV(T) = −B + Σ[t=1..T] ((S − O) / (1 + r_m)^t)

A positive NPV only means that the modeled savings exceed the initial investment at the chosen discount rate. It does not guarantee successful delivery.

---

I.4 Scenarios

All five scenarios are [SCENARIO]. The names describe orders of magnitude, not real FW Delta clients.

Scenario	SaaS / month	Build	Owned run / month	Break-even months	nominal 36 mo.	nominal 60 mo.	NPV 36 mo.	NPV 60 mo.
A – Small internal tool	€1,000	€25,000	€250	33.3	€2,000	€20,000	€-968	€12,234
B – Team platform	€2,500	€50,000	€625	26.7	€17,500	€62,500	€10,081	€43,084
C – Divisional system	€5,000	€100,000	€1,250	26.7	€35,000	€125,000	€20,162	€86,168
D – Enterprise function	€10,000	€250,000	€2,500	33.3	€20,000	€200,000	€-9,675	€122,337
E – Platform consolidation	€25,000	€400,000	€6,250	21.3	€275,000	€725,000	€200,812	€530,842

Rounding: euro amounts to whole numbers; break-even to one decimal place.

4.1 Scenario A – small internal tool

• SaaS: 1,000 euros/month
• Build: 25,000 euros
• Operations: 250 euros/month

After 36 months the nominal saving is 2,000 euros. Taking the discount rate into account, however, the present value is roughly −968 euros.

[INTERPRETATION] A nominal break-even shortly before the end of the evaluation period is not a convincing investment case. Even a small delay or change can wipe out the advantage.

4.2 Scenario B – team platform

• SaaS: 2,500 euros/month
• Build: 50,000 euros
• Operations: 625 euros/month

The nominal break-even is 26.7 months. The present value after three years is roughly 10,081 euros, after five years roughly 43,084 euros.

4.3 Scenario C – divisional system

Scenario C scales B proportionally. The break-even therefore remains identical to B. Absolute savings and risk, however, are higher.

[INTERPRETATION] The same break-even does not mean the same risk profile. A 100,000 euro project needs stronger governance, acceptance and change discipline than a 50,000 euro project.

4.4 Scenario D – enterprise function

With build costs of 250,000 euros and 10,000 euros of avoided SaaS spend, the nominal three-year saving is positive but the three-year NPV is negative.

This illustrates the difference between:

• “after 36 months more invoices were avoided than were nominally spent” and
• “the time-weighted savings justify tying up the capital”.

4.5 Scenario E – platform consolidation

Scenario E has the fastest break-even even though, at 400,000 euros, its initial investment is the highest. The reason is the high monthly net saving.

[INTERPRETATION] Large builds are not automatically slower to pay off. What matters is how many recurring costs they actually replace and whether the scope stays stable.

---

I.5 Sensitivity

The following table normalizes the model. Build multiple describes build costs as a multiple of the monthly SaaS spend. Run ratio describes your own monthly operating costs as a share of the avoided SaaS spend.

Build cost	Run = 10% of SaaS	Run = 25%	Run = 40%
12 × monthly SaaS	13.3	16.0	20.0
24 × monthly SaaS	26.7	32.0	40.0
36 × monthly SaaS	40.0	48.0	60.0

Interpretation

• At build costs equal to 12 monthly SaaS payments, even a run ratio of 40 percent leaves the break-even at 20 months.
• At 36 monthly SaaS payments and a run ratio of 40 percent, the break-even is 60 months.
• The higher the permanent cost of running it yourself, the less the ownership thesis carries on its own.

---

I.6 Complete TCO components

6.1 SaaS side

Cost block	Examples
Subscription	Seats, agents, hosts, MTU, MAR, Tasks, Credits
Add-ons	AI, API, sandbox, SSO, audit, support
Rollout	onboarding, partner, migration, training
Operations	internal administration, roles, data maintenance
Integration	middleware, connector, custom code
Growth	additional users, data, actions, environments
Risk	price increase, plan change, end of product
Exit	export, parallel operation, migration, remaining contract term

6.2 Ownership side

Cost block	Examples
Discovery	process capture, data model, scope
Build	design, engineering, tests, migration
Infrastructure	compute, storage, network, backup
Operations	monitoring, updates, on-call, support
Security	hardening, scans, patch process
Changes	new requirements, APIs, regulatory adjustment
Staff	product owner, administrator, developer
Risk	delay, misplanning, key people
Exit/replacement	handover, documentation, new platform

[RECOMMENDATION] A business case must contain at least a realistic case, a pessimistic case and a stress case.

---

I.7 Decision logic: build, buy or hybrid

Build becomes more plausible when …

• the process is strategically differentiating,
• the requirements are stable enough over several years,
• monthly SaaS costs are substantial,
• Seat or usage growth raises the price sharply,
• proprietary data models create a competitive advantage,
• interfaces and workflows are needed permanently,
• source code, deployment and data control have value in their own right,
• a competent operator is available.

Buy remains more plausible when …

• the process is largely commodity,
• the need is small or temporary,
• the vendor continuously maintains complex external rules,
• time-to-value matters more than long-term TCO,
• operating competence is missing,
• product requirements still fluctuate strongly,
• the market standard makes interoperability easier,
• switching remains relatively cheap.

Hybrid is frequently optimal

Examples:

• standard CRM plus your own event and integration layer
• SaaS identity plus your own business application
• managed database plus your own application layer
• n8n or Open Source runtime plus your own nodes and workflows
• cloud storage plus portable data formats and Exit automation

[INTERPRETATION] Ownership does not have to mean developing every infrastructure primitive yourself. It means deliberately controlling the differentiating logic and the Exit.

---

I.8 Accounting classification

IAS 38 deals with intangible assets. Software can in principle be an intangible asset if the relevant definition, control and recognition criteria are met. Development projects are subject to additional criteria, among them technical feasibility, the intention and ability to complete, expected economic benefit, available resources and reliable measurement of cost.

Important:

• Research costs and development expenditure are not the same thing.
• Not every in-house development may be capitalized.
• Not every handover of code automatically creates control in the accounting sense.
• Maintenance and ongoing operations are not automatically part of a capitalizable asset.
• For SaaS configuration and customization the customer frequently cannot recognize a separate controlled software asset; the specific treatment depends on the contract and the service.

[RECOMMENDATION] Every statement about capitalization on fwdelta.com must therefore read:

Software built in-house can, depending on control, development phase and the recognition criteria met, be recognized as an intangible asset.

Not:

Software built in-house is always capitalizable under IAS 38.

This report is no substitute for accounting advice.

---

I.9 Risk premium and real options

The simplified model does not value the option of cancelling quickly. SaaS can hold a real advantage:

• low initial investment,
• fast start,
• monthly or annual cancellation,
• product development by the vendor,
• transfer of operating risk.

Software built in-house can create different options:

• free further development,
• vendor change at the infrastructure level,
• reuse of components,
• integration without plan limits,
• sale or transfer of the code,
• lower marginal cost per additional user.

An extended TCO should account for these options as scenario values, not as a guaranteed amount of money.

---

I.10 Data requirements for a real audit

For a specific company the model requires:

1. the last twelve SaaS invoices,
2. user and usage development,
3. add-ons and overage,
4. internal admin time,
5. integration and agency costs,
6. contract terms,
7. price escalation clauses,
8. export and Exit conditions,
9. mandatory functional requirements,
10. realistic build quotations,
11. an infrastructure and operating concept,
12. a change budget,
13. a discount rate,
14. a residual value assumption,
15. a risk and delay scenario.

---

---

Part II - Self-hosted operations TCO

II.1 Research question

How does the 36-month TCO of a self-hosted system change when operating work, upgrades, incidents, initial enablement and managed fees are modeled alongside infrastructure?

Not answered:

• whether self-hosting is cheaper than a specific SaaS product,
• how high real outage costs are,
• which architecture suits a given customer,
• which provider prices will apply in three years,
• which staff costs a company actually bears,
• whether managed operations deliver a particular SLA value,
• which tax or accounting treatment applies.

---

II.2 Profile assumptions

Profile	Infra/month	Routine/month	Upgrade/quarter	Incidents/year	Labor rate
Micro	€35	2 h	4 h	2 × 2 h	€75/h
Standard	€180	6 h	8 h	4 × 4 h	€100/h
Critical	€650	16 h	16 h	8 × 6 h	€125/h

Profiles

Micro

A single or small internal system with limited traffic, manageable data volume and low criticality.

Standard

A production business application with monitoring, backups, regular upgrades and several integrations.

Critical

A business-critical service with higher redundancy, more frequent incidents, stricter change processes and greater operational responsibility.

[CRITICAL] The names are scenario labels. They correspond to no standard and no guaranteed architecture.

---

II.3 Operating models

3.1 Ad hoc

• minimal additional infrastructure,
• manual intervention,
• little initial enablement,
• higher ongoing routine and incident work,
• knowledge more strongly tied to individuals.

3.2 Standardized IaC + Runbooks

• infrastructure surcharge of 15 percent in the model,
• initial standardization,
• infrastructure as code,
• repeatable deployments,
• documented runbooks,
• reduced routine, upgrade and incident time.

3.3 Managed Operations

• infrastructure surcharge of 30 percent in the model,
• external monthly managed fee,
• smaller internal residual responsibility,
• reduced internal upgrade and incident time,
• contractual service and escalation performance as a separate cost block.

[INTERPRETATION] Managed operations must not be modeled as “a server plus a few hours”. The value lies substantially in reserved responsibility and operational capability.

---

II.4 Calculation logic

Nominal TCO

TCO 36M
= infrastructure 36M
+ internal work 36M
+ managed fees 36M

Internal work comprises:

Initial enablement
+ routine operations
+ upgrades
+ incident handling

Present value

Monthly and periodized payments are discounted to the reference date at an annual discount rate of 8 percent.

NPV = Sum(cashflow_t / (1 + r)^(t/12))

The present value is not investment advice. It merely makes early and late costs more comparable.

Not monetized

• downtime,
• lost revenue,
• regulatory consequences,
• data loss,
• staff turnover,
• bus factor,
• opportunity cost,
• security breach,
• vendor change,
• residual value of your own automation and documentation.

---

II.5 Results

Profile	Operating model	Infra 36M	Working time	internal work	Managed fee	nominal TCO	Present value 8%
Micro	Ad hoc	€1,260	132.0 h	€9,900	€0	€11,160	€9,885
Micro	Standardized IaC + runbooks	€1,449	116.8 h	€8,760	€0	€10,209	€9,385
Micro	Managed operations	€1,638	43.4 h	€3,255	€12,600	€17,493	€15,724
Standard	Ad hoc	€6,480	360.0 h	€36,000	€0	€42,480	€37,607
Standard	Standardized IaC + runbooks	€7,452	290.0 h	€29,000	€0	€36,452	€33,188
Standard	Managed operations	€8,424	103.6 h	€10,360	€32,400	€51,184	€45,950
Critical	Ad hoc	€23,400	912.0 h	€114,000	€0	€137,400	€121,603
Critical	Standardized IaC + runbooks	€26,910	692.8 h	€86,600	€0	€113,510	€102,759
Critical	Managed operations	€30,420	240.8 h	€30,100	€90,000	€150,520	€134,909

Interpretation per profile

Micro

[CALCULATED] Compared with ad hoc, standardization saves a nominal 951 euros, or 8.5 percent. The effect remains limited because initial enablement accounts for a large share at small scale.

[CALCULATED] Managed operations is 6,333 euros above ad hoc. For a non-critical system that can be uneconomical unless availability, security or staffing reasons justify the value of the service.

Standard

[CALCULATED] Standardization reduces nominal TCO by 6,028 euros, or 14.2 percent.

[INTERPRETATION] With recurring operational work, automation begins to pay for itself. The model shows exactly the range in which IaC, runbooks and standardized upgrades move from “engineering hygiene” to an economic control.

[CALCULATED] Managed operations costs 8,704 euros more than ad hoc but reduces internal working time from 360.0 to 103.6 hours.

Critical

[CALCULATED] Standardization reduces nominal TCO by 23,890 euros, or 17.4 percent.

[CALCULATED] Managed operations costs 13,120 euros more than ad hoc and reduces the internally modeled working time from 912.0 to 240.8 hours.

[INTERPRETATION] For critical systems the internal capacity freed up can be worth more than the nominal difference. That has to be evidenced through service levels, response time and business impact – not through the word “managed”.

---

II.6 Labor costs dominate

Ad hoc

Profile	Share of internal work in nominal TCO
Micro	88.71%
Standard	84.75%
Critical	82.97%

Standardized IaC + Runbooks

Profile	Share of internal work
Micro	85.81%
Standard	79.56%
Critical	76.29%

In the managed model the internal work share falls to roughly 19 to 20 percent, because a large cost block is reported as an external managed fee. That does not mean that “work disappears”; it is bought in under contract.

The server is visible because it comes with an invoice. Operational work is dangerous because it is often only calendar time.

---

II.7 What belongs to routine operations

A serious operating budget covers at least:

• operating system and runtime patches,
• container and dependency updates,
• backup monitoring,
• restore tests,
• certificates and domains,
• secrets rotation,
• log and metric review,
• disk, memory, CPU and queue capacity,
• database maintenance,
• security advisories,
• user and access reviews,
• cost and resource review,
• documentation,
• readiness for incidents.

[RECOMMENDATION] Every activity is assigned an owner, a frequency, an expected duration and an evidence artifact.

---

II.8 Initial enablement as an investment

In the model, standardization initially includes:

Profile	Initial enablement work
Micro	40 h
Standard	80 h
Critical	160 h

In the scenario, managed operations includes 20, 40 and 80 hours of internal enablement effort respectively.

Typical outputs:

• IaC repository,
• CI/CD,
• baseline hardening,
• monitoring and alerts,
• backup/restore,
• runbooks,
• secrets management,
• inventory,
• ownership,
• change and incident process.

These artifacts can generate value over several years. In the calculation they are treated entirely as cost; no residual value is recognized.

---

II.9 Assessing managed operations correctly

A managed offering should not merely state a monthly price. It should define:

• coverage hours,
• response and resolution targets,
• severity model,
• patch SLA,
• backup and restore responsibility,
• on-call,
• change windows,
• security monitoring,
• incident communication,
• reporting,
• exclusions,
• Exit and documentation handover.

Economic Capacity Value

[SCENARIO] If a managed model frees up 256.4 internal hours over 36 months in the standard profile, the question is not only what those hours cost at the given rate. What matters is whether the organization can actually use them for higher-value work.

Capacity Value
= freed-up hours
× realizable value per hour

This value is deliberately not recognized in the main model because it is specific to each organization.

---

II.10 Comparison with SaaS

A fair SaaS-versus-self-hosted comparison requires the same functional and service boundary.

SaaS side

• subscription,
• Seats and usage,
• support,
• integrations,
• export and Egress,
• internal administration,
• contract and renewal effort,
• customization limits,
• Exit.

Self-hosted side

• build/implementation,
• infrastructure,
• operations,
• upgrades,
• security,
• support,
• change requests,
• incident risk,
• documentation,
• residual value and portability.

[CRITICAL] This report does not insert any SaaS costs. It must therefore not be used on its own to claim that self-hosting saves a particular percentage.

---

II.11 Sensitivities

The results react particularly to:

1. the labor rate,
2. routine time,
3. incident frequency and duration,
4. initial enablement,
5. the managed fee,
6. criticality and redundancy,
7. growth and migration events.

Labor rate ±25 percent

Because labor costs dominate in many scenarios, a rate 25 percent higher or lower shifts TCO considerably more than small changes in server prices.

Incident tail risk

The model uses average values. A single severe incident can exceed the entire annual bill. Critical systems therefore need:

• backup and restore,
• redundancy,
• tested failover,
• security monitoring,
• an incident commander,
• a postmortem.

---

II.12 Decision rule

Self-hosting is economically plausible when:

• the process is strategic or differentiating,
• usage is high and relatively stable,
• dependency or data control matters,
• operations can be standardized,
• a clear owner exists,
• Exit and residual value are relevant.

SaaS can be economically better when:

• the need is uncertain or short-lived,
• a commodity function is sufficient,
• internal operating knowledge is missing,
• the vendor’s compliance and support value is high,
• a fast start matters more than ownership,
• switching costs remain manageable.

---

---

4. Accounting classification: IAS 38 without marketing shorthand

4.1 Basic principle

IAS 38 deals with intangible assets. For software it must be examined, among other things, whether an identifiable non-monetary resource without physical substance exists and whether the organization controls that resource. Internally generated intangible assets are subject to additional requirements, in particular the separation of the research and development phases and evidence of technical feasibility and future economic benefit.

4.2 SaaS and configuration

The IFRIC agenda decision on configuration and customization costs in cloud computing arrangements emphasizes that the customer frequently does not control the underlying application. In that case the configuration regularly does not create a separate intangible asset of the customer. In certain constellations, additional code that the customer controls may have to be assessed separately.

4.3 Practical documentation

A project intended to allow an accounting review needs at least:

• clear project phases and approval dates,
• separation of research and development,
• documented technical feasibility,
• budget and resource release,
• expected economic benefit,
• control and usage rights,
• reliable cost recording,
• useful life and amortization method,
• impairment and abandonment rules.

[CRITICAL] Whether and to what extent capitalization is permitted is decided by the responsible accounting function or the auditor on the specific facts.

---

5. Decision framework

5.1 Build tends to be plausible when …

• the process differentiates strategically,
• the requirement is stable over several years,
• the avoided license base is substantial,
• data and logic have to be controlled,
• the scope can be clearly bounded,
• operating competence is available or can be bought in,
• a realistic Exit from the build itself is possible.

5.2 Buy tends to be plausible when …

• the function is commodity,
• the number of users is small,
• speed matters more than ownership,
• requirements change strongly,
• regulatory or operational burden is sensibly carried by the vendor,
• a working export and competition exist.

5.3 Hybrid tends to be plausible when …

• identity, billing or collaboration can remain standard,
• the differentiating logic sits in your own layer,
• data is replicated into a controlled model,
• integrations are open and versioned,
• SaaS remains replaceable instead of system-leading.

5.4 Minimum hurdle

Before a build is approved, a board paper should show at least:

1. base, downside and upside,
2. 36-month and 60-month NPV,
3. break-even,
4. delivery and scope risk,
5. operating costs including labor,
6. Exit from your own system,
7. non-financial benefits with a measurement plan,
8. a clear decision on which SaaS costs actually cease.

---

6. Visualization specification

Chart 1 - NPV 36 vs. 60 months

• Data: FDR-2026-03_ownership_tco_base_scenarios.csv
• Type: grouped bars
• zero line visible
• do not mix nominal savings with NPV

Chart 2 - Monthly cumulative cash flows

• Data: FDR-2026-03_monthly_cashflows_60m.csv
• five separate small multiples
• nominal and PV not on the same line without a clear legend

Chart 3 - Monte Carlo distribution

• Data: FDR-2026-03_monte_carlo_summary.csv
• P10/median/P90 as intervals
• note: distributions are scenario assumptions

Chart 4 - Sensitivity matrix

• Data: FDR-2026-03_sensitivity_grid_36m.csv
• heatmap per scenario
• X: SaaS baseline multiplier
• Y: build cost multiplier
• color: 36M NPV

Chart 5 - Self-hosted TCO components

• Data: FDR-2026-03_selfhosted_tco_results.csv
• stacked bars: infrastructure, labor, managed fees

---

7. Reproducibility

Data files

• data/FDR-2026-03_ownership_tco_base_scenarios.csv
• data/FDR-2026-03_monthly_cashflows_60m.csv
• data/FDR-2026-03_monte_carlo_parameters.csv
• data/FDR-2026-03_monte_carlo_summary.csv
• data/FDR-2026-03_sensitivity_grid_36m.csv
• data/FDR-2026-03_selfhosted_tco_profiles.csv
• data/FDR-2026-03_selfhosted_tco_results.csv

Reproduction code

scripts/FDR-2026-03_reproduce_tco_model.py

Mandatory rules

• do not turn scenarios into client claims;
• do not cite any Monte Carlo probability without the parameter file;
• do not mix NPV and nominal savings;
• report additional benefits separately;
• do not phrase accounting treatment as guaranteed capitalization;
• make all currencies and discount rates visible.

---

8. Limitations

1. The scenarios are hypothetical.
2. The Monte Carlo distributions are not empirically calibrated.
3. Taxes, financing, residual values and inflation beyond the SaaS price assumption are not fully modeled.
4. The opportunity cost of the internal team can be higher or lower.
5. Project abandonment was captured only indirectly through cost multipliers.
6. Security and compliance benefits are not monetized.
7. SaaS discounts and minimum commitments are missing unless added in the individual model.
8. Capitalization under IAS 38 depends on the specific facts.
9. Software can become technically or economically obsolete faster than assumed.
10. A positive NPV is no substitute for an architecture, security or delivery review.

---

9. Citation notes

Permitted:

“In the disclosed FW Delta scenario model, nominal break-even times ranged between 21.3 and 33.3 months. The results are not client cases.”

Not permitted:

“Software built in-house always pays for itself after 33 months at the latest.”

Permitted:

“The simulation shows that a 36-month horizon can be considerably more uncertain than a 60-month horizon for small or capital-intensive builds.”

Not permitted:

“FW Delta has proven that building is always cheaper.”

---

10. Version history

• 1.0 · July 2026 · Deterministic 36/60-month model, three operating models and 50,000-run scenario analysis consolidated; IFRS classification added.
• Live version open · Before publication, check IFRS sources and all calculation artifacts against the final version.

---

11. Sources

1. IFRS Foundation, “IAS 38 Intangible Assets”, https://www.ifrs.org/issued-standards/list-of-standards/ias-38-intangible-assets/, accessed in July 2026.
2. IFRS Foundation, “Configuration or Customisation Costs in a Cloud Computing Arrangement (IAS 38)”, https://www.ifrs.org/projects/completed-projects/2021/configuration-or-customisation-costs-in-a-cloud-computing-arrangement-ias-38/, accessed in July 2026.
3. IFRS Foundation, “IFRIC Update March 2021”, https://www.ifrs.org/news-and-events/updates/ifric/2021/ifric-update-march-2021/, accessed in July 2026.
4. European Commission, “Data Act explained”, https://digital-strategy.ec.europa.eu/en/factpages/data-act-explained, accessed in July 2026.
5. Regulation (EU) 2023/2854 (Data Act), https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng.
6. Zapier, “Pricing”, https://zapier.com/pricing, accessed in July 2026.
7. n8n, “Pricing”, https://n8n.io/pricing/, accessed in July 2026.
8. Microsoft, “Power BI pricing”, https://www.microsoft.com/de-de/power-platform/products/power-bi/pricing, accessed in July 2026.
9. Tableau, “Pricing”, https://www.tableau.com/pricing, accessed in July 2026.
10. HubSpot, “Sales Hub pricing”, https://www.hubspot.com/pricing/sales, accessed in July 2026.
11. FinOps Foundation, “FinOps Framework”, https://www.finops.org/framework/, accessed in July 2026.
12. AWS, “Pricing Calculator”, https://calculator.aws/, accessed in July 2026.
13. Microsoft Azure, “Pricing calculator”, https://azure.microsoft.com/en-us/pricing/calculator/, accessed in July 2026.
14. Hetzner Docs, Price adjustment 2026, https://docs.hetzner.com/general/infrastructure-and-availability/price-adjustment/, accessed in July 2026.
15. Hetzner, Cloud, https://www.hetzner.com/cloud/, accessed in July 2026.
16. Hetzner, Object Storage, https://www.hetzner.com/storage/object-storage/, accessed in July 2026.
17. OVHcloud, Public Cloud pricing, https://www.ovhcloud.com/en/public-cloud/prices/, accessed in July 2026.
18. OVHcloud, Object Storage, https://www.ovhcloud.com/en/public-cloud/object-storage/, accessed in July 2026.
19. Scaleway, Pricing, https://www.scaleway.com/en/pricing/, accessed in July 2026.
20. Scaleway, Object Storage, https://www.scaleway.com/en/object-storage/, accessed in July 2026.
21. DigitalOcean, Droplet pricing, https://www.digitalocean.com/pricing/droplets, accessed in July 2026.
22. DigitalOcean Docs, Backups pricing, https://docs.digitalocean.com/products/backups/details/pricing/, accessed in July 2026.
23. NIST SP 800-218, Secure Software Development Framework, https://csrc.nist.gov/pubs/sp/800/218/final, accessed in July 2026.
24. CNCF, Cloud Native Security Whitepaper, https://www.cncf.io/reports/cloud-native-security-whitepaper/, accessed in July 2026.
25. IFRS Foundation, “IAS 38 Intangible Assets” (issued standards, 2026), https://www.ifrs.org/content/dam/ifrs/publications/html-standards/english/2026/issued/ias38.html, accessed in July 2026.
26. IFRS Interpretations Committee, “Configuration or Customisation Costs in a Cloud Computing Arrangement (IAS 38)”, Agenda Decision, March 2021, https://www.ifrs.org/projects/completed-projects/2021/configuration-or-customisation-costs-in-a-cloud-computing-arrangement-ias-38/tentative-agenda-decision-and-comment-letters/, accessed in July 2026.
27. IASB, “Intangible Assets – Definition of intangible asset and supporting requirements (SaaS test case)”, Staff Paper AP17, July 2026, https://www.ifrs.org/content/dam/ifrs/meetings/2026/july/iasb/ap17-changes-definition-guidance-saas-test-case.pdf, accessed in July 2026.

---

Disclosure and disclaimer

FW Delta sells custom software development and controlled infrastructure. A positive ownership business case can therefore align with the publisher’s economic interest. The countermeasures in this report are disclosed assumptions, negative scenarios, present value calculation, limitations and reproducible code.

The report is not accounting, tax, legal, financing or investment advice. IAS 38 and SaaS configuration must be assessed for the specific financial statements together with qualified professionals.