# Amazon.com, Inc. v. Comm'r > United States Tax Court · March 23, 2017 · 113 T.C.M. 3947 URL: https://www.frixlaw.com/law-library/cases/4340625 ## Case - **Full name:** AMAZON.COM, INC. & SUBSIDIARIES v. COMMISSIONER OF INTERNAL REVENUE - **Court:** United States Tax Court - **Decided:** March 23, 2017 - **Citations:** 113 T.C.M. 3947; 148 T.C. No. 8; 2017 U.S. Tax Ct. LEXIS 9 - **Precedential status:** Published - **Opinion:** Opinion - **Judges:** LAUBER - **Cited by:** 0 later opinions in the Frix Law Library ## Citator (automated) - No negative treatment found by the automated citator. That is not the same as a confirmation that the case is good law; read the citing cases. - Full citator and citing cases: https://www.frixlaw.com/law-library/cases/4340625 ## How later opinions describe it (automated extraction) - concluding that royalty rates "must be ramped down * * * at a rate of 33 percent per year" from prior-year royalty rate ## Opinion text 148 T.C. No. 8 UNITED STATES TAX COURT AMAZON.COM, INC. & SUBSIDIARIES, Petitioner v. COMMISSIONER OF INTERNAL REVENUE, Respondent Docket No. 31197-12. Filed March 23, 2017. In 2005 P entered into a cost sharing arrangement (CSA) with S, its Luxembourg subsidiary. Pursuant to the CSA, P granted S the right to use certain pre-existing intangible assets in Europe, including the intangibles required to operate P’s European website business. This arrangement required S to make an upfront “buy-in payment” to compensate P for the value of the intangible assets that were to be transferred to S. See sec. 1.482-7(a)(2), (g)(2), Income Tax Regs. Thereafter S was required to make annual cost sharing payments to compensate P for ongoing intangible development costs (IDCs), to the extent those IDCs benefited S. See id. paras. (a)(1), (d)(1). As consideration for the transfer of pre-existing intangibles, S made a $254.5 million buy-in payment to P. Applying a discounted cash-flow (DCF) methodology to the expected cash flows from the European business, R determined a buy- in payment of $3.6 billion, later reduced to $3.468 billion. P con- tends that R’s DCF methodology is substantially similar to that re- jected by this Court in Veritas Software Corp. v. Commissioner, 133 -2- T.C. 297 (2009). P contends that R’s determinations are arbitrary, capricious, and unreasonable and that the comparable uncontrolled transaction (CUT) method is the best method to calculate the requisite buy-in payment. P used a multistep allocation system to allocate costs from its various cost centers to IDCs. See sec. 1.482-7(d)(1), Income Tax Regs. (providing that costs “must be allocated between the intangible development area and the other areas or business activities on a rea- sonable basis”). While accepting P’s allocation method in many re- spects, R determined that 100% of the costs captured in one important cost center (“Technology and Content”) must be allocated to IDCs. P contends that R’s determination to allocate to IDCs 100% of the Technology and Content costs is inconsistent with the regulations. 1. Held: R’s determination with respect to the buy-in payment is arbitrary, capricious, and unreasonable. Veritas Software Corp. v. Commissioner, 133 T.C. 297, followed. 2. Held, further, P’s CUT method, with appropriate upward ad- justments in numerous respects, is the best method to determine the requisite buy-in payment. 3. Held, further, R abused his discretion in determining that 100% of Technology and Content costs constitute IDCs. 4. Held, further, P’s cost-allocation method, with certain ad- justments, supplies a reasonable basis for allocating costs to IDCs. John B. Magee, Sanford W. Stark, Bryon A. Christensen, Tracey X. Zheng, Robert S. Kirschenbaum, Beth L. Williams, John G. Ryan, Saul Mezei, Julia Kazaks, Rajiv Madan, John A. Polito, Michael D. Kummer, Christopher P. -3- Murphy, Royce L. Tidwell, Carl T. Ussing, Hans D. Gerling-Ritters, Nicholas A. Zemil, and Paul M. McLaughlin, for petitioner. Jill A. Frisch, Anne O’Brien Hintermeister, Melissa D. Lang, Lloyd T. Silberzweig, Shannon L. Cohen, Melissa L. Hilty, Scott W. Mentink, David A. Lee, My V. Vo, Jimeel R. Hamud, Aaron T. Vaughan, and Mary E. Wynne, for respondent. CONTENTS FINDINGS OF FACT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 I. Overview of Amazon’s European Business . . . . . . . . . . . . . . . . . . . . . . . . 12 A. Initial Expansion Into Europe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 B. Original Structure of European Business . . . . . . . . . . . . . . . . . . . . . 16 C. “Project Goldcrest” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.0 1. Cost Sharing Arrangement . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2. License Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3. Assignment Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4. European Subsidiary Contribution . . . . . . . . . . . . . . . . . . . . . 25 5. European Business Contribution . . . . . . . . . . . . . . . . . . . . . . 25 6. Four-Party Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 D. Life After Project Goldcrest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 II. Retail and Technological Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 A. Internet Retail Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 B. Evolution of Amazon’s Website Architecture . . . . . . . . . . . . . . . . . 32 C. Evolution of Amazon’s Software Applications . . . . . . . . . . . . . . . . 38 1. Customer Master Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 2. Order Master Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3. Dynamo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4. Payments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5. Item Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 -4- 6. Personalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 7. Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 D. New Products and Services After January 1, 2005 . . . . . . . . . . . . . . 46 III. Amazon’s Third-Party Businesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 A. Merchants.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 B. Associates and Syndicated Stores . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 IV. The Buy-In Payment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 V. Cost Sharing Payments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 VI. Stock-Based Compensation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 OPINION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 I. Cost Sharing Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 II. Respondent’s Determination of the Buy-In Payment . . . . . . . . . . . . . . . . . 73 III. Petitioner’s Determination of the Buy-In Payment . . . . . . . . . . . . . . . . . . . 89 A. Website Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 1. Royalty Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 2. Useful Life and Decay Curve . . . . . . . . . . . . . . . . . . . . . . . . 102 a. Useful Life . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 b. Decay Curve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 c. “Tail” Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 3. Revenue Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 4. Discount Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 B. Marketing Intangibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 1. Royalty Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 2. Useful Life . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 3. Revenue Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 4. Discount Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 5. European Portfolio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 a. Ownership of the European Portfolio . . . . . . . . . . . . 148 b. Allocating Value to the European Portfolio . . . . . . . 154 -5- C. Customer Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 IV. Cost Sharing Payments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 A. Respondent’s Position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 B. Petitioner’s Position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 C. Stock-Based Compensation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 LAUBER, Judge: The Internal Revenue Service (IRS or respondent) deter- mined, for 2005 and 2006 respectively, deficiencies in petitioner’s Federal income tax of $8,380,790 and $225,653,149.1 These deficiencies arose from a series of transactions by which Amazon.com, Inc., and its domestic subsidiaries (collective- ly, Amazon US) transferred to Amazon Europe Holding Technologies SCS (AEHT), a Luxembourg subsidiary, the intangible assets required to operate pe- titioner’s European website business. Invoking section 482, the IRS made substantial transfer-pricing adjustments reallocating income to Amazon US from AEHT. From its inception through 2005 Amazon US owned the intellectual prop- erty in question. In 2004 Amazon US and AEHT entered into a “cost sharing 1 Unless otherwise indicated, all statutory references are to the Internal Revenue Code in effect for the tax years at issue, and all Rule references are to the Tax Court Rules of Practice and Procedure. We round all dollar amounts to the nearest dollar. -6- arrangement.” See sec. 1.482-7(a)(1), (b)(1), Income Tax Regs.2 This arrange- ment required AEHT to make an up-front “buy-in payment” to compensate Ama- zon US for the value of the intangible assets that were to be transferred to AEHT. See id. paras. (a)(2), (g)(2). Thereafter AEHT was required to make annual cost sharing payments to compensate Amazon US for ongoing intangible development costs (IDCs), to the extent those IDCs benefited AEHT. In a series of transactions in 2005 and 2006 Amazon US transferred to AEHT three groups of intangible assets: (1) the software and other technology re- quired to operate petitioner’s European websites, fulfillment centers, and related business activities; (2) marketing intangibles, including trademarks, tradenames, and domain names relevant to the European business; and (3) customer lists and other information relating to petitioner’s European clientele. After concessions,3 this case requires the Court to decide two main issues: the proper amount of AEHT’s buy-in obligation with respect to the assets thus transferred; and the vol- 2 Section 1.482-7, Income Tax Regs., was redesignated section 1.482-7A, Income Tax Regs., with the promulgation of new regulations effective January 5, 2009. See T.D. 9441, 2009-7 I.R.B. 460. 3 On May 30, 2014, the parties filed a stipulation of settled issues reflecting their settlement of an issue captioned “Cost Sharing Acquired Intangibles Buy-In.” Petitioner conceded this issue in full and agreed that its taxable income would accordingly be increased by $4,881,993 for 2005 and $2,548,165 for 2006. -7- ume of petitioner’s costs properly treated as IDCs (the larger the volume, the larger the cost sharing payments that AEHT must make). On the first issue, petitioner originally reported a buy-in payment from AEHT of $254.5 million, to be paid over seven years. In determining the value of the transferred assets, petitioner assumed that each group of assets (website tech- nology, marketing intangibles, and customer information) had a seven-year useful life. On examination of petitioner’s returns, the IRS concluded that the buy-in payment had not been determined at arm’s length. See sec. 1.482-7(g)(2), Income Tax Regs. In respondent’s view, the transferred property had an indeterminate useful life, and it had to be valued, not as three distinct groups of assets, but as in- tegrated components of an operating business. Applying a discounted cash-flow (DCF) methodology to the expected cash flows from the European business, the IRS determined a buy-in payment of $3.6 billion, later reduced to $3.468 billion. Petitioner contends that respondent’s DCF methodology is substantially similar to that rejected by this Court in Veritas Software Corp. v. Commissioner, 133 T.C. 297 (2009), nonacq., 2010-49 I.R.B. (2010). Petitioner disputes the con- ceptual soundness of that methodology as applied here, contending that it treats short-lived intangibles as if they had perpetual useful lives. The result, according -8- to petitioner, is to inflate the buy-in payment by improperly including in it the value of subsequently developed intangible property. See sec. 1.482-7(g)(2), In- come Tax Regs. (requiring that the buy-in payment reflect only pre-existing in- tangibles). To value the pre-existing intangibles properly, petitioner contends that each group of transferred assets must be valued separately under the “comparable un- controlled transaction” (CUT) method. On the basis of expert testimony at trial,4 petitioner contends that the website and related technology had a value when transferred between $117 million and $182 million; that the marketing intangibles had a value when transferred between $115 million and $165 million; and that the customer information had a value when transferred between $52 million and $66 million. This would yield a buy-in payment ranging from $284 million to $413 million. Citing testimony by his trial experts, respondent urges substantially high- er values for each group of assets in the event we reject his DCF method. With respect to ongoing cost sharing payments, we must address two dis- tinct issues. The first is essentially a tax accounting question, requiring that we determine “all of the costs incurred * * * related to the intangible development 4 An alphabetical list of petitioner’s and respondent’s expert witnesses, together with a short resume of each, appears in the appendix to this Opinion. -9- area.” Id. paras. (b)(2), (d)(1), (f)(1). Petitioner used a multistep allocation system to allocate costs from its various cost centers to IDCs. See id. para. (d)(1) (pro- viding that costs “must be allocated between the intangible development area and the other areas or business activities on a reasonable basis”). While accepting petitioner’s allocation system in many respects, the IRS determined that 100% of the costs captured in one important high-level cost center (“Technology and Con- tent”) must be allocated to IDCs. The result of this determination was to increase by $23 million and $109.9 million the cost sharing payments that AEHT was re- quired to make in 2005 and 2006, respectively. Asserting that this determination was arbitrary and capricious, petitioner contends that only about half of Tech- nology and Content costs should be allocated to IDCs. The second question involves section 1.482-7(d)(2), Income Tax Regs., which requires that stock-based compensation be included in the IDC pool upon which cost sharing payments are based. Petitioner complied with this regulation in preparing its 2005-2006 tax returns; because the vast bulk of petitioner’s stock- based compensation was paid to its domestic employees, the result was to increase accordingly the cost sharing payments required of AEHT. Our treatment of this issue is governed by the terms of the parties’ cost sharing agreement, and in light - 10 - of our decision in Altera v. Commissioner, 145 T.C. 91 (2015), which invalidated the regulation in question. FINDINGS OF FACT Amazon.com, Inc. (ACI), is the common parent of a group of affiliated cor- porations that join in the filing of a consolidated return (Amazon US) and of nu- merous foreign subsidiaries (collectively, Amazon or petitioner). ACI was incor- porated in 1994 in Washington and was reincorporated in 1996 in Delaware. It began operations in 1995 and completed an initial public offering of common stock in 1997. Its principal place of business when it filed the petition was in Seattle, Washington.5 Amazon is an online retailer. It does not have brick-and-mortar stores, but rather sells products exclusively through Amazon.com and related websites. Ini- tially Amazon sold only books, but by 2000 it had expanded its offerings into many other product categories, including music, video, electronics, toys, software, video games, cameras, kitchen items, tools/hardware, and home/garden. Amazon 5 The Court issued protective orders adopting procedures to protect petition- er’s trade secrets and proprietary technology (collectively confidential informa- tion) during the pre-trial, trial, and post-trial phases of this case. The facts set forth in this Opinion have been adapted accordingly. All information included herein has been determined by the Court not to constitute “trade secrets or other confidential information” within the meaning of section 7461(b). - 11 - would identify unrelated product vendors; buy products from them; manage inventory and price the products; list the products for sale on Amazon.com; and ship the items to customers from its warehouses. Amazon is committed to continuous growth in the number and variety of products it offers for sale. With a view to increasing selection further, Amazon in 2000 began allowing third parties to sell items on its websites. Amazon made available a set of eCommerce platforms, services, and tools that enabled third par- ties to list their own products and services for sale on Amazon.com and related websites. This branch of Amazon’s business was called Marketplace. Through Marketplace, third-party merchants set their own prices for their products and ser- vices, which appeared alongside the products that Amazon itself sold. Amazon received commissions on these third-party sales and recorded the commission amounts (not the sale prices) as revenue. Some third parties desired to use Amazon’s technology but did not wish to sell their products on an Amazon-branded website. To meet this demand, Amazon built and operated eCommerce websites, custom made for a particular merchant, through which that merchant could make online sales of its products under its own brand name. This branch of Amazon’s business was called Merchants.com or M.com. Whereas Marketplace retailers sold items on Amazon’s websites, M.com - 12 - retailers sold items on their own branded websites, which were built by Amazon using the entire suite of eCommerce technology that ran Amazon’s own websites. Although Amazon built websites for numerous customers, the most successful implementation of its M.com business was the website it built for Target Corp., which enabled Target to sell its retail products through Target.com. Since its founding Amazon has committed itself to the “three pillars” of selection, price, and convenience. Under the selection pillar Amazon aims to offer its customers the widest possible selection by ensuring continuous growth in the number and variety of products offered. Under the price pillar Amazon endeavors to keep its prices as low as possible at all times. The convenience pillar encom- passes a range of goals associated with improving the customer experience, in- cluding: (1) helping customers find what they seek as quickly as possible; (2) de- livering to them as quickly and accurately as possible all items that they purchase; and (3) ensuring that potential customers have all information useful in making purchasing decisions, even if their initial decision is not to make a purchase. I. Overview of Amazon’s European Business A. Initial Expansion Into Europe In April 1998 Amazon acquired Bookpages, Ltd., an online bookstore in the UK, and Telebook, Inc., an online bookstore in Germany. Later that year Amazon - 13 - re-launched these websites under the respective domain names Amazon.co.uk and Amazon.de. In August 2000 Amazon launched its French business organically rather than by acquisition, adopting the domain name Amazon.fr. At the outset, Amazon.co.uk and Amazon.de offered only books; Amazon.fr offered books, mu- sic, and video products. During the tax years at issue, Germany, the UK, and France were the only European countries in which Amazon operated. By 1999 Amazon.co.uk, Amazon.de, and Amazon.com had become the three most popular online retail domains in Europe. By 2005 Amazon’s share of total online retail spending approached or exceeded double digits in Germany and the UK, while lagging in France. In each country, however, Internet retailing was a small fraction of the overall retail market segment. By one account, Internet sales in 2005 represented only 2.4%, 5.6%, and 1.1% respectively of total retail spending in Germany, the UK, and France. Although all three nations were EU members, the manner in which Amazon operated its business in each country was in many respects local. A local country manager supervised a staff with responsibility for vendor and customer relation- ships, fulfillment, pricing, and financial management. Due to differing cultural preferences, retail traditions, and national regulations, the details of these opera- - 14 - tions--and the technology required to make them happen--often varied from coun- try to country. As of January 1, 2005, vendors and the terms on which they sold goods to Amazon differed in each country. Local Amazon employees in each country iden- tified and recruited vendors; this recruitment process was intensely personal and could take years. For example, although Canon is a multinational corporation sell- ing cameras throughout the world, each of Amazon’s European subsidiaries had to negotiate separately with the Canon team in its country, and those Canon teams had distinct organizations, pricing policies, and sources of supply. Similar varia- tions existed in the Marketplace program: Local teams speaking the local lan- guage identified and recruited prospective Marketplace sellers in each country. As of January 1, 2005, even the largest of Amazon’s vendors and merchants trans- acted with its European subsidiaries at the local level, rather than transacting with Amazon on a global or pan-European basis. Pricing in Europe was also local. Amazon endeavored to offer the best val- ue for customers, which meant matching or beating local prices, both online and offline. But prevailing prices for a given item could vary considerably from coun- try to country on account of such factors as: (1) unique local competitors and competitive environments; (2) different vendors with different pricing policies; - 15 - and (3) local laws and regulations that restricted pricing (e.g., by preventing dis- counting on books and other items). In order to match competitors’ prices, each European subsidiary first had to determine which companies it would treat as com- petitors; this was a local decision because the markets were all different. Each subsidiary then sent teams of local employees to check prices by visiting com- petitors’ stores. Local factors also affected the fulfillment process, that is, the mechanics of preparing an order for shipment and effecting timely delivery to the customer. As of January 1, 2005, each European subsidiary filled orders from an in-country ful- fillment center; if a French warehouse was short of an item, delivery could be de- layed even if UK warehouses had ample supply. Amazon’s UK and German ful- fillment centers used a “buffer rebin sortation process” that was built indepen- dently in Europe; it had a fundamentally different design from that used in Ama- zon’s U.S. and French fulfillment centers. Amazon’s transportation costs and the speed, reliability, and accuracy of its shipping also varied because of local reg- ulations and other economic factors in Germany, the UK, and France. Surprisingly perhaps, customers’ payment preferences also differed geo- graphically. German customers, for example, used credit cards less frequently than customers in other countries. The German subsidiary thus had to build two - 16 - unique payment systems for use by its customers: “direct debit,” which enabled it to deduct purchase amounts from customers’ bank accounts; and “pay by invoice,” which provided customers a bill along with their shipment. German customers were also prone to regard items as having been purchased “on approval” and to return items with which they were dissatisfied. This required the German subsid- iary to create unique processes to deal with the high volume of returns, which could range up to 50% on certain items. The idiosyncrasies of local markets tripped up many U.S. retailers seeking to expand into Europe. Best Buy failed in the UK, and Walmart failed in Ger- many. Amazon itself came close to failing in France; in the early 2000s the French subsidiary was Amazon’s worst performing business. This led to a sub- stantial downsizing in 2004, which required the company to file with French au- thorities a “social plan” by which it communicated its downsizing plan and the justification for it. B. Original Structure of European Business Beginning in 1999 and continuing into 2006, the German retail business was conducted by Amazon.de GmbH and its subsidiary, a disregarded entity for U.S. income tax purposes (Amazon Germany). See sec. 301.7701-3(b)(2), Proced. & Admin. Regs. Beginning in 2000 and continuing into 2006, the French retail - 17 - business was conducted by Amazon.fr Holdings SAS and its subsidiaries, which were likewise disregarded entities for U.S. income tax purposes (Amazon France). The UK retail business was conducted primarily by Amazon.co.uk Ltd. (Amazon UK). Collectively, we will refer to these entities as the European Subsidiaries. The European Subsidiaries were wholly owned by Amazon US.6 Until April 30, 2006, Amazon US was the inventory owner and seller of rec- ord for the European businesses. The European Subsidiaries provided services to Amazon US in operating those businesses; in Germany, these services included setting up a commissionaire arrangement, whereby Amazon Germany held itself out to customers as the retail seller for the benefit of Amazon US. The European Subsidiaries provided Amazon US with retail support, storage facilities, fulfill- ment, back-office support, and local financial management services. Until April 30, 2006, Amazon US also operated petitioner’s “international third party” or “international 3PS” businesses. The international 3PS businesses included: (1) the European activities of Marketplace, which allowed third parties to offer products for sale on Amazon’s websites; (2) the European activities of 6 The consolidated group headed by ACI includes a bewildering array of subsidiaries. In an effort to reduce the alphabet-soup character of this Opinion, we will generally refrain from noting which particular domestic subsidiary does par- ticular things unless it is material to the legal analysis. - 18 - M.com, whereby Amazon used its technology to build websites enabling European retailers to sell their products through their own domain names and URLs; and (3) “Syndicated Stores,” essentially the converse of Marketplace, whereby Amazon used its technology to sell its own products through a European retailer’s website. The European Subsidiaries provided various services to Amazon US in connection with the international 3PS businesses, including website development and design, marketing services, and certain commissionaire services. Before April 30, 2006, Amazon US owned most of the intellectual property required to operate its European businesses, and it licensed this intellectual prop- erty to the European Subsidiaries. This intellectual property included the under- lying website technology, all of which had been developed in the United States; all of the European customer information; and most of the marketing intangibles, in- cluding trademarks and domain names. In 1996, for example, Amazon US regis- tered the “Amazon” trademark under Nice classes 9, 37, and 42 in an attempt to protect that mark throughout the EU. As explained more fully below, some of the trademarks and domain names used by the European Subsidiaries were titled in their respective names. Unlike in the United States, where Amazon operated uniform retail websites serving a large geography with a large population, Amazon’s retail business in - 19 - Europe had a siloed structure. Each European Subsidiary had a distinct website employing its own national language. Each European Subsidiary had its own ful- fillment centers, often processing country-specific inventory, and a distinct uni- verse of customers residing chiefly within its own borders. This siloed structure resulted in inefficient operations, lack of coordination among the European businesses, and barriers to pan-European expansion. The European fulfillment centers had inventory management problems and were reach- ing their physical capacity. Unlike their U.S. counterparts, European fulfillment centers could not freely transfer inventory and could not offload volume from one center to another. The growth of the European business was also stressing Ama- zon’s website technology: All website servers were in the United States, and increased website traffic exacerbated latency problems. (“Latency” refers to the speed with which a webpage loads; customers prefer faster speeds.) Recognizing that serving European customers through poorly coordinated national silos was inefficient, Amazon during the early 2000s began to investigate creation of a centralized European headquarters. One goal of this process was to enhance customer experience by locating servers closer to customers, thus reduc- ing website latency. Other goals were to place top managers in the same time zones as their customers; to standardize best practices for customer service, traffic - 20 - generation, pricing, and vendor acquisition; to increase efficiency by minimizing duplicative individual country costs; and to create a pan-European fulfillment infrastructure that would facilitate expansion into additional EU countries. Tax issues, including applicable tax rates, also loomed large in Amazon’s thinking. To avoid creating a U.S. permanent establishment, European personnel could not sign contracts or make ultimate business decisions on behalf of Amazon US within Europe. By establishing a European headquarters, Amazon could col- lect and remit value added tax (VAT) at a single rate in a single jurisdiction (the location of the seller), rather than at multiple rates in multiple jurisdictions (the locations of the buyers). And Amazon was quite aware that the effective marginal rate of corporate income tax was (or could be negotiated to be) significantly lower in certain EU member states--specifically, Luxembourg and Ireland--than it was in the United States. C. “Project Goldcrest” Amazon’s management decided to establish a European headquarters and assigned its U.S. tax department the task of developing a tax-efficient strategy for doing this. It considered several locations for the European headquarters, includ- ing Ireland and Luxembourg, and eventually opted for the latter. Amazon repre- sentatives met with Luxembourg authorities, including Jean-Claude Juncker, - 21 - Luxembourg’s then prime minister, to discuss the potential for Amazon to locate its European headquarters there. In broad outline, Amazon’s plan was to transfer from Amazon US to the Luxembourg headquarters affiliate all of the intangible assets required to operate the European website businesses; to continue using the European Subsidiaries as service companies earning a nominal rate of return; and to have the vast bulk of the income from Amazon’s European businesses taxed in Luxembourg at a very low rate. In pursuit of the latter goal, Amazon successfully negotiated an advance tax agreement with the Government of Luxembourg. After the restructuring, the Luxembourg entity would function as the operational and administrative head- quarters for the European businesses and own virtually all of the intangible assets required to operate those businesses. Beginning in 2004 Amazon undertook a series of transactions, dubbed “Pro- ject Goldcrest,” to implement this plan. (“Goldcrest” refers to Luxembourg’s na- tional bird.) These transactions were complex; they involved many steps and many entities. But the basic outline can be stated fairly succinctly. Amazon US formed AEHT, the Luxembourg headquarters entity that would serve as the hold- ing company for all of the European businesses. AEHT elected to be treated as a corporation for U.S. income tax purposes from the date of its formation. See sec. - 22 - 301.7701-3(c), Proced. & Admin. Regs. Underneath AEHT numerous subsidiaries were created (collectively, Amazon Luxembourg) to perform various functions essential to operation of the European businesses. These functions included hold- ing title to the inventory sold in Europe, licensing Amazon’s intellectual property, housing the servers, and maintaining call centers. Amazon Germany, Amazon UK, and Amazon France thereafter supplied to Amazon Luxembourg the same types of customer-related, fulfillment, and support services that they had previous- ly furnished to Amazon US. After forming Amazon Luxembourg, Amazon effected the restructuring by completing six related transactions: (1) the Cost Sharing Arrangement;7 (2) the License Agreement For Preexisting Intellectual Property (License Agreement); (3) the Assignment Agreement For Preexisting Intellectual Property (Assignment Agreement); (4) the European Subsidiary Contribution; (5) the European Business Contribution, and (6) the Four-Party Agreement. These agreements may be sum- marized as follows: 7 The Cost Sharing Arrangement actually involved two successive agree- ments. In December 2004 Amazon US and AEHT entered into an “Agreement to Share Costs and Risks of Intangible Development” with a stated effective date of June 7, 2004. On January 11, 2005, Amazon US and AEHT entered into an “Amended and Restated Agreement to Share Costs and Risks of Intangible Devel- opment” with a stated effective date of January 1, 2005. We will generally use the term “Cost Sharing Arrangement” or “CSA” to refer to the latter. - 23 - 1. Cost Sharing Arrangement The Cost Sharing Arrangement (CSA) was intended to be a “qualified cost sharing arrangement” within the meaning of section 1.482-7(a)(1), Income Tax Regs. Through the License and Assignment Agreements (described more fully below), AEHT obtained access to pre-existing intangible property of Amazon US, referred to as “the Amazon Intellectual Property.” Through the CSA, the parties agreed to share the costs of further “research, development, marketing, and other activities relating to * * * maintaining, improving, enhancing, or extending the Amazon Intellectual Property.” Through its participation in the CSA, AEHT would assist, by way of finan- cial contribution only, in the ongoing development of technology required to op- erate the European websites and related activities. The CSA required the parties to determine “Aggregate Allocable Development Costs,” which would then be allo- cated to the parties according to the ratio of benefits each was projected to derive from ongoing development. Basically, this meant that Amazon Luxembourg would pay Amazon US for its ratable share of subsequently incurred intangible development costs (IDCs). - 24 - 2. License Agreement On January 1, 2005, Amazon US and AEHT entered into the License Agree- ment with a stated effective date of January 1, 2005. Amazon US thereby granted AEHT the rights to use “Amazon Intellectual Property,” defined to exclude the marketing intangibles covered by the Assignment Agreement. The property cov- ered by the License Agreement related to Amazon’s website technology. Under the License Agreement, AEHT agreed to make a buy-in payment for the website technology in the aggregate amount of $226,520,000, to be paid in installments during the seven-year period beginning in 2005 and ending in 2011. 3. Assignment Agreement In July 2005 Amazon US and AEHT executed the Assignment Agreement. Amazon US thereby granted AEHT the rights to use Amazon Intellectual Property not covered by the License Agreement, namely, customer data and previously developed marketing intangibles including trademarks, trade names, website con- tent, and domain names relating to the European business. Though stated to be effective as of January 1, 2005, the Assignment Agreement remained executory until the “Business Transfer Date,” which was May 1, 2006. Under the Assign- ment Agreement, AEHT agreed to make a buy-in payment for the marketing in- - 25 - tangibles and customer data in the aggregate amount of $27,991,000, to be paid in installments during the six-year period beginning in 2006 and ending in 2011. 4. European Subsidiary Contribution In February 2006 Amazon Luxembourg acquired all of the stock of the European Subsidiaries via tax-free reorganizations under section 368(a)(1)(D). The reorganizations were accomplished by ACI’s transfer of the stock of the Euro- pean Subsidiaries (valued at approximately $196 million in toto) to AEHT in ex- change for AEHT stock and cash, immediately followed by each of the European Subsidiaries’ electing to be disregarded as separate from their owner for U.S. tax purposes. Amazon Luxembourg thus became the ultimate owner of all of the European Subsidiaries’ property and the ultimate employer of their employees. See sec. 301.7701-3(b)(2), Proced. & Admin. Regs. 5. European Business Contribution In a series of transactions between April 7 and May 1, 2006, Amazon US transferred to Amazon Luxembourg, in a section 351 exchange for stock, various assets (other than intellectual property) required to operate the European busi- nesses. These assets included inventory, accounts receivable/payable, vendor con- tracts, transportation/delivery contracts, “associates agreements,” licenses from third parties, and service contracts. Amazon US concurrently terminated the prior - 26 - agreements whereby the European Subsidiaries had provided services to and li- censed intellectual property from it. 6. Four-Party Agreement Under the Four-Party Agreement, effective April 30, 2006, the European Subsidiaries assigned or licensed exclusively to AEHT certain intellectual prop- erty titled in their names. Before 2005 the European Subsidiaries procured pro- tection for, and registered in their own names, certain trademarks and domain names deployed in Europe. In exchange for these assets AEHT paid in the aggre- gate about $5 million. D. Life After Project Goldcrest After April 30, 2006, Amazon Luxembourg reported, for U.S. tax purposes, all of the income and expenses connected with the European businesses. It en- tered into agreements with the European Subsidiaries whereby they provided it with certain fulfillment services, customer and merchant services, and support services within their respective territories; the European Subsidiaries were paid a cost-plus fee for these services. In May 2006 AEHT’s Irish subsidiary constructed a facility with numerous servers that provided data storage and hosting services for the European businesses; it received a cost-plus fee for doing this. - 27 - Amazon Luxembourg was by no means a shell company. Beginning in May 2006 it played a meaningful role in expanding Amazon’s existing business in Ger- many, the UK, and France and extending Amazon’s reach elsewhere in Europe. From 2006 through 2013 AEHT launched 11 new product categories through its UK and German websites, including apparel/accessories, sports/outdoors, jewelry/ watches, health/personal care, shoes/accessories, auto parts, groceries, and baby products. It launched 15 new product categories through its French website, in- cluding most of the preceding categories and some others. And it launched new website operations in Italy (Amazon.it) and Spain (Amazon.es). Amazon’s Euro- pean revenues grew very rapidly during this period. The Luxembourg headquarters also played a nontrivial part in rolling out new technology--the European Fulfillment Network (EFN)--that implemented standardized and improved fulfillment operations across Europe. The software underlying EFN was developed in the United States by Amazon US after 2005. It addressed the problem of multiple websites with country-specific fulfillment cen- ters located in multiple countries. The EFN technology successfully converted a three-country silo structure into a network, leveraging AEHT’s status as Amazon’s single seller of record throughout Europe, which simplified the sharing and pooling of inventory. The - 28 - EFN technology enabled customers shopping on one national website to view in- ventory and acquire products housed in fulfillment centers located in other coun- tries. Implementation of this technology significantly reduced the time that cus- tomers waited to receive products, reduced shipment costs, lowered product prices, and dramatically increased selection. II. Retail and Technological Environment A. Internet Retail Environment Internet technology makes retailing a more competitive business than it used to be. The World Wide Web enables consumers to compare prices in real time and buy at the lowest price offered on multiple websites. The Internet makes consum- ers’ costs of searching for a product virtually disappear and allows them to switch from one retailer to another by clicking a mouse. A theory called “stickiness” posits that a consumer usually will not switch to a competitor after a single bad experience on a particular site. But Amazon adopted as a guiding principle that “competition is literally one click away.” The price transparency associated with online retailing leads to lower sales margins, one factor that makes online retailing so competitive. During the last 20 years, innumerable online retailers have gone out of business or lost significant value; even today, online retail remains a small fraction of the total retail market - 29 - segment. Because of this competitive environment, constant innovation is essential to ensure survival. Technological failure damages profitability; a late delivery or damaged product may also alienate a customer permanently. Innovative technology underlies every aspect of Amazon’s retail business. It is integral to creating and managing the catalog, displaying items in the catalog to potential customers, conveying the look and feel of the websites, convincing a potential customer to buy an item, completing transactions, processing payments, packaging an item, shipping it to the customer, and preventing fraud. To continue to deliver on its promises, Amazon in the mid-2000s made massive investments to ensure a rapid pace of technological innovation. Respondent’s principal valuation expert, Daniel J. Frisch, agreed that Amazon operated in a “highly competitive, rapidly changing industry” that “requires substantial innovation all the time.” Respondent’s technology expert, Edward Felten, noted that “Amazon’s entire existence has been characterized by the challenges of innovating due to running into unexpected walls and growing so fast that the entire structure seems in danger of failure at any moment.” Amazon’s software engineers, computer scientists, and management team focused on continuous innovation to provide easy-to-use functionality, rich web- site content, fast and reliable fulfillment, timely customer service, and a trusted - 30 - transactional environment. Amazon regularly launched software on a test basis, fully conscious of the need for further improvements; its software and website content often changed multiple times the same day. Amazon’s software develop- ment process “leveraged the future”: By building a piece of software quickly, Amazon incurred the risk that it would not be adaptable to future needs. By re- peatedly choosing “the expedient path” over “the right path,” Amazon built up “technical debt” that inheres in software with a relatively short useful life. Amazon’s need to innovate was driven by multiple factors. Perhaps the most important factor was the need to increase “scale.” One of Amazon’s early business goals was to “get big fast”; getting big fast meant adding customers, web- page views, vendors, and new products at an extremely rapid pace. Website tech- nology by its nature is subject to scale limitations; if the website cannot “scale up” to meet the demands placed upon it, it will crash. Rapid technological innovation was required to overcome the scale challenges posed by rapid growth. These challenges were especially pronounced during Amazon’s peak holi- day seasons, when webpage views, transactions consummated, and products pack- aged increased by 300% to 400% over nonpeak periods. Holiday periods stressed every aspect of Amazon’s system, and each successive peak season entailed higher - 31 - volumes and thus greater scale challenges. Amazon risked system collapse if its technology could not scale up to these demands. Amazon’s engineers testified that they spent the 1998, 2003, 2004, and 2005 holiday seasons “in crisis mode.” Although its website was available to the public 98% of the time during the fourth quarter of 2004, Amazon experienced outages during critical holiday periods that impaired customers’ ability to browse and shop. These and other outages during 2004, which resulted in lost revenue approaching $130 million, jeopardized Amazon’s relationships with retail custom- ers and Marketplace merchants. Determined to address these scale challenges, Amazon made 24-7 website availability its chief company goal for 2005. A related factor driving innovation was the need to reduce “latency.” Dur- ing the early 2000s Amazon’s software architecture was built in a siloed fashion that required particular functions to “call” data from databases. As website traffic geometrically increased, more nanoseconds were required to call these data, caus- ing webpages to load more slowly and respond less quickly to customer requests. Amazon believed that website latency frustrated customers, leading them to aban- don the page they were viewing or leave Amazon’s site altogether. Another factor driving innovation was the need to protect customer data and prevent fraud. Computer hackers and other bad actors posed increasing security - 32 - risks through cyber-attacks of various kinds. After 2005 security became a major focus of investment for Amazon. It dedicated large teams of software engineers to create innovative security protocols designed to repel cyber-attacks, keep its web- site up, protect customer information, and maintain customer trust. The advent of new technologies, such as smartphones, likewise propelled innovation. Smartphones enabled customers to view products and make purchases through mobile networks; younger customers were especially prone to doing this. An online retailer risked losing these customers if it did not meet their demands. Because the online retail environment was changing so rapidly, Amazon believed it impossible to anticipate technological advances more than three years away. B. Evolution of Amazon’s Website Architecture In January 2005 Amazon knew that many components of its website archi- tecture would not meet its long-term needs. Its engineers, who never lacked self- confidence, believed that they would succeed in meeting future challenges as they appeared. But they did not know how they would do this. When Amazon.com was launched in 1995, its website ran on Obidos, a single monolithic application atop an Oracle database.8 Its user interface code, 8 In software engineering, a monolithic application describes a single-tiered software application in which the user interface and the data access code are (continued...) - 33 - database connections, and business logic were heavily interdependent. As traffic to Amazon’s website increased, it added more and more servers, called “onlines,” each running a web server and an instance of the monolithic Obidos code. The Obidos application was written in “catsubst,” an arcane programming language that Amazon created. Significant engineering effort was required to per- form even basic tasks. The manner in which Obidos was written made it difficult to identify “dependencies,” i.e., instances in which specific parts of the code de- pended on specific other parts of the code. Since any change to the Obidos code might affect many applications, a team desiring to modify one application had to get input from multiple engineering groups. This became a cumbersome process. Obidos was also subject to “death spirals.” Until 2000, every Obidos pro- cess, no matter how short lived, created its own database connections by calling databases directly, without coordinating requests across the different onlines. When too many onlines were seeking the same database resources, error condi- tions called “timeouts” would occur. The Obidos process would then throw a fatal error and restart, creating new database connections without properly releasing the old ones. As database connections piled up, calls from other Obidos processes to 8 (...continued) combined into a single program from a single computer system or network. - 34 - the databases would time out, throwing more fatal errors. When these “death spi- rals” occurred, the affected website could become unavailable for an hour or more. As the number of Amazon’s customers grew, such crashes became more common. By 2002 Amazon had moved six services out of Obidos: By reducing the load on Obidos it was able to handle a higher volume of web traffic. Although Amazon’s chief technology officer declared in 2005 that the Obidos architecture had reached its “end of life” in 2001, 98% of Amazon’s retail webpages still ran on Obidos as of January 2005. By May of that year there was real concern that Amazon’s website would not be able to scale through the holiday season if it con- tinued to run on Obidos. Great effort was expended to move a significant amount of traffic off Obidos and onto a service-oriented architecture known as Gurupa. Amazon transitioned rapidly away from Obidos during 2005 and ceased using it altogether on August 31, 2006. Amazon began its shift toward a service-oriented architecture around 2002. “Service-oriented architecture” describes software designed as a set of small, inde- pendent programs or “services”; the services work together to perform complex tasks. In this model, each service needs to understand how to interact only with those other functions with which it has actual contact. This differentiates it from a monolithic model, where each function must understand how to interact with - 35 - every other function in a larger program. Amazon did not invent service-oriented architecture, which was a well-known concept in the computer industry. Amazon built this new architecture on a Gurupa engine, which received re- quests from a web server, sent the requests to services or applications, and re- turned responses to the web server. The engine did not create webpage content; instead, it sent requests to applications that, in coordination with services, created and returned webpage content to the server. The role of the Gurupa engine, in effect, was to stitch together dynamic webpages. The transition from Obidos to Gurupa was an architectural shift from a monolithic to a distributed system and involved rewriting software in different programming languages. Amazon decided to abandon catsubst for building web- pages and shifted to a programming language known as Perl and a templating lan- guage known as Mason (the duo was called “Perl/Mason”). Amazon could reuse very little of the Obidos software when it moved to Gurupa. And many concepts that underlay the monolithic architecture were not applicable to a distributed system. Amazon displayed its first Perl/Mason page in August 2005, but very few European webpages were generated using Perl/Mason and Gurupa until 2006. Problems with the new architecture soon emerged. Webpages created in Perl/Mason and rendered using the Gurupa engine took longer to appear in a - 36 - user’s browser than comparable Obidos pages. Gurupa’s throughput--the number of webpages that could be displayed per second--was less than a tenth of Obidos’ in August 2005. One reason was that Gurupa at the time did not support parallel rendering or “streaming.” Rather than loading webpages sequentially, streaming enables different parts of a webpage to be loaded simultaneously, permitting the customer to view part of the page while the rest is being delivered to his or her web browser. Streaming capabilities were increasingly prevalent on Amazon’s competitors’ websites, and their absence at Amazon negatively affected its customers’ shopping experience. Another problem was that the services called by the Gurupa engine were developed in “silos” rather than as an integrated system. In certain situations, these services suffered from “circular dependencies,” that is, links that eventually connect code back to itself, which can cause the software to crash after a code change. Because of lack of coordination between service “silos,” code was often written that duplicated existing functionality. These structural problems increased as Amazon created new services and expanded its website capabilities. Because the Gurupa architecture was a set of disconnected silos rather than a technology platform, many of Amazon’s engineers regarded it as “dramatically unreliable from the first day.” Amazon found it increasingly difficult to hire pro- - 37 - grammers eager to work in this environment: Typically trained in Java and C++, they came to regard Perl/Mason as a “dead language.” In October 2009 Gurupa instances running the U.S. website were expected to crash with unacceptable fre- quency if not killed and restarted. In September 2006 Amazon hired Brian Valentine to envision and lead the development of a new eCommerce platform. He regarded Gurupa as an unreliable application and put it on “life support” shortly after he arrived. He testified that his unit had to devote most of its efforts to “keeping the lights on”--that is, keep- ing Amazon’s websites from crashing on Gurupa--rather than pursuing innovative projects. By 2012 Amazon had migrated most of its website platform from Gur- upa to Santana, but it was still using Gurupa for some applications as late as No- vember 2014. Mr. Valentine’s goal was to create a true technology platform, with a central and standardized set of services and a uniform interface for interacting with those services. A key feature of this platform was Santana, a Java-based web hosting service and rendering engine that addressed Gurupa’s performance and stability problems. Santana was first deployed on an Amazon website in 2007; by 2008 Amazon had chosen Santana as its preferred architecture for future software devel- opment projects. This shift to Santana required Amazon to rewrite virtually all of - 38 - its eCommerce services, and the new platform thus took much longer to build and implement than Amazon had expected. The new platform was vastly superior to its predecessor. Java was more efficient and performance oriented than Perl/Mason, and it was a modern pro- gramming language that made hiring easier. Java reduced the parallel rendering problem that had plagued Gurupa, and it significantly reduced latency. Java was superior for streaming digital content and, in conjunction with Santana, it provided much better throughput. C. Evolution of Amazon’s Software Applications Corresponding to these major shifts in Amazon’s software architecture, the applications or “services” that performed specific business functions underwent constant change. The shift to Santana required almost everything from Gurupa to be rewritten or thrown out. Representative examples are discussed below. 1. Customer Master Service Launched around 2000, Customer Master Service (CMS) was the first ser- vice launched in Amazon’s move toward a service-oriented architecture. CMS initially had limited ambitions, simply allowing customers to change their user names or passwords. As a result of constant revision its functionality was vastly expanded. CMS eventually functioned as a “broker” between the database storing - 39 - Amazon’s customer information and the various retail segments (e.g., service cen- ters, fulfillment centers, and the website) that needed this customer information. By fall 2004 CMS had grown very large, complex, and fragile as Amazon’s evolving business requirements necessitated constant changes to the software. CMS became a bottleneck and experienced more than 50 hours of outages during the December 2004 holiday season. To address these problems, Amazon em- barked on a complete re-architecture of CMS during 2005 and 2006. At the time of trial, CMS no longer existed, having been replaced by new software known as Identity Service. 2. Order Master Service “Ordering” includes the steps whereby a customer places an order, payment is authorized, a shipment request is prepared, and the order is handed off for ful- fillment. This requires interactions with many other parts of Amazon’s software, including the systems managing fraud prevention, payment, sales tax collection, and fulfillment. Amazon developed Order Master Service (OMS) around 2000 to handle key aspects of shopping carts, orders, shipments, and related business logic and messaging. Although it was built outside of Obidos, it resembled Obidos in being a large monolithic program that was difficult to support. - 40 - By spring 2004 OMS was causing bottlenecks that generated fatal errors in 1% of all customer sessions, frustrating customers and generating other problems. Amazon’s engineers referred to OMS as “the new Obidos” because it “created long lead times for bug fixes and new features and needlessly tied together unre- lated product launches.” Amazon concluded that OMS needed to be substantially rewritten to simplify it and decouple it from the software handling payments, pro- motion, shopping cart, and fulfillment. Beginning in 2006 Amazon’s engineers “refactored” OMS into several different services.9 The software was rewritten in a way that allowed multiple teams of programmers--e.g., those writing software for payments and sales tax collection--to work in parallel, thereby improving efficiency and avoiding time- consuming collaboration. By January 1, 2010, there was virtually nothing left of the OMS software that existed in 2005. 3. Dynamo An important component of Amazon’s ordering technology is its much- imitated “shopping cart,” which allows customers to save items they intend to purchase in a single location while they continue to shop. Amazon initially stored 9 “Refactoring” means changing the internal structure of source code to improve its efficiency--e.g., by removing dead code and unwanted dependencies-- without changing its essential function or external behavior. - 41 - shopping cart information in an Oracle database. By the end of 2004 Amazon’s overloaded shopping carts were driving the Oracle databases to operate beyond the limits of their capability, causing multi-day outages in 2004. In early 2005 Ama- zon’s shopping cart had “low availability,” which meant that customers could put items in their carts, experience a session crash, and return to find their carts empty. During 2005-2006 Amazon’s engineers developed a high-availability system called “Dynamo” to replace the Oracle databases. Dynamo was fully implemented during 2007 and lasted about five years before it needed to be replaced. 4. Payments Amazon’s Payments software manages and secures payment transactions with both retail customers and merchants. By late 2004 this software was experi- encing stress. To keep Payments running during the 2004 holiday season, Ama- zon’s engineers had to work around the clock, sleeping in hotels close to its data- centers so they could be available in the event of an emergency. By 2005, simply adding a new payment method required changing multiple services and consumed several months of an engineer’s time. Amazon’s engineers described the state of the Payments system as “pretty dire” in 2006, when slow transaction processing caused it to lose a significant amount of revenues. Concluding that small-scale revisions would not do the trick, Amazon decided (in the words of Distinguished - 42 - Engineer Vosshal) to “declare bankruptcy on Payments and just start over.” The engineering team completely rewrote this software between 2006 and 2011, re- placing all but “a few lines of code that may persist in the dark corners.” 5. Item Master Amazon stores information about products offered on its websites in data- bases referred to as “the catalog.” In 2001 Amazon began developing software called Item Master as a single repository for product information. This software allowed Merchants and suppliers to add items to Amazon’s catalog and maintain current, accurate descriptions of these products and their attributes. Item Master went through three major revisions between 2001 and 2010. By 2004 the software (then in its second version) was encountering scale limita- tions and lacked functionality that Amazon’s expanding business required. For example, Item Master was unable to identify situations where items listed by dif- ferent sellers were in fact the same item; this damaged the customer experience by returning multiple search results in response to a query for a single product. To address these and other challenges, Amazon in 2006 began developing a third version of the software, Item Master v3. Item Master v3 rebuilt the process for listing and describing items in the catalog and entailed a substantial rewrite of - 43 - Item Master v2. Item Master v3 was deployed in 2007 and ran concurrently with Item Master v2 until 2010, when the latter was shut down. 6. Personalization Amazon’s personalization technology includes “Recommendations” and “Similarities.” The “Recommendations” software tracks information about a cus- tomer and suggests products he or she might wish to buy on the basis of prior pur- chases. The “Similarities” software suggests items that resemble or are compatible with an item for which the customer is shopping (e.g., “customers who bought this item also bought item X,” or “this item and Item Y are frequently bought togeth- er”). Personalization poses two sets of problems. One set involves the algorith- mic (or mathematical) challenges posed by a constant effort to refine the accuracy of items suggested as “similar” or “recommended.” The second set of problems involves scaling: As the number of customers, prior purchases, and products for sale grows geometrically, the number of links between these variables, and the data that must be searched to make “recommendations” and propose “similarities,” grows almost exponentially. As of January 2005, Amazon’s Similarities software was scaling very poorly and faced significant challenges related to latency. The technology could not keep - 44 - up with the rapid growth of available data; as it took longer to update data, simi- larities could not be detected using the most recent data. This inability to scale reduced the technology’s value. During 2004-2005 Amazon tried to build a new Similarities engine with in- creased scaling capacity, but that effort failed. During 2005-2006, Amazon built and launched a third Similarities engine that engineers described as “a complete rethinking of the problem” and “a total game changer.” By employing “vastly more efficient algorithms,” the new Similarities engine achieved speeds 40 times faster than its predecessor’s. It significantly reduced the time needed to assemble and update Similarities data. Amazon’s Recommendations software likewise faced algorithmic, scale, and latency challenges. Because Amazon did not know which customers would visit when, the software had to process large volumes of data very rapidly in real time. Its algorithms had to select from and account for a wide variety of inputs in determining exactly which items would be recommended; for example, a purchase of patio furniture years ago would not yield useful recommendations for a cus- tomer now shopping for a computer. In an effort to ameliorate latency problems, Amazon rewrote Recommendations between May 2005 and May 2006, reducing its 60,000 lines of code to fewer than 15,000 lines. This redesign significantly - 45 - improved performance. Because of “substantial changes across every major com- ponent” of the Personalization technology, Amazon’s engineers estimated that the contribution of that software, as it existed in January 2005, was “no longer mate- rial” within six years. 7. Messaging Once Amazon moved toward a service-oriented architecture, it required “messaging” software to enable the technological components underlying its web- site to communicate with each other in a unified way. In 2003 Amazon was using commercially available publish-subscribe (or “pub-sub”) messaging software sup- plied by TIBCO, a third party. TIBCO’s messaging service at the time was state- of-the-art, but it was being pushed to its limits by the uniquely heavy performance demands that Amazon was placing upon it. During the 2003 holiday season, failures in the TIBCO messaging software caused outages that could last hours at a time. In early 2004 Amazon’s engineers expressed concern that introduction of new services could bring down Amazon’s website because of the problems associated with TIBCO messaging software. Cis- co Systems, which supplied Amazon with routers and other networking equip- ment, informed the company that its routers, in conjunction with the TIBCO soft- ware, would not support the “scaling up” required for the 2004 holiday season. - 46 - In October 2004 Amazon stopped using TIBCO for its “biggest use cases.” It then explored developing its own pub-sub software to overcome TIBCO’s per- formance and scaling problems. Amazon ultimately created and deployed the Amazon Messaging Platform (AMP) in late 2007. D. New Products and Services After January 1, 2005 Many Amazon products and services familiar to consumers today did not exist in January 2005. These included Kindle, Amazon Prime, the Fire smart- phone, Fire TV, Amazon’s digital music and video offerings, cloud computing, and cloud storage services. Though some of these products and services were in development during 2005, none generated revenues until later. Kindle, Amazon’s eBook reader, enables customers to view digital books, newspapers, magazines, and blogs directly on the device. Kindle was prototyped in May 2005 and launched in the United States in November 2007. In October 2009, AEHT launched Kindle 2, a subsequent version of the device, in France, Germany, and the UK. Amazon Prime is a membership program that enables customers to receive free one-or two-day shipping and discounted overnight shipping along with other benefits. Amazon introduced Prime in the United States in 2005 and in Europe between 2007 and 2008. The Prime program required major changes to the tech- - 47 - nology used to operate Amazon’s fulfillment centers, especially during peak shop- ping periods. Items destined for Prime customers had to be picked, sorted, pack- aged, and shipped in a different manner from other items in order to ensure the expedited delivery that Amazon promised. Amazon introduced Amazon Unbox, a digital video download service, in September 2006, and it introduced Amazon MP3 in the United States in Septem- ber 2007. AEHT launched MP3 in Europe the following year. Digital media has become an increasingly important part of Amazon’s business. Amazon Web Services (AWS), the company’s cloud-computing business, was largely developed after January 2005. It was launched in the United States in 2006. It has grown significantly in terms of employee headcount, number of servers required to operate the business, and revenues generated. III. Amazon’s Third-Party Businesses A. Merchants.com In its M.com business, Amazon used the technology that powered its own retail websites to build and operate eCommerce websites for other merchants. Amazon’s principal M.com clients were large retailers doing business in the United States and abroad; there were no material differences between the tech- nology “packages” that domestic and foreign clients received. Amazon’s major - 48 - clients included Target in the United States, Marks & Spencer in the UK, Mother- care in the UK, and Sears Canada. Amazon’s contract with Target went into effect in 2001 and was initially set to expire in 2006; it was later extended several times via amendments. Amazon eventually decided to terminate the M.com program and shut it down altogether after 2010. M.com retailers sold their own products on their own branded websites; the third-party retailer was the seller of record and owned all the inventory. Although Amazon built and operated these sites, it remained “behind the scenes” as far as the retailer’s customers were concerned. The M.com sites employed the retailer’s web address, URL, trade name, and trademarks; M.com clients had no right to use Amazon’s marketing intangibles and received no information about Amazon’s own retail customers. The clients obtained, as part of the M.com “package,” the complete suite of Amazon’s website technology, including the customer service, fulfillment, and re- lated software that Amazon itself used. M.com clients received all of the software updates and upgrades that benefited Amazon’s own websites. There was no extra charge for these upgrades; they were included within the basic deal structure re- gardless of whether Amazon’s contract with the client included an explicit “fea- ture parity” clause. - 49 - For additional fees, M.com clients could also arrange to have Amazon per- form certain services for them, using Amazon’s own facilities. These services could include fulfillment, transportation, customer service, payment processing, fraud prevention, and/or marketing. Not all M.com clients chose to avail them- selves of these additional services. In some cases Amazon agreed to develop for M.com clients (again for additional fees) specific technologies that Amazon did not use in its own business. B. Associates and Syndicated Stores Through the M.com program, Amazon functioned essentially as a supplier of technology to other retailers. Through the Associates and Syndicated Stores programs, Amazon entered into relationships with third parties with the goal of en- hancing its own customer base. In both of the latter programs, Amazon paid refer- ral fees to the third party when its customers or website visitors made purchases from Amazon. Both programs were in operation in 2005-2006; only the Associ- ates program continues to operate today. In the Associates program, the third party or “associate” includes on its own website a link to Amazon’s site. When a visitor to the associate’s website “clicks through” to Amazon and makes a purchase, the associate earns a referral fee. As- sociates could be online retailers themselves, but more typically they maintain - 50 - content-specific sites or blogs that offer product reviews or similar information. Some have as their principal goal capturing web traffic and linking their viewers to Amazon and other sellers in order to earn commissions. Generally speaking, the associate earns a commission on any purchase the customer makes from Ama- zon within 24 hours of “clicking through” to Amazon’s site. Through Syndicated Stores, Amazon used its eCommerce technology to sell Amazon products through a third-party retailer’s website (called the “mirror site”). In this scenario Amazon was the merchant making the sale; it kept the associated retail markup and paid a referral fee to the Syndicated Stores partner. Although Amazon derived benefits from Syndicated Stores apart from customer referral-- because the partner was usually a web retailer, the program eliminated some com- petition--the fees Amazon paid were essentially payments for customer referrals. Notwithstanding their differences, petitioner viewed the Associates and Syndicated Stores programs similarly: The primary purpose of both was to drive customers to Amazon. It signed agreements with about 20 Syndicated Stores part- ners (including European partners) before discontinuing the program. Whereas these agreements were individually negotiated, agreements in the Associates pro- gram were not. The process by which an associate joined the program was sub- - 51 - stantially automated and the compensation terms were fixed and largely non- negotiable. The stated commission rates under both programs depended on product mix and sales volumes. Commission rates generally ranged from 4% to 8% in the Associates program and from 4% to 6% in the Syndicated Stores program. Refer- ral fees for Syndicated Stores partners generally had a per-unit cap; this meant that the effective commission rate could be lower than the nominal rate reflected in the contract. Amazon expected that most people referred to it under these programs would be converted into Amazon customers, on whose subsequent purchases no referral fees would be due. It was accordingly willing to pay relatively high up- front commissions for customer referrals. The average referral fee Amazon actu- ally paid under the Associates and Syndicated Stores programs was approximately 5.9% of referred sales.10 IV. The Buy-In Payment Petitioner knew that it had a duty to report the Project Goldcrest transac- tions on its Federal income tax returns. To assist it in discharging this responsi- 10 In July 2001 Amazon entered into a Syndicated Stores agreement with Waterstone’s, a UK retailer. It provided for a 5% referral fee, which could in- crease to 6% if certain aggregate sales thresholds were met. This agreement had an unusual feature whereby Amazon would also pay Waterstone’s a one-time bounty of £7 for new purchases by certain customers. - 52 - bility, it hired Deloitte LLP to calculate the required buy-in payment. In order to do this, Deloitte needed multi-year financial projections for the European busi- ness. Given the unpredictability of eCommerce revenue growth, Amazon for in- ternal budgeting purposes did not make financial projections more than 12 or 18 months out. It assigned its tax department the task of creating longer term projections for this occasion. The tax department started with Amazon’s historical financial data and the most recent income-statement forecast, which included projections for the next 18 months. In consultation with business and finance personnel, the team forecast growth rates for revenue, gross margins, operating expenses, and operating mar- gins for the U.S. and the European businesses. These projections covered calendar years 2005 through 2010. In 2006 Deloitte supplied Amazon with a “Transfer Pricing Documentation Report” to calculate the required buy-in payment. Deloitte determined that the best method for calculating the buy-in price was “an unspecified income-based method.” See sec. 1.482-4(a)(4), Income Tax Regs. Although the method De- loitte employed was not “specified” in the regulations, Deloitte regarded it as simi- lar in many respects to the specified residual profit split method. See sec. 1.482-6, Income Tax Regs. - 53 - Deloitte determined that the intangible assets Amazon US transferred to AEHT had a seven-year useful life. Relying on Amazon’s 2005-2010 projections (which Deloitte extrapolated to 2011), Deloitte determined the future income streams of AEHT reasonably attributable to these assets, then allocated those in- come streams between pre-existing and subsequently-developed intangible proper- ty. Deloitte determined that the appropriate buy-in price was $254.5 million, to be paid over a seven-year period commencing in 2005. At trial petitioner supported its position with respect to the buy-in payment principally on the basis of the comparable uncontrolled transaction (CUT) method. See sec. 1.482-4(c), Income Tax Regs. It contended that each species of intan- gible property--the website technology, the marketing intangibles, and the Euro- pean customer information--had to be valued separately. For each species of prop- erty, Amazon submitted expert reports that estimated the property’s useful life and valued it on the basis of available CUTs. Respondent contended that the best method for determining an arm’s-length buy-in payment was the discounted cash flow (DCF) methodology employed by Dr. Frisch. In the event the Court rejects that methodology, respondent submitted expert reports that employed a CUT methodology. For each species of property, - 54 - respondent’s experts supported values substantially higher than those determined by Amazon’s experts. For the website technology, petitioner’s experts derived a CUT by reference to the prices Amazon charged its M.com clients for the technology needed to run those clients’ eCommerce websites. Petitioner’s expert John Wills testified as to his belief that Amazon offered these M.com customers its full suite of website technologies together with all necessary services. He opined that the M.com transactions thus furnished appropriate internal CUTs for the technology that Amazon US made available to AEHT. Four of petitioner’s other technology experts--Ken Birman and Lorenzo Alvisi, David Parkes, and Alan MacCormack--employed various approaches to ascertain the useful life of Amazon’s website technology and the rate at which it would “ramp down” or decay in its utility. Applying these useful life conclusions to the pricing data derived from the M.com transactions, Dr. Wills concluded that the value of the website technology transferred by Amazon US to AEHT ranged between $117 million and $182 million. Respondent’s expert Harlow Higinbotham agreed that the CUT method could be used to value the pre-existing technology and that the M.com transactions supplied a reliable source of CUTs. However, he concluded that Amazon’s web- - 55 - site technology had an indefinite useful life. On the basis of his useful life deter- minations, Dr. Higinbotham valued the website technology transferred by Amazon US to AEHT at $3.34 billion. For the marketing intangibles, Robert Reilly (petitioner’s expert) and David Haigh (respondent’s expert) both used an external CUT methodology to determine an arm’s-length buy-in price. In selecting their CUTs, both experts also relied on the same sources of public information. But the two experts came to disparate value determinations, chiefly because of very different conclusions as to the useful life of the transferred property and the proper royalty rate to apply over the proper- ty’s useful life. Mr. Reilly concluded that the arm’s-length value of the marketing intangibles ranged from $251 million to $312 million; Mr. Haigh determined a value of $3.13 billion for the same intangible property. The customer information that Amazon US transferred to AEHT consisted of data about European retail customers who had transacted with the European Subsidiaries before May 1, 2006. These data included names, email addresses, phone numbers, purchasing history, and credit card information. Amazon viewed this customer information as having a short useful life: People change their phone numbers and email addresses often, and their buying habits change significantly - 56 - over time. For its Similarities software, Amazon uses only relatively recent data because it regards older data as having little or no value. Given the relatively short useful life of the customer information, Amazon’s experts regarded Amazon US as having in essence “referred” its European cus- tomers to AEHT, which then benefited from having a base of inherited customers when it began operations on May 1, 2006. Dr. Wills accordingly used as CUTs the referral fees that Amazon paid its business partners in the Associates and Syn- dicated Stores programs. Two of petitioner’s other experts--Wendy Moe and Robert Wentland-- performed analyses that estimated future purchases by the referred European customers and the rate at which these individuals would convert to direct cus- tomers of AEHT. Using these estimates, Dr. Wills applied a referral fee of 5.9%-- the average referral fee Amazon itself paid to its Associates and Syndicated Stores partners--for all purchases by customers deemed to arrive at AEHT’s websites by referral. Dr. Wills assumed that AEHT would pay referral fees for only six years, and he discounted the resulting revenue stream at 18%. This generated a buy-in payment of $52 million for the customer information that Amazon US made available to AEHT. Dr. Wills determined that this value would rise to $66 million if AEHT paid referral fees for 10 years. - 57 - Dr. Higinbotham agreed that the commissions Amazon paid third parties for customer referrals supplied appropriate CUTs. However, he gave particular weight to Amazon’s agreement with Waterstone’s, a Syndicated Stores partner in the UK. It provided not only for referral fees ranging from 5% to 6%, but also for a one-time bounty of £7 for new purchases by certain customers. Using these parameters, Dr. Higinbotham valued the customer information at $215 million. V. Cost Sharing Payments The CSA required AEHT to make annual cost sharing payments to compen- sate Amazon US for ongoing intangible development costs (IDCs), to the extent those IDCs (as determined by a revenue ratio) benefited the Luxembourg head- quarters. See sec. 1.482-7(a)(1), (d)(1), Income Tax Regs. Virtually all techno- logical innovation occurred within Amazon US. Thus, the larger the volume of IDCs that Amazon US is treated as having incurred, the larger the cost sharing payments that AEHT was required to make. The regulations define IDCs and provide that costs that contribute both to intangible development activity and to other business activities must be allocated “on a reasonable basis.” See id. para. (d)(1). Petitioner’s cost accounting system during 2005-2006 did not specifically segregate IDCs or R&D expenses from other operating costs. Petitioner therefore developed a formula and applied it to - 58 - allocate to IDCs a portion of the costs accumulated in various “cost centers” under its method of accounting. “Cost centers” are accounting classifications that enable a business to man- age and measure operating expenses. Petitioner tracked expenses in six high-level cost centers: (1) Cost of Sales, (2) Fulfillment, (3) Marketing, (4) Technology and Content (T&C), (5) General and Administrative (G&A), and (6) Other. Each of these high-level cost centers is a “rollup” of numerous subsidiary cost centers. For some calendar quarters, more than 200 individual cost centers, each recording a specific type of expense, “rolled up” into intermediate cost centers and ultimately into one of the six top-level cost centers. For example, cost center 7710, “Systems and Network Engineering,” rolls up into C210 (“Product Development”) and C250 (“Technology/External”). All costs accumulated in “Product Development” and “Technology/External” roll up into the T&C category. The parties agree that none of the costs accumulated in the “Cost of Sales” and “Other” categories are allocable to IDCs. Respondent accepts petitioner’s formula-based allocation to IDCs of costs accumulated in the “Fulfillment” and “Marketing” categories, and he accepts petitioner’s decision to allocate G&A costs to IDCs on the basis of the IDC outcomes for the other five categories. - 59 - The parties’ dispute focuses on the T&C category. Respondent contends that 100% of the costs accumulated in the T&C category constitute IDCs; as a corollary, this would produce a commensurate increase in the percentage of G&A costs allocable to IDCs. Petitioner urges that T&C costs must be allocated be- tween IDCs and other activities “on a reasonable basis” and that its allocation formula accomplishes this result. Broadly speaking, the costs accumulated in the T&C category include ex- penses related to technological development and website content. According to petitioner’s SEC filings, its T&C category expenses “consist principally of payroll and related expenses for employees involved in research and development, includ- ing application development, editorial content, merchandising selection, systems and telecommunications support, and costs associated with the systems and tele- communications infrastructure.” T&C costs included costs associated with ac- quired website content; payroll and related expenses for employees involved in research, website development, and telecommunications support; and payroll and related expenses for employees involved in category expansion (i.e., expanding Amazon’s product offerings) and buying. During 2005-2006 many employees whose time was captured in T&C cost centers engaged solely in intangible development activity; certain employees en- - 60 - gaged solely in other types of activity; and certain employees engaged in both. This diversity of tasks was reflected in their job classifications. All Amazon em- ployees have job codes beginning with a capital letter, one of which is “T,” which stands for “Technical.” Most cost centers that rolled up into T&C have a mix of T-coded and non-T-coded workers. During the first quarter of 2006, for example, 35 T&C cost centers had no T-coded employees; 27 had all T-coded employees; and 69 had a mix. On average during 2005-2006, there were almost as many T&C cost centers with no T-coded employees (31.4 cost centers) as there were with all T-coded employees (31.9 cost centers). The subsidiary cost centers that “rolled up” into T&C captured a significant volume of non-IDC personnel costs. The diversity of the employees’ tasks, which is reflected in their annual performance evaluations,11 is illustrated by these exam- ples: • Employees in cost center 5155 manage third-party digital content that is viewed on or downloaded from Amazon.com. Certain employees manage the “customer purchasing experience.” Other employees spend time negotiating and 11 The performance evaluations show that certain employees whose time was captured in T&C cost centers engaged in substantial non-IDC activity. Relevant cost centers include 7334, New Product Development; 7823, Data Warehouse Development; 5355, Large Accounts Services Account Management; and 7402, Payments Platform. - 61 - managing the logistics of acquiring website content from third parties and deter- mining how this website content will be displayed to Amazon’s customers. • Employees in cost center 5357 build and improve technology that helps sellers integrate their products into Amazon.com. Some employees spend signif- icant time helping sellers list their products. This includes assisting sellers in filling out spreadsheets and directing their submissions to other Amazon staff members. • Employees in cost center 7723 design, expand, and maintain Amazon’s product catalog. Some write code to compile and display the catalog or to allow customers to place orders. Others engage in routine maintenance and make minor code adjustments to alter the manner in which website content is displayed. Because petitioner’s T&C cost centers, like its Fulfillment, Marketing, and G&A cost centers, captured both IDCs and other costs, it devised a complex, mul- ti-step formula to allocate costs “between the intangible development area and the other areas or business activities.” See sec. 1.482-7(d)(1), Income Tax Regs. The details of this formula have varied over time. The formula that petitioner urged at trial employed data derived from a PricewaterhouseCoopers (PwC) study that identified qualifying research activities for purposes of claiming section 41 re- search and experimentation (R&E) credits for 2005 and 2006. - 62 - Because Amazon’s employees did not record time specifically to R&E activities, the PwC study relied heavily on employee surveys. Most employees in T&C cost centers, regardless of job code, were surveyed. Some employees outside of T&C cost centers were surveyed if petitioner believed they engaged in quali- fying research. In these surveys PwC asked employees to complete questionnaires on which they divided their time among 14 specified activities. Eight of these activities involved software development, from the initial “requirements” phase through deployment and testing, together with direct supervision and direct support of software development. The time devoted to these eight activities was deemed to yield qualifying R&E expenses for section 41 purposes. Time devoted to five types of activities--specifically, routine engineering, routine data collection, re- verse engineering, human resources/training, and activities outside the United States--was deemed not to yield qualifying R&E expenses for section 41 purposes. The 14th category captured days when no work was done, such as vacation days, sick days, and holidays. From these surveys, PwC derived estimates to allocate employee time to section 41 qualifying activities. For each surveyed employee, PwC computed a “qualified research expenditure” (QRE) percentage, reflecting the portion of that - 63 - person’s time that was spent on qualified research. In the fourth quarter of 2006, for example, the average QRE percentage for employees in the 7000 series of cost centers (capturing costs related to technology development, maintenance, and management) was 61.15%. In that same quarter the average QRE percentage for employees in the 5000 series of cost centers (capturing costs related to business line management) was 53.41%. PwC used these percentages in determining the section 41 credit to which it believed Amazon was entitled. Noting the similarity between section 41 qualified research expenditures and IDCs, Amazon employed the PwC survey data as a central component of its formula for allocating costs under section 1.482-7(d)(1), Income Tax Regs. Sim- plifying somewhat, petitioner’s formula for allocating T&C category costs be- tween IDCs and other activities proceeds in several steps. As the first step, peti- tioner eliminated from the T&C cost centers all costs captured in 26 general ledger accounts that petitioner determined to be unrelated to intangible development. The resulting sum may be called “modified T&C category costs.” As the second step, petitioner identified the employees within the T&C cate- gory who were likely to have engaged in intangible development. Assuming that only T-coded employees were likely to have done this, petitioner divided the num- ber of such employees by the total number of employees in the T&C category. - 64 - This yielded what petitioner called the “T-ratio.” Petitioner calculated a distinct T-ratio for the T&C category for each calendar quarter during 2005-2006. The next step was to examine the QRE survey results. Petitioner adjusted the PwC data to reflect the fact that certain costs ineligible for the section 41 credit (e.g., costs attributable to reverse engineering and non-U.S. activities) may prop- erly be includible in IDCs. Petitioner accordingly determined an “adjusted QRE percentage” for each person in the T&C category, representing the portion of that person’s time spent on intangible development. Petitioner computed the arith- metic average of these “adjusted QRE percentages,” which it called the “adjusted QRE ratio” or “A-ratio.”12 Petitioner then multiplied the T-ratio by the A-ratio to yield a “development ratio” for the T&C category. Finally, petitioner multiplied “modified T&C category costs” (as determined at step 1) by the “development ratio” to determine the dollar volume of T&C category costs properly allocable to IDCs. Petitioner made separate computations for each calendar quarter and summed these results to produce annual IDC figures for the T&C category.13 12 If there was no PwC survey data for a particular T&C cost center--e.g., be- cause that cost center was recently created or because it was determined not to contribute to section 41 qualifying research--petitioner applied the average A-ratio for cost centers with available survey data. 13 Petitioner employed a similar methodology to determine the percentage of (continued...) - 65 - On its 2005 and 2006 Federal income tax returns, petitioner reported cost sharing payments from AEHT of $116,092,584 and $77,297,000, respectively. (These amounts were reported as reimbursed R&E expenses, thus reducing other- wise-allowable deductions.) The cost sharing payment for 2006 was determined using the PwC survey data as described previously. Because the PwC data were not available when petitioner filed its 2005 return, it initially used a different sys- tem to determine the 2005 cost sharing payment. It subsequently filed an affirma- tive claim for 2005, reporting a lower cost sharing payment computed under the methodology used for 2006. By this affirmative claim, petitioner sought to reduce the 2005 cost sharing payment by approximately $59 million, or almost 50%. VI. Stock-Based Compensation The CSA executed by Amazon US and AEHT defined IDCs to “include all direct and indirect costs (including Stock-Based Compensation Costs)” relating to intangible development. Specifically, IDCs were defined to include “compensa- tion provided by a Party to its employees or independent contractors in the form of equity instruments, options to acquire stock, or rights with respect to * * * equity 13 (...continued) G&A category costs allocable to IDCs. Respondent does not object to the G&A methodology, except to the extent that it employs what respondent views as an unduly low allocation of IDCs to the T&C category. - 66 - instruments or stock options as defined in Treasury Regulation § 1.482-7(d)(2)(i) (as amended by T.D. 9088).” The parties further elected, pursuant to section 1.482-7(d)(2)(iii)(B), Income Tax Regs., to take into account “all stock-based compensation in the form of stock options in the same amount, and as of the same time, as the fair value of the stock options reflected as a charge against income in the audited financial statements of a Party.” This election was made “without pre- judice to the Party’s right to challenge the validity of Treasury Regulation § 1.482- 7(d)(2).” In filing its 2005 and 2006 returns, petitioner thus complied with the reg- ulation requiring that stock-based compensation be included in the IDC “cost pool” upon which cost sharing payments are determined. Like many technology companies, petitioner questioned the validity of this regulation. The CSA ac- cordingly included a “clawback” provision that will apply in the event section 1.482-7(d)(2), Income Tax Regs., is held to be an invalid regulation by a final decision in a court of law with respect to pending litigation involving another taxpayer including a U.S. Supreme Court decision, U.S. Court of Appeals decision upon denial of a writ of certiorari or lapse of time for filing such writ, or a decision by a federal trial court upon lapse of time for filing a notice of appeal, or * * * [is] revised or withdrawn by the Treasury Department such that the costs of stock-based compensation are not required to be included as costs for qualified cost sharing arrangements. - 67 - In the event this regulation is ultimately invalidated or withdrawn, the CSA provides that “stock-based compensation shall not be included in the determina- tion of * * * [IDCs] in any Year to which this Agreement applies.” For any year in which stock-based compensation turns out to have been “improperly” included in IDCs, “the Cost Share shall be recomputed without the inclusion of stock-based compensation in * * * [IDCs],” and “the Cost Share less the Recomputed Cost Share shall be refunded * * * [to the proper party].” The CSA provides that any such refund shall be “treated as an adjustment to the Cost Share for the Year in which the Triggering Event occurs * * *, and to the extent that such adjustment exceeds the Cost Share, the adjustment shall be applied to subsequent Years until fully exhausted.” In Altera Corp. v. Commissioner, 145 T.C. 91 (2015), this Court invalidated section 1.482-7(d)(2), Income Tax Regs., the provision that requires stock-based compensation costs to be included in the IDC pool. Our decision in that case was appealed to the U.S. Court of Appeals for the Ninth Circuit on February 19, 2016. The case remains pending on appeal. OPINION Section 482 gives the Commissioner broad authority to allocate gross in- come and deductions among commonly controlled entities if he determines that it - 68 - is necessary “to prevent evasion of taxes or clearly to reflect the income.” The purpose of section 482 is prevent artificial shifting of income by placing a con- trolled taxpayer on a tax parity with an uncontrolled taxpayer. Sec. 1.482-1(a)(1), Income Tax Regs. The statute empowers the Commissioner to determine the “true taxable income” of a controlled taxpayer by ascertaining the income it would have earned if it had dealt with unrelated parties at arm’s length. See Commissioner v. First Sec. Bank, 405 U.S. 394, 400 (1972); Seagate Tech., Inc. & Consol. Subs. v. Commissioner, 102 T.C. 149, 163-164 (1994). “In determining the true taxable income, ‘the standard to be applied in every case is that of a taxpayer dealing at arm’s length with an uncontrolled taxpayer.’” Veritas, 133 T.C. at 317 (quoting section 1.482-1(b)(1), Income Tax Regs.). The Commissioner has broad discretion in applying section 482, and we will uphold his determination unless the taxpayer shows it to be arbitrary, capri- cious, or unreasonable. Seagate Tech., 102 T.C. at 164; Sundstrand Corp. v. Com- missioner, 96 T.C. 226, 353 (1991). Whether respondent has abused his discretion is a question of fact. Sundstrand Corp., 96 T.C. at 353-354; Am. Terrazzo Strip Co. v. Commissioner, 56 T.C. 961, 971 (1971). In a series of transactions in 2005 and 2006, Amazon US transferred intan- gible property to AEHT. These transfers required AEHT to make an upfront buy- - 69 - in payment to compensate Amazon US for the value of the assets thus transferred. See sec. 1.482-7(a)(2), (g)(2), Income Tax Regs. Respondent urges that a DCF methodology, as implemented by Dr. Frisch, supplies the best method for determining an arm’s-length buy-in payment, and that the required payment is $3.468 billion. The first question we must answer is whether respondent abused his discretion in making this determination. We conclude that he did. I. Cost Sharing Background We begin our analysis with the regulations in effect in 2005 when Amazon US and AEHT entered into the CSA. Where parties have entered into a qualified cost sharing arrangement (QCSA), they share the cost of developing intangible property. See id. para. (a)(1). When one participant (here, Amazon US) makes pre-existing intangible property available for purposes of research under a QCSA, that party is deemed to have transferred an interest in such property to the other participant. This requires the other participant (here, AEHT) to make a “buy-in payment” to the transferor. Id. para. (g)(1) and (2). The required buy-in payment “is the arm’s length charge for the use of the intangible” multiplied by the controlled participant’s share of reasonably antici- pated benefits. Id. subpara. (2). The best-method rule, set forth elsewhere in the regulations, “seeks the most reliable measure of an arm’s-length result.” Veritas, - 70 - 133 T.C. at 327; see sec. 1.482-1(c)(1), Income Tax Regs. The regulations pro- vide that an arm’s-length charge must be determined under one of four methods: (1) the comparable uncontrolled transaction (CUT) method; (2) the “comparable profits” method; (3) the “profit split” method; or (4) an “unspecified” method. See sec. 1.482-1(c), Income Tax Regs. “[T]here is no strict priority of methods, and no method will invariably be considered to be more reliable than others.” Veritas, 133 T.C. at 327; sec. 1.482-1(c)(1), Income Tax Regs. The regulations make clear that the buy-in payment represents compensa- tion solely for the use of pre-existing intangibles. Section 1.482-7(g)(2), Income Tax Regs., captioned “Pre-existing intangibles,” states: If a controlled participant makes pre-existing intangible property in which it owns an interest available to other controlled participants for purposes of research in the intangible development area under a qualified cost sharing arrangement, then each such other controlled participant must make a buy-in payment to the owner. * * * By definition, compensation for subsequently developed intangible property is not covered by the buy-in payment. Rather, it is covered by future cost sharing pay- ments, whereby each QCSA participant pays its ratable share of ongoing IDCs. As in effect during 2005-2006, the regulations provided that the Commis- sioner “shall not make allocations with respect to a qualified cost sharing arrange- ment” except in two respects. Id. para. (a)(2). Specifically, adjustments are per- - 71 - mitted only to ensure: (1) that an arm’s-length buy-in payment is made for pre- existing intangible property and (2) that each participant pays its appropriate share of ongoing IDCs. This Court interpreted and applied these cost sharing regulations in Veritas, supra. The taxpayer there, a domestic corporation (Veritas US), developed, manu- factured, and sold throughout the world advanced storage-management software products. Pursuant to a QCSA executed in November 1999, Veritas US granted a European subsidiary (Veritas Ireland) the right to use pre-existing intangible prop- erty overseas. The assets thus transferred consisted of short-lived technology, including source code for software products to be sold outside the United States, as well as the right to use outside the United States trademarks, trade names, and service marks owned by Veritas US. Veritas Ireland made a buy-in payment of $118 million for use of these pre-existing intangibles. The IRS challenged the buy-in payment and ultimately determined that the required buy-in payment was $1.675 billion. Veritas, 133 T.C. at 312. The Com- missioner’s expert, Dr. Hatch, “assumed that the preexisting intangibles ha[d] a perpetual useful life” and “characterized the CSA as ‘akin’ to a sale or geographic spinoff” of the U.S. parent’s international business operations. Id. at 313. Dr. Hatch “rejected the comparable uncontrolled transaction method” and “employ[ed] - 72 - a discounted cashflow analysis”--specifically, “the income method”--to determine the requisite buy-in payment. Id. at 312, 313. Dr. Hatch defined the buy-in payment as “the present value of royalty obli- gations” expected to be paid in perpetuity under arm’s-length terms. Id. at 313. He did not value individually any of the specific intangible assets that Veritas US transferred to its Irish subsidiary. Instead, “he employed an ‘aggregate’ valuation approach” that proceeded in three steps. First, he estimated the arm’s-length royalty that would be due after November 1999 “on a go-forward basis.” Ibid. Second, he chose a discount rate to convert these estimated future royalty pay- ments into November 1999 dollars. Third, he “calculated the buy-in payment as equal to the present value of the royalty payments estimated in step 1, discounted at the rate determined in step 2.” Ibid. This produced a buy-in payment of $1.675 billion, which Dr. Hatch determined to be economically equivalent to “a 22.2 per- cent perpetual annual royalty.” Ibid. We held that the buy-in payment thus determined represented an abuse of discretion. Id. at 327. Although we found several deficiencies in Dr. Hatch’s methodology, his core error was to value “short-lived intangibles * * * as if they have a perpetual life.” Id. at 321. We found that Veritas US “was in a perpetual mode of innovation” and that the useful life of the pre-existing technology-related - 73 - intangibles was four years. Id. at 324, 336. We found that the useful life of the trademarks, brand names, and other marketing intangibles was seven years. Id. at 338. It was unreasonable, we concluded, for respondent to determine the buy-in payment by assuming that a third party, acting at arm’s length, would pay royalties in perpetuity for use of these short-lived assets. As we emphasized in Veritas, the cost sharing regulations “unequivocally require[] a buy-in payment to be made with respect to transfers of ‘pre-existing intangible property.’ No buy-in payment is required for subsequently developed intangibles.” Id. at 323. By valuing “short-lived intangibles * * * as if they have a perpetual life,” the Commissioner’s buy-in computation improperly took into ac- count the value of “intangibles that were subsequently developed rather than pre- existing.” Id. at 321. We concluded in Veritas that reliable CUTs existed for each form of intangible property transferred pursuant to the QCSA and that, with cer- tain adjustments, “the CUT method is the best method for determining the requi- site buy-in payment.” Id. at 339. II. Respondent’s Determination of the Buy-In Payment In this case respondent’s primary position as to the appropriate buy-in pay- ment was set forth in the expert report of Dr. Frisch. Like Dr. Hatch in Veritas, Dr. Frisch rejected use of the CUT method and applied a DCF methodology to - 74 - determine AEHT’s buy-in obligation. His valuation, like that of Dr. Hatch, pro- ceeded in three main steps. First, he estimated the future cash flows of AEHT’s European business. Second, he selected a discount rate to convert these estimated cash flows into 2005 dollars. Third, he calculated the buy-in payment as equal to the present value of the cash flows determined at step 1, discounted at the rate de- termined in step 2. For step 1, Dr. Frisch started with the projections by Amazon’s management of revenues, expenses, and operating income for the European business for calendar years 2005 through 2011.14 For years after 2011 Dr. Frisch assumed that the revenues, expenses, and operating income of the European business would grow at 3.8% per year, the rate at which the EU economy as a whole was projected to grow.15 With these assumptions, Dr. Frisch projected AEHT’s operating in- come into the indefinite future. Believing that future cash flows, rather than operating income, would yield the best estimate of an appropriate buy-in payment, Dr. Frisch made several ad- 14 We will refer to these seven-year figures as “projections by Amazon’s management” even though the figures for 2011 were extrapolated by Deloitte. 15 We find no fault with this assumption. As will be discussed later, various experts expressed divergent views as to how AEHT’s growth rate should be calcu- lated after 2011. Dr. Frisch’s decision to drop down to the long-term projected growth rate of the European economy was conservative and reasonable. - 75 - justments to AEHT’s projected operating income. First, he subtracted the cost sharing payments that AEHT was projected to make to Amazon US under the QCSA. Second, he added back expected depreciation because it involves no out- lay of cash. Third, he subtracted AEHT’s projected future capital expenditures. Finally, he made adjustments based on AEHT’s projected working capital. After estimating AEHT’s future free cash flows, Dr. Frisch moved to step 2 of his analysis: selecting an appropriate discount rate. Generally speaking, the higher the discount rate, the lower the present value of future cash flows. For in- ternal budgeting purposes, Amazon’s treasury department employed a weighted average cost of capital (WACC) of 13%. Using market data, Dr. Frisch concluded that a discount rate of 18% was appropriate. At step 3, Dr. Frisch discounted AEHT’s future cash flows through 2024-- i.e., for 20 years out--at 18%. He determined that the present value of these cash flows was $3.067 billion. He then computed a discounted “terminal value” of $399 million for post-2024 cash flows; this calculation was necessary because he assumed that the intangible property subject to the buy-in payment had a perpetual (he called it an “indeterminate”) useful life. Finally, to isolate the future cash flows attributable to AEHT’s intangible assets, Dr. Frisch subtracted the value of the tangible assets it owned as of year-end 2004, which he determined to be neg- - 76 - ative $1.8 million (representing a negative cash position). This yielded a buy-in payment of $3.468 billion ($3.067 billion + $399 million + $1.8 million = $3.468 billion). One does not need a Ph.D. in economics to appreciate the essential similar- ity between the DCF methodology that Dr. Hatch employed in Veritas and the DCF methodology that Dr. Frisch employed here. Both assumed that the pre- existing intangibles transferred under the QCSA had a perpetual useful life; both determined the buy-in payment by valuing into perpetuity the cash flows sup- posedly attributable to these pre-existing intangibles; and both in effect treated the transfer of pre-existing intangibles as economically equivalent to the sale of an en- tire business. Respondent admitted as much on brief, urging that “Project Gold- crest transferred all cash flows relating to the European operation to AEHT in what was, as an economic matter, a transfer of the European Websites Business for the indefinite future.” By assuming a perpetual useful life, Dr. Frisch failed to restrict his valuation to the “pre-existing intangible property,” sec. 1.482-7(g)(2), Income Tax Regs., that Amazon US actually transferred to AEHT in 2005. As explained in connec- tion with petitioner’s CUT methodology, see infra pp. 103-107, the website technology that Amazon US initially transferred to AEHT had a useful life of - 77 - about seven years. Thus, after decaying or “ramping down” in value over a seven- year period, Amazon’s website technology as it existed in January 2005 would have had relatively little value left by year-end 2011. But approximately 58% of Dr. Frisch’s proposed buy-in payment, or roughly $2 billion, is attributable to cash flows beginning in 2012 and continuing in perpetuity.16 Conversely, it is clear that Dr. Frisch, like Dr. Hatch, improperly included in the buy-in payment the value of “subsequently developed intangibles.” Veritas, 133 T.C. at 323. Management’s projections for the European business were based on the (extremely high) growth rates that Amazon had achieved in the past. Such growth rates could be sustained only through constant innovation, including inno- vations concerning products and services that did not yet exist in marketable form.17 Projects that would contribute to high future growth rates, some of which were in early development as of January 2005, included the Kindle, Amazon 16 As explained more fully infra pp. 117-120, we do not conclude that the website technology transferred in January 2005 had become wholly worthless at year-end 2011. It continued to have some residual value; it could be used for research and as a springboard for developing replacement technology. We conclude that a “tail” of 3-1/2 years is appropriate to capture this residual value. But this residual value, when added to the initial seven-year value, does not come close to Dr. Frisch’s $3.468 billion figure. 17 Dr. Frisch admitted that he did not investigate the manner in which Ama- zon constructed its revenue projections, testifying that he “couldn’t do a detailed analysis of what was in the projections in terms of individual product.” - 78 - Prime, the Fire smartphone, Fire TV, digital music/video offerings, cloud com- puting and storage, and the EFN, which implemented standardized and improved fulfillment operations across Europe. These new products and services, as well as the next generation of Ama- zon’s website platform, would be created thanks to massive projected IDC invest- ments by Amazon in years after 2004. But AEHT would have paid, via cost shar- ing, its ratable share of these future IDCs, and it would thus co-own these subse- quently-developed intangibles. Because AEHT would pay for these assets via cost sharing, it was not required to pay for them through the upfront buy-in payment. As we held in Veritas, 133 T.C. at 323: “No buy-in payment is required for sub- sequently developed intangibles.” Dr. Frisch’s DCF methodology resembles Dr. Hatch’s in another respect: It is based in essence on an “akin to a sale” theory. See id. at 313, 316, 320-321. Dr. Frisch computes the buy-in payment not by valuing the specific intangible assets transferred under the CSA but by determining an enterprise value for Amazon’s entire European business. He deems the pre-existing intangibles to have a value equal to AEHT’s enterprise value, less its initial tangible assets. By employing an enterprise valuation, Dr. Frisch necessarily sweeps into his calculation assets that - 79 - were not transferred under the CSA and assets that were not compensable “intan- gibles” to begin with. “[F]or the definition of an intangible,” the cost sharing regulations in effect for 2005-2006 refer to the definition set forth in section 1.482-4(b), Income Tax Regs. See id. sec. 1.482-7(a)(2) (last sentence). This definition is essentially the same as that set forth in section 936(h)(3)(B). In both provisions, “intangible” is defined to include five enumerated categories of assets, each of which has “sub- stantial value independent of the services of any individual.” These include pat- ents, inventions, copyrights, know-how, trademarks, trade names, and 20 other specified intangibles. Each definition also includes a sixth category, consisting of “other similar items” in the regulatory definition and “any similar item” in the stat- utory definition. The former elaborates slightly on the latter by stating that, “[f]or purposes of section 482, an item is considered similar to those * * * [enumerated] if it derives its value not from its physical attributes but from its intellectual con- tent or other intangible properties.” Sec. 1.482-4(b)(6), Income Tax Regs. An enterprise valuation of a business includes many items of value that are not “intangibles” as defined above. These include workforce in place, going con- cern value, goodwill, and what trial witnesses described as “growth options” and corporate “resources” or “opportunities.” Unlike the “intangibles” listed in the - 80 - statutory and regulatory definitions, these items cannot be bought and sold inde- pendently; they are an inseparable component of an enterprise’s residual business value. These items often do not have “substantial value independent of the serv- ices of any individual.” Sec. 936(h)(3)(B) (last clause); sec. 1.482-4(b), Income Tax Regs. And these contributors to value are not “similar” to the enumerated intangibles because they do not derive their value from their “intellectual content or other intangible properties.” Sec. 1.482-4(b)(6), Income Tax Regs.18 Thus, as we concluded in Veritas, there was for the tax years at issue “no explicit author- ization” in the cost sharing regulations for “respondent’s ‘akin’ to a sale theory or * * * [his] inclusion of workforce in place, goodwill, or going-concern value” in determining the buy-in payment for pre-existing intangibles. 133 T.C. at 316.19 18 This conclusion is supported by the regulations’ history. See DHL Corp. v. Commissioner, 285 F.3d 1210 (9th Cir. 2002), aff’g in part, rev’g in part T.C. Memo. 1998-461; Austin v. Commissioner, 141 T.C. 551, 561 (2013) (“The history of a regulation may be helpful in resolving ambiguities in it.”). In 1993 the IRS considered updating the 1968 transfer pricing regulations. Via temporary and proposed regulations, the Secretary requested comments specifically as to whether “the definition of intangible property * * * should be expanded to include items not normally considered to be items of intellectual property, such as work force in place, goodwill or going concern value.” 58 Fed. Reg. 5312 (Jan. 21, 1993). After receiving numerous comments opposing such an expansion, the IRS decided not to change the definition of intangible property. See T.D. 8552, 1994-2 C.B. 93 (explaining that the revised regulations merely clarified the 1968 definition). 19 Even if certain items discussed in the text were thought to constitute “in- (continued...) - 81 - Respondent urges that Dr. Frisch’s adoption of a business enterprise valua- tion is supported by the “aggregation” principle. Under the caption “Aggregation of transactions,” the regulations in effect during 2006 provided that the combined effect of multiple transactions may be considered “if such transactions, taken as a whole, are so interrelated that consideration of multiple transactions is the most re- liable means of determining the arm’s length consideration for the controlled transactions.” Sec. 1.482-1(f)(2)(i)(A), Income Tax Regs. We rejected respondent’s “aggregation” argument in Veritas, 133 T.C. at 321, and we likewise reject it here. The buy-in payment represents compensation for “pre-existing intangible property” owned by the transferor. Sec. 1.482-7(g)(2), Income Tax Regs. For at least two reasons, the type of “aggregation” proposed by respondent does not yield a reasonable means, much less the most reliable means, of determining an arm’s-length buy-in payment. See id. sec. 1.482-1(f)(2)(i)(A). 19 (...continued) tangibles” for cost sharing purposes, they were not necessarily owned directly by Amazon US or covered by the CSA. The European Subsidiaries had been in busi- ness--in Germany and the UK, very successfully--for more than six years as of January 1, 2005. They had substantial assets apart from their tangible property, in- cluding workforce in place and going-concern value. AEHT inherited these values when it acquired the stock and assets of the European Subsidiaries pursuant to the European Subsidiary Contribution, the European Business Contribution, and the Four-Party Agreement. See supra pp. 25-26. AEHT was not required to compensate Amazon US for these assets via the buy-in payment. - 82 - First, Dr. Frisch’s business-enterprise approach improperly aggregates pre-existing intangibles (which are subject to the buy-in payment) and subsequently developed intangibles (which are not). Second, his business-enterprise approach improperly aggregates compensable “intangibles” (such as software programs and tradem [Text truncated at 120,000 characters. The full text is on the page linked above.] --- Source: Frix Law Library, https://www.frixlaw.com/law-library/cases/4340625. Public record. Not legal advice.