Capitalising Self-Developed Software Before a Funding Round: What CFOs Need to Know

Self-developed software, platforms or methods can be recorded on the balance sheet as an investment under German GAAP (HGB) instead of being expensed immediately. That lowers personnel expense in the income statement and increases equity and EBIT, without a single euro of cash inflow. Anyone preparing a funding round should understand this decision: commercial law (HGB) permits it as capitalisation of internally generated intangible assets, tax law forbids it, and investors interpret the two quite differently.

What capitalisation actually means

When a startup builds its own software platform, personnel costs are incurred. Under standard treatment, these costs appear immediately as an expense in the income statement and reduce annual profit. That is the default situation, and most companies leave it at that.

Under German commercial law there is an alternative: development costs for self-created intangible assets can be treated as an investment and recorded on the balance sheet. Instead of disappearing as personnel expense in the income statement, they appear as fixed assets. The income statement then contains an offsetting item under capitalised own work (in German: Andere aktivierte Eigenleistungen) that compensates the cost. Current-year EBIT rises. Equity rises. Without a single euro of cash inflow.

The capitalised amount is then depreciated on a straight-line basis over its estimated useful life: for self-developed custom software, in practice often in the range of three to five years, with standard business software such as ERP systems typically at the upper end of that range. What governs is the actual economic useful life in the specific case, not a fixed benchmark. The costs do not disappear, they shift into the future.

The legal position: HGB permits it, tax law forbids it

Since the 2009 BilMoG reform: self-created intangible fixed assets may be capitalised, but they are not required to be (§ 248 (2) sentence 1 HGB). It is an option, not an obligation.

Excluded from this option are self-created brands, mastheads, publishing rights and customer lists (§ 248 (2) sentence 2 HGB). These can never be capitalised, regardless of how much a company has invested in them.

In the tax balance sheet, the opposite applies: self-created intangible assets generally may not be capitalised (§ 5 (2) EStG, German Income Tax Act). Development costs are immediately deductible for tax purposes. That is favourable from a tax perspective, but it creates a difference from the commercial (HGB) balance sheet.

The consequence of this difference: a company that capitalises under HGB reports higher assets in its HGB balance sheet than in its tax balance sheet. This generally results in a deferred tax liability (small corporations are partially exempt from this recognition under § 274a HGB). For illustration: on a capitalised amount of EUR 350,000 at a tax rate of roughly 30 percent, the deferred tax liability would be approximately EUR 105,000, so the net equity effect of the capitalisation would be around EUR 245,000 instead of EUR 350,000. The specific treatment should be clarified with the tax advisor or auditor.

Research versus development: the dividing line that is often missing in practice

The capitalisation option applies exclusively to development costs. Research costs may not be capitalised under either HGB or tax law. This distinction is conceptually clear but often difficult to apply in practice.

The relevant threshold is known in the professional literature as the point of no return: the moment at which it becomes evident that a functioning product will result. Costs incurred before this point cannot be capitalised retroactively. Whatever was booked as an expense beforehand remains an expense.

For startups, this means in practice: only the personnel costs attributable to actual development work on the asset are capitalisable, valued as hours worked multiplied by the hourly rate (§ 255 (2) HGB). This is not a developer's full gross salary. Non-productive time must first be deducted from annual salary: holidays, sick leave, public holidays, general training, team meetings and administrative tasks. Of the remaining productive time, only the share attributable to capitalisable development counts, meaning the creation of new functionality after the point of no return. Maintenance, bug fixing, planning and work during the research phase remain expenses.

Minute-by-minute time tracking is not legally required for this. The standard is reliable determinability, not exact measurement. A plausible, documented estimate of the capitalisable hour share is permissible as long as it is verifiably substantiated, for example through sprint planning, commit history, tickets in the project management tool, or role descriptions. The size of the share depends heavily on role and phase: for developers who primarily build new functionality, it can be well above half; in maintenance- or research-heavy setups it will be correspondingly lower. What auditors question is not the size of the share itself, but a missing derivation. A high share is defensible if the underlying activity structure is documented.

What changes in the balance sheet and income statement: a worked example

A SaaS startup develops a new core feature for its platform in 2025. Total cost: EUR 400,000, of which EUR 50,000 is research cost (feasibility study, not capitalisable) and EUR 350,000 is development cost (capitalisable, since technical feasibility is documented).

From the second year onward, annual depreciation of EUR 70,000 appears as an expense in the income statement. The first-year EBIT benefit is unwound again over five years. Capitalisation shifts the expense, it does not eliminate it.

