Software

We have delivered projects for several dozen software companies, with consultants who have worked in the industry for many years. We are just as much at home where software is sold with hardware, and stock, shipping and returns join the subscription.

We deliver complete operations platforms as well as best-of-breed systems, and we have integrated them with each other many times. We work with Salesforce, HubSpot, Chargebee, NetSuite, Odoo, PayPal and Checkout.com, among others.

Our recommendation is a platform: NetSuite or Odoo, depending on your global footprint and your service model. For a European footprint we increasingly recommend Odoo, because NetSuite, born in the US, falls further behind on European localisation. In Europe it keeps its place in finance-only projects, in software and in eCommerce. We also recommend it wherever contracts need revenue allocated by standalone selling price, which NetSuite calls fair value.

What we deliver along the software value chain

We set up each step of the software value chain and connect the steps that share data:

1. Development project accounting: hours and overhead by deliverable, with the directly attributable cost split into what is capitalised and what is expensed
2. Pricing: price lists, plans, bundles, discounts and price increases at renewal
3. Sales channels: direct sales, resellers and distributors, with partner prices, margins and commissions
4. Subscription billing: renewals, upgrades, aligned end dates, proration and usage
5. Payments: cards and wallets, refunds, disputes and chargebacks, matched to open invoices and provider fees
6. Revenue recognition: under each framework you report under, whether IFRS 15, ASC 606, Swiss GAAP FER or the Swiss Code of Obligations

Where software ships with hardware, the chain grows: stock, serial numbers, shipping and returns join the contract, and revenue has to be split between the device and the subscription.

Development, run as a project business

We set up software development the way engineering firms and consultancies run their projects: every deliverable has a budget, and every hour and every share of overhead is booked to one.

Your largest cost is the time your developers spend on the product. In our experience, software companies have yet to manage and account for that time the way engineering and consulting firms do. We bring the controls those firms use: hours at cost, a budget per deliverable and a monthly forecast to finish.

Our approach is project-centric. We tie your development method, Scrum or another agile method, to measurable deliverables, the epics in that language. Then we track time and overhead expenses against each one:

• Each epic is a project with a budget of its own; a small epic can be a parent task, which carries hours and their cost but no budget or overhead share of its own
• Developers book their hours to the epic's tasks, costed at each employee's hourly cost
• Overhead expenses, such as tools, licences and office space, reach each epic at a rate we agree with you
• Overhead counts in the epic's cost, but only directly attributable cost is capitalised (IAS 38.67), and rent stays out of the figures for an IP box
• Every month, the cost of each epic against its budget, and the remaining hours at cost

With enough of that data you can track efficiency, see what each deliverable is expected to earn, and allocate and reallocate people faster. With agentic AI and in the age of disposable software, that speed has become crucial.

Neither Odoo nor NetSuite has a record of its own for sprints or epics, so we map each epic to a project. Where your teams plan in Jira, we deliver the integration with a partner's connector, so epics and hours reach the ERP.

In Odoo, projects, tasks, milestones, timesheets and project profitability are in Community, and budgets need Enterprise. Overhead reaches a project through an analytic distribution at a fixed percentage. NetSuite sets cost budgets per project task and month, and moves overhead to projects with allocation schedules. In both systems the overhead share sits on the project, not on a task.

Software IP is an asset the CFO manages

We set up the books so that software IP is managed like any other asset: cost per product, legal entity and year, from the first timesheet.

A real-estate CFO carries buildings under construction and decides which company holds them, for value and tax. A software CFO does the same with code. Software under development is the CFO's work in progress: it collects cost before it earns anything.

Under IFRS, development cost becomes part of an intangible asset only from the date all six criteria of IAS 38.57 are met; before that it is an expense. Until the software is available for use, the asset is tested for impairment every year (IAS 36.10). Amortisation starts when it is available for use, in the same words IAS 16 uses for buildings and equipment (IAS 38.97, IAS 16.55).

The difference: an investment property may be shown at fair value (IAS 40), while software in practice stays at cost (IAS 38.75). Its value shows in tax, and in the prices group companies charge each other for it. Whether development becomes an asset depends on the framework:

Every row of that table depends on the same records: hours by development project, kept apart from research, maintenance and customer work, and costed at the right rate. They must be right by the period close, because an amount once expensed cannot be capitalised later (IAS 38.71).

Where the IP sits, and what the ERP must cover

We set up the ERP for the countries you grow into, so that the CFO has the figures to decide, with the tax advisers, where the IP sits. The return follows the company that does and controls the development, not the one that only holds the rights (OECD Transfer Pricing Guidelines 6.42, 6.56). The books must therefore show where that work is done.

