How to manage contract terms with staggered hardware deployments

Contract duration is a surprising challenge for Sales and Finance teams at hardware-as-a-service (HaaS) companies. The contract “term” becomes complex when different elements are billed at different times. This trips up Legal teams at hardware companies when structuring and drafting a HaaS contract, but usually not until after the contract is signed.

The simplest example: a down payment due on signing for devices, but software fees billed on deployment. When does the contract start?

Complexity explodes when a contract includes multiple assets with different deployment dates. For example, a single HaaS deal for four batches of equipment, with one batch installed each month January through April:

Each “batch” could be 1 large machine installed, could be 10 mobile assets deployed, could be 100 digital sensors activated, or any other combination of equipment. Many factors lead to “staggered” rollouts: supply chain delays, a custom build process, long deployments, varying burn-in periods, or simply multiple customer locations with different configurations.

With four different deployment dates, the simple question is even harder. When does the contract start?

Given the complexity of these scenarios, and the unpredictable nature of deployments, such start dates are often left ambiguous. This can put Sales teams in the awkward position of having to re-negotiate with the customer midway through the contract. So HaaS companies need clear answers and alignment from Finance and Legal up front. Are these four separate contract terms? Do all subscriptions start with the first deployment (January)? With the last deployment (April)? Is each one prorated?

Three ways to manage contract terms for staggered deployments

There are three ways for hardware subscription businesses to approach staggered deployments:

1. Treat each deployment as an individual term (repeat full terms so as to stagger billing terms of every deployment)
2. Co-term subscriptions such that terms renew at the time of the first deployment (shorten later terms by offering prorated discounts on later deployments)
3. Co-term subscriptions such that terms renew at the time of the last deployment (extend earlier terms with partial paid extensions on earlier deployments)

The question for device-as-a-service companies: Do you want to prioritize different billing periods for each set of assets? Do you want to align all your assets to the same billing period by prioritizing your first set of assets? Do you want to align all your assets to the same billing period by prioritizing your last set of assets?

1. Repeat full terms (“staggered billing”)

With a “staggered billing” approach, each deployment is treated individually and managed on a separate billing and accounting schedule. “Full terms” means that the term for each deployment is the same—in the case of a year-long contract, that term is 12 months. So renewal periods always overlap for staggered terms:

Repeated terms is the most straightforward to implement from a billing standpoint. But it creates the most overhead billing work for the company, which has to manage each term independently. It is also the least convenient for the customer, which has to receive regular invoices for every single deployment. Separate terms also create more ongoing accounting work because there are multiple revenue and cost schedules to track for each contract.

This approach is the most common for companies starting out, partly because it’s the “accidental” approach that many companies adopt when another co-terming approach is not specified in the contract. So the biggest advantage of this approach is that it’s “easy”—if an equipment company neglects to think about multiple terms, it can fall back to staggered billing.

The biggest drawback with repeating full terms comes at the end of a contract. Customers want to know the end date of the contract, whether for renewal, for budgeting, or even to switch vendors. But there is no “end” of the contract in this model! With repeat full terms, there are multiple different contract periods, running concurrently with different end dates. This leads to confusion and frustration, straining customer relationships.

2. Shorten later terms ("prorated discounts")

With a “prorated discounts” approach, the first deployment is treated as the definitive initial term, and each subsequent deployment is prorated to match that term. All deployments share a common end date, which is calculated based on the first deployment.

When the initial asset renews, all deployments are billed and accounted for together. As such, later deployments have successively shorter terms. In the above example of four one-year deployments, one per month—every other deployment renews with the January deployment (12 months), the February deployment gets ~11 months, the March deployment gets ~10 months, and the April deployment gets ~9 months. Thus all four deployments renew at the time that the first deployment renews:

Shortening later terms delivers the most straightforward customer experience. It’s more complex from a billing standpoint, because every new deployment has to be prorated and co-termed. And the partial terms create additional accounting complexity in year 1. But it’s much simpler to manage down the road, since the co-terming only needs to occur in the first year.