The example below shows the income statement and balance sheet effect over the full capitalisation period. Toggle between P&L and balance sheet and compare the presentation with and without capitalisation.

How investors read capitalised own work

Experienced investors routinely strip capitalised own work out of EBIT and EBITDA. They work with a cash EBITDA that removes non-cash items. Development costs regularly show up as an EBITDA adjustment in transaction processes, either through the accounting treatment of capitalisation or as an explicit normalisation outside the balance sheet.

In transaction processes, such EBITDA adjustments are the rule rather than the exception. Software development costs, along with management compensation, are among the adjustments that come up most often, since they can meaningfully distort reported earnings.

In practice, this means a professional investor's view of the company's earnings power changes little depending on whether it capitalises or not. What does change is the quality signal the documentation sends:

• Positive signal: a consistent capitalisation policy, verifiably documented cost allocation and a plausible depreciation schedule signal structured financial management.
• Negative signal: capitalisation that jumps sharply just before a funding round, without a clearly describable new product behind it, invites due diligence questions.
• Neutral: capitalisation in line with actual investment behaviour, consistent across multiple periods, is generally accepted as standard practice.

Another point: under IFRS (IAS 38), once the capitalisation criteria are met in the development phase, capitalisation is mandatory, not optional. A company that exercises the HGB option therefore aligns its presentation with international standards. That is a useful argument when talking to investors who benchmark against IFRS-reporting companies.

When to capitalise, and when not to

First-time capitalisation in an ongoing business: step by step

One clarification up front: the capitalisation option under § 248 (2) HGB is exercised as of the balance sheet date for development costs incurred during the current fiscal year, starting from the point at which the emergence of the asset is sufficiently probable. For costs already expensed in closed prior years, prevailing opinion holds that retroactive capitalisation is prohibited: they cannot be brought onto the balance sheet after the fact. First-time exercise therefore takes effect prospectively from the current fiscal year; no restatement of prior-year comparatives is required. How this applies in a specific case should be coordinated with the tax advisor or auditor.

Step 1: Check whether the requirements are met

Before any other action, the question is whether capitalisable output exists at all. Three conditions must be met simultaneously: an identifiable intangible asset must be emerging (not diffuse knowledge accumulation), the costs must be reliably determinable and attributable to a specific project, and technical feasibility must already be established at the time of capitalisation. If you cannot answer yes to all three, do not capitalise.

Step 2: Document cost allocation

Capitalisable production costs must be reliably determinable. This requires a traceable allocation of development hours to the project, though not necessarily minute-by-minute time tracking. The hourly rate is derived from average personnel costs per function or pay grade (gross salary plus employer social security contributions, divided by productive annual hours). Multiplied by the hours attributable to capitalisable development, this yields the capitalised amount. Companies with project-based time tracking are on the safest footing. Without it, a documented estimate of the capitalisable hour share can be used, derived from sprint planning, tickets or role descriptions. What is needed in every case: a recognisable separation between the research and development phases, and a cost basis that traceably shows direct personnel costs, material costs and capitalisable overheads per project.

Step 3: Prepare a production cost calculation per project

For each capitalisable project, a calculation is prepared to serve as the valuation basis for the annual financial statements. The document must contain the following items:

This document is not a one-off form but is updated annually: remaining book value, cumulative depreciation and any impairments are added. It also serves as the basis for the notes to the financial statements and for due diligence questions.

Step 4: Set a written capitalisation policy

Before the first capitalisation, a written policy must exist that answers the following: which project types qualify for capitalisation? Above what minimum amount is capitalisation applied (materiality threshold, e.g. EUR 10,000)? What depreciation period applies to which asset category? How is the overhead allocation rate calculated, and who calibrates it annually? Who in the company decides on capitalising a project, and who signs off? The policy is created once, reviewed annually, and any changes are explained in the notes.

Step 5: Coordinate with the tax advisor or auditor

Small GmbHs without an audit requirement (balance sheet total under EUR 7.5 million, revenue under EUR 15 million, fewer than 50 employees, two of three criteria) can exercise the option without an auditor. The tax advisor prepares the annual financial statements and can carry out the capitalisation. What should be coordinated with the tax advisor: the production cost calculation and the boundary decisions, the calculation of the deferred tax liability, the wording of the disclosure notes, and the treatment in the tax return (where the expense remains immediately deductible).

