Company Revenue Modeling

• Public company revenue models tie to SEC-reported revenue or other legal public agencies outside the United States (at least at the total company level and often at more granular levels when available).

• Geographic region and operating environment distribution percentages are generally obtained from companies at the primary market level and prorated to individual markets. However, for large companies that have wide variations in geographic and/or operating environment allocations across different markets, these allocations are maintained at the secondary or functional market level whenever that level of detail can be obtained.

Revenue Recognition
Software companies and other companies with software revenue vary in the manner in which they recognize revenue from packaged software sales for reporting purposes, although U.S. public companies are constrained by U.S. accounting practice standards. This is important because IDC's revenue information for companies and for software markets is based on recognized revenue as defined in U.S. practice rather than on bookings, which is another measure. (In the case of private companies, IDC assumes they are using standards that are similar to public companies for their internal accounting.)
For accounting purposes, what matters is revenue, and this is what IDC uses as its metric for the software industry. One reason is that there is a reasonably consistent set of methodologies for determining what is revenue and what is not. These methodologies hinge on the issue of how bookings become "recognized" as revenue. In general, IDC bases its reporting of, and forecasts for, the software market based on revenue as defined by GAAP (to the extent that this is possible for non-U.S. companies).
The first requirement for the recognition of revenue for accounting purposes is whether the actual payment has been received (either directly from the customer or from a distributor or other agent) or whether a contract has been received that obligates the buyer to future payment. Once the booking has been deemed to be recognizable, the issue becomes one of how much may be recognized immediately and how much must or may be deferred and recognized in future periods. There are three basic methods of recognizing revenue: immediate recognition, deferred recognition, and subscription revenue.

Immediate Recognition
Under this method, a company immediately recognizes all the value of a customer's purchase of software. In this case, a booking is turned almost immediately into recognized revenue. If a limited-term license is booked and there are no other contingencies or future deliverables (such as technical support) under the terms, then the total booking may also be recognized immediately.

Deferred Recognition
In practice, it is usual to negotiate mainframe and other large enterprise contracts as limited-term contracts with software "maintenance" and support provisions. Maintenance in the software sense means the right to "bug fixes," minor updates, and functionality improvements (what are called "point releases"), among other things. Here, the software company typically records the total value of the booking of a new or renewed long-term software right-to-use contract by amortizing the part associated with software maintenance over the life of the contract and then recognizing the remainder as immediate revenue.
A company may choose to report revenue recognized in the period as a total or may choose to break it out as license revenue versus maintenance revenue. Alternatively, a company may choose to report maintenance revenue together with revenue from other services, such as consulting services and implementation services, as one services figure. IDC attempts to determine in its data collection process the portion for license and for software maintenance.

Subscription Revenue
An alternative method of licensing software is via a subscription. In this case, the customer agrees to pay on a month-by-month basis (or some other period plan). Because the cancellation clauses of such contracts typically have a fairly small advance-notice requirement (usually between 30 and 90 days), there is no assurance of future revenue; therefore, revenue may be recognized only as it is billed under the terms of the contract.

In all instances, IDC's software research reports revenue as it is recognized regardless of the specific method a company uses for revenue recognition. See Software Revenue Recognition Policies and Their Effects on Market Data (IDC #29458, May 2003) for a more complete discussion of this topic.

Mergers and Acquisitions: "Backstreaming"
To provide a true depiction of market (as opposed to individual vendor) changes over time, we "backstream" revenue when a company is acquired. That is, historical reports show revenue for the combined companies for previous years — independent of when the acquisition actually occurred. The specific rules for backstreaming are as follows:

• Revenue is backstreamed only when an entire company is acquired, not just a product line(s).
• Backstreaming occurs in the first full calendar year following the completion of a merger or acquisition.
• Backstreaming is performed for three years of history.

Calendar Versus Fiscal Years
All IDC software vendor revenue data is reported for calendar years regardless of the reporting cycles or fiscal years of specific vendors.

Treatment of Exchange Rates
IDC's software worldwide market sizing, vendor shares, and forecasts are published in U.S. dollars. For historical data, worldwide revenue models are based on information from company headquarters:

