Skip to content

Implementation fee

An implementation fee covers the one-off work of getting a customer operating: configuration, integration, data setup and the initial enablement. It is separate from recurring access because it is finite work with a defined scope, and keeping it separate is what stops it being counted as recurring revenue.

Implementation is fixed scope and fixed price, kept separate from recurring revenue, and should shrink as the work is productised.

Why it matters when the plan changes

Blending setup work into a subscription overstates recurring revenue and hides whether the product is getting easier to deploy. Keeping it separate makes the number visible, and a visible implementation cost that does not fall over time is evidence that the work is not being productised. A statement of work exists precisely to fix the scope of a defined piece of work, which is what an implementation charge requires if it is to remain outside recurring revenue rather than drift into it.

The tension is commercial. Customers dislike a separate fee and suppliers dislike the margin pressure of absorbing it, so both are tempted to bundle. Bundling makes the deal easier and the business harder to read, because nobody can then tell how much of the recurring line is actually recurring, and how much is one-off work dressed up as a subscription line. Onboarding covers matters such as role clarity for new users, work that is genuinely finite and should be reported as such.

In practice

A second division joins an existing agreement. The covered population and licences expand, and only the new implementation work is charged. The setup already done for the first division is not billed again, because the scope was defined per person and per unit rather than per contract event.

Evidence

What it cannot tell you

An implementation fee describes one-off setup cost, not the quality of the deployment itself. A low or shrinking fee does not confirm the product works well once configured, and a high fee does not confirm poor productisation. It is silent on whether the underlying software delivers value after setup is complete.

Questions

Implementation covers configuration, integration, data setup, access provisioning and initial enablement, defined the way a statement of work defines scope and deliverables, per the Wikipedia entry on statement of work (2026). It is finite work with an effort allowance, not an open-ended workstream billed as it runs.

Because blending it overstates recurring revenue and hides whether deployment is getting cheaper. Reporting it separately makes the implementation cost visible over time, and a cost that does not fall is fairly direct evidence that the work has not been productised.

Only for the new scope. Adding a division means implementation for that division, not a second charge for work already done. Charging twice for the same person and scope is the most common way an expansion becomes a negotiation rather than a routine addition.

Absorbing it makes the deal easier and the margin worse, and removes the discipline of defining scope. Onboarding, per the Wikipedia entry dated 2026, covers matters such as role clarity for new users, work genuinely worth pricing. A defined fee with a defined scope serves both sides better than pretending the work costs nothing.

Downward, as the work becomes more standardised and more of it is productised. That trend is the reason to report it separately, since it is the clearest available measure of whether deployment is genuinely getting easier or simply being absorbed.