Finance as a Stakeholder in Product Management

By Stephen Konig April 19, 2011

Don’t confuse Finance with financial data; product managers are used to dealing with market size, penetration, unit volumes, market share and sales. But this is mostly expressed in terms of units sold, bookings and forecasts, not in accounting or financial earnings terms. One of the challenges with Finance is reported financial earnings, especially if your company is public. And unfortunately the discrepancy between sales bookings and reported financial earnings can be significant, especially under specific circumstances. As a product manager you should really be aware of these when the CFO knocks on your door (or cube) and starts talking about software revenue recognition.

The rules for software revenue recognition are varied and complex (for details, read the American Institute for Certified Public Accountants’ Statement of Position 97-2). There are times when decisions about the product can have a direct effect on how it gets treated from an accounting perspective. And there are times when product features, sales approaches and purchasing models impact Finance, such as when a product

  • is new and trying to satisfy “early adopters”
  • requires a lot of post-sale professional services
  • is sold under a software-as-a-service model (SaaS)

What is revenue recognition and why should I care?

Usually when measuring a product’s performance we’re focused on sales—i.e. how many units or copies were sold or shipped, what was the average price, the length of the sales cycle, the win rate, etc. Often ignored is how those sales got treated from an accounting perspective. If the company incurs a future obligation under the terms of the sales contract, some or all of the contract value may be recorded as deferred revenue (a kind of liability like debt) instead of revenue or income. Imagine if every sale of a product caused the company to look like it was taking on more and more debt… if it stayed that way you’d quickly go out of business. Revenue recognition is the set of accounting policies and rules under which Finance determines whether your sale will be classified as revenue versus deferred revenue, and when that deferred revenue can be re-classified as real revenue or income.

Let’s say my business is selling pencils, and each pencil sells for 5 cents. On Thursday a customer buys 10,000 pencils. I take $500 cash from the customer, hand him the pencils, and $500 of revenue goes onto my books. Simple and easy. In this world my total sales of pencils in the quarter will always be the same as my reported revenue or income from pencil sales.

On the other hand, suppose I don’t actually have the pencils I’m selling; maybe I sell custom pencils (for example, with the customer’s name and logo). On the very last day of the quarter I get an order for 10,000 custom pencils. My policy is to get the cash up front, so the customer pays me $500, but I still have to make and deliver those pencils. This takes a few days, and won’t actually happen until a day or two after the start of the next quarter. In this scenario, the accounting rules say I need to consider that $500 cash a liability, not revenue, because I still owe the customer something. I can’t really say that I’ve earned $500 until I fulfill my end of the bargain, which is to make and deliver those custom pencils. If for some reason I weren’t able to deliver those pencils (maybe I decide to go out of the pencil business, or my pencil machine breaks and I can’t deliver them by the time I’d promised), I’d have to return that $500 to the customer. This liability is deferred revenue—it represents money we think we’re going to earn, but haven’t earned yet. Continuing with this example, my financial results for the quarter would show no revenue or income from pencil sales, but would show that my deferred revenue increased by $500. Let’s say I do deliver those pencils a few days later: I can now say I’ve legitimately earned the $500. On my financial statement for the next quarter I could fairly claim $500 of revenue or income, and reduce deferred revenue by the same $500. If I were just reporting on sales in the quarter, none of this matters—in both cases I could say I made $500 in pencil sales. But from an accounting perspective, these two scenarios are quite different.        

The problem in many software sales is a customer doesn’t always immediately get what they purchased. It can take a long time for a product to be implemented or customized or configured… and until the customer gets all of what’s paid for, the company may not be able to report the full value of the sale as revenue. While this is usually just temporary—the money will eventually be recognized as revenue as future commitments are honored, deliverables are delivered and obligations fulfilled—the longer it takes, the larger the discrepancy between the product’s internal performance (contracts signed, cash received from the customer) and its reported financial performance. Indeed it is possible for a dichotomy to emerge: internally the product can be performing well (sales volumes and bookings are high and cash is coming in the door), while externally it appears as though the product is not earning any or even losing money (since the costs associated with delivering the product—like salaries—are being paid now, even though you aren’t earning any revenue with which to offset those costs). The longer the period of time between a sale and the reported revenue, the greater will be the disparity between the product’s internal performance and its reported financial results. The greater the share of your company’s overall performance is attributable to the product, the greater will be the impact for Finance. If the company is publicly traded or preparing a public offering, this takes on increased significance, since shareholders and financial analysts are often unable to review internal sales metrics… all they see is reported financial earnings. Consequently they may have an incomplete and comparatively negative understanding of the product’s performance.

While there are many circumstances that can lead to a product’s sales being booked as deferred revenue, in this context understand these three: (1) when making a promise to deliver new functionality in a future release; (2) when the product requires significant post-sale services; and (3) under a software-as-a-service (SaaS) delivery model (see the table below).

