Frequently asked questions
BOM payback period (BPP) is a critical metric for hardware-as-a-service businesses to understand. It’s the number of months before recurring payments cover the upfront cost in your bill of materials.
Legacy hardware companies don’t have to worry about it because they sell assets. The concern is immediate margins.
SaaS companies don’t understand it. There’s no upfront investment beyond customer acquisition cost! The concern is LTV:CAC.
But for a HaaS program, BPP is crucial to understand for scalability and must be closely monitored.
So what is a good BPP? Hardfin typically sees 6-24 months as reasonable:
- 🥇 Excellent: 6-12 months
- 👍 Solid: 12-18 months
- 👌 Okay: 18-24 months
- 😳 Challenging: 24+ months
Best-in-class BPP would be 6-12 months for a solution with low-cost hardware, a strong software layer, and a complementary service package. We often see 12-18 month BPP for proprietary HaaS models that are working well. Companies with an 18-24 month BPP can make it work, but margins will suffer.
In all those ranges, HaaS companies can float the cost with balance sheet, and debt is accessible. Beyond 24 months, it’s difficult to get financing and tough to make the interest math work.
Of course there are exceptions, such as long-term contracts with major counterparties like the government. But the above are guidelines for well-designed pricing bundles.
Bundle and pricing hardware-as-a-service programs is complicated. Hardfin reviews lots of HaaS company pricing programs to develop a strong understanding of how pricing is balanced across the market.
Depending on the cost of hardware being subscribed, here are the B2B trends:
🖲️ $100 sensor 🖲️
→ Package is 10x cost ($1,000)
→ Software is $900 (~90% of package)
💻 $1,000 electronics 💻
→ Package is 5x cost ($5,000)
→ Software is $4,000 (~80% of package)
🦾 $10,000 machine 🦾
→ Package is 4x cost ($40,000)
→ Software is $30,000 (~75% of package)
🤖 $100,000 automated robot 🤖
→ Package is 3x cost ($300,000)
→ Software is $200,000 (~67% of package)
🛻 $500,000 truck 🛻
→ Package is 2x cost ($1,000,000)
→ Software is $500,000 (~50% of package)
🖨️ $1,000,000 3D printing system 🖨️
→ Package is 1.25x cost ($1,250,000)
→ Software is $250,000 (~20% of package)
This is a simplification—there are often other charges such as installation, shipping, maintenance, and accessories. But the hardware/software breakdown is fairly consistent in high-performing HaaS companies.
Businesses such as additive manufacturing drive meaningful revenue from consumables. Companies providing infrastructure (e.g., water, electrical, internet) may have a slightly different profile.
Margins on hardware-as-a-service (HaaS) depend in large part on the breakdown of components in the solution.
The trends we’re seeing at Hardfin for B2B HaaS in 2023 suggest that a 65-75% blended gross margin (GM) is a good target for most HaaS businesses.
The bulk of the solution will be in two core components:
- 🚜 Hardware: 40-60% GM 🚜
- 📀 Software: 85-95% GM 📀
A few components usually have very slim margins:
- 🔋 Accessories: 0-20% GM 🔋
- 🧩 Installation: 0-20% GM 🧩
- 🚚 Shipping: 0-20% GM 🚚
Three optional components have margins that vary widely:
- 🛠️ Maintenance and repair: 30-70% GM 🛠️ (depending on overhead)
- 📃 Warranty and service plans: 40-80% GM 📃 (depending on reliability)
- 🖨️ Consumables: 10-90% GM 🖨️ (depending on proprietary media)
It is critical for HaaS companies to define an explicit threshold for when a contract has started.
Some contracts specify an “installation” or “deployment” date based on activity such as setting up a machine. The clearest contracts specify a system acceptance test (SAT) based on defined criteria such as performance thresholds. Yet other contracts specify an abstract “mutual” agreement between provider and customer. The most ambiguous contracts don’t specify anything at all!
Subscription billing cannot start (and revenue cannot be recognized) until this threshold is met. Hardware subscriptions can be held up for weeks or months based on the customer—perhaps an approval hasn’t been granted, the production line hasn’t started, or a key stakeholder hasn’t signed into the software platform.
- 💰 For sales teams, this means ambiguity about commission. 💰
- 🤝 For support teams, this means ambiguity about customer expectations. 🤝
- 📈 For finance teams, this means ambiguity about contract term and revenue recognition. 📈
One clear lesson for HaaS: ALL contracts should specify a “drop-dead date.”
A simple example: the term will commence no later than 30 days after equipment installation. These are often called “deemed acceptance” provisions.
Such provisions ensure mutual understanding about the manufacturer meeting their performance obligations on the contract. And they ensure there’s no internal debate between sales, support, and finance about when a contract has “started.”
Most companies don’t have good enough data to track the most important metric in hardware-as-a-service (HaaS) billing. That metric is called "average days to send" (ADS).
⏳ ADS is how many days it takes a company to send invoices. More technically, this is days between (a) the earliest date a line item could have been invoiced and (b) the date the line item is actually invoiced.
🤯 The surprising part? For HaaS companies, ADS can be longer than your payment terms! Companies are busy fighting tooth and nail with customers to reduce receivables from 45 to 44 days. Meanwhile, their own operations are driving a 60 day process to get invoices out the door!
⏱️ Does this sound familiar? Asset ships on Jan 1, shipping could be billed immediately. On Jan 15 the Shipping team updates a spreadsheet. On Feb 3 Finance emails for the report, which is sent Feb 10. AR processes it on Feb 20. Over the next week, contracts are checked and invoices prepared for release Mar 1. ADS was 60 days!
A customer might have net 30 terms and pay on time, but it takes twice that long to send the invoice...
Is it possible to get ADS to 0? It is with software —connect assets to billing natively, so invoices can be sent as soon as possible.
Hardware-as-a-service (HaaS) companies often seek options to help pull cash forward on a new leasing program.
HaaS companies face a lot of pressure to accelerate cash payments. Much more than a SaaS company, a HaaS business needs to front the bill of materials (BOM) as part of the fully-loaded cost of goods (COGS) for their assets.
Aside from BOM lending programs, there are a few common ways that HaaS companies structure contracts and pricing to help pull cash earlier:
🗓️ Annual payments (or quarterly payments)
⬅️ Prepayment for some period (usually 6-12 months of multi-year contract)
💰 “Standard” prepaid items (installation fees and shipping charges)
🛠️ “Optional” prepaid items (usually a service plan or warranty program)
Defining a “contract period” for software-as-a-service (SaaS) is easy. For hardware-as-a-service (HaaS) business, it’s much more complex.
🎬 Start dates themselves are often unclear. Is it when hardware ships? Arrives and is functional? Passes a system acceptance test (SAT)? It’s important for HaaS businesses to define this event precisely.
🔚 And what about end dates? If it’s a 24 month contract, end date may fluctuate with the start date. Or was a specific date set on contract signing, so that a 2 month shipping delay means you have a 22 month contract? HaaS companies should be clear internally about contract duration.
🎰 The WILD card here is a multi-deployment contract. When companies get a PO for multiple machines — what is the start date? When device 1 goes active? Unit 100? Do you create and track many separate contract terms, each spaced by days or weeks? HaaS companies should consider co-terming the contracts.
Contract duration is a surprisingly challenging question for hardware-as-a-service (HaaS) companies. How can a HaaS company “co-term” subscriptions?
Companies can manage a simple “term” even if contract elements are billed at different times. For example: a down payment on contract signing, with a software fee that starts at deployment. Does the subscription start at signing or deployment? Just pick one!
Things get more complicated when a contract includes multiple assets or deployments. For example: 4 robots on a single HaaS deal — each month, 1 robot is installed. Is this 4 separate contract terms? Do all the subscriptions start on the first month?? Or the last month?! Are they prorated?!?
Companies manage this 3 ways…
1️⃣ Individual terms (no co-term) 1️⃣
EACH deployment is treated separately and managed on a separate billing and accounting schedule. This is easiest to implement from a billing standpoint, but least convenient for the customer. It also creates more downstream accounting work because there are 4 schedules to track. This is the most common approach for companies starting out.
⬅️ Co-term to the beginning ⬅️
The FIRST deployment is treated as the definitive initial term, and each subsequent deployment is pro-rated to match that term. When the initial term renews, all deployments are billed and accounted for together. This delivers the most straightforward customer experience. It is more complex from a billing standpoint, because every new deployment has to be co-termed. And it creates accounting complexity in year 1, but is simpler to manage down the road. This is the most common approach for more sophisticated billing operations.
➡️ Co-term to the end ➡️
The LAST deployment is treated as the definitive term, and the prior deployments are pro-rated to match that term. When the definitive term renews, all deployments are billed and accounted for together. This delivers a straightforward customer experience, although not all customers expect it. It is the most complex from a billing standpoint, because a credit balance has to be carried through to the renewal. So it also creates accounting complexity in year 1, but is simpler to manage down the road. This creates the best cashflow, but is unusual because of its complexity.
Of course, such complexities can be mitigated with software designed for the job! Hardfin is the billing and accounting platform for HaaS. So you can focus on your HaaS business and let our software handle the messy quirks.
