Making sense of start dates in hardware-as-a-service (HaaS) contracts

It’s essential for companies with hardware-as-a-service (HaaS) business models to define an explicit start date in customer contracts. This sounds simple—and it can be—but problems frequently arise from contracts that are not well defined.

Defining a HaaS contract start date is necessary, but surprisingly complex

One strange thing about HaaS and hardware subscriptions: it’s not always obvious when a HaaS contract starts. It’s unintuitive that a HaaS subscription doesn’t just “start” like SaaS. This causes problems for HaaS companies and their customers. Sales teams often draft ambiguous customer contracts—without start dates, with multiple start dates, or with unclear start dates.

A contractual start date is simple in theory: a contractual definition that is clear to everyone—Sales, Finance, Accounting, Legal, Buyer, Sponsor, and their Accounts Payable team—when payments should start. Without a clear start date, here are typical responses about whether the contract has begun:

• Sales says “yes” because the contract date has passed
• Inventory says “yes” because the hardware has shipped
• Deployment says “no” because the solution hasn’t finished installation
• Service says “no” because the cloud software hasn’t been turned on yet

This puts Finance in a precarious position! Two departments say the contract has started, and two departments say that it hasn’t. Should the Finance team invoice the customer? This compounds the broader complexity around timing in hardware-as-a-service contracts.

Unfortunately such a lack of clarity is common. The negative implications can culminate in invoicing problems, payment delays, and even non-payment. It also creates internal friction between teams—usually Sales, Finance, Support/Success, Accounting, and Legal—leading to misalignment, confusion, mistakes, or worse.

Five common options for contractual start dates

Hardfin typically sees five different milestones used in equipment-as-a-service contracts. Billing may occur at one or more of these milestones, including being split across milestones. Milestone billing is separate from determining the contract start date, but each of these dates can be used as an explicit rule for contract start.

The typical HaaS contract milestones are:

Contractual start dates in practice for hardware businesses

Here's how this might work in a real-world deployment:

• A HaaS company ships equipment to a customer. If the hardware is a simple widget that plugs into the wall, it might make sense for an equipment-as-a-service contract to start at shipping. But if the hardware is a $1 million 3D printer shipped in multiple truckloads, it doesn’t make sense for the contract to start at shipping—the components might take six weeks to arrive.
• The asset is delivered. If the customer can set up the hardware themselves within 24 hours, the contract can start on delivery. But if the HaaS company has to fly two people out to configure the system and train the customer—which might take another two weeks—it doesn’t make sense for the asset-as-a-service contract to start at delivery.
• The machine is turned on. If the system starts delivering value immediately, it makes sense for the contract to begin when the machine is turned on. But often, for example, there’s a burn-in period in which that machine has to get dialed-in. In that case, the machine should pass a precision test before the machine-as-service contract can start.
• A device meets certain criteria. If there are clear criteria that the device meets to provide value, such as a product velocity or utilization rate, then it makes sense to start the contract after a system acceptance test (SAT). If criteria are too difficult to define or metrics are too hard to ascertain, it doesn’t make sense to start a device-as-a-service contract based on SAT.

Considerations for different date options for HaaS

There are pros and cons of using each of these contract milestones for contract start:

For HaaS teams, the point is to get super clear on what constitutes the “start” of a contract. For example: “The asset will be designated, shipped, delivered, and turned on. And the minute the data starts flowing, the contract has started.”

The importance of a drop-dead date (“deemed acceptance” provision)

Every HaaS contract should include a drop-dead date alongside a contractual start date. A drop-dead date might look like: “The system acceptance test is the final sign-off, but in no case will the contract start later than 30 days after deployment” or “the term will commence no later than 30 days after equipment installation.”

Why? One challenge HaaS companies face is deploying the solution and having a lack of clarity or agreement about customer utilization—understanding customer usage at all, whether usage is to the extent initially expected, or whether customer results are as initially expected. Passing an SAT is an ideal measure of this, but it can add extra work for both sides. And end users are often not excited to respond to a Success team asking for SAT data. So for a number of reasons, hardware companies may be held hostage for contract start!

This happens more often than it should, and it creates real problems for hardware companies. At some point, Finance needs to invoice the customer and Accounting needs to start dealing with the revenue and cost implications of the contract. Small customer issues end up taking a disproportionate amount of energy and effort, which should instead be spent serving the rest of the customer base.

A drop-dead date is an important mitigation technique to ensure that—even if customers have problems—there are no downstream operational implications as far as contract interpretation.

The cross-functional benefits of a contractual start date

There are many cross-functional benefits to a clear start for a hardware-as-a-service contract:

• Sales teams have a clear understanding of when they can expect to see their commissions, and can avoid tense disagreements about compensation
• Success/Support teams have clarity about customer expectations and how and when to follow up with customers, and can avoid awkward customer encounters
• Finance teams are clear about exactly when invoices can go out, and can avoid embarrassing misunderstandings about billing
• Accounting teams are clear about when to start recognizing revenue, and can avoid costly restatements and audit headaches
• Legal teams are able to mitigate risk, and can avoid redlining every deal as a one-off negotiation

Establishing a contractual start date for HaaS

The steps to defining a start date for a hardware-as-a-service contract are simple:

1. Identify the optimal start date with your team based on your business model (see the considerations above)
2. Implement the start date universally (sales, implementation, success, finance, accounting, legal)
3. Include deemed acceptance language (small step with important implications)
4. Train each team on the standard definition (and how to communicate about it with customers)

The first step of identification gives you the default that should become common knowledge, so every department in your organization can understand what a standard contract looks like. Rally around that default. Depending on the size of your team, the last step of training might be the most complicated. It’s important that the entire organization is aware of your contractual start. Your Sales team has to speak about it the same way your Success team does.

That said, your default rule—which should be in your standard contract and used as often as possible—might occasionally have an exception. If a large prospect insists on different treatment, Sales should get buy-in from Finance and Legal, and Success must be notified of a nonstandard contract. Outline and understand the communications process for exceptions.

But even in the case of an exception, the four steps above should be the same for the outlier contract: choose one start date (maybe with that big account it’s “SAT” instead of “deployment”). Communicate it clearly to your customer in the contract. Include a drop-dead date. And educate your team.

How Hardfin can help

At Hardfin, we talk HaaS teams through a lot of different problems that arise from murky contractual start dates. The Hardfin platform makes it simple to define clear start dates for your contracts, and to execute the necessary billing and accounting rules related to those dates. We partner with businesses looking to run best-in-class hardware financial operations and support them with a best-in-class platform to do so.

Want to learn more about how a unified platform can ensure consistency across your business, and let you take charge of your hardware financial operations? Speak with an expert—we’d love to chat with you.

As HaaS business models evolve, technology is evolving to support it. That’s where Hardfin comes in: manage, operate, and report on your hardware, regardless of the complexity of your business model.