Revenue recognition issues encountered in software sales

Scenario

Revenue Recognition Issues

Mitigation

Promising future functionality

Future functionality is treated as an “undelivered element” of the contract that results in all contract revenue being deferred until all future functionality has been delivered or until the customer has accepted the new features

  1. Avoid if possible
  2. Ensure future functionality commitments are tightly and carefully worded
  3. Seek favorable acceptance criteria from the customer

Product includes significant and lengthy post-sale services

If the services are necessary to use the product, software revenue is recognized over the term of the services engagement

  1. Augment the software with features that reduce the services effort
  2. Enhance the offering to include pre-packaged configurations
  3. Enhance the offering to include standard integration to 3rd party systems
  4. Enhance the offering to reduce the level of customizations required

Product is sold under a software-as-a-service model and includes significant post-sale services

Revenue is deferred until customer is live. Services revenue is recognized ratably over the term of the contract.

  1. Augment the software with features that reduce the services effort
  2. Outsource delivery of professional services to a 3rd party

Promise of future functionality

A common challenge is the prospect who says your product lacks some critical functionality without which they won’t buy. While it is not a good idea to manage the product roadmap for individual customer requests, there are circumstances in which it may be unavoidable.

When entering the market with a new offering it is common to solicit early adopters with the hope these customers will turn into references. Generally these customers are willing to accept a product’s immaturity because they see its potential. The hope is you convert early adopters into successful users, who then serve as reference accounts to future prospects.

It is common—particularly in markets where references from peer organizations are critical to sales success—to spend a significant amount of time and effort courting and working with early adopters. Ideally the early adopters are also considered bellwether organizations by their peers, enabling the sales team to reference them in discussions with prospects.

Because the product is new and you may be selling before all of the key features have been developed, early adopters often find the product to be inadequate or incomplete. While they may see the promise the product offers, they are uncertain when or if it will be developed to satisfy their needs. As a way to hedge risks, they ask you to commit to including certain additional features or functionality, often by a particular date.

Once agreed to—whether verbally or in the contract—you have a revenue recognition issue. The future functionality commitment will be treated as an “undelivered element” in the contract, making it likely that no revenue from the sale can be recognized until all of the promised features ship. (There are many accounting rules surrounding undelivered elements and multi-element contract arrangements that can cause a different accounting treatment. However in most cases the undelivered element of a future product deliverable will cause all of the revenue associated with the deal to be deferred until the promised features and functionality are delivered.)

If the sale includes other elements—such as services for setup, configuration, customization, training, maintenance, data conversion, subscriptions or hosting—not only will product revenue be deferred until the promised functionality is delivered, but all of the revenue from all of the other elements will be deferred! If, for whatever reason, you don’t deliver those new features, the customer could legitimately ask for their money back, even the money spent on other services, as they never would have purchased those other items had they known they weren’t going to get their requested features. In essence, your company will receive no economic benefit from the sale until all the promised functionality has been delivered to the customer.

If you’re facing whether to agree to a prospect’s request, what should you do? In one way, the financial significance of the commitment helps in judging whether you should agree to it. There are scenarios such as market entry where the value obtained may be worth the short-term economic costs. Finance should always review contracts or agreements when promises for future functionality are made and will typically advise on the implications of the various terms.

If you have agreed to certain features in the future, the challenge will quickly shift to mitigation, as not all commitments are created equal. Since the value of the sale will be deferred until all future functionality has been delivered, it becomes important to understand what “delivered” means. There are a few traps to avoid: (1) vaguely-defined features or requirements that are subject to wide-ranging interpretations, and (2) any sort of sign-off or acceptance on the part of the customer with respect to future functionality.

Vaguely-worded feature and requirements can create a significant problem for revenue recognition, since it becomes difficult to identify when the promised feature has actually been delivered. If you agree to deliver “a way to publish content to the Web,” it can be hard to understand when you’ve actually done that, since different people may have different ideas of what this means. The circumstances around the sale and the best understanding of what the customer (not you) had in mind will likely be used to determine if the promised feature has been delivered. When considering a commitment for future functionality, it is important to know what you are actually committing to. How will you know (or rather, when an objective person would know) the commitment has been met? The commitments should be in writing, should be narrow and clearly scoped and should include a definition of “done.”          

It is not unusual in cases where the customer asks for a commitment of future functionality they also ask for contract language to provide the right to accept what is delivered. Sometimes this acceptance language is explicitly tied to the future functionality, but often comes as a generalized right with respect to all of the activities within the contract. In some cases the acceptance language can be vague or subjective, such as a language that deliverables are simply subject to the customer’s satisfaction.