Several countries reduce the tax on profit from software, where the conditions are met:

Germany and Austria reward research and development itself, where the work qualifies. The Forschungszulage grants 25 % of eligible R&D wages (2026), more for small and medium-sized companies. The Forschungsprämie grants 14 % of qualifying R&D spend and needs an annual opinion of the FFG.

These IP boxes follow the OECD nexus rule: the benefit follows the share of qualifying spend in total development spend, measured per IP asset, product or product family. Under the OECD standard, development bought from related companies and acquired IP do not count as qualifying spend; Switzerland also counts R&D done by Swiss group companies. For groups with consolidated revenue of EUR 750 million or more in at least two of the four preceding years, the global minimum tax tops up the effective rate in a country to 15 % where it falls below.

That makes it an ERP question as well as a tax question. The ERP has to cover each region: the local books and tax of each entity, and group reporting under IFRS, US GAAP or Swiss GAAP FER. It also has to carry licence fees between group companies, with the withholding tax of each route, and development cost per IP asset, kept for years.

Contracts, subscriptions and usage, as you sell them

We set up billing for the contracts you actually sell. First we decide with you where the contract lives: in the ERP, in a CRM such as Salesforce or HubSpot, or in a billing system such as Chargebee. The other systems then read it from there.

Contract shapes vary, and many companies sell more than one:

• Subscriptions bought online and paid by card, monthly or yearly
• Subscriptions with a start date, a term, a billing period and a renewal rule
• One-off items such as licences, set-up fees and training days
• Implementation work at a fixed price, by milestone or on time and materials
• Usage priced per transaction, per API call or per active user

For each shape we set the rules for changes: whether added users are billed at once or at renewal, how a second contract is aligned to the first end date, and what a cancellation does.

Usage is measured in your product. We agree with you how the quantities reach the invoice, by import or by interface, and who checks them before it goes out.

Monthly and annual recurring revenue (MRR and ARR), churn and expansion then come from the contract records and reconcile to the ledger, instead of a spreadsheet that is rebuilt every month.

Revenue recognition depends on what you sold and where you report

We set up revenue recognition per legal entity and framework. On NetSuite with Advanced Revenue Management, the revenue schedule follows the contract's performance obligations. On Odoo, it follows each invoice line, which is enough where every line is invoiced in advance with its own price and period. What each framework requires:

A Swiss subsidiary often reports under OR or Swiss GAAP FER while the group reports under IFRS, or under US GAAP. There ASC 606 applies, the counterpart of IFRS 15, issued together with it in May 2014. The system then has to keep both views of the same contract.

Where contracts need an allocation by standalone selling price, which NetSuite calls fair value, we set it up in NetSuite with Advanced Revenue Management and its Revenue Allocation add-on. Odoo's standard product does not reallocate between invoice lines; partner apps for Odoo 19 add the allocation on contract records of their own.

Implementation projects and support

Where you sell implementation, integration, training or support, we set them up as projects with budgets, milestones and hours, on the same timesheets your developers use for the product. Each hour then lands on a customer project or on a development epic, never on both.

• Fixed-price, milestone and time-and-materials billing from the same timesheets
• Project margin with actual hours at cost, not at list price
• A helpdesk with service levels tied to the customer's contract
• Renewal and upsell opportunities that reach sales from the support history

A platform first, specialist systems where they earn their place

We set up a platform first, because the links matter. The contract and its invoices set the revenue schedule, the timesheet sets project margin, cost per epic and capitalised development, and support feeds the renewal. Split across systems that are not connected, each link becomes an export.

A specialist system still earns its place where it does one job better, and many software companies should keep the ones they run. We decide with you which system owns which record, and connect them so that you still get:

• One contract record shared by sales, billing, finance and support
• A revenue schedule per contract line, released under the rules of each framework you report under
• Recurring revenue figures that reconcile to the ledger
• Development hours that can be capitalised without a separate spreadsheet
• Cost per epic and per IP asset, for each legal entity

How we test it in an evaluation

In our evaluations, each shortlisted system has to run one of your contracts and one of your epics from end to end, with your data. Every vendor can show a recurring invoice; what matters is what happens when something changes:

1. One of your contracts, as you sell it
2. An upgrade in the fifth month and a renewal at a new price
3. A month of usage imported and invoiced
4. A period close with deferred revenue in each set of books you report, and the recurring revenue figures reconciled to it
5. A month of development hours and overhead on two epics, with the directly attributable cost split into what is capitalised and what is expensed
6. A licence fee charged between two group companies in different currencies

Not slides. Transactions.