Oracle 2010 Annual Report Download - page 211

Download and view the complete annual report

Please find page 211 of the 2010 Oracle annual report below. You can navigate through the pages in the report by either clicking on the pages listed below, or by using the keyword search tool below to find specific information within the annual report.

Page out of 272

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150
  • 151
  • 152
  • 153
  • 154
  • 155
  • 156
  • 157
  • 158
  • 159
  • 160
  • 161
  • 162
  • 163
  • 164
  • 165
  • 166
  • 167
  • 168
  • 169
  • 170
  • 171
  • 172
  • 173
  • 174
  • 175
  • 176
  • 177
  • 178
  • 179
  • 180
  • 181
  • 182
  • 183
  • 184
  • 185
  • 186
  • 187
  • 188
  • 189
  • 190
  • 191
  • 192
  • 193
  • 194
  • 195
  • 196
  • 197
  • 198
  • 199
  • 200
  • 201
  • 202
  • 203
  • 204
  • 205
  • 206
  • 207
  • 208
  • 209
  • 210
  • 211
  • 212
  • 213
  • 214
  • 215
  • 216
  • 217
  • 218
  • 219
  • 220
  • 221
  • 222
  • 223
  • 224
  • 225
  • 226
  • 227
  • 228
  • 229
  • 230
  • 231
  • 232
  • 233
  • 234
  • 235
  • 236
  • 237
  • 238
  • 239
  • 240
  • 241
  • 242
  • 243
  • 244
  • 245
  • 246
  • 247
  • 248
  • 249
  • 250
  • 251
  • 252
  • 253
  • 254
  • 255
  • 256
  • 257
  • 258
  • 259
  • 260
  • 261
  • 262
  • 263
  • 264
  • 265
  • 266
  • 267
  • 268
  • 269
  • 270
  • 271
  • 272

general right of return relative to the delivered products. Where the aforementioned criteria
for a separate unit of accounting are not met, the deliverable is combined with the undelivered
element(s) and treated as a single unit of accounting for the purposes of allocation of the
arrangement consideration and revenue recognition. For those units of accounting that include
more than one deliverable but are treated as a single unit of accounting, we generally
recognize revenues over the delivery period. For the purposes of revenue classification of the
elements that are accounted for as a single unit of accounting, we allocate revenue to
hardware systems and services based on a rational and consistent methodology utilizing our
best estimate of fair value of such elements.
For our nonsoftware multiple-element arrangements, we allocate revenue to each element
based on a selling price hierarchy at the arrangement inception. The selling price for each
element is based upon the following selling price hierarchy: VSOE if available, third party
evidence (TPE) if VSOE is not available, or estimated selling price (ESP) if neither VSOE
nor TPE are available (a description as to how we determine VSOE, TPE and ESP is provided
below). If a tangible hardware systems product includes software, we determine whether the
tangible hardware systems product and the software work together to deliver the product’s
essential functionality and, if so, the entire product is treated as a nonsoftware deliverable.
The total arrangement consideration is allocated to each separate unit of accounting for each
of the nonsoftware deliverables using the relative selling prices of each unit based on the
aforementioned selling price hierarchy. We limit the amount of revenue recognized for
delivered elements to an amount that is not contingent upon future delivery of additional
products or services or meeting of any specified performance conditions.
To determine the selling price in multiple-element arrangements, we establish VSOE of
selling price using the price charged for a deliverable when sold separately and for software
license updates and product support and hardware systems support, based on the renewal rates
offered to customers. For nonsoftware multiple-element arrangements, TPE is established by
evaluating similar and interchangeable competitor products or services in standalone
arrangements with similarly situated customers. If we are unable to determine the selling
price because VSOE or TPE doesn’t exist, we determine ESP for the purposes of allocating
the arrangement by reviewing historical transactions, including transactions whereby the
deliverable was sold on a standalone basis and considering several other external and internal
factors including, but not limited to, pricing practices including discounting, margin
objectives, competition, the geographies in which we offer our products and services, the type
of customer (i.e. distributor, value added reseller, government agency and direct end user,
among others) and the stage of the product lifecycle. The determination of ESP is made
through consultation with and approval by our management, taking into consideration our
pricing model and go-to-market strategy. As our, or our competitors’, pricing and
go-to-market strategies evolve, we may modify our pricing practices in the future, which
could result in changes to our determination of VSOE, TPE and ESP. As a result, our future
revenue recognition for multiple-element arrangements could differ materially from our
results in the current period. Selling prices are analyzed on an annual basis or more frequently
if we experience significant changes in our selling prices.
Revenue Recognition Policies Applicable to both Software and Nonsoftware Elements
Revenue Recognition for Multiple-Element Arrangements – Arrangements with Software and
Nonsoftware Elements
We also enter into multiple-element arrangements that may include a combination of our
various software related and nonsoftware related products and services offerings including
hardware systems products, hardware systems support, new software licenses, software
license updates and product support, consulting, Cloud Services and education. In such
arrangements, we first allocate the total arrangement consideration based on the relative
selling prices of the software group of elements as a whole and to the nonsoftware elements.
We then further allocate consideration within the software group to the respective elements
within that group following the guidance in ASC 985-605 and our policies as described
above. After the arrangement consideration has been allocated to the elements, we account for
each respective element in the arrangement as described above.
Other Revenue Recognition Policies Applicable to Software and Nonsoftware Elements
Many of our software arrangements include consulting implementation services sold
separately under consulting engagement contracts and are included as a part of our services
business. Consulting revenues from these arrangements are generally accounted for separately
from new software license revenues because the arrangements qualify as services transactions
as defined in ASC 985-605. The more significant factors considered in determining whether
the revenues should be accounted for separately include the nature of services (i.e.
consideration of whether the services are essential to the functionality of the licensed
product), degree of risk, availability of services from other vendors, timing of payments and
impact of milestones or acceptance criteria on the realizability of the software license fee.
Revenues for consulting services are generally recognized as the services are performed. If
there is a significant uncertainty about the project completion or receipt of payment for the
consulting services, revenues are deferred until the uncertainty is sufficiently resolved. We
estimate the proportional performance on contracts with fixed or “not to exceed” fees on a
monthly basis utilizing hours incurred to date as a percentage of total estimated hours to
complete the project. If we do not have a sufficient basis to measure progress towards
completion, revenues are recognized when we receive final acceptance from the customer that
the services have been completed. When total cost estimates exceed revenues, we accrue for
the estimated losses immediately using cost estimates that are based upon an average fully
burdened daily rate applicable to the consulting organization delivering the services. The
complexity of the estimation process and factors relating to the assumptions, risks and
uncertainties inherent with the application of the proportional performance method of
accounting affects the amounts of revenues and related expenses reported in our consolidated
Source: ORACLE CORP, 10-K, June 28, 2011 Powered by Morningstar® Document Research