Acceptance by the customer of future product features can create an issue, as the test for whether the company can recognize the revenue from the contract becomes not one of, “have we delivered the functionality we promised?” but rather “has the customer accepted what we delivered?”. Acceptance language will cause the revenue deferral to last until the acceptance has occurred, which may be long after the delivery!

There are a few approaches to mitigate the acceptance issue. Best case, seek to avoid any customer acceptance with respect to the future product deliverables. Without explicit acceptance language, the test for revenue recognition reverts to “have we delivered what we said we would deliver.” Provided the features are clearly scoped, a simple documentation exercise of describing how “what was delivered” met the commitment given can be sufficient to declare “done” and recognize all the deferred revenue.

If it’s not possible to avoid acceptance language in the contract, include clearly defined acceptance criteria as part of the commitment. Then the acceptance becomes objective (were the acceptance criteria met?) rather than subjective (does the customer like it?). Documenting the acceptance criteria in advance also helps determine the scope and cost of what you’re agreeing to deliver.

Precisely defining acceptance criteria up front may be impractical. In this case, seek language defining a formal acceptance process that is closed-ended. For example, the language may specify the parties will work to jointly define the acceptance criteria for the features once the work begins, or the acceptance process may include only a limited number of rework/revision periods in which you agree to make changes. In general, the more tightly defined and closed-ended the acceptance process, the better. Just make sure the contract language is reviewed by Finance.
Products that include services

A different problem occurs when the product consists of licensed software with significant post-sale services (such as those for setup, configuration, data conversion or customization). If the services are essential to the delivery of the solution—i.e., the software has limited or no value from the services that go with it—there may be revenue recognition issues.

The accounting literature makes a distinction between services that are incidental to the software and those that are essential. While there is no hard-and-fast rule when services are essential or incidental, the following factors would suggest the services are essential: (1) the software itself is not off-the-shelf (i.e., it is not shrink-wrapped but is highly tailored for each customer); or (2) the software is off-the-shelf but the customer is getting significant alterations to the out-of-the-box features and functionality; or (3) you need to build complex interfaces in order for the customer to use the software; or (4) the customer pays for software as the service work is performed; or (5) payment for software is milestone-based or subject to customer acceptance1.

In the case where there are no services sold with the software or where the services are deemed non-essential, the software license fee would be recognized as revenue as soon as it is delivered.

However if the services sold with the product are determined to be essential, the rules require that “revenue should be recognized in accordance with contract accounting.”2 Under contract accounting, the revenue from the license fees will initially be booked as deferred revenue, with “a portion of the total [license fees]… recorded [as revenue] in each period based on the relative cost or effort applied during that period.”3 Essentially the software license is recognized as revenue as the services work is performed. If the related services stretch over twelve months, one-twelfth of the software license fee would be recognized as actual revenue each month.

The impact in this scenario is less obvious but still potentially significant. Finance will likely look at how to shorten the revenue recognition period and the obvious way to do this is to shorten the duration of the services engagement. But there are limits to how much time can be compressed in a project with a fixed amount of work.

If the product is new, some effort may be needed to work around functional gaps. Closing these can result in decreased effort and time. You could look at ways to reduce deployment and setup time (e.g., tools that assist in implementation, or moving configurations from a test environment into production).
Regardless, you will need to identify ways to replace the lost revenue. Good approaches here include selling prepackaged configurations or interfaces separately, increasing the software price, or selling services as a fixed price package at a higher price, rather than on a time-and-materials basis.

Customers often don’t distinguish or care about the ways in which functionality or features are delivered, merely that they get delivered. Provided the overall price and timeline are acceptable, whether a feature is delivered directly out of the box or as a result of services it may not be a significant distinction to a customer. However, the dividing line between software and services can be significant from the perspective of Finance.
Software as a Service (SaaS)

In software-as-a-service arrangements, the customer doesn’t buy the software up front; they pay for how much they use on a periodic basis, usually monthly.

Two different kinds of revenue recognition issues can arise under a SaaS arrangement. Revenue cannot be recognized until the customer is “live,” or using the software with actual data. Additionally, any associated professional services sold must be recognized evenly (the accounting term is ratably) over the term of the subscription contract, instead of as they are delivered. Both of these can impact the way revenue recognition impacts the product.

In the first case, consider a customer who agrees to pay $10,000 per month. The customer signs the contract and begins paying the subscription fee. However your offering involves some significant setup, configuration and customization work, so it takes six months before the customer is able to use the software in a production capacity. The typical accounting treatment would be to defer the subscription revenue until the customer is live, meaning that none of the subscription fees can be recognized as revenue until then. For six months, the company would not be able to record subscription revenue.

The significance of this is in an effort to recognize more revenue sooner, Finance may ask if anything can be done to shorten the implementation period. This might include adding features to your product to make setup, configuration and implementation more efficient.

