Microsoft Revenue Recognition Systems

Our Challenge We are seeking a revenue recognition technology solution to scale with the increasing complexity of existing and future business models and address the new standard Some of the opportunities:  New business models (new revenue types, more MEA)  Multiple provisioning, order processing, invoicing systems (revenue infrastructure)  Data mastering, models and flows (increased data needs)  Impact of new proposed standard: Contract modifications Tracking new performance obligations (namely license and possibly others) Fair value calculations and allocations of transaction price, creating contractual assets and liabilities System impact: Common subledger needed, new data and integration

Revenue Recognition Joint Project Objective of project: Develop a standard based on a single model to deal with all types of contracts and business sectors Would replace most of existing U.S. GAAP and IFRS revenue recognition standards Final Standard in Summer 2013 Effective Date (U.S. GAAP): Public entities: fiscal years and interim periods within those years, beginning after December 15, 2016 – early adoption prohibited Transition Approaches: Retrospective, or Cumulative effect at the date of adoption

Transition, Early Application, and Effective date – Tentative Decisions Transition MethodFY16 and FY17FY18 Date of Cumulative Effect Adjustment 1 Full RetrospectiveRestate for all contractsApply new revenue standard to all contracts July 1, 2015 Cumulative Effect at the Date of Adoption These periods not restated for any contracts Apply new revenue standard to new and existing contracts; disclose effect of applying new standard July 1, 2017

Main Steps To Apply the Model Identify the contract with a customer 1 Identify the separate performance obligations in the contract 2 Determine the transaction price 3 Allocate the transaction price to the separate performance obligations 4 Recognize revenue when (or as) the entity satisfies a performance obligation 5

Step 2: Identify the Separate Performance Obligations in the Contract Separate performance obligations Single performance obligation YesNo Are promised goods and services distinct from other goods and services in the contract? Can the customer benefit from the good or service either on its own or together with other resources that are readily available to the customer? The good or service is not highly dependent on, or highly interrelated with, other promised goods or services in the contract AND Yes No

Step 3: Determine the Transaction Price Transaction price = Total amount of consideration entity expects to be entitled to under the contract in exchange for transferring goods or services (excluding amounts collected on behalf of third parties) Variable consideration and constraint on variable consideration Noncash consideration Consideration payable to a customer Time value of money Collectibility Variable Consideration - may be a result of discounts, rebates, refunds, credits, incentives, performance bonuses/penalties, royalties, price concessions, or other similar items. At contract inception, entities would estimate variable consideration using probability-weighted or most-likely approach Revenue Constraint – Transaction price limited to fixed consideration plus portion of estimated variable consideration the inclusion of which does not create the risk of a significant revenue reversal. Need to have a high level of confidence in variable amounts before including them in transaction price Ongoing Reassessment – Entities will continually update their estimates of variable consideration and amounts thereof subject to the constraint

Step 4: Allocate the Transaction Price to the Performance Obligations Transaction price allocated based on relative stand alone selling prices ABC Performance obligations Observable price Estimated price How to estimate the stand alone selling price? Best evidence If not available Adjusted market assessment approach Expected cost plus a margin approach Residual approach if price is highly variable or uncertain

Disclosure Requirements  High level objective Intended to assist users to understand nature, amount, timing, and uncertainty of revenue and cash flows arising from contracts with customers  Disclosures about contracts with customers Disaggregation of revenue Changes in contract assets, liabilities, and costs Remaining performance obligations Qualitative disclosures Interim requirements

Examples of some key challenges  BUNDLES  One product has multiple performance obligations  One contract has multiple products/services  Multiple contracts need to be combined and accounted for together  Multiple products/services need to be accounted for as one performance obligation  Increased Disclosure Requirements  Two sets of books likely needed during transition

11 Solution Approach and Key Findings Revenue Recognition Pillars Exposure Draft Analysis Revenue Solution Analysis Governance Systems (Tools) Systems (Tools) Systems (Data) Systems (Data) Policy & Process Current State Analysis Peer Company Analysis Findings Governance Enterprise data management is a key success factor Rev Rec is always part of a larger program Policy & Process Pro-active Exposure Draft analysis Policies can significantly affect the complexity (and cost) of system solution Revenue Systems - Data New business models and GAAP guidance change the type of data necessary to process Rev Rec Revenue Systems - Tools Excel is most common toolset for FV among peers No enterprise ready solutions are available today Due Diligence Activities

Custom built.Net based solution Enhance LOB solution; Leverage 3 rd party as needed (e.g., FV calculation/allocation) Customized implementation of standard SAP solution Standard RevPro solution (+) Allows most flexibility (–) Complicated bottom-up build Note: Potential to co- develop solution as a commercial grade asset (+) Leverages existing logic for data integration and Rev Rec (+) Alignment with reporting/analysis roadmap (+) Lead Time (-) Requires significant effort to enhance our existing infrastructure (+) Leverages our ERP system for accounting (–) Dependency on SAP development timelines (–) High costs and extended timelines for customization (+) Out of the box solution addressing core revenue recognition needs (–) Scalability concerns (e.g., complexity and volume) (–) Unable to handle complex upstream data integration needs and requires external reporting infrastructure Removed from consideration Short term solution in process Continued engagement with SAP product development for both input and evaluation Oh site pilot completed for limited scenarios. Currently investigating implementation options Rev Rec System Solution Options 12 Solution Considerations Custom New SAPRevPro Custom existing Disposition

High Level Rev. Rec. System Attributes Accounting:  Ability to handle accounting requirements  Ease and flexibility of rules configuration for multiples of SKUs  Ability to support revenue accounting/operational reporting, such as earn-out schedules Operational:  Adequate controls over access, and workflow/reporting/audit capabilities  Ability to make manual adjustments, with adequate logging and approval System:  Ability to handle the complexity and volume of Microsoft, and yet ability to scale  Ability to integrate various feeds from upstream systems  Ability to “accept” revenue recognition from upstream systems, and then calculate the GAAP adjusting entries  Ability to support significant and complex management reporting and compensation programs, including ability to maintain revenue recognition and GAAP/FV entries separately