• For those companies that report in U.S. dollars (the majority of those in IDC's SMF database), we do not attempt to determine the currency conversion methodologies utilized internally by the vendor; we just use the reported revenue in U.S. dollars.

• For companies that report in other currencies, we use the average annual exchange rate to calculate revenue in terms of U.S. dollars.

• As a general rule, we do not restate previous years' revenue to account for exchange rate fluctuations (i.e., prior year revenue is "as reported" for that year). In some instances, regional or country-level studies do restate previous-year market size data (but not vendor shares) in market forecast tables for growth rate comparison purposes.
Annual forecasts are created using a constant exchange rate from the prior historical year (e.g., 2006–2010 forecasts use the average 2005 exchange rates). This approach provides a consistent picture of real growth most nearly aligned to growth in local currencies. For a more thorough discussion of the impact of exchange rates on IDC revenue models and forecasts, see The Impact of Exchange Rates on IT Spending Forecasts: An IDC Position Paper (IDC #30274, October 2003).

Allocating Revenue to Geographic Regions
IDC attempts to allocate revenue to the region where the software is deployed/used, not, for example, where a contract is signed. However, we are highly dependent on company headquarters' reported (or supplied) regional revenue recognition data. IDC regional analyst guidance is factored into revenue allocation models to provide additional detail as available.

Allocating Revenue to Operating Environments
The preferred method is to allocate revenue to operating environments based on where the license revenue is derived (for platform-specific licenses). An alternative method is to allocate revenue based on where the product is run (i.e., based on the percentage of executables on various platforms).

Historical Data Reporting

• A maximum of three years of historical revenue data is reported (including backstreaming). Additional historical data may be available on request, but backstreaming of vendor revenue and taxonomy changes makes time-series comparisons difficult and may require custom data compilation and analysis by IDC.

• The "best" data for a given year is found in the study/SMF pivot table with the latest publication date including the year in question.

• Taxonomy changes are backstreamed (three years); historical years in current reports are stated in terms of the current taxonomy.

• From time to time, we revise historical (prior years) revenue numbers for a company. This may occur because:

Determination of "Other"
IDC's SMF database contains revenue data for more than 1,000 vendors. Although we believe we have included nearly all of the largest vendors, there are certainly a significant number of other software suppliers about which we do not have information. IDC estimates the aggregate revenue for these "other" vendors for each functional market to provide a complete revenue picture of the overall packaged software marketplace:

• "Other" represents IDC's estimate of the difference between the explicitly identified vendors' revenue and the total revenue for the market.

• "Other" is largely composed of relatively small vendors, but there is no guarantee that IDC has tracked all companies larger than the smallest shown in a study or pivot table.

• The size of "other" (in terms of percentage of the total market revenue) varies significantly by market but is generally larger for small, emerging markets than it is for more mature markets.

Figure 4 illustrates the process for estimating the size of "other." The yellow (or light) rectangles represent the number of known vendors by revenue range in the market. The heavy line denotes the analyst's conceptualization of the "market profile." This is often, but not always, an exponential curve (i.e., there are an increasingly smaller number of vendors as the revenue per vendor increases). The blue (or dark) rectangles are the difference between the known vendors and the profile curve and represent the estimated number of unknown (or "other") vendors by revenue range. The estimated aggregate size of "other" for a market is then calculated by multiplying the number of estimated unknown vendors by the midpoint of the revenue size range.

"Other" Company Estimation Model

Source: IDC, 2006

"When a Product Becomes a Feature"
A common phenomenon in the software industry is for new technologies to first appear on the market as standalone, unique products. Over time, these products often begin to become functions/features of more inclusive products or suites of products. If and when the market for the standalone products disappears — or at least becomes insignificantly small — IDC would no longer track the market separately. An example would be GUI builders, which are now incorporated into almost all modern development environments and tools. However, an issue of how to track revenue arises during a transition phase when a specific function/feature is marketed both as a standalone product by some vendors and at the same time as an inseparable feature of a larger product or suite by the same or other vendors. In this case, there is no defined generic IDC policy; market dynamics and customer interest dictate how IDC models the market(s). Therefore, the definitions for, and published studies on, specific functional and competitive markets denote how the issue of "when a product becomes a feature" is addressed.

Forecast Methodology

• Software market forecasting begins with the formulation of global and regional macroeconomic assumptions that are then analyzed to determine how they apply to specific market segments. In addition, assumptions about specific market-level drivers and inhibitors are developed.

• All company revenue models and market forecasts are generated and maintained in a central database. The "forecast base" is the vendor historical revenue models by market, geographical region, and operating environment.

• Annual growth rates are determined for each market by geographic region (bottom up) by IDC's regional analysts. Regional forecasts may be at the primary, secondary, or functional market level depending on granularity of research in a particular region. Also, regional analysts factor country-level inputs into the regional forecasts where available.

• IDC's worldwide analysts compile the regional data and are responsible for the overall forecast.

• Operating environment forecasts are performed on a worldwide basis and are a distribution of revenue (i.e., total market forecasts are not changed by operating environment forecasts).

• Annual forecasts are reviewed and updated as required throughout the year. Updated forecasts for functional markets are published quarterly via the Software Market Forecaster pivot tables.

Dynamic Market Maps
The dynamic market map (DMM) is a recently introduced IDC tool for evaluating the competitive position of software vendors in an increasingly complex market. The goal of the dynamic market map is to present a quantitative software vendor comparison tool based on IDC's rigorous software taxonomy and the depth and breath of software market data collected and analyzed by IDC. The DMM is a tool that permits quantitative competitive analysis based on four variables: vendor revenue, momentum, reliance, and diversity. The metrics used are defined as follows.

• Vendor revenue. The size of the bubble is determined by the size of the vendor's revenue in the selected market(s) relative to all the other vendors included in the selection for the selected year. All bubbles are normalized in a particular graph.
• Momentum. On the y-axis, momentum is calculated as the product of the vendor's growth rate and the vendor's annual revenue in the selected market in the selected year relative to the previous year.

Momentum = (growth rate from year 1 to year 2) x (revenue in year 2)

• Reliance. This is the ratio of a vendor's revenue in the selected market to that vendor's total revenue in the domain in the selected year. The color of the bubble shows the range of the ratio with:

• Diversity. Diversity (on the x-axis) is a measure of the breadth and depth of product offerings within a single market dimension. Diversity is weighted by the importance of each individual market segment among all segments along the selected dimension. Given a market dimension:

Where:

Thus, a company with a given share in all segments will have a greater diversity than a vendor with the same share in fewer segments. A company with a minimal share in all market segments along a dimension will have less diversity than a vendor with greater shares in all the segments. Also, vendors with a given share in a large market segment will have a larger diversity that a vendor with the same share in a smaller market segment. Diversity is thus proportional to:

Figure 5 is an example of a DMM.

Sample Dynamic Market Model

Source: IDC, 2006