If the goal is to reduce the implementation time without reducing the total revenue, you may need to evaluate the feasibility of increasing the services billing rate, of offering pre-packaged services that generate the same revenue but can be delivered more quickly, or to better define what represents a true go-live milestone (e.g., deferring tasks that could be performed after go-live).

The second case presents a more interesting challenge and suggests other potential remedies to investigate. Under the traditional licensed software model, revenue from professional services is recognized as the work is done. For example if the customer purchased $100,000 worth of software and $120,000 worth of professional services, and the services engagement lasts for twelve months, your company would recognize $10,000 of services revenue per month (assuming the work was done in even increments over this period). This approach works well because the costs are typically incurred in a similar pattern: your company probably pays employees working on that project monthly as well. Assuming the deal is profitable overall, your company will be able to report profits from this engagement right from the start.  

Unfortunately, the accounting treatment for this arrangement under a subscription arrangement is less favorable. Under subscription rules, the revenue from associated professional services must be recognized over the term of the subscription contract, not over the duration of the services engagement. Consider a similar example to the one above, except that in this case the customer purchases a $10,000 per month, three-year subscription to the software. They still agree to the same $120,000 worth of professional services which are still performed within the first twelve months.

Accounting rules for subscription arrangements will require your company to recognize the $120,000 ratably over the term of the contract. In this example, that means the company can only recognize $3,333 per month of revenue from the professional services engagement. But if we are paying our employee $8,000 per month, the company will report a loss of $4,667 per month on the services.

It is possible for the treatment to be less severe, as there are means by which some of the $8,000 can be spread over the contract term, as well. However it is generally not possible to spread all of the costs over the contract term. The effect of this is also muted over time as more and more subscriptions are sold, since revenue from previously completed engagements continue to be recognized even though there may no longer be any continuing direct costs. However margins will generally appear far less favorable under a subscription arrangement than under a perpetual license arrangement.

Since the impact to the accounting treatment is directly correlated with the amount of professional services needed, lessening the amount of services will lessen the financial impact. Another alternative is to recommend the company not provide services at all, but instead partner with a third-party firm to provide them. In either case your company would be foregoing the services revenue. Perhaps there is room to increase the monthly subscription fee in order to offset the lost services revenue, perhaps you can generate referral revenue from the partners, or you may simply conclude that the revenue recognition issues are not worth the incremental services revenue. But in modeling these scenarios—especially one that involves partnering with third parties —make sure you take customer satisfaction into account.

A final alternative would be to shorten the duration of the subscription contract, ideally to a timeline consistent with the expected duration of the services engagement. The drawback here is it increases the potential for customer churn (as customers are able to discontinue the subscription sooner); in addition, your company may incur increased retention costs as well (e.g., sales costs to re-engage with the customer and ensure they are satisfied before their contract expires). You will need to model the effects of increased churn and retention costs to determine if shortening the contract duration is a viable option.

Conclusion

It may be surprising to learn that you need to understand accounting revenue recognition rules or that you need to involve Finance in decisions around your offering. Ignorance of revenue recognition, how they impact your company and how product offering decisions influence them can result in very bad outcomes for the company. Outcomes that a product manager is in a position to avoid, if aware of the issues.

As a first step, consult with Finance to understand how revenue from your offerings is recognized today and what policies Finance has adopted. When considering a new offering, review the expected elements of the offering, the nature of the sales arrangement and deliverables, and the expected cash flow and timing of payments. Review this before the first sale and you can avoid significant downstream pain and ensure the offering is structured for the best possible revenue recognition treatment. Just as with product development—where changes become more expensive as the development process progresses—changes due to finance concerns become much more expensive once your product has launched.      

  1. KPMG, Software Revenue Recognition: An Analysis of SOP 97-2 and Related Guidance, Second Edition, August 2005, pp. 207-210; http://us.kpmg.com/microsite/attachments/2005/SoftwareRevRecognitionBook2005.pdf
  2. Steven T Petra, Revenue Recognition for Software Products with Multiple Deliverables, AllBusiness, April 1, 2005; http://www.allbusiness.com/accounting-reporting/record-keeping-gross-receipts/1096815-1.html
  3. The ‘Lectric Law Library, Legal Lexicon on Accounting Methods, The ‘Lectric Law Library, retrieved 25 June 2009; http://www.lectlaw.com/def/a099.htm

Categories: Roles & Activities
Stephen Konig

Stephen Konig

Stephen Konig is a product manager with more than 15 years of experience in bringing B2B and enterprise software solutions to market. His work has spanned vertical solutions for the energy industry, HR and talent management software for businesses and governments, and solutions to assist non-profit organizations raise money and deliver on their missions. Stephen is currently a Director of Product Management at Blackbaud, Inc. Contact Stephen at stephen@konig-us.net, or via Twitter @StephenKonig.

Looking for the latest in product and data science? Get our articles, webinars and podcasts.