Where an auditor is involved, bring them in early, ideally before the year-end close. Retroactive discussions about the valuation basis or the research/development boundary are more time-consuming than early coordination. The auditor does not need to approve the capitalisation, but reviews it and can require corrections.

Step 6: Annual financial statements and disclosure requirements

In the annual financial statements, the self-created asset is recognised at production cost in fixed assets, and the deferred tax liability is taken into account. The bookkeeping is handled by the tax advisor or accounting team. As CFO, the disclosure requirements are what you actively manage, since this is where the most common gaps arise. Three disclosures are required:

• § 284 (2) no. 2 HGB: explanation of the first-time exercise of the capitalisation option and justification of the departure from prior practice.
• § 285 no. 28 HGB: disclosure of the amount that is barred from distribution as a result of the distribution restriction.
• § 285 no. 29 HGB: explanation of deferred taxes, including the cause (HGB/tax balance sheet difference from capitalisation) and the tax rate used.

Prior-year comparatives do not need to be restated. HGB does not have a restatement principle comparable to IFRS IAS 8. The change takes effect only from the year of first-time exercise.

Step 7: Subsequent years and ongoing documentation

From the year of first-time capitalisation onward, three ongoing obligations apply: the depreciation schedule is updated annually. Each year, it is checked whether the carrying amount is still justified (impairment test): if a product is discontinued, becomes technologically obsolete or the project is abandoned, an impairment write-down is required. And the capitalisation policy is applied consistently, with deviations explained in the notes.

The operational process: who supplies which data?

In practice, capitalisation rarely fails on understanding; it fails on data collection. As CFO you sit in the middle and pull together three inputs: development (typically the CTO or a lead developer) supplies the activity structure, payroll supplies the fully loaded personnel costs, and the tax advisor confirms the methodology. Concretely, that means two templates going to two different places. One goes to technical leadership, the other to payroll. Together they yield the capitalised amount.

Template 1: to technical leadership (CTO or lead developer)

This template clarifies what share of development time was capitalisable work. The instructions matter: not a gut estimate, but derived from epics in Jira or Linear, from sprint boards or ticket labels. Technical leadership knows the projects, the finance team does not. Request a breakdown per developer or per role:

Template 2: to payroll

This template supplies the cost basis. What is capitalisable is not gross salary, but the fully loaded daily rate based on productive working days. Payroll has these figures, development does not:

Bringing it together at CFO level

The two templates together yield the capitalised amount per developer. Productive days multiplied by the capitalisable percentage gives capitalisable days; multiplied by the fully loaded daily rate gives the capitalisable personnel cost share. A worked example:

Add capitalisable overheads on top: a pro-rata share of cloud and tooling costs during development, a pro-rata share of leadership time. The sum across all contributors plus overheads is the production cost of the asset. Build this calculation once as a template and fill it in quarterly or at year-end close. Keep a dated sign-off from finance leadership for each capitalisation decision: who decided, on what basis. This traceability, from the individual developer through the daily rate to the signed-off capitalised amount, is exactly what an audit or due diligence process wants to see.

The calculator below reflects this logic. Enter your roles with headcount, monthly gross salary and the estimated capitalisable time share. The result is a guide for the production cost basis, not a substitute for project-level individual cost allocation.

Edge cases the standard process misses

• Founder or CTO without salary: anyone who does not pay themselves a salary in the early phase has not booked any personnel expense. Without an expense, there is nothing to capitalise, regardless of how much code has been written. A capitalisable basis only arises once salary payments begin.
• Freelancers and agencies: the simplest case. Invoices from external developers with a clear project reference are direct, audit-proof evidence. No hour estimation is needed here, just clean project allocation of the invoices.
• Mixed roles: a developer who also does support or sales is captured proportionally. The support and sales share is not capitalisable and belongs in the 'other' line of Template 1.
• No ticket tagging in place: if Jira or Linear is not labelled capitalisable versus non-capitalisable, the share can be estimated retrospectively from completed epics, or a label can be introduced going forward. For future periods, the label is the cleanest path.
• Documenting the point of no return: the reference date needs an artefact. A product decision in meeting minutes, a dated prototype demo, a budget approval by management. Without dateable evidence, the start of capitalisation is challengeable.
• Double use with the R&D tax credit: the same activity and cost documentation that supports capitalisation is often also the basis for the German R&D tax credit (Forschungszulage). Documenting cleanly once serves both purposes.
• Timing relative to the fiscal year: set up the process at the start of a fiscal year, not retroactively mid-year. A mid-year decision is possible, but retroactively gathering data for the months already past is considerably more effort and weaker evidence than clean capture from day one.