This approach is the most common method of dealing with contract terms for more sophisticated billing operations. It also works automatically for any number of deployments, over any time period, including any contract changes over time. For example, if the last deployment takes 14 months to deploy, it can be rolled directly into the renewal term of the first deployment. Or if, in month 14, the customer decides to buy an extra subscription for a new batch of machines, that subscription can be rolled right into the initial contract with a prorated discount.

By a small margin, shortened later terms generally trade off a slightly smaller total contract value (TCV) in exchange for collecting some cash earlier. The tradeoff depends on how staggered the deployments become.

3. Extend earlier terms ("paid extensions")

The “paid extensions” approach is essentially the opposite of prorated discounts—the last deployment is treated as the definitive term, and prior deployments are extended to match that term.

When the final deployment renews, all deployments are billed and accounted for together. In order for this to happen, the terms of each earlier deployment must be extended.  In the above example of four one-year deployments, one per month—the term for the January deployment is ~15 months, the February deployment is ~14 months, the March deployment is ~13 months, and every batch renews along with the April deployment (12 months).  Thus all four deployments renew at the time that the last deployment renews:

Extending earlier terms does deliver a straightforward customer experience, but not all customers expect it because it’s the least common approach. From a billing standpoint, this is the most complex approach, because a credit balance has to be carried through to the renewal. And as with shortened later terms, it creates accounting complexity in year 1, usually because unbilled revenues have to be accrued.  But this approach is similarly simpler to manage down the road.

By a small margin, extended earlier terms generally trade off a slightly larger total contract value (TCV) in exchange for collecting some cash later. The tradeoff depends on how staggered the deployments become.

Steps to co-term HaaS agreements

Sales and Finance teams at companies offering managed services programs must take these steps any time they have a contract that includes staggered deployments:

1. Choose your start date: Does the contract start at signing? At shipment? At delivery? At deployment? After a systems acceptance test? Initially assets have their own start date. But HaaS vendors must be consistent about what triggers the start date across deployments.
2. Confirm the co-term approach specified in the contract:
   • If repeating full terms, each deployment will have different start and end dates
   • If shortening later terms, the common end date will be the end date of your first deployment
   • If extending earlier terms, the common end date will be the end date of your last deployment
3. Take the start dates of every deployment and apply the co-term approach to determine each deployment end date.

Best practice for HaaS: shorten later terms

HaaS companies should generally shorten later terms. This is the best approach for customers in all cases. It also has the advantage of manageable billing and accounting complexity (especially after the first year), and overall is the lowest-effort method of handling multiple deployments on a single contract.

Repeated full terms is an understandable default for new hardware-as-a-service models (it’s the most basic approach). But it’s ultimately problematic, as vendors end up with multiple concurrent terms running on a single contract. Billing complexity is low, but the overhead is high. It also creates more complexity and overhead for the customer.

Extending earlier terms also means less complexity for the customer. But both billing and accounting complexity for this approach are high. Small tradeoffs in TCV and cashflow do not typically merit using this approach unless it is requested specifically by a customer.

Software solutions for HaaS contracts

Without automated software in place, HaaS Finance teams have two choices. First and most common is to manage individual terms forever so nothing is missed, which creates ongoing overhead for every contract based on the number of deployments involved.  Second is managing proration manually for every deployment on every contract, which introduces manual calculations and creates a major risk factor for accounts receivable (A/R).

Finance teams that shorten later terms benefit greatly from software to automate billing and A/R. Those that opt to extend earlier terms need software to support it.  Hardfin analysis shows that 2% of top-line revenue is never even billed because of clerical errors when HaaS companies manually. As if finance leaders at HaaS companies didn’t have enough to worry about!

Deployments aren't simple. Unfortunately, that means billing isn’t simple, payments aren't simple, and accounting isn’t simple. These complexities call for software designed for the job. Hardfin is the first platform purpose-built to help modern hardware companies manage financial operations.

As HaaS business models evolve, software is evolving to support it. Modern hardware companies use Hardfin to manage, operate, and report on financial operations.