The most common reason capitalisation fails in practice is not the accounting; it's the missing routine. Reconstructing the activity structure retroactively at year-end close produces weak data and a lot of stress. Have the development team spend ten minutes per quarter on categorisation, and you have an audit-proof basis at year-end. Capitalisation is a process, not a year-end event.

What to do concretely before a funding round

1. 1Review documentation before the decision is made. Traceable cost allocation (project-based time tracking or documented allocation logic), a clear split of research versus development phase, a production cost calculation with direct costs and capitalisable overheads. Without a defensible, documented basis, capitalisation is vulnerable in due diligence.
2. 2Set a written capitalisation policy. Which project types qualify? Above what scope is capitalisation applied? What depreciation period applies? Setting these decisions before the first capitalisation prevents debate at every subsequent review and shows investors the treatment is systematic, not opportunistic.
3. 3Prepare investor communication in the data room. Explain capitalised own work proactively, rather than waiting for investors to ask. What is capitalised? Since when? On what documentation basis? What does adjusted EBIT look like? A clear memo on this point in the data room takes the question out of the negotiation.

The alternative: pro forma presentation in the info memo instead of capitalisation in the statutory accounts

Not every startup wants to or can carry out the capitalisation in its statutory annual accounts. Sometimes the round is too near-term, sometimes the effort of the commercial accounting change is not justified, sometimes the tax advisor resists. In these cases there is an alternative: show the effect of capitalisation as a pro forma calculation in the investor info memo, without touching the audited financial statements. The core question then is: what would EBIT and equity look like if we had capitalised under the HGB option? This presentation is permissible as long as it is clearly labelled as pro forma and cleanly reconciled.

This is worthwhile above all when historical EBIT figures appear distorted by high development costs, but the company never capitalised. Or when comparable companies, for instance IFRS-reporting or US companies, capitalise their development costs and the company's own EBIT looks visually worse than the peer group as a result. In PE processes and with strategic buyers who read balance sheet metrics closely, the pro forma bridge is more effective than with seed VCs, who focus on cash burn regardless.

Variant 1: EBITDA bridge (recommended)

The cleanest form is not a full pro forma income statement, but an explicit reconciliation from reported to adjusted earnings. It shows transparently which expense would have been capitalisable, without altering the statutory accounts:

The advantage of this form: professional investors already work with an adjusted cash EBITDA and either add back or strip out capitalised own work themselves. Providing the bridge yourself saves them the work and lets you control the narrative. It is important that the amount added back meets the same strict standard as genuine capitalisation: only actual development hours for new functionality after the point of no return, not the full development budget. A pro forma bridge that calculates too generously destroys more trust than it creates.

Variant 2: pro forma income statement in the info memo

More effortful but more structured is a full recalculation of the income statement for two to three prior years with capitalisation applied. This is only worthwhile if the underlying documentation is defensible, the investor group is highly balance-sheet literate, and the amounts are material enough to justify the effort. A pro forma income statement absolutely requires a methodology note disclosing how production costs were determined and hour shares were allocated. Without that note, it will not hold up in due diligence.

Variant 3: commentary in the pitch deck

The most informal form is an explanatory note in the financial section of the deck: EBIT margin would be X percent if development costs of EUR Y were capitalised under HGB, which will be adopted from the coming fiscal year. This is transparent, signals awareness of the balance sheet effect, and avoids the impression of hiding something. It does not replace a defensible reconciliation, though, once an investor digs deeper.

Common mistakes

• Research and development costs not separated: if project documentation does not distinguish between exploratory work and concrete implementation, the entire capitalised amount is at risk under review.
• Capitalisation started too early: costs incurred before technical feasibility was established cannot be capitalised retroactively. Many startups draw the line too early.
• Sales costs and calculated profit margins capitalised: these must not be included when valuing internally generated work. Only production costs are capitalisable.
• Deferred tax forgotten: the accounting EBIT effect of capitalisation is reduced by the deferred tax liability. Omitting this item results in incorrect accounting.
• Distribution restriction overlooked: founders who want to distribute a high profit are constrained by ongoing capitalisation. This implication should be discussed with the tax advisor before year-end close.
• Subsequent measurement neglected: an annual impairment test is mandatory. If a product is no longer developed further, becomes technologically obsolete, or the project is abandoned, an impairment write-down is due.
• Useful life chosen too optimistically: anyone depreciating custom-developed software over ten years must be able to justify it. For most software products, three to five years is realistic.