Bloomberg L.P., Bloomberg, Inc., Tax Matters Partner
Opinion
United States Tax Court
T.C. Memo. 2024-108
BLOOMBERG L.P., BLOOMBERG, INC., TAX MATTERS PARTNER, Petitioner
v.
COMMISSIONER OF INTERNAL REVENUE, Respondent
__________
Docket Nos. 3755-17, 3756-17. Filed December 11, 2024.
[*2] investments. This product required a subscription to the first product to operate, though it had separate customer agreements and a separate subscription fee. Software that enabled the second product to function was hosted on P’s servers. Customers accessed the software by internet/private network connection rather than by installing the software on their own hardware. With respect to the second product, P claims that (1) most subscription fees (and related expenses) were allocable to product software and (2) the software at issue meets an exception to the rule that the provision of access to software is a service based on similar third-party software that was available to customers by disk or download. See Treas. Reg. § 1.199-3(i)(6)(ii), (iii)(B).
R issued P Notices of Final Partnership Administrative Adjustment for years 2008–10 disallowing P’s claimed I.R.C. § 199 deductions. R’s position is that none of P’s gross receipts were derived from the provision of access to software, but rather that all of P’s gross receipts were derived from the provision of other services. R also argued that P did not meet other requirements of the Treas. Reg. § 1.199-3(i)(6)(iii)(B) exception to the general rule that the provision of access to software constitutes a service. Alternatively, R argued that P’s allocation of gross receipts (and related expenses) between software and services was incorrect.
P filed Petitions challenging R’s determinations. P later argued in support of allocations of gross receipts (and related expenses) between software and services different from the allocations reported on its 2008–10 returns.
Held: Regarding the first product, P derived gross receipts from the provision of access to analytical and graphing software.
Held, further, regarding the first product, P did not derive gross receipts from the provision of access to other software, as such software merely enabled the provision of services.
[*3] Held, further, regarding the first product, the requirements of Treas. Reg. § 1.199-3(i)(6)(iii)(B) are satisfied with respect to the analytical and graphing software.
Held, further, regarding the second product, P mostly derived gross receipts from the provision of access to software.
Held, further, regarding the second product software, the requirements of Treas. Reg. § 1.199- 3(i)(6)(iii)(B) are satisfied.
Held, further, P’s allocation of gross receipts (and related expenses) between software and services was incorrect.
[*4] VI. Tax and Other Representations .......................................... 18
A. Promotional Materials ...................................................... 18 B. Income Tax Returns and Financial Statements ............. 19 C. Massachusetts Sales Tax Returns ................................... 19 D. Letters Regarding Foreign Withholding Taxes ............... 19 E. Advance Pricing Agreements ........................................... 20
VII. McKinsey & Co. Survey of BPS Users........................................ 22 VIII. Competing Systems ..................................................................... 23
A. 3000 Xtra........................................................................... 23 B. RMDS ................................................................................ 24 C. Combination of 3000 Xtra and RMDS ............................. 25 D. Charles River Investment Management System ............ 25
IX. Miscellaneous .............................................................................. 26
OPINION ................................................................................................ 27 I. Burden of Proof and Issues Presented ....................................... 27 II. Evidentiary Matters Regarding APAs........................................ 28 III. Section 199, Treasury Regulation § 1.199-3, and Computer Software ..................................................................... 29
A. General Information ......................................................... 29 B. Computer Software ........................................................... 31 C. Background on the Self-Comparable and Third-
Party Comparable Exceptions.......................................... 32
IV. Job Creation in the United States .............................................. 34 V. BATS Global and Direct Supply ................................................. 35
A. BATS Global I and II ........................................................ 35 1. BATS Global I ........................................................ 35 2. BATS Global II ....................................................... 37
B. Direct Supply I and II....................................................... 37 1. Direct Supply I ....................................................... 37 2. Direct Supply II...................................................... 39
C. Distinguishing Bloomberg’s Cases ................................... 40
VI. Issues with Treasury Regulation § 1.199-3 ................................ 42
[*5] A. General Issues .................................................................. 42 B. Interpreting Treasury Regulation § 1.199-3.................... 42 C. Treatment of Gross Receipts as Derived from the Disposition of Computer Software ................................... 44
VII. BPS Software Qualification Issue .............................................. 45
A. The Parties’ Use of Certain Evidence .............................. 46 B. The Treasury Regulation § 1.199-3(i)(6)(iii)
Threshold Requirement .................................................... 46 1. Element One: Deriving Gross Receipts from Providing Customers with Access to Software ................................................................. 47 a. Collection and Search Software .................. 48 b. Email and IM Software ............................... 51 c. Analytical and Graphing Software ............. 53 d. Other BPS Software .................................... 55 e. Conclusion Regarding Element One .......... 56
2. Considering BPS Analytical and Graphing Software Alone ....................................................... 56 3. Element Two: Software MPGE in Whole or in Significant Part Within the U.S........................ 58 4. Element Three: Direct Use of Software by Customers .............................................................. 58 5. Element Four: Use of Software While Connected to the Internet or Any Other Public or Private Communications Network ........ 59 6. Other Arguments Related to the Threshold Requirement ........................................................... 59 a. Bloomberg’s APA Request........................... 60 b. Massachusetts Sales Tax Returns.............. 60 c. Foreign Tax Withholding Letters ............... 62 d. Federal Returns .......................................... 63 e. McKinsey Survey and Customer Testimony .................................................... 63 f. Data Center Connection Requirement ....... 64 g. Treasury Regulation § 1.199-3(d)(1), (i)(1)(i), and (i)(4)(i)(A)................................. 64 i. Treasury Regulation § 1.199-
3(i)(1)(i) ............................................. 65 ii. Treasury Regulation § 1.199-
3(d)(1) ................................................ 66
[*6] iii. Treasury Regulation § 1.199-
3(i)(4)(i)(A) ........................................ 70
Free access — add to your briefcase to read the full text and ask questions with AI
United States Tax Court
T.C. Memo. 2024-108
BLOOMBERG L.P., BLOOMBERG, INC., TAX MATTERS PARTNER, Petitioner
v.
COMMISSIONER OF INTERNAL REVENUE, Respondent
__________
Docket Nos. 3755-17, 3756-17. Filed December 11, 2024.
[*2] investments. This product required a subscription to the first product to operate, though it had separate customer agreements and a separate subscription fee. Software that enabled the second product to function was hosted on P’s servers. Customers accessed the software by internet/private network connection rather than by installing the software on their own hardware. With respect to the second product, P claims that (1) most subscription fees (and related expenses) were allocable to product software and (2) the software at issue meets an exception to the rule that the provision of access to software is a service based on similar third-party software that was available to customers by disk or download. See Treas. Reg. § 1.199-3(i)(6)(ii), (iii)(B).
R issued P Notices of Final Partnership Administrative Adjustment for years 2008–10 disallowing P’s claimed I.R.C. § 199 deductions. R’s position is that none of P’s gross receipts were derived from the provision of access to software, but rather that all of P’s gross receipts were derived from the provision of other services. R also argued that P did not meet other requirements of the Treas. Reg. § 1.199-3(i)(6)(iii)(B) exception to the general rule that the provision of access to software constitutes a service. Alternatively, R argued that P’s allocation of gross receipts (and related expenses) between software and services was incorrect.
P filed Petitions challenging R’s determinations. P later argued in support of allocations of gross receipts (and related expenses) between software and services different from the allocations reported on its 2008–10 returns.
Held: Regarding the first product, P derived gross receipts from the provision of access to analytical and graphing software.
Held, further, regarding the first product, P did not derive gross receipts from the provision of access to other software, as such software merely enabled the provision of services.
[*3] Held, further, regarding the first product, the requirements of Treas. Reg. § 1.199-3(i)(6)(iii)(B) are satisfied with respect to the analytical and graphing software.
Held, further, regarding the second product, P mostly derived gross receipts from the provision of access to software.
Held, further, regarding the second product software, the requirements of Treas. Reg. § 1.199- 3(i)(6)(iii)(B) are satisfied.
Held, further, P’s allocation of gross receipts (and related expenses) between software and services was incorrect.
[*4] VI. Tax and Other Representations .......................................... 18
A. Promotional Materials ...................................................... 18 B. Income Tax Returns and Financial Statements ............. 19 C. Massachusetts Sales Tax Returns ................................... 19 D. Letters Regarding Foreign Withholding Taxes ............... 19 E. Advance Pricing Agreements ........................................... 20
VII. McKinsey & Co. Survey of BPS Users........................................ 22 VIII. Competing Systems ..................................................................... 23
A. 3000 Xtra........................................................................... 23 B. RMDS ................................................................................ 24 C. Combination of 3000 Xtra and RMDS ............................. 25 D. Charles River Investment Management System ............ 25
IX. Miscellaneous .............................................................................. 26
OPINION ................................................................................................ 27 I. Burden of Proof and Issues Presented ....................................... 27 II. Evidentiary Matters Regarding APAs........................................ 28 III. Section 199, Treasury Regulation § 1.199-3, and Computer Software ..................................................................... 29
A. General Information ......................................................... 29 B. Computer Software ........................................................... 31 C. Background on the Self-Comparable and Third-
Party Comparable Exceptions.......................................... 32
IV. Job Creation in the United States .............................................. 34 V. BATS Global and Direct Supply ................................................. 35
A. BATS Global I and II ........................................................ 35 1. BATS Global I ........................................................ 35 2. BATS Global II ....................................................... 37
B. Direct Supply I and II....................................................... 37 1. Direct Supply I ....................................................... 37 2. Direct Supply II...................................................... 39
C. Distinguishing Bloomberg’s Cases ................................... 40
VI. Issues with Treasury Regulation § 1.199-3 ................................ 42
[*5] A. General Issues .................................................................. 42 B. Interpreting Treasury Regulation § 1.199-3.................... 42 C. Treatment of Gross Receipts as Derived from the Disposition of Computer Software ................................... 44
VII. BPS Software Qualification Issue .............................................. 45
A. The Parties’ Use of Certain Evidence .............................. 46 B. The Treasury Regulation § 1.199-3(i)(6)(iii)
Threshold Requirement .................................................... 46 1. Element One: Deriving Gross Receipts from Providing Customers with Access to Software ................................................................. 47 a. Collection and Search Software .................. 48 b. Email and IM Software ............................... 51 c. Analytical and Graphing Software ............. 53 d. Other BPS Software .................................... 55 e. Conclusion Regarding Element One .......... 56
2. Considering BPS Analytical and Graphing Software Alone ....................................................... 56 3. Element Two: Software MPGE in Whole or in Significant Part Within the U.S........................ 58 4. Element Three: Direct Use of Software by Customers .............................................................. 58 5. Element Four: Use of Software While Connected to the Internet or Any Other Public or Private Communications Network ........ 59 6. Other Arguments Related to the Threshold Requirement ........................................................... 59 a. Bloomberg’s APA Request........................... 60 b. Massachusetts Sales Tax Returns.............. 60 c. Foreign Tax Withholding Letters ............... 62 d. Federal Returns .......................................... 63 e. McKinsey Survey and Customer Testimony .................................................... 63 f. Data Center Connection Requirement ....... 64 g. Treasury Regulation § 1.199-3(d)(1), (i)(1)(i), and (i)(4)(i)(A)................................. 64 i. Treasury Regulation § 1.199-
3(i)(1)(i) ............................................. 65 ii. Treasury Regulation § 1.199-
3(d)(1) ................................................ 66
[*6] iii. Treasury Regulation § 1.199-
3(i)(4)(i)(A) ........................................ 70
C. The Third-Party Comparable Exception ......................... 72 1. Reuters Derived Gross Receipts from the Disposition of 3000 Xtra and RMDS Analytical and Graphing Software. ...................... 73 2. 3000 Xtra and RMDS Analytical and Graphing Software Was Provided by Disk or Download. ............................................................... 73 3. Reuters’s Analytical and Graphing Software Was Substantially Identical to BPS Analytical and Graphing Software. ...................... 74 a. Aggregating RMDS and Portions of 3000 Xtra Software ..................................... 75 b. Substantially Identical Software ................ 77
D. BPS Qualification Issue Conclusion ................................ 80
VIII. OMS Software Qualification Issue ............................................. 80
A. Separate Item ................................................................... 80 B. The Threshold Requirement ............................................ 82 C. The Third-Party Comparable Exception ......................... 83
IX. Allocation Issue: Expert Reports ................................................ 84
A. Respondent’s Expert: Dan Peters .................................... 85 B. Bloomberg’s Expert: Dr. Meenan ..................................... 90
X. Allocation Issue: Analysis and Conclusions ............................... 94
A. Jurisdiction Regarding Expenses Allocable to DPGR ................................................................................ 94 B. Reasonableness of Bloomberg’s Allocation Method......... 94 C. Discussion of Expert Reports ........................................... 95 D. Total BPS Plus OMS Gross Receipts and Expenses ....... 98 E. OMS Gross Receipts and Expenses ................................. 99 1. OMS Gross Receipts That Qualify as DPGR ........ 99 2. OMS Expenses Attributable to DPGR ................ 100
F. BPS Gross Receipts and Expenses................................. 101 1. BPS Gross Receipts That Qualify as DPGR ....... 101
[*7] 2. BPS Expenses Attributable to DPGR ................. 103
XI. U.S. Wages Issue ....................................................................... 105 XII. Conclusion ................................................................................. 108
MEMORANDUM FINDINGS OF FACT AND OPINION
GOEKE, Judge: These consolidated cases concern Notices of Final Partnership Administrative Adjustment (FPAAs) pertaining to tax years 2008–10 (years at issue). The primary issue is the amounts, if any, of Bloomberg’s 1 gross receipts that qualify as domestic production gross receipts (DPGR) used to calculate section 199 deductions. 2 The amount of DPGR in dispute totals approximately $10 billion for the years at issue. We hold that Bloomberg’s DPGR are $1.231 billion for 2008, $1.272 billion for 2009, and $1.359 billion for 2010. 3
We issued a protective order to prevent disclosure of proprietary and confidential information. The protective order allows protected information to be included in this Opinion at the Court’s discretion. We deem all protected information included in this Opinion to be necessary.
1 Unless otherwise specified, “Bloomberg” refers to Bloomberg, L.P., and its
subsidiaries and branches. Bloomberg was treated as a partnership under the Tax Equity and Fiscal Responsibility Act of 1982 (TEFRA), Pub. L. No. 97-248, §§ 401–407, 96 Stat. 324, 648–71. Before its repeal, TEFRA governed the tax treatment and audit procedures for many partnerships.
2 Unless otherwise indicated, facts discussed in this Opinion pertain to the
years at issue, statutory references are to the Internal Revenue Code, Title 26 U.S.C., in effect at all relevant times, regulation references are to Code of Federal Regulations, Title 26 (Treas. Reg.), in effect at all relevant times, and Rule references are to the Tax Court Rules of Practice and Procedure. We round all monetary amounts to the nearest dollar or nearest million (for large amounts). We round all percentages to the nearest percent. Certain sums and products have been slightly adjusted to account for the use of rounding.
3 We are not ruling on the amounts of section 199 deductions for the years at
issue. The parties agree that calculating those deductions requires partner-level determinations that we have no jurisdiction over in this partnership-level proceeding.
[*8] FINDINGS OF FACT
I. History and Overview of Bloomberg
Bloomberg is a well-known financial technology, information, and news business with offices and operations around the world. It is a Delaware limited partnership that maintains its headquarters and principal place of business in New York, New York.
Future mayor of New York City Michael Bloomberg founded Bloomberg in 1981 to create and market what became the Bloomberg Professional Service (BPS), commonly referred to as a “Bloomberg Terminal” or a “Bloomberg.” BPS was an interactive financial information/analysis product that customers 4 paid a subscription fee to access. Through BPS, users (mostly employees of institutional investors, central banks, and other large entities) could access a vast amount of financial data and news. Users could also use included software to manipulate, analyze, and model that data and news.
Although financial data companies existed before and during the 1980s, the combination of data, analytical software, and news found in BPS was lacking in the marketplace. BPS was successful shortly after its release in 1982 and continued to gain market share. BPS revenue, over $5 billion for each year at issue, constituted over 80% of Bloomberg’s gross receipts. Bloomberg spent billions of dollars each year to maintain and improve BPS software, data, and news. By the end of 2010, Bloomberg employed approximately 12,600 people around the world, in departments including news, research and development (R&D), data processing, sales, etc.
In December 2008 Bloomberg employed approximately 2,200 people in its R&D department. These employees included 1,500 software programmers, as well as engineers, managers, administrators, researchers, and support personnel. Over 85% of the software programmers worked in the United States, as did over 85% of all R&D department employees. Unsurprisingly, BPS software programming was concentrated in the United States.
In the years at issue, the number of employees in Bloomberg’s R&D department increased by approximately 35%, mostly because of hires in the United States. Bloomberg paid U.S. wages of $806 million
4 Although there is not a perfect overlap, we will use the terms “customer” and
“user” largely interchangeably in this Opinion.
[*9] for 2008, $812 million for 2009, and $968 million for 2010. Bloomberg’s U.S. wages increased even though the economy was generally poor in the years at issue.
II. BPS User Agreements and Fees
Customers accessed BPS through the internet or a dedicated private line, using their own computers or computers leased from Bloomberg. To gain access to BPS, a customer had to enter into a subscription agreement with Bloomberg (BPS Subscription Agreement). BPS Subscription Agreements entered into in the years at issue identified Bloomberg as a “service provider” and the customer as a “service recipient.” BPS Subscription Agreements stated that Bloomberg would provide “services described in” the BPS Subscription Agreement and that the service recipient “subscribes to such services in accordance with this Agreement.”
BPS Subscription Agreements entered into in the years at issue provided that “Services” consisted of “a nonexclusive and nontransferable right to use the BLOOMBERG PROFESSIONAL service information, data, software, and equipment.” BPS Subscription Agreements from prior years that had been renewed were also in effect in the years at issue and provided that “Services” consisted of “a nonexclusive and nontransferable license and lease to use the BLOOMBERG PROFESSIONAL service software, data and equipment.”
Bloomberg charged customers a BPS subscription fee of $1,700– $1,975 per month for a single BPS subscription. If a customer had multiple subscriptions, Bloomberg charged $1,425–$1,655 per month, per subscription. BPS subscription fees did not vary with how customers used BPS, how much they used BPS, or the results they achieved. All customers paying a BPS subscription fee received access to the core BPS functionality, as well as an optional keyboard developed by Bloomberg that included speakers, a fingerprint scanner, and keys not found on standard keyboards. BPS subscription fees were not broken down among data, software, news, and other BPS features.
Customers could pay additional fees to rent displays and/or computers from Bloomberg. Customers could also pay additional fees for certain items related to BPS, such as real-time data (discussed infra).
[*10] III. BPS Hardware and Software Architecture
BPS used a server-client architecture comprising software, networking, and computing infrastructure. A server-client architecture describes a computer system where computer components are separated between a “client” and a “server.” A client is typically software that sits on a user’s computer and a server is software that runs on a remote system (often itself called a “server”) from the client. The client interacts with the server over the internet or other network, with each server usually providing functionality to multiple clients. Aside from a requirement to maintain a connection to a server, from a user’s perspective there was typically little or no discernable distinction between programs run using a server-client architecture and programs run entirely on the user’s hardware. BPS’s server-client architecture allowed it to accept, process, and return results for most user requests in less than one-tenth of a second.
Bloomberg’s physical technology infrastructure comprised 2 data centers, over 100 “node sites,” and Bloomberg’s equipment installed on a user’s premises (such as computers leased by users). Data centers are centralized spaces that house hardware such as servers, storage, and networking equipment. Bloomberg’s data centers included thousands of servers that stored, processed, created, routed, integrated, and disseminated data. Both data centers were in the United States and performed almost all the computing work that kept BPS operational. Consequently, BPS would not function if a user did not have an active connection to Bloomberg’s data centers.
Bloomberg’s node sites were located throughout the world; they routed user requests to data centers for processing and then routed the results back to the user’s computer for display. Node sites are of little relevance in these cases.
There were two BPS-related software applications installed on user computers, (1) “WINTRV” and (2) a Microsoft Excel (Excel) plug-in. The principal purposes of WINTRV were to transmit user requests to node sites, display the BPS graphical user interface, and complete some charting functions. The Excel plug-in allowed users to download data from BPS into Excel spreadsheets and analyze that data using BPS software functionality that then appeared within Excel.
When a user made a request using BPS software installed on its computers, it was transmitted through a node site and received by
[*11] “Loader” software at a data center. Loader software operated like a map, routing user requests to an appropriate “BIG” for processing. A BIG was a collection of server software that generated responses to user requests. There were different types of BIGs which responded to different user requests. BIGs would query and extract relevant information from BPS data center systems (including “Ticker Plants,” “Reference Databases,” and “News Servers”), perform the user’s requested calculation or function, and send the completed request back to the Loader to be returned to a node site and then on to the user.
Ticker Plants were used to monitor and access securities information from exchanges and other sources. They received data from thousands of sources so that users could access prices and other information. For example, if a user set up a list of securities to monitor, Ticker Plants pushed price updates to the user throughout the day. Ticker Plants were assisted by “feed handlers” that ingested streaming data from external sources, then converted that data into a common format that Ticker Plants could process.
Reference Databases stored various types of information, including historical asset prices, user preferences and work, economic data, and archived news articles. Database management software was used to store and retrieve information from Reference Databases as needed.
News Servers aggregated, stored, and distributed news from Bloomberg and other sources. These servers supported various BPS functions, including displaying “top” news articles to users who had requested them and overlaying news articles on graphs of securities so that users could see what news might have caused price changes.
IV. BPS Features and Functions
Bloomberg has described BPS as a “service [that] seamlessly integrates data, news, analytics, multimedia reports, and email into a single platform.” One witness gave a helpful analogy at trial, likening BPS to a three-legged stool with data, news, and software being the legs. As the witness testified, “the stool would not stand without those three legs.” We will discuss data, news, software, and certain other BPS features in this Findings of Fact (FoF) Part IV.
[*12] A. Data
BPS collected, categorized, and stored vast amounts of data across all asset classes that users could retrieve almost instantaneously. BPS users could use only the BPS information feed; 5 they could not use other information feeds with BPS. However, when using BPS analytical tools, users could often overwrite BPS data with other values to test different assumptions or hypotheses, discussed further infra FoF Part IV.C.
BPS provided coverage of approximately (1) 246,000 securities in 129 countries; (2) 153,000 companies; (3) 530,000 corporate bonds; (4) 53,700 government bonds; (5) 10,180 preferred securities; (6) 256,000 mortgages; (7) 21,000 money market programs; (8) 30,100 syndicated loans; (9) 3,490,000 municipal bonds; (10) 80,000 funds in 72 countries; (11) numerous currencies and commodities; and (12) thousands of additional sources of contributed exchange, news, pricing, and research feeds. BPS also stored historical information on approximately 5 million bonds, equities, commodities, currencies, and funds.
To provide data to users, Bloomberg was a party to approximately 149 contracts with financial exchange operators worldwide. These contracts allowed BPS to connect to approximately 250 exchanges. By paying the BPS subscription fee, BPS users received exchange data that was 15–20 minutes delayed. BPS users could obtain real-time data for separate fees, most of which were passed through to the exchanges. 6
Some BPS data was submitted by BPS users. Much of this data pertained to over-the-counter (OTC) products, such as corporate bonds, that were not traded on an exchange or other centralized marketplace. BPS users could “broadcast” prices at which they were willing to sell OTC products and, if they chose to, specify/limit the other users who could see those prices. Users contributed millions of prices on thousands of OTC products every day. Users looking to buy OTC products could use BPS to search for products that were being offered for sale, along with prices and other information. While users could find trading partners in this manner, BPS was not an exchange, and trades did not occur on BPS. Furthermore, users did not pay commissions to Bloomberg when they
5 We will generally refer to a collection of current data and/or news as an
“information feed” and a collection of historical data and/or news as “historical information.”
6 Bloomberg does not contend that the amounts passed through to exchanges
or the markups that it kept are DPGR.
[*13] found trading partners on BPS; this benefit was part of the BPS subscription fee.
In addition to financial product data, BPS provided huge amounts of complementary data. Such data included (1) government and trade group statistics; (2) industry data points; (3) product line and geographic performance data; (4) performance/earnings estimates; (5) live cargo ship tracking; (6) outage and emission data for refineries, power plants, and natural gas terminals; (7) weather data (including forecasting); (8) company filings; and (9) other information on almost every publicly traded company. Some of this data, such as earnings estimates, was “derived data” that was computed from raw data. BPS also included biographies of over 1 million people.
Bloomberg worked to increase its data coverage and to close any gaps in its coverage. Bloomberg was a party to hundreds of contracts with third-party data providers and vendors that allowed it to procure data that was sometimes not available from any other source. Contracts with third-party data providers were nonexclusive, so providers could still sell their data to other parties.
Bloomberg had both automatic and manual quality controls in place to ensure that BPS data was accurate. Bloomberg described BPS data as “the most complete, comprehensive, and accurate in the world.” The quantity and quality of BPS data was very strong, though one of Bloomberg’s competitors (Thomson Reuters, discussed infra) offered an information feed and historical information that included largely comparable data.
B. News
Bloomberg News, a department within Bloomberg, developed original news content that BPS users could access. Bloomberg News had more than 2,300 reporters and editors in 135 bureaus and published more than 5,000 stories on an average day. Bloomberg News provided coverage of companies, markets, industries, economies, governments, sports, and entertainment.
Bloomberg News was a real-time news service, meaning that events were reported immediately as they unfolded. This was important because many financial professionals require timely, high-quality news to effectively do their jobs. BPS users could view live news broadcasts, speeches, conferences, meetings, and seminars through BPS. Users
[*14] could also access Bloomberg’s archive of over 15 million stories and multimedia reports.
As it did with data, Bloomberg took steps to expand its news coverage. Bloomberg had over 100 nonexclusive contracts with third- party news providers that increased news available to BPS users. If a BPS user wanted access to content that was not already provided through BPS, the user could request that Bloomberg expand its coverage, which Bloomberg sometimes did.
Not all of Bloomberg’s news was exclusive to BPS users.
Bloomberg published a significant amount of news online at no cost to readers. Bloomberg’s news also appeared in approximately 400 publications worldwide, as well as on some radio stations.
C. Software
Bloomberg built BPS software in house and used very little third-
party software. This was because Bloomberg viewed BPS software as a strategic advantage that it wanted to maintain control over.
BPS software enabled the collection and updating of data from sources around the world. It also enabled users to not only search through otherwise overwhelming amounts of data and news, but also to manipulate, analyze, and model that data and news. BPS included tools for graphing, calculating, screening, pricing, comparing assets, managing portfolio risk, etc. In short, BPS software enabled the completion of tasks from the straightforward (e.g., looking up stock prices) to the extremely complex (e.g., forecasting the behavior of a portfolio in hypothetical scenarios, such as a terrorist attack).
BPS users could take advantage of thousands of different software functions, which generally had three- or four-letter codes that users could enter to run them. Examples of functions include YAS (yield spread analysis), OAS (option adjust spread), and HGCS (credit default swap valuation). Most BPS functions were based on industry-accepted calculators and financial models.
Current and historical information/data was integrated with BPS software for functions to work. However, many functions allowed users to overwrite BPS-supplied data with other values to test different assumptions or hypotheses. For example, when running a currency
[*15] swap analysis, 7 users could overwrite almost all BPS-supplied data to evaluate potential trades. A picture of a BPS currency swap analysis follows:
In this picture, fields with orange backgrounds could be altered by users, with most alterations changing the analysis. Without such tools providing populated data and nearly instantaneous responses to alterations, financial professionals would spend more time analyzing trades and devising strategies. This would put them at a disadvantage in their jobs.
BPS’s graphing and charting (collectively, graphing) tools allowed users to produce visual representations of numerous financial products, portfolios, etc., including those for which users had altered data populated by BPS. BPS visual representations ranged from the simple (e.g., graphing the price of a stock over a day) to the complex (e.g., allowing users to create three-dimensional volatility surfaces used to analyze certain assets). A picture of a volatility surface (and associated graphs) generated in BPS follows:
7 A swap is a type of OTC derivative where parties exchange the value or cash
flows of one asset for another (i.e., swapping U.S. dollars for euro).
[*16]
In this picture, fields with orange backgrounds could be altered by users to change the visual outputs. Users could also zoom in, rotate, annotate, and otherwise manipulate the volatility surface.
Once a visual representation had been created, users could save, copy, and/or share it with other BPS users. Users could also correlate dates with news and events, add overlays, calculate trendlines, and make other alterations/additions. The breadth of visual representations and overlays that could be created and used in BPS was extensive. BPS allowed users to visualize and glean insights from sophisticated financial concepts such as Fibonacci retracements, Hurst exponents, numerous bands and oscillators, etc.
BPS software also allowed users to customize the layout of items on their BPS “launch screens.” Users could arrange dozens of “tiles” on their launch screens, such as charts, security lists, news panels, price/rate monitors, etc. This allowed users to easily see and access data, news, and functions that they used most often.
Bloomberg frequently added new functions or enhanced existing functions in response to user suggestions. Bloomberg provided training courses and materials regarding new/enhanced functions, as well as training and materials to help newer users familiarize themselves with
[*17] BPS systems and functions. Such updates and training helped to embed BPS use into users’ daily routines, resulting in higher subscription renewals. Many customers described specific BPS analytical and graphing functions that they used as “essential” in their work.
D. Email and Instant Messaging
BPS included email and instant messaging (IM) systems, and customers received a Bloomberg.net email address. These communications features were integrated into BPS, allowing users to easily share data, graphs, news, and other information. Email and IM also helped to create something of a marketplace and community on BPS that attracted new users and retained existing ones.
Users could use email and IM to request quotes from other users and broadcast prices at which they were willing to sell products. BPS software assisted users in creating price lists that could be sent out automatically. Users could also turn on a “price scraping” option in BPS that extracted pricing data from emails and messages to make it easier to view and analyze products that were being offered for sale. While trades could not be completed on BPS, users could use BPS email and IM to route proposed trades to brokers. Integrated email and IM allowed users to quickly agree on trades, which was important in the fast-moving business of finance.
E. Helpdesks and Sales Support
Bloomberg provided BPS users with support services known as “Helpdesks” to answer questions about BPS. The two types of Helpdesks were support and analytics. The support Helpdesk handled technical questions, such as those pertaining to issues logging into BPS. The analytics Helpdesk handled questions about BPS functions and data, such as how to create certain graphs.
Bloomberg also employed “application specialists” with significant prior experience in the financial industry. Application specialists did not provide user support; they trained Bloomberg’s salespeople and provided other sales assistance.
V. Order Management System
The Order Management System (OMS) was a computer program created by Bloomberg that was integrated with BPS. There were
[*18] multiple versions of OMS that were intended to be used by different types of customers (e.g., buy-side and sell-side customers). OMS helped customers keep track of their transactions and investments (for both performance and accounting purposes) and to comply with company, client, and regulatory requirements.
One version of OMS, Sell Side Equity Order Management System (SSEOMS), was an integrated market access and order management system with tools to book trades, receive and route order flow to various markets, and directly participate in select markets, among other features. SSEOMS also provided connectivity to numerous exchanges, dark pools, 8 other trading venues, and broker algorithms over Bloomberg’s network that were not otherwise provided with a BPS subscription.
OMS required BPS data (such as current asset prices) to function.
OMS was available only to BPS customers, who accessed OMS through BPS. To subscribe to OMS, a BPS customer paid an OMS subscription fee (in addition to a BPS subscription fee) and executed an addendum to its BPS Subscription Agreement as well as a separate schedule of services and service-level agreements. These documents reflected that the BPS customer would receive “[a]dditional [s]ervices,” with “[s]ervices” having the same definition as in a BPS Subscription Agreement.
Bloomberg charged varying prices for subscriptions to different versions of OMS. Subscriptions ranged from $25,000 to $600,000 per year. Bloomberg’s total OMS gross receipts were $84 million for 2008, $100 million for 2009, and $133 million for 2010. Many BPS customers did not subscribe to OMS because they did not need such a program at all, or because they used in-house programs/tools, or because they subscribed to a competing offering (discussed further infra FoF Part VIII.D).
VI. Tax and Other Representations
A. Promotional Materials
Bloomberg’s promotional materials generally focused on BPS data, news, and analytical/graphing tools (and, to a lesser extent, communication features). For example, on its website Bloomberg
8 Dark pools are marketplaces that allow users to place orders without publicly
displaying the sizes and prices of their orders to other participants in the pool.
[*19] described BPS as “providing the most comprehensive and advanced set of financial data, real time market coverage, news, analytic tools, portfolio solutions and research.” Regarding derivatives, Bloomberg stated that BPS “offers a suite of intraday data, marketstandard models, flexible idea generation analytics, and independent valuation tools.” Regarding fixed income products, Bloomberg claimed that BPS “weds the most timely and accurate fixed income data available with industry standard analytics in order to provide the most comprehensive platform for analyzing investment opportunities.” Regarding commodities, Bloomberg emphasized “market-moving news,” “critical pricing and statistical data,” and “all the [analytical] tools you need to pull it together.” In short, Bloomberg promoted BPS as an integrated package that was greater than the sum of its parts.
B. Income Tax Returns and Financial Statements
On Bloomberg’s federal returns for the years at issue, it reported its principal business activity as business services and its principal product or services as information services. On the same returns, Bloomberg claimed section 199 deductions based on gross receipts that it determined were derived from providing software to BPS users.
Bloomberg filed Massachusetts and New York state income tax returns for the years at issue that reported business activity and/or principal product information similar to Bloomberg’s federal tax returns.
On Bloomberg’s consolidated financial statements for the years at issue, it identified BPS revenue as being from “[f]inancial information services.”
C. Massachusetts Sales Tax Returns
Bloomberg filed Massachusetts sales tax returns for the years at issue. Bloomberg took the position that its gross receipts from BPS and OMS subscription fees were exempt from Massachusetts sales tax.
D. Letters Regarding Foreign Withholding Taxes
Bloomberg received BPS subscription fees from customers in numerous countries. Bloomberg issued letters to customers in Singapore, the Philippines, and India advising them of their foreign tax withholding obligations. Letters issued to customers in (1) Singapore described BPS subscription payments as being for “financial
[*20] information;” (2) the Philippines described BPS subscription payments as being for “an information service;” and (3) India described BPS subscription payments as being for a “subscription to [a] database.” In the letters, Bloomberg concluded that BPS subscription fees paid were not subject to foreign tax withholding. In letters issued to customers in Singapore, Bloomberg also stated that “withholding tax obligations . . . apply only to” payments for the rental of equipment from Bloomberg.
E. Advance Pricing Agreements
Bloomberg requested respondent’s assistance in obtaining advance pricing agreements (APAs) covering the years at issue that would allocate its profits among the United States, the United Kingdom, and Japan. In December 2008 Bloomberg submitted a “Request for Bilateral Advance Pricing Agreements Between the United States and Japan and the United States and the United Kingdom” (APA request). 9 Bloomberg also submitted a required statement signed under penalties of perjury affirming that “the APA request contains all the relevant facts relating to the APA request, and such facts are true, correct and complete.” See Rev. Proc. 2006-9, § 4.09(1), 2006-2 I.R.B. 278, 284. In the APA request, Bloomberg stated that it had a 24% market share of the credit and financial information industry segment of the information services industry. Bloomberg defined BPS as “an electronic information service that combines news, market data, analytics, email and order routing into a single interactive package.”
Bloomberg’s APA request includes a lengthy and intricate sevenstep process for allocating profits. In short, Bloomberg proposed using a modified Residual Profit Split Method (RPSM) 10 as its transfer pricing method (TPM). As Bloomberg described it in the APA request, “there is a routine return earned for the service-provider functions performed and a residual profit earned that reflects the value of the Bloomberg intangibles.”
In its APA request, Bloomberg proposed that “activities undertaken by the News Reporting department” be considered routine
9 The discussion in this Opinion pertains only to the first of three transactions
discussed in the APA request. The two other transactions are not relevant.
10 An RPSM involves two steps. First, arm’s-length returns for routine
activities performed by entities in different countries are determined. Second, residual profits that remain are allocated according to the relative value of the nonroutine contributions made by each entity. See Treas. Reg. § 1.482-9(g)(2) (example 2 (vii)).
[*21] activities. Such activities included writing “articles/stories on . . . economic data or other topics” that would be posted on BPS. Bloomberg also proposed that “data collections and processing group” activities be considered routine activities. Such activities included “data gathering, entry, and/or editing functions.”
After allocations to routine activities, Bloomberg proposed allocating residual profits to three intangible assets: (1) Technology Intangible Property (IP); (2) Customer Relationship (CR) IP; and (3) Marketing IP. Bloomberg defined the Technology IP as its “software intangible asset” and described it as Bloomberg’s “single most valuable intangible asset without which the business would not exist.” Bloomberg defined the CR IP as its “intangible asset related to the significant effort and investment undertaken by Bloomberg to enhance the value of the BPS to existing customers by making the product familiar, customers’ knowledge of the features current, and customizing/tailoring the BPS to meet specific customer requests.” Bloomberg defined the Marketing IP as its “brand and trademark intangible asset” and later described it as being enhanced “through media ventures and by syndicating Bloomberg news content.”
Bloomberg proposed (1) “a Marketing IP return equal to 5% of [Bloomberg’s] customer revenue from the BPS;” (2) “a CR IP [return] equal to 10% of revenue for” Bloomberg; and (3) that “remaining [Bloomberg] residual profit after the CR IP and Marketing IP have been compensated” be assigned to the Technology IP. These amounts would be assigned to Bloomberg subsidiaries in various countries “based on . . . [their] contributions to the development and maintenance of the relevant intangibles.” Because most software was created in the United States, about 90% of Technology IP residual profits were assigned to the United States. A lower percentage of CR IP, Marketing IP, and routine returns was assigned to the United States. Using a five-year average of profit allocations, Bloomberg proposed that 71% of profits be allocated to the United States, 18% of profits be allocated to the United Kingdom, and 3% of profits be allocated to Japan. 11
After Bloomberg submitted its APA request, its agent met with tax authorities to discuss the APA request, and IRS employees met with Bloomberg employees in various departments. In December 2010 the Commissioner provided Bloomberg with a 68-page draft of his
11 Bloomberg’s proposed profit allocation to Japan was a placeholder, as
Bloomberg was waiting for certain “actual results.”
[*22] recommended negotiating position (draft RNP) for the “U.S.-U.K. Bilateral APA.” In the draft RNP, respondent accepted most of the premises and methods in Bloomberg’s APA request. However, respondent proposed to eliminate CR IP as a separate intangible asset, effectively combining it with the Technology IP and “attribut[ing] this total return in the same manner that Taxpayer proposed to attribute the Technology IP Return.” This resulted in an increased percentage of Bloomberg’s profits being allocated to the Technology IP, which meant a higher share of profits being assigned to the United States and subject to U.S. income tax.
An APA regarding the United Kingdom (United Kingdom APA)
was executed by Bloomberg in September 2014 and by respondent in October 2014. 12 The United Kingdom APA substantially comports with the terms set forth in respondent’s draft RNP. It also follows the APA request by defining “Technology IP” as “Bloomberg’s software intangible asset.” Neither Bloomberg’s APA request, respondent’s draft RNP, nor the United Kingdom APA discusses section 199.
VII. McKinsey & Co. Survey of BPS Users
Bloomberg paid McKinsey & Co. (McKinsey), a management consulting firm, to conduct a survey of BPS users (McKinsey Survey) in 2008. The principal purposes of the McKinsey Survey were to (1) gather information about the BPS user base, such as what specific businesses users worked in and what assets they traded; and (2) find out what BPS functions were most used by, and most important to, BPS users. 13 McKinsey sent the survey questionnaire to about 190,000 BPS users and received 14,660 responses. McKinsey then removed “‘straight-line’ respondents” and other unreliable responses to reach 13,426 usable responses. McKinsey determined that the “responses were representative of the [BPS] user base.”
The McKinsey Survey showed that more general BPS features (such as news, email, security descriptive/pricing, and graphing
12 The parties later executed APAs regarding Japan and Germany. The APA
regarding Japan was significantly different from Bloomberg’s APA request; it did not explicitly address Technology IP or many other elements of the APA request. The APA regarding Germany was similar to the APA regarding the United Kingdom, though there were some material differences that were not well explained in other evidence or by the parties. We will not discuss the APAs regarding Japan and Germany further.
13 While Bloomberg had access to some BPS usage statistics, it wanted more
in-depth information that a survey could ideally provide.
[*23] features) were the most used BPS features. However, more specific features tended to be highly used by BPS users in certain jobs. For example, portfolio analytical features were not commonly used by most BPS users but were frequently used by BPS users who were portfolio managers.
To adjust for the fact that certain functions were commonly used by almost all BPS users, McKinsey ranked groups of features by how “critical” they were. To do this, McKinsey first asked users to identify what features they regularly used. Users were then asked to rate how important the features they regularly used were “to doing [their] job well” on a scale with five options. If a user chose one of the top two options (“Absolutely Essential” and “Very Important”) the feature was considered critical to that user. McKinsey divided the number of users who considered a feature to be critical by the number of users who regularly used the feature to determine overall “criticality.” McKinsey then sorted specific features into groups and determined that the 12 most critical groups of BPS features were, in order: (1) security descriptive and pricing functions; (2) downloads into Excel; (3) news stories; (4) graphing tools; (5) OMS; (6) economic monitors and analysis; (7) email; (8) quote histories and recaps; (9) technical analysis tools; (10) launch screen functionality; (11) portfolio analytics; and (12) instant messaging.
Bloomberg referenced the McKinsey Survey in its 2009 business plans, though whether/the extent to which Bloomberg made any specific decisions based on the McKinsey Survey was not established.
VIII. Competing Systems
A. 3000 Xtra
Thomson Reuters Corp. (Reuters) 14 was Bloomberg’s chief competitor. Reuters offered a subscription product called 3000 Xtra that Reuters described as “a high-performance information service for financial professionals.” Like BPS, 3000 Xtra was a system designed to integrate news, data, analysis, and messaging. The 3000 Xtra system included server software, graphing software installed on a user’s
14 Reuters Group, PLC (Reuters Group), and Thomson Corp. merged on April
17, 2008. Before the merger, Reuters Group sold the competing systems discussed in FoF Part VIII.A through C. References to “Reuters” in this Opinion include Reuters Group.
[*24] desktop computer, and an Excel plug-in like the BPS Excel plug- in (also installed on a user’s desktop computer).
BPS and 3000 Xtra were competing products and had substantially overlapping purposes and sets of features. Bloomberg and Reuters fought to procure subscriptions/renewals from the same pool of potential users. Some larger institutions even subscribed to both BPS and 3000 Xtra and let their employees use the product they preferred. When Bloomberg or Reuters introduced a new or improved feature on BPS or 3000 Xtra, the opposing company worked to match or exceed that feature to avoid its product’s losing market share.
BPS and 3000 Xtra (using Reuters’s consolidated information feed) 15 included similar data for major asset classes. However, there were certain types of assets for which one product had better data. For example, 3000 Xtra had better overall currency data, while BPS had better overall fixed-income data. Bloomberg’s and Reuters’s (on its consolidated information feed) news products were both strong.
Though they were largely similar, there were two notable differences between 3000 Xtra and BPS. First, users could pay a monthly fee to license most 3000 Xtra desktop software components without subscribing to other components of 3000 Xtra, such as an information feed. Second, users could use 3000 Xtra desktop computer software in combination with Reuters Market Data System (RMDS) software to achieve outcomes relevant to these cases, discussed infra FoF parts VIII.B and VIII.C.
B. RMDS
Reuters also offered RMDS, a software product that was often used in conjunction with 3000 Xtra (though 3000 Xtra was not required to use RMDS or vice versa). RMDS was generally licensed by larger institutions, where it would be installed on an institution’s servers. Once installed, RMDS sat between desktop software (usually 3000 Xtra desktop software) and one or more information feeds.
15 Unlike BPS, 3000 Xtra used no one specific information feed, though Reuters
offered a consolidated information feed called “Reuters Data Feed Plus.” Reuters offered 3000 Xtra users the option to receive limited portions of Reuters’s consolidated information feed for a reduced fee. For example, a user who traded only in commodities and/or energy markets could subscribe to a Reuters information feed that focused on commodities and energy information, for a lower price than Reuters’s consolidated information feed.
[*25] RMDS required an information feed to function. Customers could connect one or more information feeds to RMDS. These feeds could be from Reuters, a third party (e.g., broker or exchange feeds), the customer itself, or any combination thereof. Once an information feed was connected, RMDS could collect, normalize, store, analyze, and distribute data and/or news from that feed to users connected to the server(s) on which RMDS was installed. In short, once connected to one or more information feeds, RMDS software on a customer’s server(s) could effectively act like 3000 Xtra software that was found on Reuters’s servers, discussed further infra FoF Part VIII.C.
All of Reuters’s largest 3000 Xtra subscribers also licensed RMDS. Customers had two options to pay for an RMDS license: (1) a one-time fee plus a monthly maintenance fee for updates and support; or (2) a monthly fee.
C. Combination of 3000 Xtra and RMDS
Reuters designed RMDS to work with 3000 Xtra desktop software and enhance the 3000 Xtra system. Once RMDS was connected to an information feed, RMDS and 3000 Xtra desktop computer software worked together; RMDS collected, analyzed, and distributed large volumes of information, which users could further manipulate, perform calculations on, model, and share using 3000 Xtra desktop software components. This allowed the combination of RMDS and 3000 Xtra desktop computer software (once an information feed was connected to RMDS) to act much like the complete 3000 Xtra system (with an information feed). Unlike the complete 3000 Xtra system though (which used software installed on Reuters’s servers), the RMDS plus 3000 Xtra desktop computer software combination was installed completely on a customer’s hardware.
3000 Xtra users, even those with RMDS, primarily used data from Reuters’s consolidated information feed. However, these users were not required to use Reuters’s consolidated information feed and could use (1) their own information feed; (2) a different Reuters information feed; and/or (3) a third-party information feed.
D. Charles River Investment Management System
Charles River Development (Charles River) offered Charles River Investment Management System (IMS) software that competed with
[*26] OMS. 16 OMS and Charles River IMS had overlapping functionality and largely similar features. Charles River derived gross receipts from licensing Charles River IMS to customers, who could download Charles River IMS and install it on their own hardware.
Like OMS, Charles River IMS needed up-to-date information from a customer and/or third party to function as intended. Information could be imported into Charles River IMS from numerous information feeds and other sources, such as customer data sets. As a result, Charles River IMS could be used with BPS, 3000 Xtra, customer-developed software, etc., whereas OMS could be used only with BPS.
IX. Miscellaneous
Bloomberg timely filed a federal return for each year at issue. It reported DPGR of $2.121 billion for 2008, $1.773 billion for 2009, and $4.077 billion for 2010. Bloomberg also reported expenses allocable to DPGR 17 (for purposes of computing section 199 deductions) of $1.377 billion for 2008, $1.002 billion for 2009, and $2.084 billion for 2010. Using these amounts, Bloomberg calculated and reported section 199 deductions of $45 million for 2008, $46 million for 2009, and $179 million for 2010.
Respondent timely issued FPAAs to Bloomberg’s tax matters partner, Bloomberg, Inc., regarding the years at issue. In the FPAAs respondent determined that DPGR, expenses allocable to DPGR, and section 199 deductions were all zero for each year. Respondent determined Bloomberg’s DPGR to be zero because receipts Bloomberg reported did not qualify as DPGR pursuant to section 199 and related regulations. Respondent determined that expenses allocable to DPGR were zero “because of [respondent’s] adjustments to Bloomberg’s DPGR.” Respondent disallowed Bloomberg’s claimed section 199 deductions because of the other adjustments, as well as respondent’s determination that “[t]he section 199 deduction is determined at the partner level and not at the partnership level.”
Respondent also determined that Bloomberg’s U.S. wages paid ($806 million for 2008, $812 million for 2009, and $968 million for 2010)
16 At least one company other than Charles River offered software that also
competed with OMS. For purposes of this Opinion, it is sufficient to discuss only Charles River IMS.
17 References to “expenses allocable to DPGR” in this Opinion include both
directly allocable expenses and other apportionable expenses.
[*27] were zero for purposes of section 199. This adjustment pertained only to section 199; respondent did not adjust Bloomberg’s claimed total deductions or net income. Respondent stated that adjustments to U.S. wages were made “because Bloomberg was not eligible to determine . . . W-2 wages that are properly allocable to DPGR at the partnership level” and such wages “are computed at the partner level and not at the partnership level.”
Bloomberg, by petitioner, its tax matters partner, timely filed Petitions with this Court in response to the FPAAs, and the cases were consolidated in June 2017. In August 2021 Bloomberg filed Amended Petitions in which it claimed: (1) additional DPGR for 2008 of $1.766 billion; (2) additional expenses allocable to DPGR for 2008 of $614 million; (3) additional DPGR for 2009 of $2.031 billion; and (4) additional expenses allocable to DPGR for 2009 of $1.014 billion. 18
After Bloomberg filed its Amended Petitions, the total amounts of DPGR in dispute were $3.887 billion for 2008, $3.804 billion for 2009, and $4.077 billion for 2010. The total amounts of expenses allocable to DPGR in dispute were $1.990 billion for 2008, $2.016 billion for 2009, and $2.084 billion for 2010. An expert witness for Bloomberg later calculated lower DPGR and allocable expenses than Bloomberg claimed in its Amended Petitions. See infra OPINION Part IX.B.
OPINION
I. Burden of Proof and Issues Presented
Generally, taxpayers bear the burden of proving, by a preponderance of the evidence, that the Commissioner’s determinations are incorrect. Rule 142(a); Welch v. Helvering, 290 U.S. 111, 115 (1933). Bloomberg does not contest that it bears the burden of proof regarding the issues ruled on in this Opinion. 19
We must first decide whether any portion of Bloomberg’s gross receipts from BPS and/or OMS subscriptions qualify as DPGR
18 In its Amended Petitions, Bloomberg also claimed that it was entitled to
additional foreign tax credits for the years at issue. Respondent almost entirely agreed, and the issue was resolved by stipulation.
19 As discussed infra OPINION Part XI, there is a dispute regarding U.S. wages
allocable to DPGR. Bloomberg argued that “in any . . . proceedings to establish the W-2 wages allocable to DPGR, Respondent would bear the burden of proof, since the issue plainly constitutes a ‘new matter.’” Because we decline to rule on the U.S. wages issue in this Opinion, we need not decide whether Bloomberg is correct.
[*28] (qualification issue). To prevail, Bloomberg must show that (1) it derived receipts from providing customers access to computer software that it manufactured, produced, grew, or extracted (MPGE) in whole or in significant part within the United States for customers’ direct use while connected to the internet or any other public or private communications network; and (2) that a third party derived gross receipts from the lease, rental, license, sale, exchange, or other disposition of substantially identical software. See Treas. Reg. § 1.199- 3(i)(6)(iii)(B). 20 Because we rule for Bloomberg in part on the qualification issue, we must proceed to determine the allocation of gross receipts between DPGR and non-DPGR and determine expenses allocable to DPGR (allocation issue).
II. Evidentiary Matters Regarding APAs
In June 2022 respondent filed a Motion in Limine seeking to exclude the United Kingdom APA from evidence. Respondent’s Motion in Limine was primarily based on Rev. Proc. 2006-9, § 10.03 and 10.04, 2006-2 I.R.B. at 289, which reads, in part:
.03 An APA will have no legal effect except with respect to the taxpayer, taxable years, and transactions to which the APA specifically relates.
.04 Unless provided otherwise by written agreement or regulations, the Service and the taxpayer may not introduce the APA or non-factual oral and written representations made in conjunction with the APA request as evidence in any judicial or administrative proceeding regarding any tax year, transaction, or person not covered by the APA. . . .
Bloomberg objected to respondent’s Motion in Limine, arguing that “the [United Kingdom] APA is relevant evidence that will assist the Court in its valuation decision, and Rev. Proc 2006-9 does not bar [Bloomberg’s] proposed use of it.” 21 Bloomberg also stated that it sought “to introduce the [United Kingdom APA] solely for valuation,” and that it did not intend to use the United Kingdom APA with respect to the qualification issue.
20 Bloomberg does not argue that gross receipts at issue qualify as DPGR
pursuant to any other provision of Treasury Regulation § 1.199-3(i)(6).
21 Bloomberg’ reference to “valuation” is to the allocation issue.
[*29] By Order issued October 13, 2022, we agreed with Bloomberg that the United Kingdom APA was admissible with respect to the allocation issue. 22 We noted that Bloomberg did “not intend to use the APA with respect to the qualification issue.”
After the issuance of our October 13, 2022, Order, the parties stipulated Bloomberg’s APA Request, respondent’s draft RNP, and various related documents, such as annual reports that Bloomberg submitted to respondent pursuant to the United Kingdom APA (APA- related documents). Neither Bloomberg nor respondent objected to the admission of the APA-related documents and did not limit use of the documents to the allocation issue. 23
In its opening brief, Bloomberg did not make arguments regarding the United Kingdom APA or the APA-related documents with respect to the qualification issue. Bloomberg limited its opening brief arguments regarding those documents to the allocation issue. In his opening brief, respondent made arguments regarding the United Kingdom APA and the APA-related documents with respect to the qualification issue. Bloomberg addressed respondent’s arguments in its reply brief. Like Bloomberg, we will discuss only the United Kingdom APA and the APA-related documents with respect to the qualification issue when addressing respondent’s arguments.
III. Section 199, Treasury Regulation § 1.199-3, and Computer Software
A. General Information
Congress enacted section 199 as part of the American Jobs Creation Act of 2004, Pub. L. No. 108-357, § 102(a), 118 Stat. 1418, 1424, to provide a tax deduction for certain domestic production activities. Section 199 was intended to stimulate job creation in the United States and strengthen the economy by reducing the tax burden on domestic
22 As discussed further infra OPINION Part IX.A, one of respondent’s expert
witnesses relied on the United Kingdom APA and Bloomberg’s APA request to complete calculations regarding the allocation issue, which respondent supported. The fact that respondent based arguments on the United Kingdom APA and related documents supports our decision to admit the United Kingdom APA with respect to the allocation issue.
23 The parties also stipulated APAs regarding Japan and Germany, though
respondent reserved objections to the admission of those documents based on Rev. Proc. 2006-9, § 10.03 and 10.04. We admitted both APAs into evidence over respondent’s objection during the trial.
[*30] manufacturers. See ADVO, Inc. & Subs. v. Commissioner, 141 T.C. 298, 311–12 (2013) (citing Gibson & Assocs., Inc. v. Commissioner, 136 T.C. 195, 223 (2011)). Section 199 was repealed for tax years beginning after December 31, 2017. Tax Cuts and Jobs Act of 2017, Pub. L. No. 115-97, § 13305(a), (c), 131 Stat. 2054, 2126.
As in effect for the years at issue, section 199(a) allows a deduction equal to 6% (for 2008 and 2009) or 9% (for 2010) of the lesser of (1) the qualified production activities income (QPAI) of the taxpayer for the tax year or (2) taxable income (determined without regard to section 199) for the tax year. The amount of the deduction is limited to 50% of the wages of the taxpayer reported on Form W–2, Wage and Tax Statement, for the taxable year that are properly allocable to DPGR. § 199(b). QPAI for any taxable year is an amount equal to the excess, if any, of (A) the taxpayer’s DPGR for such taxable year, over (B) the sum of (i) the cost of goods sold allocable to such receipts and (ii) other expenses, losses, or deductions (other than the deduction under section 199) that are properly allocable to such receipts. § 199(c)(1). In the case of a partnership, section 199 applies at the partner level, though certain partnership-level items are necessary to compute the partner-level deduction. § 199(d)(1)(A); Treas. Reg. § 1.199-5(b).
DPGR includes gross receipts derived from any lease, rental, license, sale, exchange, or other disposition of qualifying production property (QPP) that was MPGE by the taxpayer in whole or in significant part within the United States. § 199(c)(4)(A)(i)(I). The regulations specify that the term “derived from the lease, rental, license, sale, exchange, or other disposition” (collectively, disposition) is limited to the gross receipts directly derived from the disposition of QPP and note that federal income tax principles apply to determine whether a transaction is a disposition, a service, or some combination thereof. Treas. Reg. § 1.199-3(i)(1)(i).
The definition of DPGR does not include gross receipts derived from services. The regulations clarify that gross receipts derived from the performance of services generally do not qualify as DPGR, though there are exceptions included in both the regulations and section 199. § 199(c)(4)(A)(ii) and (iii); Treas. Reg. § 1.199-3(i)(4)(i). In the case of an embedded service, that is, a service for which the price, in the normal course of the taxpayer’s business, is not separately stated from the amount charged for the disposition of QPP, DPGR includes only the gross receipts derived from the disposition of QPP and not any receipts attributable to the embedded service. Treas. Reg. § 1.199-3(i)(4)(i)(A).
[*31] B. Computer Software
QPP includes “any computer software.” § 199(c)(5)(B). 24 DPGR includes gross receipts derived from the disposition of computer software MPGE by the taxpayer in whole or in significant part within the United States. Treas. Reg. § 1.199-3(i)(6)(i). “Such gross receipts qualify as DPGR even if the customer provides the computer software to its employees or others over the Internet.” Id. Consistent with the general treatment of services under section 199, “[g]ross receipts derived from customer and technical support, telephone and other telecommunication services, online services (such as Internet access services, online banking services, providing access to online electronic books, newspapers, and journals), and other similar services do not constitute gross receipts derived from a . . . disposition of computer software.” Treas. Reg. § 1.199-3(i)(6)(ii).
The regulations provide narrow exceptions to the general rule stated in Treasury Regulation § 1.199-3(i)(6)(ii) excluding “online services” and other services from DPGR. Treas. Reg. § 1.199-3(i)(6)(iii); accord BATS Glob. Mkts. Holdings, Inc. & Subs. v. Commissioner (BATS Global I), 158 T.C. 118, 140 (2022) (describing the exceptions as “narrow”), aff’d, BATS Glob. Mkts. Holdings, Inc. & Subs. v. Commissioner (BATS Global II), No. 22-9002, 2023 U.S. App. LEXIS 17608 (10th Cir. July 12, 2023). Treasury Regulation § 1.199-3(i)(6)(iii) provides:
Notwithstanding paragraph (i)(6)(ii) of this section, if a taxpayer derives gross receipts from providing customers access to computer software MPGE in whole or in significant part by the taxpayer within the United States for the customers’ direct use while connected to the Internet or any other public or private communications network (online software), then such gross receipts will be treated as being derived from the lease, rental, license, sale, exchange, or other disposition of computer software only if—
(A) The taxpayer also derives, on a regular and ongoing basis in the taxpayer’s business, gross receipts from the lease, rental, license, sale, exchange, or other disposition to customers that are
24 We will discuss the definition of “computer software” in Treasury Regulation
§ 1.199-3(j)(3)(i) infra OPINION Part VII.B.2.
[*32] not related persons (as defined in paragraph (b)(1) of this section) of computer software that—
(1) Has only minor or immaterial differences from the online software;
(2) Has been MPGE by the taxpayer in whole or in significant part within the United States; and
(3) Has been provided to such customers either affixed to a tangible medium (for example, a disk or DVD) or by allowing them to download the computer software from the Internet; or (B) Another person derives, on a regular and ongoing basis in its business, gross receipts from the lease, rental, license, sale, exchange, or other disposition of substantially identical software (as described in paragraph (i)(6)(iv)(A) of this section) (as compared to the taxpayer’s online software) to its customers pursuant to an activity described in paragraph (i)(6)(iii)(A)(3) of this section.
We refer to Treasury Regulation § 1.199-3(i)(6)(iii)(A) as the self-
comparable exception. Cf., e.g., I.R.S. Chief Couns. Adv. Mem. 201603028 (Jan. 15, 2016). Bloomberg does not assert that it meets the requirements of the self-comparable exception, but the exception is still of minor relevance in these cases.
We refer to Treasury Regulation § 1.199-3(i)(6)(iii)(B) as the third-party comparable exception. Cf., e.g., I.R.S. Chief Couns. Adv. Mem. 201603028. For purposes of the third-party comparable exception substantially identical software is computer software that (1) from a customer’s perspective has the same functional result as the taxpayer’s online software and (2) has a significant overlap of features or purpose with the taxpayer’s online software. Treas. Reg. § 1.199-3(i)(6)(iv)(A).
C. Background on the Self-Comparable and Third-Party Comparable Exceptions
On January 19, 2005, the Department of the Treasury (Treasury)
issued I.R.S. Notice 2005-14, 2005-1 C.B. 498, to provide “interim guidance” on section 199. The notice stated: “Except as provided in the
[*33] safe harbor [for embedded services 25], gross receipts derived by a taxpayer from software that is merely offered for use to customers online for a fee are not DPGR.” Notice 2005-14, § 3.04(7)(d), 2005-1 C.B. at 508. This general rule, that the provision of access to online software constituted a service, was reflected in proposed regulations published November 4, 2005. REG-105847-05, 70 Fed. Reg. 67,220, 67,226 (Nov. 4, 2005); see also id. at 67,250. A preamble accompanying the proposed regulations read, in part: “[T]he use of online computer software does not rise to the level of a lease, rental, license, sale, exchange, or other disposition as required under section 199 but is instead a service.” Id. at 67,226. Treasury requested comments “concerning whether gross receipts derived from the provision of certain types of online software should qualify under section 199 as being derived from a lease, rental, license, sale, exchange, or other disposition of the software and, if so, how to distinguish between such types of online software.” Id. at 67,239.
In June 2006 Treasury issued temporary regulations regarding section 199. The supplementary information to the temporary regulations noted that on July 21, 2005, the Chairman and the Ranking Member of the Senate Finance Committee and the Chairman of the House Ways and Means Committee sent a letter to Treasury regarding the treatment of online access to computer software. T.D. 9262, 2006-1 C.B. 1040, 1040–41. The letter requested that Treasury consider whether the treatment of computer software accessed online should be similar to the treatment of computer software distributed by other means, such as by physical delivery or delivery via internet download. Id., 2006-1 C.B. at 1041. The letter also noted that “gross receipts from the provision of services are not treated as DPGR, regardless of the fact that computer software may be used to facilitate such service transactions.” Id.
The supplementary information to the temporary regulations also summarized comments regarding the treatment of online software. Comments “suggested that a customer’s use of computer software is tantamount to a license of the computer software.” Id. Other commentators suggested that “other disposition” in section 199(c)(4)(A) “is broad enough to include the provision of computer software for online use.” Id. These comments were not incorporated into the temporary regulations. Id. Instead, the temporary regulations introduced the
25 The safe harbor for embedded services set forth in the interim guidance was
later altered. Compare Notice 2005-14, § 3.04(7)(b), 2005-1 C.B. at 508, with Treas. Reg. § 1.199-3(i)(4)(i)(A).
[*34] self-comparable and third-party comparable exceptions. The supplementary information noted that these exceptions were added “as a matter of administrative convenience” to provide “two exceptions under which gross receipts derived by a taxpayer from providing computer software to customers for the customers’ direct use while connected to the Internet will be treated as being derived from the lease, rental, license, sale, exchange, or other disposition of such computer software.” Id.
On April 16, 2007, Treasury promulgated final regulations under section 199. The supplementary information to the final regulations reiterates first the general rule that gross receipts derived from online services are excluded from DPGR, and second, the two exceptions from the general rule, under which gross receipts derived from online software are treated as DPGR. T.D. 9317, 2007-1 C.B. 957, 958.
IV. Job Creation in the United States
As stated supra OPINION Part III.A, Congress enacted section 199 with the intent to stimulate job creation in the United States and strengthen the economy by reducing the tax burden on domestic manufacturers. While it is not legally determinative, Bloomberg hired employees in the United States in the years at issue to produce BPS software, which is the outcome that Congress sought to promote. 26
In the years at issue, the number of employees in Bloomberg’s R&D department (which comprised mostly programmers) increased by about 35%, largely because of hires in the United States. Over 85% of Bloomberg’s software programmers worked in the United States, as did over 85% of all R&D department employees. Testimony suggested that
26 There were (and are) other economic and national security benefits to producing software domestically. See Tax Reform Options: Incentives for Capital Investment and Manufacturing: Hearing Before the S. Comm. on Finance, 112th Cong. 47–50 (2012) (Statement of Robert D. Atkinson, President and Founder, Information Technology and Innovation Foundation) (discussing section 199 and “economic rationales for designing a tax code that favors traded technology industries”); see also David A. Kessler, Protection and Protectionism: The Practicalities of Offshore Software Development in Government Procurement, 38 Pub. Cont. L.J. 1, 26–38 (2008) (discussing federal government scrutiny of “foreign origin software”); Off. of Mgmt. & Budget, Exec. Off. of the President, Memorandum M-22-18: Enhancing the Security of the Software Supply Chain Through Secure Software Development Practices 1 (2022) (noting that the global information technology supply chain “faces relentless threats from nation state and criminal actors seeking to steal sensitive information and intellectual property, compromise the integrity of Government systems, and conduct other [harmful] acts”).
[*35] R&D department employees were well paid. For example, one witness testified that an entry-level data department “analyst would have cost [Bloomberg] about half what an [entry-level] engineer would have cost.”
Working predominantly in the United States, Bloomberg’s R&D department employees maintained, updated, and improved BPS, including the software that enabled it. Jobs created from BPS software production contributed to U.S. wages paid by Bloomberg that increased from $806 million in 2008 to $968 million in 2010. It is noteworthy that this 20% increase in two years occurred at a time when the economy was generally poor.
V. BATS Global and Direct Supply
BATS Global I and Direct Supply, Inc. v. United States (Direct Supply I), 635 F. Supp. 3d 685 (E.D. Wis. 2022), aff’d, Direct Supply, Inc. v. United States (Direct Supply II), 96 F.4th 1031 (7th Cir. 2024), are the only cases with published opinions that substantively address Treasury Regulation § 1.199-3 as it relates to computer software. We will discuss these cases and why they are distinguishable.
A. BATS Global I and II
1. BATS Global I
BATS Global Markets Holdings, Inc. (BATS), operated securities exchanges that used software BATS developed. BATS Global I, 158 T.C. at 120, 146. BATS charged its customers three types of fees: (1) logical port fees, (2) routing fees, and (3) transaction fees. Id. at 132. We considered whether each type of fee was derived from providing customers access to software for their direct use, concluding that no fees were so derived. Id. at 143.
Logical port fees were connectivity fees for access to BATS’s private communications network, which enabled customers to interact with BATS’s exchanges. Id. We ruled that “[c]onnection to the logical ports is akin to internet access rather than direct use” of software. Id. at 144. Accordingly, we held that the logical port fees were fees for the service of “provid[ing] the customer with a connection” and were not DPGR. Id.
Routing fees were charged when a customer’s order was executed on an external exchange. Id. On the basis of a “securities routing
[*36] agreement” between BATS and its customers, we found that customers “could only submit orders with instructions as to routing strategy” and BATS then “acted as the customers’ agent for the purpose of providing these routing services.” Id. at 144–45. We also stated that “varying prices customers paid for routing strategies reflected the different services [BATS] provided, such as routing orders to particular types of external markets.” Id. at 145. Accordingly, we held that the routing fees were fees for “routing and trade execution services” and were not DPGR. Id.
Transaction fees were charged when a customer’s order was executed, but only if the order removed liquidity from one of BATS’s exchanges. 27 Id. at 133–34, 145–46. In part because “transaction fees were charged to customers according to how much they accessed or removed liquidity,” we ruled that transaction fees “reflected the trade execution services [BATS] provided.” Id. at 145–46. In addition, BATS charged varying transaction fees for different order types. Id. at 146. We ruled that “[t]he different prices of the transaction fees reflected the different services [BATS] performed for customers, such as hiding their orders from being displayed in market data or adjusting the order prices using display price sliding. Customers paid for different services, not different uses of the trading software.” Id. Accordingly, we held that the transaction fees were fees for “trade execution services” and were not DPGR. Id.
With respect to the fees as a whole, we stated that “[t]he fact that [BATS’s] Exchanges use software to operate does not convert [BATS’s] trade execution services into the provision of software for customers’ direct use.” Id. We further held that, even if any fees were derived from providing customers access to software for their direct use, other requirements of the third-party comparable exception were not satisfied. Id. at 148. Though third parties sold software that allowed their customers to operate electronic exchanges, we noted that BATS’s customers did not license BATS’s software, and could not use it, to operate their own exchanges. Id. at 151–52. Rather, BATS “itself operated the Exchanges” and BATS’s “customers could only submit, cancel, and modify orders to trade securities.” Id. at 151. We ruled that “[t]rading securities and operating a securities exchange are two distinct activities and are not the same functional result from a customer’s perspective.” Id. at 152. Accordingly, we held that “third-party vendors’
27 BATS also offered rebates (equal to 79% of transaction fees charged) to entice
customers to add liquidity to BATS’s exchanges. BATS Global I, 158 T.C. at 145.
[*37] software is not substantially identical to [BATS’s] software within the meaning of Treasury Regulation § 1.199-3(i)(6)(iv)(A), and therefore [BATS] does not meet the requirements of the third-party comparable exception.” Id. at 152–53 (citing Treas. Reg. § 1.199-3(i)(6)(iii)(B)).
2. BATS Global II
The U.S. Court of Appeals for the Tenth Circuit affirmed BATS Global I. In its short order and judgment in BATS Global II, 28 2023 U.S. App. LEXIS 17608, at *2, the Tenth Circuit did not address whether BATS derived gross receipts from providing customers’ access to software for their direct use. Instead, the Tenth Circuit affirmed BATS Global I because BATS “failed to demonstrate that a third party derived revenue from licenses or other dispositions of software that was substantially identical to [BATS’s] software, as required by the so-called third-party comparable exception.” Id.
B. Direct Supply I and II
1. Direct Supply I
Direct Supply, Inc. (Direct Supply), was in the business of supplying nursing home chains. Direct Supply I, 635 F. Supp. 3d at 686. In one of its lines of business, Direct Supply created software that nursing home chains used to order products over the Internet. Id. Direct Supply used the software to create and operate an electronic marketplace of goods available from suppliers, which was called DSSI. Id. Using DSSI, a nursing home chain could browse and order products available from all the suppliers with which that chain had procurement contracts. Id. at 686–87. Direct Supply owned, hosted, maintained, and updated the DSSI software, with nursing home chains “access[ing] the software by entering login credentials into web portals.” Id. at 689.
If a nursing home chain wanted to use DSSI, it and its suppliers first had to sign agreements with Direct Supply. Id. at 687–88. The agreements generally described Direct Supply’s provision of services other than the provision of access to software to nursing home chains and suppliers. Id. The agreements provided that Direct Supply would be compensated in three ways. Id. First, the nursing home chain would pay Direct Supply a “[m]aintenance [f]ee” based on the chain’s number of beds and facilities using DSSI. Id. at 687. This was a fee for creating an
28 The Tenth Circuit’s order and judgment is not binding precedent but may be
cited for its persuasive value consistent with Fed. R. App. P. 32.1 and 10th Cir. R. 32.1.
[*38] electronic catalog with information from the chain’s suppliers, operating DSSI, maintaining transaction information, and otherwise developing the chain’s “e-procurement system.” Id. Second, each supplier was obligated to pay a one-time “[i]mplementation [f]ee” for integrating into DSSI, though this fee was almost always waived. Id. at 688. Third, “[t]ransaction [f]ee[s]” paid by suppliers were based on “amount[s] invoiced by a supplier for goods sold through” DSSI. Id. Transaction fees constituted about 95% of the fees paid to Direct Supply in the years before the Court. Id. at 689. Maintenance and certain miscellaneous fees made up the remaining 5%; Direct Supply did not receive any implementation fees in the years before the Court. Id. at 689–90.
Direct Supply argued that it was entitled to a section 199 deduction pursuant to either Treasury Regulation § 1.199-3(i)(6)(i) or (iii). Id. at 692–96. Much of the analysis in Direct Supply I pertains to the Treasury Regulation § 1.199-3(i)(6)(i) issue. Id. Because Bloomberg claimed only that it was entitled to a section 199 deduction pursuant to Treasury Regulation § 1.199-3(i)(6)(iii), some of the analysis in Direct Supply I is inapplicable to Bloomberg’s case.
In granting summary judgment in favor of the Government in Direct Supply I, the court held that neither the transaction nor the maintenance fees constituted DPGR pursuant to Treasury Regulation § 1.199-3(i)(6)(i) because the fees
were derived from the provision of a service rather than from a license or rental of software. Direct Supply did not simply rent or license software to a nursing-home chain or supplier and then leave the customers to use the software as they saw fit. Instead, Direct Supply created and maintained a customized online marketplace for the chain and its suppliers. Services were involved in every step of this process. . . . In short, Direct [S]upply derived revenue from creating and maintaining customized online marketplaces for its customers, not from renting or licensing software to them.
Direct Supply I, 635 F. Supp. 3d at 693. Addressing Treasury Regulation § 1.199-3(i)(6)(iii), the court stated:
A threshold requirement for [the third-party comparable exception] is that the taxpayer “derive[] gross receipts from
[*39] providing customers access to computer software . . . for the customers’ direct use while connected to the Internet.” [Treas. Reg. § 1.199-3(i)(6)(iii).] Direct Supply’s customers do access DSSI while connected to the Internet. However, as explained above, Direct Supply does not derive gross receipts from providing access to DSSI over the Internet. Instead, Direct Supply derives revenue from providing the services involved in creating and maintaining customized online marketplaces for nursing-home chains and their suppliers. . . . [T]he mere fact that customers access Direct Supply’s online software while using these services does not convert the services into a provision of software for the customers’ direct use, just like a bank customer’s accessing the bank’s online software to complete an online banking transaction does not convert the banking transaction into a provision of software to the customer. See also [BATS Global I, 158 T.C. at 146] (“Petitioner is an operator of securities exchanges. The fact that the Exchanges use software to operate does not convert petitioner’s trade execution services into the provision of software for customers’ direct use.”). Thus, the Treasury exceptions that treat software accessed over the Internet equivalently to software provided on physical media or by download do not apply to DSSI. No matter how DSSI is provided to or accessed by customers, the customers are not paying fees for the software itself. They are paying fees for Direct Supply’s services involved in creating and maintaining the customized online marketplace.
Id. at 695–96. The court declined to address other requirements of the third-party comparable exception “[b]ecause Direct Supply [did not] meet the threshold requirement.” Id. at 696.
2. Direct Supply II
The U.S. Court of Appeals for the Seventh Circuit affirmed Direct Supply I. The Seventh Circuit stated that “Direct Supply’s receipts were not ‘directly derived’ from software.” Direct Supply II, 96 F.4th at 1033 (citing Treas. Reg. § 1.199-3(i)(6)(i)). The Seventh Circuit also stated that Direct Supply did not satisfy Treasury Regulation § 1.199-3(i)(6)(iii) because “it did not provide ‘direct use’ of the software underlying DSSI or establish that DSSI is ‘substantially identical’ from consumers’ perspective to” third-party software. Direct Supply II, 96 F.4th at 1033.
[*40] In the section of its opinion addressing Treasury Regulation § 1.199-3(i)(6)(i), the Seventh Circuit stated:
Things might be more complex if Direct Supply had attempted to determine how much of the revenue from DSSI could be traced to the value of software and how much to the efforts of its staff (and the efforts of both vendors and customers) to make ordering work, but it has not attempted any such partition. It treated the whole gross revenue from DSSI as eligible for the § 199 deduction, which has to be the one impossible outcome.[29]
Direct Supply II, 96 F.4th at 1033. The Seventh Circuit also stated, directly after discussing Treasury Regulation § 1.199-3(i)(6)(iii):
As Direct Supply sees things, “if Direct Supply had chosen a different pricing model and its contracts had said, ‘Direct Supply hereby grants licensee a non-exclusive license to use DSSI for one year for $X . . .’ there would be much less controversy on this aspect of the deduction.” Maybe—though as we’ve remarked DSSI is more than just software. Direct Supply would have needed to license something comparable to the packages licensed or sold by [third parties]. Even then, all Direct Supply could have deducted would have been the fees received from its customers. What it actually deducted were [mostly] fees received from the vendors—and even with the pricing model that Direct Supply now wishes it had used, it would be impossible to picture the vendors as acquiring any software from Direct Supply.
Id. at 1033–34 (citation of the record omitted).
C. Distinguishing Bloomberg’s Cases
While the facts are complex, the BATS Global and Direct Supply opinions involve relatively straightforward applications of Treasury
29 While this statement is part of the opinion pertaining to Treasury Regulation
§ 1.199-3(i)(6)(i), there appears to be some overlap in the Seventh Circuit’s analysis pertaining to that regulation and its analysis pertaining to Treasury Regulation § 1.199-3(i)(6)(iii). Similar overlap occurred in Direct Supply I. See Direct Supply I, 635 F. Supp. 3d at 695–96 (referring back to Treas. Reg. § 1.199-3(i)(6)(i) analysis during analysis of Treas. Reg. § 1.199-3(i)(6)(iii)). We believe the Seventh Circuit’s statement is relevant to Bloomberg’s cases.
[*41] Regulation § 1.199-3(i)(6). BATS’s logical port fees were derived from providing access to BATS’s private communications network, and the routing and transaction fees were charged per executed order (not submitted order) and varied for different order types and routing strategies. BATS Global I, 158 T.C. at 143–48. Direct Supply derived receipts from setting up, maintaining, and selling products on DSSI. Direct Supply I, 635 F. Supp. 3d at 693–96. Clearly, none of these network-access, setup, maintenance, or transaction-based fees were derived from the provision of access to software. Agreements between BATS/Direct Supply and third parties also strongly supported the position that BATS and Direct Supply did not derive fees from the provision of access to software. Rather, each company derived fees only from the provision of other services.
Unlike BATS and Directly Supply, Bloomberg charged customers flat subscription fees to use BPS and OMS, no matter how, or how much, they used BPS and OMS. Furthermore, subscription agreements support Bloomberg’s position that a portion of the fees was derived from Bloomberg’s provision of access to software. Bloomberg has consistently recognized that a portion of the fees was not DPGR because it was attributable to the provision of other services (data, news, etc.). Though we do not adopt Bloomberg’s position with respect to all software at issue in these cases, we believe that this is the pricing model and general effort to partition fees between “the value of [the provision of access to] software” and other services that the Seventh Circuit contemplated in Direct Supply II, 96 F.4th at 1033–34.
Portions of the BPS subscription fees allocable to the provision of data and news (financial information services) and email and instant messaging (communication services), and the software that enabled those services, are similar to fees charged by BATS and/or Direct Supply. However, the portion of the BPS subscription fees attributable to BPS analytical and graphing software (used to manipulate, analyze, visualize, and otherwise draw insights from data and news) is different from any fees charged by BATS or Direct Supply. As discussed infra OPINION Part VII.B.1.c, although BPS analytical and graphing software operates in conjunction with financial information services, a portion of the BPS subscription fees is attributable to Bloomberg’s provision of access to the analytical and graphing software to customers. As discussed infra OPINION Part VIII.B, Bloomberg also derived gross receipts from the provision of access to OMS software to customers.
[*42] In BATS Global I and II it was clear that the third-party comparable exception was not satisfied. The third-party software at issue was not remotely close to being “substantially identical to [BATS’s] software within the meaning of Treasury Regulation § 1.199- 3(i)(6)(iv)(A).” See BATS Global I, 158 T.C. at 152–53; see also BATS Global II, 2023 U.S. App. LEXIS 17608 (issuing an order and judgment with almost no analysis because the issue was clear cut). However, Reuters’s RMDS and 3000 Xtra programs, running together, use analytical and graphing software that is substantially identical to BPS analytical and graphing software, discussed further infra OPINION Part VII.C.3. In addition, Charles River IMS software is substantially identical to Bloomberg’s OMS software, discussed further infra OPINION Part VIII.C.
VI. Issues with Treasury Regulation § 1.199-3
A. General Issues
Though application of Treasury Regulation § 1.199-3 is straightforward in less complex matters involving computer software, such as the BATS Global and Direct Supply cases, we often found the regulation to be deficient as applied to the facts in these cases. While we recognize the challenges of drafting regulations regarding the quickly evolving field of computer software, Treasury Regulation § 1.199-3 provisions regarding/relevant to computer software often read more as a collection of parts forced together than as a seamless whole.
Inadequacies of Treasury Regulation § 1.199-3 will be addressed throughout this Opinion, and largely fall into three categories: (1) imprecisely written examples and provisions; (2) poor incorporation of computer software provisions into the rest of the regulation; and (3) inadequate descriptions and definitions, especially regarding modular software.
B. Interpreting Treasury Regulation § 1.199-3
We find Treasury Regulation § 1.199-3 to be ambiguous with respect to many of the questions presented in these cases. There are several instances in which we must interpret ambiguities in the regulation.
In matters of regulatory construction, the rules of statutory construction apply. Caltex Oil Venture v. Commissioner, 138 T.C. 18, 34 (2012) (citing Estate of Schwartz v. Commissioner, 83 T.C. 943, 952–53
[*43] (1984)). The starting point for interpreting a statute or a regulation is its plain and ordinary meaning unless that “would produce absurd or unreasonable results.” Union Carbide Corp. & Subs. v. Commissioner, 110 T.C. 375, 384 (1998). Furthermore, “we do not just look at the words or phrases in isolation, but rather we read th[o]se words and phrases in their context.” See Shea Homes, Inc. v. Commissioner, 142 T.C. 60, 100 (2014) (citing FDA v. Brown & Williamson Tobacco Corp., 529 U.S. 120, 133 (2000)), aff’d, 834 F.3d 1061 (9th Cir. 2016). That context includes the governing statute and the entire scheme of regulations issued thereunder. See id. at 100–01.
Respondent argued for an extremely restrictive interpretation of Treasury Regulation § 1.199-3 that would eliminate favorable treatment under section 199 for all of Bloomberg’s software. Indeed, it seems that the provision of access to almost any complex software would not qualify for a section 199 deduction if we adopted respondent’s interpretation of the regulation. Such a result cannot be reconciled with the statute.
Bloomberg did not argue that any part of Treasury Regulation § 1.199-3 is invalid, even after the release of Loper Bright Enterprises v. Raimondo, 144 S. Ct. 2244 (2024) (overruling Chevron, U.S.A., Inc. v. Natural Resources Defense Council, Inc., 467 U.S. 837 (1984)). While we recognize that implementing section 199 without some administrative guidance is not a tenable position, see Loper Bright Enters., 144 S. Ct. at 2262 (“[C]ourts may . . . seek aid from the interpretations of those responsible for implementing particular statutes.”), we generally agree with Bloomberg that respondent’s interpretation of Treasury Regulation § 1.199-3 is overly restrictive. However, we need not invalidate any portion of Treasury Regulation § 1.199-3 at issue because our interpretation of the regulation differs from respondent’s. Our reading represents the best interpretation of both section 199 and the regulation text itself. See Loper Bright Enters., 144 S. Ct. at 2266 (stating that if a government agency’s interpretation of a statute “is not the best, it is not permissible”).
In enacting section 199, Congress generally treated computer software like any other QPP. See § 199(c)(5)(B) (defining “qualifying production property” as including “any computer software”). In Treasury Regulation § 1.199-3(i)(6), the Commissioner limited the disposition of computer software by not including the provision of access to software over the internet. As discussed supra OPINION Part III, the Commissioner later added exceptions to this limitation that (in short) treat gross receipts derived from the provision of access to software as
[*44] DPGR in certain instances. See Treas. Reg. § 1.199-3(i)(6)(iii). However, the Commissioner failed to draft Treasury Regulation § 1.199- 3(i)(6) in an unambiguous manner.
Implicitly recognizing that Treasury Regulation § 1.199-3(i)(6) is not clearly written, respondent argued that we should interpret Treasury Regulation § 1.199-3(i)(6)(iii) in his favor because “exceptions are narrowly construed in order to preserve the contours of the general rule (in this case § 1.199-3(i)(6)(ii)). See Maracich v. Spears, 570 U.S. 48, 60 (2013); Commissioner v. Clark, 489 U.S. 726, 739 (1989).” But as we have long recognized, we interpret regulations so as to avoid conflict with the corresponding statute. See Austin v. Commissioner, 141 T.C. 551, 563 (2013) (“In the end, a regulation will be interpreted to avoid conflict with a statute.” (citing Phillips Petroleum Co. & Affiliated Subs. v. Commissioner, 97 T.C. 30, 35 (1991), aff’d, 70 F.3d 1282 (10th Cir. 1995) (unpublished table decision))); see also Liberty Glob., Inc. v. Commissioner, No. 341-21, 161 T.C., slip op. at 20–21 (Nov. 8, 2023). The statute Congress drafted shows that it intended for “any computer software” (meeting other general requirements stated in the statute) to qualify for the section 199 deduction. See § 199(c)(5)(B). The statute itself draws no distinction between computer software used while connected to the Internet or computer software used otherwise. The distinction is drawn only in the Commissioner’s regulations. Thus, the “general rule” that respondent asks us to preserve is a creature of the Commissioner’s own making. In this circumstance, there is no warrant for construing the exception to the general rule more narrowly than it is written, and the cases respondent cites (which pertain to general rules found in statutes) are not on point.
We decline respondent’s request to interpret in his favor the ambiguity that he created. Throughout this Opinion we interpret the ambiguous provisions of Treasury Regulation § 1.199-3 consistently with the statute and congressional intent, rather than reward the Commissioner for drafting an ambiguous regulation. The result we reach is consistent with the best reading of both section 199 and Treasury Regulation § 1.199-3.
C. Treatment of Gross Receipts as Derived from the Disposition of Computer Software
We will address one ambiguous provision of Treasury Regulation § 1.199-3 in this OPINION Part VI.C. Other ambiguous provisions will be addressed throughout the remainder of this Opinion.
[*45] The parties agree that the provision of online software is a service pursuant to Treasury Regulation § 1.199-3(i)(6)(ii). If satisfied, Treasury Regulation § 1.199-3(i)(6)(iii) does not on its face treat the provision of online software as a disposition of property. Instead, that subsection only “treat[s]” gross receipts from the provision of qualifying online software “as being derived from the lease, rental, license, sale, exchange, or other disposition of computer software.” Id.
There is a subtle but important distinction here: By its terms Treasury Regulation § 1.199-3(i)(6)(iii) affects only gross receipts derived from the provision of access to software. The regulation does not explicitly treat the underlying provision of access to software as a disposition of property (instead of a service) for purposes of section 199.
Our interpretation of Treasury Regulation § 1.199-3(i)(6)(iii) is that, if it is satisfied, the provision of access to software is treated as a disposition of property for purposes of the section 199 deduction. This makes substantially more sense than merely treating the gross receipts derived from such a transaction as being derived from a disposition of property, while leaving the transaction itself a service. We note that Treasury Regulation § 1.199-3(i)(1)(i) defines “[t]he term derived from the lease, rental, license, sale, exchange, or other disposition . . . as, and limited to, the gross receipts directly derived from the lease, rental, license, sale, exchange, or other disposition of QPP.” In addition, certain other general provisions in Treasury Regulations § 1.199-3 apply only when there has been a disposition of property. Id. paras. (d)(1), (i)(4)(i)(A). Our interpretation of Treasury Regulation § 1.199-3 is that such general provisions were meant to apply in conjunction with the specific rules for computer software in Treasury Regulation § 1.199- 3(i)(6). 30 Relevant general provisions of Treasury Regulation § 1.199-3 will be discussed further infra OPINION Part VII.B.6.g.
VII. BPS Software Qualification Issue
In this OPINION Part VII, we will address whether gross receipts derived from the provision of access to BPS software satisfy the requirements of Treasury Regulation § 1.199-3(i)(6)(iii) and qualify as DPGR. We rule that only gross receipts derived from the provision of access to BPS analytical and graphing software qualify as DPGR. We
30 Though the parties differ on many specifics, they largely agree that general
provisions of Treasury Regulation § 1.199-3 apply or are relevant in these cases.
[*46] will determine the amounts of those gross receipts infra OPINION Part X.
A. The Parties’ Use of Certain Evidence
The parties submitted lengthy briefs setting forth numerous arguments regarding whether a portion of the BPS subscription fees constitutes DPGR. We will address most of those arguments in depth in this OPINION Part VII but will first generally address the parties’ use of certain evidence.
Many of the parties’ arguments in these cases pertain to whether BPS, BPS components, and/or other items (such as 3000 Xtra) are mostly or entirely software products or services. The extensive record in these cases has provided the parties with ample opportunities to cherry-pick discrete descriptions from various documents that the parties claim support their respective positions. We mostly found such evidence to be of little relevance. There are numerous occasions in which Bloomberg or another person/entity describes BPS or another item as either “a service,” “software,” “a program,” or another such term simply as a matter of convenience. In addition, a given person might consider BPS (or 3000 Xtra) software to be “software as a service” (SaaS) and describe it as either software or a service. 31
B. The Treasury Regulation § 1.199-3(i)(6)(iii) Threshold Requirement
Before we address the third-party comparable exception, we must determine whether Bloomberg derived gross receipts from providing customers access to software MPGE in whole or in significant part by
31 As stated in Direct Supply I, 635 F. Supp. 3d at 694, SaaS
is a way of obtaining access to software. To access SaaS software, a customer does not purchase the software on tangible media (such as a disk) or download it to his or her own computer hardware over the Internet. Instead, the customer accesses the software by connecting to the SaaS provider’s servers over the Internet. At all times, the software is hosted on the SaaS provider’s servers rather than on the customer’s computer hardware.
(Citation omitted.)
Bloomberg and respondent dispute whether BPS software qualifies as SaaS;
Bloomberg claims it does and respondent claims it does not. We need not decide which party is correct because BPS software is certainly close enough to SaaS that a given person might easily consider BPS software to be SaaS. The same is true of 3000 Xtra software.
[*47] Bloomberg within the United States for customers’ direct use while connected to the internet or any other public or private communications network. See Treas. Reg. § 1.199-3(i)(6)(iii). This is the threshold requirement of Treasury Regulation § 1.199-3(i)(6)(iii) (threshold requirement). Direct Supply I, 635 F. Supp. 3d at 695; see also BATS Global I, 158 T.C. at 148 (holding that taxpayer “did not meet the threshold requirements of Treasury Regulation § 1.199-3(i)(6)(iii) with respect to the Fees” at issue).
The threshold requirement can be broken up into four elements:
(1) the taxpayer must derive gross receipts from providing customers access to computer software, (2) the software must be MPGE in whole or in significant part by the taxpayer within the United States, (3) customers must directly use the software, and (4) customers must use the software while connected to the internet or any other public or private communications network. The parties made numerous arguments relating to the threshold requirement. After we have addressed each element (and whether BPS analytical and graphing software can be considered alone), we will address more specific arguments.
1. Element One: Deriving Gross Receipts from Providing Customers with Access to Software
The parties disagree whether Bloomberg derived any gross receipts from providing customers with access to BPS software. We conclude that (1) Bloomberg derived a portion of the BPS subscription fees from providing customers with access to BPS analytical and graphing software and (2) Bloomberg did not derive fees from the provision of access to other software.
BPS Subscription Agreements entered into in the years at issue identified Bloomberg as a “service provider” and the customer as a “service recipient.” The agreements read that Bloomberg would provide “services described in” the agreements and that the service recipient “subscribe[d] to such services in accordance with this Agreement.” The agreements provided that the services consist of “a nonexclusive and nontransferable right to use the BLOOMBERG PROFESSIONAL service information, data, software, and equipment . . . in accordance with this Agreement.” BPS Subscription Agreements from prior years that had automatically renewed were in effect in the years at issue and provided that the services “consist of a nonexclusive and nontransferable license and lease to use the BLOOMBERG
[*48] PROFESSIONAL service software, data and equipment . . . in accordance with this Agreement.” These BPS Subscription Agreements generally favor Bloomberg’s position that portions of the BPS subscription fees were derived from the provision of access to software. Although the BPS Subscription Agreements do not set forth specific portions of the BPS subscription fees attributable to software, they identify the provision of access to software as one of the services being provided by Bloomberg. 32
Bloomberg built BPS software in house because it viewed BPS software as a strategic advantage that it wanted to maintain control over. Bloomberg employed thousands of people in its R&D department, including 1,500 software programmers as of December 2008. Such programmers were vital in maintaining and improving BPS software; they allowed Bloomberg to frequently add new functions or enhance existing functions in response to user suggestions or advances by competitors. Such updates (and associated user training) helped to (1) embed BPS use into users’ daily routines and (2) fend off competitive threats to Bloomberg’s market share. In the years at issue the number of employees in Bloomberg’s R&D department increased by about 35%, significantly expanding its software programming capabilities even at a time when the economy was generally poor. Bloomberg’s actions to strengthen its R&D department (especially in difficult economic times) indicate that it viewed software as integral to improving BPS and increasing BPS revenue.
While the facts discussed in the prior two paragraphs favor Bloomberg’s position with respect to software in general, facts regarding many of the specific BPS software components do not favor Bloomberg. The evidence shows that, much as in BATS Global I and Direct Supply I and II, significant portions of BPS software merely enabled the provision of Bloomberg’s financial information and communication services. We will proceed to discuss various BPS software components.
a. Collection and Search Software
A portion of BPS software enabled BPS to collect, categorize, and store vast amounts of financial information. Such software likewise
32 Obviously, we would not accept unsupported statements in agreements
between a taxpayer and its customers as satisfying the “derived fees from providing customers access to computer software” element. In these cases, other evidence confirms that portions of the BPS subscription fees were derived from the provision of access to software.
[*49] enabled users to search, sort, and generally access that financial information, as well as receive updated information throughout the day. Bloomberg argued that “BPS software helped [users] make sense of an otherwise unmanageable amount of information.” That is true, but the collection and search software did this only by facilitating/enabling Bloomberg’s financial information service. Customers were not paying for access to the BPS collection and search software that they used to find and view financial information; they were paying for the provision of the underlying financial information that such software enabled.
BPS collection and search software is similar to software at issue in BATS Global I that enabled BATS’s exchanges to operate. Discussing the transaction fees in that case, we stated:
The regulations provide an analogous example of a company that uses computer software to provide online services to customers. Example 2 describes M, an internet auction company that produces computer software within the United States that enables its customers to participate in internet auctions for a fee. Treas. Reg. § 1.199-3(i)(6)(v) (example 2). The example does not elaborate on how M’s auction software enabled customers to participate in internet auctions or how M’s customers participated in internet auctions; it focuses only on the fact that M’s activities constituted the provision of online services. The example concludes that M’s gross receipts derived from the internet auction services are non-DPGR because Treasury Regulation § 1.199-3(i)(6)(ii) excludes gross receipts derived from online services from gross receipts derived from a disposition of computer software.
[BATS’s] transaction fees are analogous to Example 2. Both [BATS] and M, the company in the example, charged their customers fees for participation in electronic markets and facilitated this service with computer software. [BATS’s] provision of trade execution services was an online service within the meaning of Treasury Regulation § 1.199-3(i)(6)(ii).
BATS Global I, 158 T.C. at 146. We also cited Treasury Regulation § 1.199-3(i)(6)(v) (example 1), which reads:
[*50] L is a bank and produces computer software within the United States that enables its customers to receive online banking services for a fee. Under paragraph (i)(6)(ii) of this section, gross receipts derived from online banking services are attributable to a service and do not constitute gross receipts derived from a lease, rental, license, sale, exchange, or other disposition of computer software. Therefore, L’s gross receipts derived from the online banking services are non-DPGR.
BATS Global I, 158 T.C. at 147. We found that BATS was “more like the companies described in regulatory Examples 1 and 2, which produce computer software that they use as part of their business.” Id. Similarly, Bloomberg provided a financial information service as part of its business that BPS collection and search software enabled.
Bloomberg argued that Examples 1 and 2 in Treasury Regulation § 1.199-3(i)(6)(v) are inapplicable in these cases, stating:
Examples 1 and 2 illustrate the “online services” rule [in Treasury Regulation § 1.199-3(i)(6)(ii)]. But those examples plainly do not address the online software exceptions [in Treasury Regulation § 1.199-3(i)(6)(iii)]. They do not state, for example, that the bank or auction company charges fees for access to their software (such as a subscription fee or license, as with the BPS), that their customers directly use it, or that third parties license substantially identical software provided by disk or download. Thus, those examples do not address the online software exception of § 1.199-3(i)(6)(iii).
Importantly, Examples 1 and 2 illustrate a point the IRS overlooks: what the taxpayer charges money for matters. Respondent argues that “use of online software by customers is insufficient to satisfy the threshold requirement.” Fair enough. What matters is whether the vendor “derives gross receipts from providing access” to the software for that use. Examples 1 and 2 state explicitly that gross receipts from services do not qualify. But if the facts were different, the results would differ too. If a bank charged fees for access to domestically-produced online banking software (satisfying the online software exceptions’ threshold requirement), and if competing banks
[*51] licensed substantially identical software delivered by disk or download, receipts from online banking software would qualify under (iii). Likewise, in Example 2, if the online auction company charged customers fees to access and use American-made auction software (rather than charging commissions on transactions, as is often the case), and if third parties licensed competing auction software delivered by disk or download, the results would be different too.
(Citations of the record omitted.) Bloomberg goes on to argue that it derived gross receipts from the provision of access to software.
Bloomberg is correct that Examples 1 and 2 in Treasury Regulation § 1.199-3(i)(6)(v) could have been more thorough by discussing Treasury Regulation § 1.199-3(i)(6)(iii). However, those examples clearly show that when software simply enables or facilitates a service such as online banking, receipts are attributable to the provision of that service rather than the provision of access to software.
BPS collection and search software has one overarching purpose:
to enable the provision of Bloomberg’s financial information service. Customers did not pay Bloomberg for access to such software. Rather, customers paid for the financial information service that the software enabled. Accordingly, we rule that Bloomberg did not derive gross receipts from the provision of access to BPS collection and search software.
b. Email and IM Software
A portion of BPS software enabled BPS users to send and receive emails and instant messages through BPS. This allowed users to easily share data, graphs, news, and other information, as well as to find trading partners. Email and IM software helped to create something of a marketplace and community on BPS that attracted new users and retained existing ones.
Treasury Regulation § 1.199-3(i)(6)(ii) provides that “[g]ross receipts derived from . . . telecommunication services . . . do not constitute gross receipts derived from a lease, rental, license, sale, exchange, or other disposition of computer software.” In BATS Global I, we cited this and Treasury Regulation § 1.199-3(i)(6)(v) (example 3) in support of our conclusion that BATS’s logical port fees were for communications services, not the provision of access to software. Example 3 reads:
[*52] N provides telephone services, voicemail services, and e-mail services. N produces computer software within the United States that runs all of these services. Under paragraph (i)(6)(ii) of this section, gross receipts derived from telephone and related telecommunication services are attributable to a service and do not constitute gross receipts derived from a lease, rental, license, sale, exchange, or other disposition of computer software. Therefore, N’s gross receipts derived from the telephone and other telecommunication services are non-DPGR.
Bloomberg argued that “BPS communications functions were software functions,” comparing them to Microsoft Outlook. Bloomberg described Treasury Regulation § 1.199-3(i)(6)(v) (example 3) as one of
several examples where, unlike the case here, companies collect fees for rendering services online and use software merely to enable customers to receive those services. But these are cases where software facilitates the provision of a service and where there is no third party comparable. And, critically, these examples concern situations where companies derive gross receipts from online services under paragraph (i)(6)(ii) . . . and not, as in the case of the BPS, from providing access to software for a customer’s direct use.
(Citation omitted.)
Like other examples in Treasury Regulation § 1.199-3(i)(6)(v), Example 3 could have been more thorough by discussing Treasury Regulation § 1.199-3(i)(6)(iii). However, the example clearly stands for the general proposition that when a company produces software to run communication services, gross receipts derived are attributable to the communication services rather than the software that enabled those services. The facts of these cases indicate that the general proposition should apply. There is no indication that the BPS email and IM software had any value separate from Bloomberg’s communication services that the software enabled. We rule that Bloomberg did not derive gross receipts from the provision of access to email and IM software. Rather, any gross receipts attributable to email and instant messaging were derived from Bloomberg’s provision of communication services.
[*53] c. Analytical and Graphing Software
A portion of BPS software enabled BPS users to analyze, manipulate, and model the financial information that was available through BPS. This portion of software included tools for graphing, calculating, managing portfolio risk, etc. Unlike other BPS software discussed in this OPINION Part VII.B.1, the analytical and graphing software did not merely enable or facilitate the provision of Bloomberg’s financial information or any other service. Considering the facts and law, we rule that Bloomberg derived a portion of the BPS subscription fees for providing customers with access to the analytical and graphing software.
While other BPS software enabled or facilitated Bloomberg’s financial information or communication services, BPS analytical and graphing software did not. Instead, it helped users to draw their own insights from financial information. Whereas users had no control over the underlying financial information that they could access through BPS, users had a high amount of control over how they could analyze and/or visualize that information. Indeed, users could use analytical and graphing software to overwrite BPS-supplied data with other values to test assumptions or hypotheses. Users could also create bespoke visual representations using the extensive number of graphing functions and tools that BPS provided.
Largely because of the rise of the internet and other information technologies, by the years at issue the amount of financial information available to financial professionals (much of it for free) was enormous. BPS analytical and graphing software helped those users to find signals in the noise; to manipulate, analyze, model, and generally make data and news actionable. In the fast-moving business of finance, such software (especially operating in conjunction with data and news 33) was valuable, which partially explains why Bloomberg could charge well over $1,000 per month for each BPS subscription.
Testimony also showed that BPS analytical and graphing software was valuable to BPS customers. Bloomberg’s employees credibly testified to the importance of analytical and graphing software in obtaining new customers and retaining existing customers. One
33 While BPS analytical and graphing software operated in conjunction with
financial information, it did not enable the provision of Bloomberg’s financial information service (as BPS collection and search software did). Respondent makes many arguments related to this point, which we address infra.
[*54] employee testified that “what we find is the more that [customers] engage with [BPS], the more functions[34] that they find value in, the more that they become loyal to Bloomberg as a product.” Such testimony was supported by BPS users. One BPS user testified that BPS was “essential” in his everyday work, going on to explain the importance of various BPS software tools, including graphing, computational, and other analytical functions. The user testified that certain analytical tools were available outside of BPS but using those tools “was far less convenient” than using similar BPS tools because on BPS “it was kind of all right there at my fingertips.”
Respondent argued that BPS analytical and graphing software was
part of [Bloomberg’s financial] information service; customers were not given [the] software to use as they saw fit without the need for constant other services from [Bloomberg]. Customers’ use of these functions was integrated with, and reliant upon, [Bloomberg’s] ongoing service of providing data, news, and other content through the BPS.
Respondent further claimed that BPS analytical and graphing software was “useless” without Bloomberg’s financial information service. However, nothing in Treasury Regulation § 1.199-3 provides that gross receipts cannot be derived from the provision of software if that software merely operates in conjunction with other services.
Respondent attempted to draw inferences from regulatory examples that pertain to software that “enables” or “runs” a service. See Treas. Reg. § 1.199-3(i)(6)(v) (examples 1–3). However, BPS analytical and graphing software did not enable or run a service. Rather, it operated in conjunction with Bloomberg’s financial information service. Furthermore, Example 6 in Treasury Regulation § 1.199-3(i)(6)(v) favors Bloomberg. Example 6 reads:
Q produces payroll management computer software within the United States. For a fee, Q provides customers access to the payroll management computer software for the customers’ direct use while connected to the Internet. This
34 Although some functions did not relate to BPS analytical and graphing
software, this and similar testimony largely pertained to customers’ use of BPS analytical and graphing software.
[*55] is Q’s sole method of providing access to its payroll management computer software to customers. In conjunction with the payroll management computer software, Q provides storage of customers’ data and telephone support. One of Q’s competitors, R, derives, on a regular and ongoing basis in its business, gross receipts from the sale to customers of R’s substantially identical payroll management software that has been affixed to a compact disc as well as from the sale to customers of R’s substantially identical payroll management software that customers have downloaded from the Internet. Under paragraph (i)(6)(iii)(B) of this section, Q’s gross receipts derived from providing access to its payroll management online software will be treated as derived from the lease, rental, license, sale, exchange, or other disposition of computer software and are DPGR (assuming all the other requirements of this section are met). However, Q’s gross receipts derived from the fees that are properly allocable to the storage of customers’ data and telephone support are non-DPGR.
(Emphasis added.) The software in Example 6 runs “[i]n conjunction with” the service of data storage. While not directly on point, this example is certainly more analogous to the BPS analytical and graphing software that runs in conjunction with Bloomberg’s financial information service than the examples that respondent points to.
We rule that Bloomberg derived gross receipts from providing customers with access to BPS analytical and graphing software. The amounts of the gross receipts so derived will be addressed infra OPINION Part X.
d. Other BPS Software
BPS included other, less significant software, such as (1) feed handler software that converted data from external sources into a common format, (2) price scraping software that extracted information from user emails and instant messages, and (3) software that allowed users to arrange tiles on their launch screens (launch screen software). We rule that Bloomberg did not derive any gross receipts from the provision of access to such software.
[*56] Bloomberg admits that the feed handler software does not satisfy the Treasury Regulation § 1.199-3(i)(6)(iii) threshold requirement.
The price scraping software enabled and facilitated the delivery of certain pricing data, which was part of Bloomberg’s financial information service. The price scraping software is akin to the BPS collection and search software that we have already addressed at length. For the same reasons discussed supra OPINION Part VII.B.1.a, we rule Bloomberg did not derive gross receipts from the provision of access to the price scraping software.
Whether Bloomberg derived gross receipts from the launch screen software is a close call. On one hand, the software helped users to easily see and access data and news that they used most often. In that sense, the software facilitated Bloomberg’s financial information service. However, the software also allowed users to customize their launch screens and to see and access analytical and graphing functions that they commonly used. Ultimately, the launch screen software is a tiny portion of BPS software; analysis in both parties’ allocation issue expert reports (discussed infra OPINION Part IX) indicates that less than 1% of R&D employee hours worked were on launch screen software. We do not believe that any portion of the BPS subscription fees is allocable to Bloomberg’s provision of access to launch screen software, which was incidental to the substantive BPS features that customers paid for.
e. Conclusion Regarding Element One
We rule that only BPS analytical and graphing software satisfies the first element of the threshold requirement. Before addressing the other elements of the threshold requirement, we will address whether BPS analytical and graphing software can be considered alone for purposes of the threshold requirement and third-party comparable exception.
2. Considering BPS Analytical and Graphing Software Alone
BPS is a modular software system, meaning that it “comprise[s]
numerous software components, each of which performs independent functions, but all of which operate as a single system.” Pearl Invs., LLC v. Standard I/O, Inc., 257 F. Supp. 2d 326, 334 (D. Me. 2003). Treasury Regulation § 1.199-3 does not precisely describe how to evaluate modular software system components. Considering the facts and law, we rule that BPS analytical and graphing software may be considered
[*57] alone for purposes of the threshold requirement and third-party comparable exception.
The computer software provisions found in Treasury Regulation § 1.199-3(i)(6) do not explicitly provide for the division of software systems into separate components. However, they do provide that only gross receipts derived from the disposition of, or provision of access to, software may qualify as DPGR. See Treas. Reg. § 1.199-3(i)(6)(i), (iii). 35 In general, if a taxpayer derives gross receipts from the provision of access to software, Treasury Regulation § 1.199-3(i)(6)(iii)(B) directs one to compare “the taxpayer’s online software” to software which a third party derived gross receipts from the disposition of. Neither Treasury Regulation § 1.199-3(i)(6)(iii) nor (iii)(B) clearly states whether the comparison pertains to the entirety of the taxpayer’s online software or only the portion of the online software from which the taxpayer derived gross receipts.
On the basis of the definition of “computer software” in Treasury Regulation § 1.199-3(j)(3)(i), we rule that the comparison pertains only to the portion of the online software from which a taxpayer derives gross receipts. Treasury Regulation § 1.199-3(j)(3)(i) reads in part:
The term computer software means any program or routine or any sequence of machine-readable code that is designed to cause a computer to perform a desired function or set of functions, and the documentation required to describe and maintain that program or routine. Thus, for example, an electronic book available online or for download is not computer software. For purposes of this paragraph (j)(3), computer software also includes the machine-readable code for video games and similar programs, for equipment that is an integral part of other property, and for typewriters, calculators, adding and accounting machines, copiers, duplicating equipment, and similar equipment,
35 As previously stated, Bloomberg did not argue that a disposition of software
pursuant to Treasury Regulation § 1.199-3(i)(6)(i) occurred, only that it derived gross receipts from the provision of access to a portion of the BPS software. However, Treasury Regulation § 1.199-3(i)(6)(i) is still relevant. Treasury Regulation § 1.199- 3(i)(6)(iii) treats gross receipts that satisfy the threshold requirement and third-party comparable exception “as being derived from the lease, rental, license, sale, exchange, or other disposition of computer software.” Treasury Regulation § 1.199-3(i)(6)(i) then provides that “DPGR include the gross receipts of the taxpayer that are derived from the lease, rental, license, sale, exchange, or other disposition of computer software MPGE by the taxpayer in whole or in significant part within the United States.”
[*58] regardless of whether the code is designed to operate on a computer . . . . Computer programs of all classes, for example, operating systems, executive systems, monitors, compilers and translators, assembly routines, and utility programs, as well as application programs, are included.
This is an expansive definition. “[C]omputer software” is not limited to an entire program but may also include a “routine or any sequence” of “code . . . designed to cause a computer to perform a desired function or set of functions.” Treas. Reg. § 1.199-3(j)(3)(i) (emphasis added).
The evidence shows that BPS analytical and graphing software is a set of routines or sequences of code that cause computers to perform desired functions. Thus, it is computer software and, pursuant to the most straightforward reading of Treasury Regulation § 1.199-3(i)(6)(iii), especially (iii)(B), may be considered alone for purposes of the threshold requirement and third-party comparable exception.
3. Element Two: Software MPGE in Whole or in Significant Part Within the U.S.
The evidence in these cases shows that BPS software as a whole was MPGE in significant part within the United States. Respondent has not argued otherwise in his briefs. The evidence also strongly suggests that, like BPS software as a whole, BPS analytical and graphing software was MPGE in significant part within the United States. BPS analytical and graphing software therefore satisfies the second element of the threshold requirement.
4. Element Three: Direct Use of Software by Customers
Treasury Regulation § 1.199-3(i)(6)(iii) does not define “direct use” or specify the degree of direct use and/or access required to satisfy the threshold requirement. In BATS Global I and Direct Supply I and II, questions of “direct use” were addressed alongside other elements of Treasury Regulation § 1.199-3(i)(6)(ii) and (iii), especially whether the taxpayers derived fees from providing their customers with access to software or other services. For example, in BATS Global I, 158 T.C. at 153, we ruled that all fees “at issue . . . were derived from services [BATS] performed for customers in the course of operating its Exchanges. The Fees were not derived from providing customers access to computer software for their direct use, and they therefore do not meet the requirements of Treasury Regulation § 1.199-3(i)(6)(iii).” Other quotations regarding direct use from BATS Global I and Direct Supply I
[*59] and II are found supra OPINION Part V. Those opinions do not squarely address the “direct use” issue presented in Bloomberg’s cases in which we have already ruled that Bloomberg derived fees from providing BPS users with access to analytical and graphing software.
Considering the facts, we rule that BPS customers directly used BPS analytical and graphing software. BPS could perform thousands of analytical and graphing functions when it was directed to by a BPS user. The BPS hardware and software architecture discussed supra FoF Part III shows that (and how) BPS produced results in response to customer prompts. Treasury Regulation § 1.199-3(j)(3)(i) provides that “[t]he term computer software means any program or routine or any sequence of machine-readable code that is designed to cause a computer to perform a desired function or set of functions.” BPS customers caused BPS to perform functions by using the analytical and graphing software. This was not merely BPS customers accessing software to use a service; it was the direct use of software by customers. Cf. Direct Supply I, 635 F. Supp. 3d at 696 (“[T]he mere fact that customers access Direct Supply’s online software while using [its] services does not convert the services into a provision of software for the customers’ direct use.” (citing BATS Global I)).
BPS customers directly used BPS analytical and graphing software to perform desired functions. BPS analytical and graphing software therefore satisfies the third element of the threshold requirement.
5. Element Four: Use of Software While Connected to the Internet or Any Other Public or Private Communications Network
There is no dispute that customers used BPS while connected to BPS via the Internet or a dedicated private line. We have already ruled that customers used BPS analytical and graphing software. This element is satisfied.
6. Other Arguments Related to the Threshold Requirement
The parties (mainly respondent) made numerous arguments related to the threshold requirement, many of which we have already addressed. Several of respondent’s arguments were similar to one another and/or pertained to portions of Treasury Regulation § 1.199-3 outside of Treasury Regulation § 1.199-3(i)(6)(iii).
[*60] a. Bloomberg’s APA Request
Respondent noted that, “[i]n its APA Request, [Bloomberg]
characterized the BPS as ‘an electronic information service that combines news, market data, analytics, email and order routing into a single interactive package.’” Respondent argued that because Bloomberg’s software was embedded in BPS, Bloomberg did not derive receipts from any distinct software product. We disagree.
Bloomberg’s APA request shows the high value that Bloomberg placed on its software. Bloomberg assigned most BPS profits to Technology IP, which Bloomberg defined as its “software intangible asset” and later described as “its single most valuable intangible asset without which the business would not exist.” Respondent later accepted most of the premises and methods in Bloomberg’s APA request, though respondent proposed assigning an even higher percentage of profits to Bloomberg’s Technology IP. 36 Though respondent raised Bloomberg’s APA request with respect to the qualification issue in these cases, the APA request favors Bloomberg’s position.
b. Massachusetts Sales Tax Returns
Respondent argued that Bloomberg’s Massachusetts sales tax returns are inconsistent with Bloomberg’s claim that it derived receipts from the provision of access to software. Massachusetts law in the years at issue imposed state sales tax on fees charged for the use of software on remote servers. See 830 Mass. Code Regs. 64H.1.3(3)(a), (14)(a) (2010). 830 CMR 64H.1.3(14)(a) (2010) provides, in part:
Generally, charges for the access or use of software on a remote server are subject to tax. However, where there is no charge for the use of the software and the object of the transaction is acquiring a good or service other than the use of the software, sales or use tax does not apply.
Bloomberg took the position that gross receipts from BPS and OMS subscription fees were exempt from Massachusetts sales tax. Accordingly, Bloomberg did not collect, report, or remit any sales tax to Massachusetts with respect to gross receipts from BPS and OMS
36 Because Bloomberg’s software was largely created within the United States,
respondent’s change led to a higher percentage of Bloomberg’s profits’ being subject to U.S. income tax. Increased profits subject to U.S. income tax represented another benefit that the country gained from Bloomberg’s domestic production of BPS software.
[*61] subscription fees during the years at issue. This comported with Bloomberg’s Massachusetts (and New York) state income tax returns for the years at issue, on which Bloomberg reported its principal product or services as information services.
Respondent argued that Bloomberg’s Massachusetts sales tax position makes it “clear that [Bloomberg] reported its gross receipts as being derived from information services and not from the provision of software . . . . This shows that even [Bloomberg] did not believe that any of its fees were derived from disposing of software but is merely taking an incorrect position herein to gain large section 199 deductions for its partners.”
Bloomberg argued that respondent failed to prove exactly why Bloomberg took the Massachusetts sales tax position that it did. However, Bloomberg made no serious attempt to explain its Massachusetts sales tax position. Instead, Bloomberg simply argued that its Massachusetts sales tax position is irrelevant. For example, Bloomberg pointed to our statement in Maines v. Commissioner, 144 T.C. 123, 132 (2015):
Our precedents establish that a particular label given to a legal relationship or transaction under state law is not necessarily controlling for federal tax purposes. Federal tax law looks instead to the substance (rather than the form) of the legal interests and relationships established by state law.
(Citation omitted.)
Bloomberg’s Massachusetts sales tax returns on their face appear to be inconsistent with Bloomberg’s federal returns on which it claimed sizable amounts of DPGR and section 199 deductions. Clearly, Bloomberg was in a better position to explain such inconsistencies, which it did not do. However, we decline to base our decision on Bloomberg’s Massachusetts state sales tax position. Though we have occasionally considered state sales tax return positions as relevant evidence, see Lambaiso v. Commissioner, T.C. Memo. 1999-343, 1999 Tax Ct. Memo LEXIS 396, at *8–9; Epic Metals Corp. & Subs v. Commissioner, T.C. Memo. 1984-322, 1984 Tax Ct. Memo. LEXIS 351, at *6, *18 (1984), aff’d, 770 F.2d 1069 (3d Cir. 1985) (unpublished table decision), no precedent obligates us to strictly follow such return positions. In these cases, the weight of the evidence shows that
[*62] Bloomberg derived gross receipts from providing customers access to BPS analytical and graphing software. To the extent Bloomberg’s Massachusetts sales tax returns are inconsistent with this, the evidence shows that they are incorrect.
c. Foreign Tax Withholding Letters
Respondent argued that Bloomberg’s letters to foreign customers regarding tax withholding obligations show Bloomberg considered BPS a financial information service. Respondent focused on Bloomberg’s letters to BPS customers in Singapore, which referenced “a waiver of withholding tax on end-user subscriptions to online financial information providers such as Bloomberg.” 37 These letters cited a speech from the Singapore Minister for Finance in support of the waiver. See Lee Hsien Loong, Deputy Prime Minister and Minister for Finance, Speech to the Parliament of Singapore: Budget Statement 2003: Seizing Opportunity in Uncertainty (Feb. 28, 2003) (transcript available at https://www.nas.gov.sg/archivesonline/data/pdfdoc/20030228_Budget .pdf). In the speech, the Minister for Finance addressed a “[w]ithholding [t]ax [e]xemption for [p]rovision of [i]nformation and [d]igitised [g]oods.” Id. For purposes of the Singapore withholding tax exemption, Singapore defined “information” as “(a) information comprised in any newspaper or magazine article or report, including financial and business data (such as foreign exchange, stock, and property data) and other proprietary data; and (b) information obtained solely for research purposes.” Income Tax (Exemption of Royalties and Other Payments for Economic and Technological Development) (No. 2) Notification 2003. Singapore defined “digitised goods” as “text, images, or sound that are transferred through any handphone, fixed-line phone, cable network, satellite, the Internet, or other form of electronic transmission, but does not include software.” Id.
Bloomberg’s response to respondent’s argument was short and weak:
Interpreted generously, this is just another label-based argument like those above, and the Court should reject it accordingly. Respondent cites no authority for any proposition related to its argument, whether as to the tax laws in the relevant jurisdiction, as to how to interpret the
37 Respondent did not allege that the foreign withholding letters were an
attempt by Bloomberg to whipsaw taxing authorities or otherwise reduce its overall tax obligations.
[*63] letters in light of the law, or even how those foreign laws relate in any respect to Section 199.
The second sentence is incorrect in that respondent did cite authority from Singapore that does not favor Bloomberg’s position. Bloomberg did not cite any foreign authority in favor of its position.
Like the Massachusetts sales tax returns discussed supra OPINION Part VII.B.6.b, the foreign withholding letters favor respondent’s position. However, the weight of the evidence still shows that Bloomberg derived receipts from providing access to BPS analytical and graphing software. To the extent the foreign withholding letters issued by Bloomberg are inconsistent with this, the evidence shows that they are incorrect.
d. Federal Returns
On Bloomberg’s federal returns for the years at issue, it reported its principal business activity as business services and its principal product or services as information services. Respondent argued that Bloomberg’s identification of its business and principal product as a service, rather than being related to software, undermines Bloomberg’s position in these cases. We disagree. The provision of access to software is a service under federal tax law. See Treas. Reg. § 1.199-3(i)(6)(ii). Though the provision of access to software may be treated as a disposition of software if Treasury Regulation § 1.199-3(i)(6)(iii) is satisfied, see discussion supra OPINION Part VI.C, that treatment is only for purposes of section 199. There is nothing inconsistent with Bloomberg’s identification of its business and principal product as a service and its claimed section 199 deductions.
e. McKinsey Survey and Customer Testimony
Respondent argued that the McKinsey Survey and BPS customer testimony showed that “[c]ustomers used the BPS for the provision of news, data, communications, charting, and to some extent, analytics.” We have already discussed customer testimony supra OPINION Part VII.B.1.c. Regarding the McKinsey Survey, we find that it does not favor respondent’s position. The McKinsey Survey generally showed that data, news, and analytical and graphing software were all important parts of BPS.
[*64] f. Data Center Connection Requirement
Like his argument about BPS users requiring “constant other services from” Bloomberg, addressed supra OPINION Part VII.B.1.c, respondent argued that
it is instructive to inquire whether the activities for which customers paid a fee in question could have been accomplished by software delivered offline (on a disk or by download). If there is no way to accomplish [an] activity without connectivity, it is a good indicator that customers received nonqualifying services and the transaction is not described in section 1.199-3(i)(6)(iii).
We reiterate that there is no requirement in Treasury Regulation § 1.199-3(i)(6)(iii) that a customer not receive any nonqualifying services in exchange for a fee paid in part for access to software. Indeed, Treasury Regulation § 1.199-3(i)(6)(v), Example 6, supports the opposite proposition and provides for an allocation of a fee between access to software and nonqualifying services. We disagree with respondent’s position.
g. Treasury Regulation § 1.199-3(d)(1), (i)(1)(i), and (i)(4)(i)(A)
Respondent argued that Bloomberg “attempt[ed] to shave away its services of providing non-software items . . . in order to attribute gross receipts to the software that enabled its financial information services.” In addition to rehashing some of his other arguments, respondent made arguments based on Treasury Regulation § 1.199- 3(d)(1), (i)(1)(i), and (i)(4)(i)(A). Respondent claimed that those regulations do not allow Bloomberg to “allocate a portion of the gross receipts attributable to its nonqualifying financial information services to the software that enabled those services.” Bloomberg made various counterarguments and stated that “[b]ecause Bloomberg provided the BPS’s direct-use BPS software together with non-qualifying components (i.e., data, news, and helpdesk support services) all for a single, nonitemized subscription fee, an allocation to DPGR and non-DPGR must be made.”
The parties’ arguments regarding Treasury Regulation § 1.199-
3(d)(1), (i)(1)(i), and (i)(4)(i)(A) were somewhat vague, and we will discuss and quote many of them at length in this OPINION Part VII.B.6.g.
[*65] i. Treasury Regulation § 1.199-3(i)(1)(i)
Treasury Regulation § 1.199-3(i)(1)(i) reads:
Definition. The term derived from the lease, rental, license, sale, exchange, or other disposition is defined as, and limited to, the gross receipts directly derived from the lease, rental, license, sale, exchange, or other disposition of QPP, a qualified film, or utilities, even if the taxpayer has already recognized gross receipts from a previous lease, rental, license, sale, exchange, or other disposition of the same QPP, qualified film, or utilities. Applicable Federal income tax principles apply to determine whether a transaction is, in substance, a lease, rental, license, sale, exchange, or other disposition, whether it is a service, or whether it is some combination thereof.
Respondent claimed that BPS software enabled Bloomberg’s financial information and communications services and that no portion of the BPS subscription fees can be allocated to BPS software pursuant to Treasury Regulation § 1.199-3(i)(1)(i). Respondent argued:
Certainly, taxpayers in the banking industry, internet auction industry, and telecommunications industry can hire paid experts to assign value to the portion of their gross receipts attributable to the software that enables their services (as [Bloomberg] did). Doing this, however, would be contrary to the rule in section 1.199- 3(i)(1)(i) that taxpayers must derive gross receipts directly from a disposition, and to how section 1.199-3(i)(6)(ii) and (iii) are intended to work as illustrated by [examples in Treasury Regulation § 1.199-3(i)(6)(v)]. If taxpayers do not directly derive their gross receipts from providing access to online software . . . they simply do not qualify for the narrow Exceptions and their gross receipts are non-DPGR for failure to satisfy the statutory disposition requirement.
Bloomberg disputes respondent’s position and notes that the last sentence of Treasury Regulation § 1.199-3(i)(1)(i) shows that transactions can comprise both qualifying and nonqualifying elements.
We disagree with respondent’s argument. First, as discussed supra OPINION Part VII.B.1.c, BPS analytical and graphing software did not merely enable Bloomberg’s financial information service.
[*66] Instead, that software allowed users to draw their own insights from financial information.
Second, respondent asserted that Bloomberg must “directly derive” gross receipts from the provision of access to software. However, Treasury Regulation § 1.199-3(i)(6)(iii) uses only the terms “derives” and “derived.” Similarly, Treasury Regulation § 1.199-3(i)(6)(i) uses only the term “derived,” rather than “directly derived.” Furthermore, Congress defined “domestic production gross receipts” as “the gross receipts of the taxpayer which are derived from . . . any lease, rental, license, sale, exchange, or other disposition of” QPP. § 199(c)(4)(A). The Commissioner then added “directly” into the definition of “derived from the lease, rental, license, sale, exchange, or other disposition” in Treasury Regulation § 1.199-3(i)(1)(i). Respondent now ascribes significant importance to that addition. Surely though, the word “directly” cannot be that important if Congress omitted it from section 199(c)(4)(A) and the Commissioner omitted it from Treasury Regulation § 1.199-3(i)(6), which provides specific rules for computer software. 38 We rule that Bloomberg derived gross receipts from the provision of access to the analytical and graphing software, as part of the BPS subscription fees.
We also agree with Bloomberg that the last sentence of Treasury Regulation § 1.199-3(i)(1)(i) favors Bloomberg’s position. That sentence and Treasury Regulation § 1.199-3(d)(1)(ii) and (i)(4)(i)(A) (discussed infra OPINION Part VII.B.6.g.ii and iii) all support the position that transactions can be split into qualifying and nonqualifying elements for purposes of section 199.
ii. Treasury Regulation § 1.199-3(d)(1)
Treasury Regulation § 1.199-3(d) is titled “[d]etermining domestic production gross receipts.” Treasury Regulation § 1.199-3(d)(1) reads:
In general. For purposes of §§ 1.199-1 through 1.199-9, a taxpayer determines, using any reasonable method that is satisfactory to the Secretary based on all of the facts and circumstances, whether gross receipts qualify as DPGR on an item-by-item basis (and not, for example, on a division-
38 To the extent one agrees with respondent that the word “directly” in
Treasury Regulation § 1.199-3(i)(1)(i) is of significant importance, we question whether that provision represents the best interpretation of section 199. See Loper Bright Enters., 144 S. Ct. at 2266 (stating that if a government agency’s interpretation of a statute “is not the best, it is not permissible”).
[*67] by-division, product line-by-product line, or transaction-bytransaction basis).
(i) The term item means the property offered by the taxpayer in the normal course of the taxpayer’s business for lease, rental, license, sale, exchange, or other disposition (for purposes of this paragraph (d), collectively referred to as disposition) to customers, if the gross receipts from the disposition of such property qualify as DPGR; or (ii) If paragraph (d)(1)(i) of this section does not apply to the property, then any component of the property described in paragraph (d)(1)(i) of this section is treated as the item, provided that the gross receipts from the disposition of the property described in paragraph (d)(1)(i) of this section that are attributable to such component qualify as DPGR. Each component that meets the requirements under this paragraph (d)(1)(ii) must be treated as a separate item and a component that meets the requirements under this paragraph (d)(1)(ii) may not be combined with a component that does not meet these requirements.
We will refer to Treasury Regulation § 1.199-3(d)(1)(i) as the Item Rule and Treasury Regulation § 1.199-3(d)(1)(ii) as the Shrink-Back Rule.
Respondent argued that
[a]s a threshold matter, the Item Rule and Shrink-Back Rule expressly apply only to “the property offered by the taxpayer in the normal course of the taxpayer’s business” for disposition. (Emphasis added.) By its express terms then, these rules do not apply to [Bloomberg’s] information services, which are not property. To illustrate this point, section 1.199-3(d)(4) sets forth twelve examples applying the Item Rule and the Shrink-Back Rule. All of these examples involve the taxpayers’ disposition of property . . . . None of these examples illustrates a provision of services as the “item” or a shrink-back of a taxpayer’s services to self-produced property enabling those services. Since [Bloomberg] offered services (not property) to customers in the normal course of its business, the unambiguous text of section 1.199-3(d)(1)(ii) does not
[*68] permit [Bloomberg] to shrink-back from its nonqualifying online information services to the property (software) that enabled those services.
We disagree with respondent’s claim that Bloomberg offered only “information services” to its customers. As discussed supra, portions of the BPS subscription fees were derived from the provision of access to BPS analytical and graphing software that did not enable a service.
Bloomberg argued that
DPGR is computed on the basis of the “item.” Treas.
Reg. § 1.199-3(d)(1). Section 199 generally defines an “item” as the property offered by the taxpayer in the normal course of its business if the gross receipts from the property’s disposition qualify as DPGR. Id. If the entire property does not qualify as giving rise to DPGR, “then any component of the property” that generates DPGR “is treated as the item.” Treas. Reg. § 1.199-3(d)(1)(ii). The facts establish that the BPS software . . . [is Bloomberg’s] “item” for purposes of Section 199.
The shrink back rule recognizes that some but not all of the gross receipts from a single transaction may be DPGR, and that a single transaction may be a combination of qualifying and non-qualifying elements. . . .
. . . [Bloomberg] claims DPGR only for the portion of BPS gross receipts attributable to the software that customers access and directly use while connected to the Internet or other network. Whether under the shrink back rule or under a carve-out of the non-qualifying elements from the provision of online software, the answer is the same: the BPS consists, in part, of access to and use of online software, and, in part, of non-qualifying news and data content, as well as non-qualifying helpdesk services. Since [Bloomberg’s] software meets the requirements of the Third-Party-Comparable Exception . . . an allocation to DPGR and non-DPGR is required.
We agree with Bloomberg’s argument that “[t]he shrink back rule recognizes that some but not all of the gross receipts from a single transaction may be DPGR.” Treasury Regulation § 1.199-3(i)(1)(i) and (i)(4)(i)(A) also support this position.
[*69] Neither party attempted to provide a step-by-step outline of how to apply the Item and Shrink-Back Rules with respect to computer software. However, respondent argued that
the Shrink-Back Rule in section 1.199-3(d)(1)(ii) expressly applies only if the gross receipts attributable to an alleged component qualify as DPGR. The Shrink-Back Rule does not provide the operative rules for determining if gross receipts attributable to the component are DPGR. Rather, the rule only provides a framework for identifying the property to determine if the gross receipts from such property qualify as DPGR, such that the component will qualify as an “item.” Other section 199 regulations provide the specific rules for determining whether gross receipts constitute DPGR depending on the nature of the property. . . . In this case, the controlling rules for software are found in section 1.199-3(i)(6).
Respondent’s argument lacks specifics, likely because Treasury Regulation § 1.199-3 is poorly written. The regulation does not specify whether one should apply Treasury Regulation § 1.199-3(d)(1) before or after Treasury Regulation § 1.199-3(i)(6). Treasury Regulation § 1.199- 3(d) is titled “[d]etermining domestic production gross receipts,” but application of the Item and Shrink-Back Rules requires one to first consider whether gross receipts attributable to an item or component “qualify as DPGR.” The rules to determine whether gross receipts from the provision of access to software qualify as DPGR are found in Treasury Regulation § 1.199-3(i)(6).
We need not engage in a lengthy “before or after” analysis in these cases because, as respondent notes, the specific rules governing computer software are found in Treasury Regulation § 1.199-3(i)(6). See Long Island Care at Home, Ltd. v. Coke, 551 U.S. 158, 170 (2007) (noting that specific regulations “normally” govern general ones); see also TBL Licensing LLC v. Commissioner, 158 T.C. 1, 55–56 (2022) (applying a specific regulation over a general one), aff’d, 82 F.4th 12 (1st Cir. 2023). Applying the rules in Treasury Regulation § 1.199-3(i)(6) (and the definition of “computer software” in Treasury Regulation § 1.199- 3(j)(3)(i)) shows that only BPS subscription fees attributable to BPS analytical and graphing software qualify as DPGR. Because gross receipts attributable to the analytical and graphing software qualify as
[*70] DPGR, that software is an item under Treasury Regulation § 1.199-3(d)(1)(ii). 39
iii. Treasury Regulation § 1.199-
3(i)(4)(i)(A)
Treasury Regulation § 1.199-3(i)(4) reads, in part:
Allocation of gross receipts. (i) Embedded services and non- qualified property. (A) In general. Except as otherwise provided in paragraph (i)(4)(i)(B), paragraph (m) (relating to construction), and paragraph (n) (relating to engineering and architectural services) of this section, gross receipts derived from the performance of services do not qualify as DPGR. In the case of an embedded service, that is, a service the price of which, in the normal course of the taxpayer’s business, is not separately stated from the amount charged for the lease, rental, license, sale, exchange, or other disposition of QPP, a qualified film, or utilities, DPGR include only the gross receipts derived from the lease, rental, license, sale, exchange, or other disposition of QPP, a qualified film, or utilities (assuming all the other requirements of this section are met) and not any receipts attributable to the embedded service. In addition, DPGR does not include the gross receipts derived from the lease, rental, license, sale, exchange, or other disposition of property that does not meet all of the requirements under this section (non-qualified property).
We will refer to Treasury Regulation § 1.199-3(i)(4)(i)(A) as the Embedded Services Rule.
Bloomberg argued that
in discussing the embedded services rule . . . the IRS and Treasury reiterated that “the statutory language and legislative history require that transactions be bifurcated into qualifying and nonqualifying elements and that gross
39 We need not decide whether the analytical and graphing software qualifies
as an item under Treasury Regulation § 1.199-3(d)(1)(i). The analytical and graphing software certainly qualifies as a component (and therefore an item) under Treasury Regulation § 1.199-3(d)(1)(ii), which leads to the same result in these cases as qualification under Treasury Regulation § 1.199-3(d)(1)(i).
[*71] receipts be allocated accordingly for purposes of Section 199.” [70 Fed. Reg. 67,220] at 67,226 (emphasis added). The Preamble further explained that “[t]he legislative history also does not support adopting principles applicable to other Code sections under which a single predominant nature character is assigned to a transaction . . . .” Id. (emphasis added). In short, . . . Section 199 and the Regulations thereunder require a separate analysis of the BPS software and data and news components . . . .
(Footnote omitted.)
Respondent argued that
[Bloomberg] erroneously applies the Embedded Services Rule in reverse. That is, [Bloomberg] attempts to (1) first isolate the software associated with the BPS that enables [Bloomberg’s] data, news, analytics, communications, and trading services, and (2) then point to [third-party] software . . . that [Bloomberg] alleges is substantially identical to its online software. As previously discussed at length, [Bloomberg’s] online information services are properly characterized as nonqualifying services for which there is no disposition under section 1.199-3(i)(6)(ii). Without a disposition of computer software, the Embedded Services Rule has no application.
We favor Bloomberg’s position that Treasury Regulation § 1.199-
3 generally provides for a separate analysis of services treated as a disposition of property (i.e., the provision of access to software that satisfies Treasury Regulation § 1.199-3(i)(6)(iii)) and other services that are part of the same transaction. While the Embedded Services Rule supports this result, our decision is primarily based on the specific computer software provisions in Treasury Regulation § 1.199-3(i)(6).
Bloomberg derived gross receipts from the provision of both access to BPS analytical and graphing software (treated as disposition of property as discussed supra OPINION Part VI.C) and services. Respondent incorrectly characterizes BPS gross receipts as entirely from “online information services” and cites Treasury Regulation § 1.199-3(i)(6)(ii), even though Treasury Regulation § 1.199-3(i)(6)(iii) applies “[n]otwithstanding” Treasury Regulation § 1.199-3(i)(6)(ii). Furthermore, how else could Bloomberg compare its software to
[*72] third-party software other than by first isolating software? Bloomberg need not use the Embedded Services Rule for such an isolation of software, as Treasury Regulation § 1.199-3(i)(6)(iii) plainly calls for the comparison of software to software (discussed infra OPINION Part VII.C).
Citing Treasury Regulation § 1.199-3(i)(6)(v), Example 6, respondent agreed that the Embedded Services Rule generally applies with respect to the provision of access to software that satisfies the threshold requirement and third-party comparable exception. We agree, and considering our rulings in this Opinion that BPS analytical and graphing software satisfied the threshold requirement and third-party comparable exceptions, we rule that the Embedded Services Rule applies in these cases. See 70 Fed. Reg. 67,220 at 67,226 (“The IRS and Treasury Department continue to believe that the statutory language and legislative history require that transactions be bifurcated into qualifying and nonqualifying elements and that gross receipts be allocated accordingly for purposes of section 199. The . . . exceptions to this general rule should be limited.”). As in Treasury Regulation § 1.199- 3(i)(6)(v), Example 6, after comparison of BPS analytical and graphing software to third-party software, the Embedded Services Rule calls for an allocation of gross receipts between the provision of access to BPS analytical and graphing software and Bloomberg’s services. The allocation of Bloomberg’s gross receipts between DPGR and non-DPGR will be addressed infra OPINION Part X.
C. The Third-Party Comparable Exception
Having ruled that BPS analytical and graphing software satisfies the threshold requirement, we turn to whether that software satisfies the third-party comparable exception. For the software to do so, a third party must derive, on a regular and ongoing basis in its business, gross receipts from the disposition to its customers of software (in a tangible medium or by download) that is substantially identical to BPS analytical and graphing software. See Treas. Reg. § 1.199-3(i)(6)(iii)(B). To be substantially identical to BPS analytical and graphing software, a third- party’s software must (1) from a customer’s perspective, have the same functional result and (2) have a significant overlap of features or purpose. See id. subdiv. (iv)(A).
Bloomberg claimed that BPS software satisfies the third-party comparable exception because of the 3000 Xtra and RMDS software
[*73] offered by Reuters. Respondent argued otherwise. 40 We will address each operative part of the third-party comparable exception.
1. Reuters Derived Gross Receipts from the Disposition of 3000 Xtra and RMDS Analytical and Graphing Software.
The third-party comparable exception requires that “[a]nother person derives, on a regular and ongoing basis in its business, gross receipts from the” disposition of software. Treas. Reg. § 1.199- 3(i)(6)(iii)(B). Respondent did not dispute that Reuters’s RMDS software meets this requirement. However, respondent argued that “Reuters derived its 3000 Xtra gross receipts from the provision of online financial information services, which do not constitute gross receipts from a disposition of software.” Opposing this argument, Bloomberg points to Reuters customer agreements that reflect customers paid for software, as well as “line items on customer invoices and order forms that . . . were for 3000 Xtra software.”
Respondent’s argument largely rehashed similar claims he made about BPS being a financial information service. We will not address these arguments again at length with respect to 3000 Xtra. In short, the facts show that Reuters derived gross receipts from the disposition of some 3000 Xtra software, specifically, software associated with analytical and graphing functions. Not only do Reuters customer agreements identify software as one of the items that customers paid for, but it was even possible for customers to lease some 3000 Xtra software without a Reuters information feed. We rule that Reuters derived gross receipts from the disposition of both 3000 Xtra and RMDS analytical and graphing software.
2. 3000 Xtra and RMDS Analytical and Graphing Software Was Provided by Disk or Download.
The third-party comparable exception requires that the third-
party provide software “to its customers pursuant to an activity described in paragraph (i)(6)(iii)(A)(3) of this section.” Treas. Reg. § 1.199-3(i)(6)(iii)(B). Treasury Regulation § 1.199-3(i)(6)(iii)(A)(3) provides that software be provided to “customers either affixed to a
40 The parties’ arguments regarding the third-party comparable exception
pertained to all BPS software in dispute in these cases, not just the analytical and graphing software.
[*74] tangible medium (for example, a disk or DVD) or by allowing them to download the computer software from the Internet.”
Respondent does not dispute that RMDS software meets this requirement. However, respondent argued that only 3000 Xtra desktop software was provided to customers by disk or download, and that 3000 Xtra relied on Reuters’s data center software to function. Echoing arguments that he made with respect to BPS, respondent further argued that 3000 Xtra was “dependent” on an information feed to function. Bloomberg argued that RMDS could substitute for the portions of 3000 Xtra software found in data centers and that “nothing in the Regulations requires that the third-party derive gross receipts from software independent of . . . related services.”
We agree with Bloomberg. For reasons discussed infra OPINION Part VII.C.3.a, we rule that Bloomberg may compare BPS software to a combination of RMDS and 3000 Xtra analytical and graphing software that was provided by disk or download. Furthermore, as we have previously ruled with respect to BPS, nothing in Treasury Regulation § 1.199-3(i)(6)(iii) provides that software cannot operate in conjunction with other services. See supra OPINION Part VII.B.1.c. Treasury Regulation § 1.199-3(i)(6)(iii)(B) requires only that one derive gross receipts from the disposition of software.
3. Reuters’s Analytical and Graphing Software Was Substantially Identical to BPS Analytical and Graphing Software.
The third-party comparable exception requires that third-party software be “substantially identical software (as described in paragraph (i)(6)(iv)(A) of this section) (as compared to the taxpayer’s online software).” Treasury Regulation § 1.199-3(i)(6)(iv)(A) reads, in part:
Substantially identical software. For purposes of paragraph (i)(6)(iii)(B) of this section, substantially identical software is computer software that—
(1) From a customer’s perspective, has the same functional result as the online software described in paragraph (i)(6)(iii) of this section; and (2) Has a significant overlap of features or purpose with the online software described in paragraph (i)(6)(iii) of this section.
[*75] The parties made two primary arguments on this issue: (1) whether Bloomberg may aggregate RMDS and portions of 3000 Xtra software for purposes of the comparison; and (2) if Bloomberg can aggregate RMDS and portions of 3000 Xtra software, whether such software is substantially identical to BPS software. We will address these arguments separately.
a. Aggregating RMDS and Portions of 3000 Xtra Software
Bloomberg argued that RMDS and the portions of 3000 Xtra that were available by disk or download should be aggregated for purposes of the third-party comparable exception. Bloomberg points to the facts that Reuters developed RMDS and 3000 Xtra to work together, many customers licensed and used RMDS and 3000 Xtra together (including all of Reuters’s largest customers) and the two products were so tightly integrated that Reuters’s customers “were often unaware that the RMDS software was fueling their 3000 Xtra workstations—just as BPS software users were often unaware of the database management software . . . that executed their requests.” Respondent argued that 3000 Xtra and RMDS may not be aggregated because “Reuters marketed and provided 3000 Xtra and RMDS as separate and distinct offerings, with different features, functions, and purpose.”
Both parties pointed to Treasury Regulation § 1.199-3 in support of their positions. Respondent stated that the Item Rule in Treasury Regulation § 1.199-3(d)(1) does “not permit such aggregation.” Respondent also argued that
[t]he Third-Party Comparable Exception requires a comparison between the taxpayer’s online software and an identifiable and self-contained piece of software offered by a third-party, like software provided by a vendor to its customers by disk or download. [Bloomberg’s] argument must fail because the Exception does not contemplate the combination of multiple pieces of third-party software so that the taxpayer may blend their different features, functions, and purpose and compare that aggregate against the taxpayer’s online software.
Bloomberg countered that
[n]othing in the Regulations expressly limits the number of modules that can comprise the third-party software, and it
[*76] would be inconsistent with the Exception’s animating purpose (i.e., to provide an objective test to distinguish between software and services based on whether similar functionality can be physically transferred to customers for their own use) to read in such a limit. The Exception asks simply whether “[a]nother person derives . . . gross receipts from the . . . disposition of substantially identical software”—it does not require “an identifiable and self- contained piece of software,” as Respondent alleges, or that the third party sell the software as a single “item” within the meaning of Treas. Reg. § 1.199-3(d)(1). . . .
The plain language of the Regulation makes sense in light of the business realities of the software industry. After all, most if not all complex software is modular and componentized, as all competent evidence at trial established.
(Citations omitted.)
Surprisingly, neither party cited the definition of “computer software” in Treasury Regulation § 1.199-3(j)(3)(i) in support. As discussed supra OPINION Part VII.B.2, the definition of “computer software” is expansive. Software is not limited to “any program or routine,” but may also include “any sequence of . . . code that is designed to cause a computer to perform a desired function or set of functions.” Treas. Reg. § 1.199-3(j)(3)(i). It is also notable that operating systems are specifically included in the definition, as they control an entire computer and can comprise multiple programs. See, e.g., Cyrix Corp. v. Intel Corp., 846 F. Supp. 522, 526 (E.D. Tex. 1994) (“An ‘operating system’ is a program or set of programs that provides the basic ‘services’ used by application programs that run on the . . . computer. The operating system . . . has specific functions associated with controlling the computer.”), aff’d, 42 F.3d 1411 (Fed. Cir. 1994) (unpublished table decision).
We rule that it is permissible for Bloomberg to aggregate RMDS and portions of 3000 Xtra software that were available by disk or download for purposes of the third-party comparable exception. We strongly weigh the fact that Reuters designed RMDS to work with and enhance 3000 Xtra desktop software components. Once RMDS was connected to an information feed, RMDS and 3000 Xtra desktop computer software would work together; RMDS collected, analyzed, and
[*77] distributed large volumes of data from one or more information feeds, which users could further manipulate, graph, perform calculations on, model, share, and otherwise act on using 3000 Xtra desktop software components. In this way, they acted as a single routine or sequence of code “designed to cause a computer to perform a desired function” and are, together, computer software as defined in Treasury Regulation § 1.199-3(j)(3)(i). Though RMDS and 3000 Xtra are different programs, nothing in the third-party comparable exception directs us to compare one program to another. See Treas. Reg. § 1.199-3(i)(6)(iii)(B). Rather, the exception directs us to compare a taxpayer’s “software” to third-party software. Id.
We do not mean to suggest that a taxpayer can pick and choose endless portions of third-party software from various programs and compare those portions to the taxpayer’s software. Our ruling is based on the specific facts of these cases, especially that Reuters designed RMDS to work with 3000 Xtra, the programs were highly integrated, and all of Reuters’s largest 3000 Xtra subscribers also licensed RMDS. These are not two random, disassociated programs; they are designed to, and do, work together to perform functions for users.
b. Substantially Identical Software
To be substantially identical to BPS analytical and graphing software for purposes of Treasury Regulation § 1.199-3(i)(6)(iii)(B), Reuters’s analytical and graphing software must (1) from a customer’s perspective, have the same functional result as BPS analytical and graphing software and (2) have a significant overlap of features or purpose with the BPS software. Treas. Reg. § 1.199-3(i)(6)(iv)(A).
Respondent argued that Reuters’s software satisfied neither prong, claiming in his opening brief that
Reuters offered RMDS as a “data management solution” that was downloaded on a customer’s servers that helped customers manage their market data. [Bloomberg] introduced no evidence that BPS software provided [Bloomberg’s] customers with similar control over data or data management functionality. In contrast, [Bloomberg], and not the BPS customers, managed and distributed large quantities of data over its network.
RMDS was an “open” application as it allowed customers to add additional data feeds that could be
[*78] viewed, displayed, and evaluated on 3000 Xtra Desktop Applications. In contrast, although the BPS allowed customers to input data into particular fields to run “what if” scenarios in certain analytics screens, it did not allow customers to independently upload a third-party’s data feed into BPS, like a Reuters data feed. In that sense, a Reuters customer received RMDS software that they could use as they saw fit, but [Bloomberg’s] customers could not do the same with the software associated with BPS.
(Citations of the record omitted.) Respondent leaned farther into this argument in his reply brief, arguing that
BPS’ analytics feature was integrated and wed to [Bloomberg’s] data. [Bloomberg’s] customers only received the limited ability to input specific data points into those particular fields shaded in amber in those limited analytics screens that had one or more amber fields. Any customer use of the BPS software was therefore within the closed confines of the BPS information service.
. . . BPS was a “closed box” because customers could only use [Bloomberg’s] financial data with the BPS, while 3000 Xtra was an “open box” because customers could integrate their own data and third-party data into the “3000 Xtra container.” [Bloomberg’s] expert . . . acknowledged that 3000 Xtra and RMDS were “‘open systems’ in the sense that users could use Reuters’ software to act on a variety of data sources (not just Reuters data) . . . .”
(Citations of the record omitted.)
Bloomberg focused more on outcomes for users and the competition between Bloomberg and Reuters products, arguing that both BPS and Reuters’s software
enabled customers to manage and distribute data around their organization and to outside parties (e.g., clients and counterparties). Additionally, both allowed users to create, transform, and store real-time and historical data, before calling it up on their individual workstation or sending it to other users. RMDS may have had some more enhanced capabilities—for example, greater flexibility in adding new
[*79] data streams—but that does not change the functional result, features, or purpose of RMDS and 3000 Xtra when used together—and neither Respondent nor its experts claim otherwise.
Ultimately, Respondent does not dispute, nor can it, that 3000 Xtra and the BPS are substantially identical. Its experts admit that both products provided “overlapping functions,” had the same “primary purpose,” and were each other’s main rivals. This direct comparability is possible only because the RMDS software fueled and enhanced 3000 Xtra so that Reuters could successfully compete with the BPS.
(Citations of the record omitted.)
Bloomberg has the better argument with respect to analytical and graphing software. First, Reuters’s analytical and graphing software has, from a customer’s perspective, the same functional result as BPS analytical and graphing software. See Treas. Reg. § 1.199- 3(i)(6)(iv)(A)(1). Both BPS and Reuters’s analytical and graphing software use an information feed and allow customers to manipulate, model, and otherwise analyze that information. Bloomberg and Reuters were direct competitors and fought to procure subscriptions/renewals from the same pool of potential users, because their software enabled customers to achieve the same functional results. Some institutions even subscribed to both BPS and 3000 Xtra 41 and let their employees use the product they preferred.
Second, Reuters’s analytical and graphing software has a significant overlap of features or purpose with BPS analytical and graphing software. See Treas. Reg. § 1.199-3(i)(6)(iv)(A)(2). Much for the same reasons as stated in the prior paragraph, BPS software and Reuters’s software have a significant overlap of purpose. Regarding features, Bloomberg and Reuters were competitors who worked to match or exceed new features introduced by the other to avoid losing market
41 As previously stated, the combination of 3000 Xtra desktop software and
RMDS (once an information feed was connected to RMDS) acted like the complete 3000 Xtra system. Unlike the complete 3000 Xtra system software though (which used software installed on Reuters’s servers), the 3000 Xtra desktop software plus RMDS combination was installed completely on a user’s hardware.
[*80] share. The facts strongly support Bloomberg’s position that there was a significant overlap of features.
Respondent’s claim that Reuters’s software was an “open system”
compatible with numerous information feeds, while BPS was a “closed system” compatible only with Bloomberg’s information feed, is accurate. That fact might be relevant if we were comparing all BPS software to all of Reuters’s software. However, we are comparing only BPS analytical and graphing software to Reuters’s analytical and graphing software. We are not comparing the software that caused Reuters’s software to be an open system and BPS to be a closed system.
BPS’s and Reuters’s analytical and graphing software acted upon information in the same ways and, from a customer’s perspective, returned the same functional results, satisfying Treasury Regulation § 1.199-3(i)(6)(iv)(A)(1). Such software also had a significant overlap of features and purpose, satisfying Treasury Regulation § 1.199- 3(i)(6)(iv)(A)(2) (which requires only “a significant overlap of features or purpose” (emphasis added)). We therefore rule that BPS analytical and graphing software is substantially identical to Reuters’s analytical and graphing software.
D. BPS Qualification Issue Conclusion
We hold that BPS analytical and graphing software satisfies the threshold requirement and the third-party comparable exception. Gross receipts attributable to BPS analytical and graphing software therefore qualify as DPGR. We will proceed to address whether Bloomberg’s OMS software satisfies the threshold requirement and the third-party comparable exception before addressing the allocation issue.
VIII. OMS Software Qualification Issue
A. Separate Item
The parties disagreed whether OMS software and qualifying BPS software are a single item pursuant to Treasury Regulation § 1.199- 3(d)(1). Respondent argued that OMS and BPS software must be evaluated separately because OMS was not required to use BPS, BPS customers who licensed OMS were charged a separate fee, and OMS customers signed an addendum to their BPS Subscription Agreements
[*81] and separate other agreements pertaining to OMS. 42 Respondent cited Treasury Regulation § 1.199-3(d)(2)(i), which reads, in part: “[I]n no event may a single item consist of two or more properties unless those properties are offered for disposition, in the normal course of the taxpayer’s business, as a single item (regardless of how the properties are packaged).”
Bloomberg argued that OMS and BPS software are one item because OMS was an “add-on” to BPS and that “Bloomberg offered the BPS both on a standalone basis and together with its OMS feature.” Bloomberg cited Treasury Regulation § 1.199-3(d)(4), Example 3, which reads:
R manufactures toy cars in the United States. R also purchases cars that were manufactured by unrelated persons. R offers the cars for sale to customers, in the normal course of R’s business, in sets of three, and requires no minimum quantity order. R sells the three-car sets to toy stores. A three-car set may contain some cars manufactured by R and some cars purchased by R. If the gross receipts derived from the sale of the three-car sets do not qualify as DPGR under this section, then, under paragraph (d)(1)(ii) of this section, R must treat a toy car in the three-car set as the item, provided the gross receipts derived from the sale of the toy car qualify as DPGR under this section.
We agree with respondent. BPS and OMS software are not offered for disposition by Bloomberg as a single item. Although a BPS subscription is required to use OMS, BPS and OMS subscriptions are offered separately. This is evidenced by the separate fees paid, and agreements signed, by OMS customers. The facts here are more analogous to Treasury Regulation § 1.199-3(d)(4), Example 4, which reads:
The facts are the same as Example 3 except that R offers the toy cars for sale individually to customers in the normal course of R’s business, rather than in sets of three. R’s customers resell the individual toy cars at three for $10. Frequently, this results in retail customers purchasing
42 Respondent did not argue that different versions of OMS should be treated
as separate items from each other.
[*82] three individual cars in one transaction. In determining R’s DPGR, under paragraph (d)(2)(i) of this section, each toy car is an item and R cannot treat three individual toy cars as one item, because the individual toy cars are not offered for sale in sets of three by R in the normal course of R’s business.
Similarly, OMS and BPS subscriptions are not offered as a set. The fact that a BPS subscription is required to use OMS does not change the fact that the subscriptions are offered separately. We rule that OMS and BPS software are separate items.
B. The Threshold Requirement
Respondent argued that OMS software does not satisfy “the Threshold Requirement because (1) [Bloomberg] did not directly derive its gross receipts from the provision of software associated with OMS, and (2) customers did not receive OMS software to use as they saw fit without the need for continuous other services from” Bloomberg. Respondent’s arguments echoed arguments he made with respect to BPS software that we have addressed at length supra. We will not rehash those arguments here. We rule that most OMS subscription fees satisfy the threshold requirement.
OMS customers mostly paid for the provision of access to OMS software. Unlike BPS, OMS mostly did not include the provision of data, news, and communication services. OMS customers mostly used OMS software to sort large numbers of transactions, check positions, ensure regulatory and other requirements were met, etc. In this way, OMS software is analogous to BPS analytical and graphing software, which helped customers to model and act on large amounts of data and news. Although OMS operated only in conjunction with BPS data, we again note that nothing in Treasury Regulation § 1.199-3 provides that gross receipts cannot be derived from the provision of software if that software operates in conjunction with other services.
Respondent argued that “[t]he functionality of [Bloomberg’s]
SSEOMS offering was also dependent upon [Bloomberg’s] ongoing connectivity services.” Respondent claimed that such “connectivity services were in the nature of internet access services and telecommunications services and thus cannot give rise to DPGR.” Bloomberg made no counterargument. Indeed, Bloomberg’s expert witness regarding the allocation issue agreed that Bloomberg’s total
[*83] OMS gross receipts were partially derived from the provision of services, regarding both the SSEOMS offering and other versions of OMS. The expert witness correctly did not count OMS gross receipts allocable to such services as DPGR. We will discuss that issue further infra OPINION Part X.E.1.
C. The Third-Party Comparable Exception
Bloomberg argued that OMS software satisfies the third-party comparable exception because Charles River derived gross receipts from the disposition of substantially identical software (Charles River IMS). Respondent argued that Charles River IMS is not substantially identical to OMS because Charles River IMS gave “customers the ability to incorporate their own data streams or data streams from third-party providers” while OMS was part of “a closed system [that] did not allow for incorporation of external data sets or feeds.” 43
We discussed a similar “open vs. closed system” argument supra OPINION Part VII.C.3.b when comparing BPS analytical and graphing software to Reuters’s software. We stated that because we were “not comparing the software that caused Reuters’s software to be an open system and BPS to be a closed system,” we did not need to substantively address the argument. However, the fact that OMS could not be used with any program other than BPS was a characteristic of OMS software. Meanwhile, Charles River IMS could be used with BPS or numerous other programs/information feeds. As a result, we must address the open vs. closed system argument with respect to OMS.
To be substantially identical, OMS and Charles River IMS software must (1) have the same functional result from a customer’s perspective and (2) have a significant overlap of features or purpose. See Treas. Reg. § 1.199-3(i)(6)(iv)(A). Neither party addressed whether the “open system” nature of Charles River IMS or the “closed system” nature of OMS pertains to the programs’ functional results or the programs’ features. However, respondent stated in his reply brief that, “[a]lthough [Bloomberg’s] OMS offerings and Charles River IMS may have had overlapping functionality, each had different strengths.” We take this as
43 Oddly, respondent made this argument in furtherance of his claim that OMS
software did not satisfy the threshold requirement. Respondent did not specifically address this argument with respect to the third-party comparable exception, though we will treat it as if he did. Respondent’s arguments regarding OMS were poorly organized, and he made almost no arguments regarding the OMS third-party comparable exception issue in his Opening and Reply Briefs.
[*84] an acknowledgement that the “open vs. closed system” issue pertains to software features rather than functional result. We agree with this position.
Treasury Regulation § 1.199-3(i)(6)(iv)(A)(2) does not require that two pieces of software have identical features; it requires only that they have “a significant overlap of features or purpose.” (Emphasis added.) OMS and Charles River IMS share a significant overlap of both features and purpose. These are competing programs used for the same purposes, by the same types of customers, in the same ways. Respondent made no specific arguments to the contrary. While OMS was a closed system and Charles River IMS was an open system, this was only one of the many features the programs offered. Although this feature was different between the two programs, we do not view it as so important to say that the programs lacked a significant overlap of features or purpose.
The evidence also shows that OMS and Charles River IMS software have the same functional result from a customer’s perspective. Again, these pieces of software are used for the same purposes, by the same types of customers, in the same ways. Respondent even acknowledges that OMS and Charles River IMS had “overlapping functionality.” Accordingly, we rule that OMS and Charles River IMS software are substantially identical and the third-party comparable exception is satisfied. See Treas. Reg. § 1.199-3(i)(6)(iv)(A).
IX. Allocation Issue: Expert Reports
Each party introduced an expert report pertaining to allocations of Bloomberg’s (1) gross receipts between DPGR and non-DPGR and (2) expenses between those allocable to DPGR and those allocable to non- DPGR. These reports included extremely lengthy and complex explanations and calculations. We will describe each expert’s conclusions and provide a comparatively brief summary of each expert’s work. Both experts had extensive experience in the field of transfer pricing and were well qualified to opine on the allocation issue presented in these cases. The parties also introduced rebuttal reports by the same expert witnesses. Some of the points raised in the rebuttal reports will be discussed infra OPINION Part X.
[*85] A. Respondent’s Expert: Dan Peters 44
Mr. Peters determined that Bloomberg had DPGR of $760 million for 2008, $704 million for 2009, and $747 million for 2010. Mr. Peters also determined that Bloomberg’s expenses allocable to DPGR were $444 million for 2008, $432 million for 2009, and $448 million for 2010. Mr. Peters determined that the total DPGR of $2.211 billion was 12% of total BPS (plus OMS) revenue for the years at issue. Mr. Peters also determined that the total expenses allocable to DPGR of $1.324 billion were 12% of total BPS (plus OMS) expenses for the years at issue. 45
Mr. Peters’s allocation method is similar to the method Bloomberg used when it computed DPGR and expenses allocable to DPGR for its 2010 return and in its Amended Petitions (with respect to 2008 and 2009). 46 We will begin by describing the allocation method that Bloomberg used for its 2010 return and in its Amended Petitions.
Bloomberg used the TPM described in its APA request, assigning revenue and expenses to its entities and branches worldwide. Bloomberg assigned premium and routine revenue “rewards” to larger “Hubs” and smaller “Satellites” partly on the basis of expenses they incurred. Bloomberg also assigned rewards for its Marketing IP and CR IP intangibles on the basis of contributions to those intangible assets. Finally, Bloomberg assigned residual profit rewards for its Technology IP, also on the basis of contributions to that intangible asset.
To determine DPGR and allocable expenses, Bloomberg adjusted its TPM to allocate some gross receipts and expenses to three BPS
44 In addition to the calculations in Mr. Peters’s report, respondent’s opening
brief includes 23 pages of appendixes with alternative/derivative calculations based on Mr. Peters’s work. Bloomberg filed a Motion to Strike the appendixes and respondent’s proposed findings of fact that reference the appendixes. We will issue a separate order denying Bloomberg’s Motion.
45 Mr. Peters used total BPS (plus OMS) gross receipts and expenses previously
determined by Bloomberg rather than calculating those amounts independently. Dr. Peter Meenan, Bloomberg’s expert witness, calculated total gross receipts and expenses independently. As a result, there are differences in the total gross receipts and expense amounts used by the experts. These differences will be discussed further infra OPINION Part X.D.
46 Dr. Meenan used a different allocation method and reached results different
from those that Bloomberg reached in its Amended Petitions and 2010 return. Bloomberg asserts that Dr. Meenan’s method and results are correct and does not argue that we should accept its earlier method or results.
[*86] components (data, news, and “Analytics” 47). Bloomberg allocated other gross receipts and/or expenses to four “functions” (operating, R&D, multimedia, and selling) that benefited BPS as a whole. Bloomberg then (re)allocated receipts and/or expenses from the four functions to data, news, and Analytics according to expenses and gross receipts attributable to those components. As part of these allocations, Bloomberg determined that all gross receipts from the Technology IP and CR IP rewards were allocable to Analytics, in addition to a portion of the gross receipts from the routine, hub premium, and Marketing IP rewards. 48
Bloomberg counted all gross receipts ultimately allocated to Analytics as DPGR. Any gross receipts not allocated to Analytics were allocated to either news or data and not counted as DPGR. Bloomberg’s allocation method resulted in DPGR of $3.887 billion for 2008, $3.804 billion for 2009, and $4.077 billion for 2010, as well as expenses allocable to DPGR of $1.990 billion for 2008, $2.016 billion for 2009, and $2.084 billion for 2010.
To complete his report, Mr. Peters altered numerous adjustments that Bloomberg made to its TPM. In doing this, Mr. Peters “relied upon guidance from Respondent’s Counsel as it relates to which activities potentially qualify as DPGR and which activities do not.” Pursuant to respondent’s guidance and/or using his own judgment, Mr. Peters (1) added a BPS communications component and excluded gross receipts allocable to it from DPGR; (2) added an OMS component and excluded gross receipts allocable to it from DPGR; (3) replaced the R&D function used by Bloomberg with an “Allocable R&D” function that was broader; (4) excluded gross receipts from CR IP rewards from DPGR; and (5) excluded from DPGR gross receipts allocable to BPS software that (in his opinion) facilitated the provision of news, data, and/or communications services by allocating such gross receipts to news, data, or communication functions rather than Analytics. For purposes of his
47 Bloomberg defined “Analytics” to be all section 199 qualifying software and
generally used the terms “Analytics” and “software” interchangeably.
48 The Marketing IP reward was initially allocated entirely to the multimedia
function, which was later allocated to the Analytics, data, and news components based on the percentage of revenue previously allocated to those components.
[*87] report, Mr. Peters accepted Bloomberg’s claim that gross receipts allocable to analytical (but not graphing) software were DPGR. 49
Mr. Peters allocated gross receipts among five components (data, news, Analytics, communications, and OMS) as well as four functions (Allocable R&D, operating, multimedia, and selling). He made unremarkable changes to the allocation of premium and routine revenue rewards from the method Bloomberg used. However, Mr. Peters significantly changed the allocation method used by Bloomberg for gross receipts assigned to Marketing IP and CR IP by allocating them on the basis of direct costs associated with four BPS components (data, news, Analytics, and communications) and the Allocable R&D function.
Mr. Peters also significantly changed the allocation method Bloomberg used for gross receipts assigned to Technology IP. Instead of allocating Technology IP entirely to Analytics, Mr. Peters used Bloomberg’s system for managing the allocation of R&D personnel to different projects (known as “HIER Nodes”) 50 to allocate Technology IP among four BPS components (data, news, Analytics, and communications) 51 and the Allocable R&D function. To do this, Mr. Peters assigned HIER Node projects to one of the four components or the Allocable R&D function. He then divided the number of employees that worked on each HIER Node project by the total number of
49 Mr. Peters stated that he “attempted to allocate the BPS’s gross receipts
allocable to Analytics between software which provides a monitoring function versus other more complex analytics that perform calculations.” (Footnote omitted.) He stated that he “was unable to do so because Bloomberg did not provide Respondent with sufficient records to perform this segmentation.” (Footnote omitted.) Mr. Peters believed that the DPGR he determined was “likely overstate[d]” as a result.
50 HIER Node data showed how many Bloomberg employees were assigned to
work on different software development projects.
51 Mr. Peters also assigned a portion of the Technology IP amounts to the OMS
component, but he used “the portion of the Technology IP revenues that can be directly attributed to OMS based on the actual fees paid by customers to Bloomberg for this []component. OMS revenues are sourced from general ledger accounts . . . .” Mr. Peters stated that for “2008, the directly attributable OMS revenues were approximately $84 million. Deducting this amount from the total Technology IP revenue of $1,184 million results in $1,104 million of allocable Technology IP revenues.” The math in the last quoted sentence is incorrect on its face. Furthermore, charts afterward show that Mr. Peters used 2008 OMS revenues of $65 million in his report. In the later charts, Mr. Peters subtracted $65 million from Technology IP of $1.184 billion and correctly determined the resulting allocable Technology IP revenues to be $1.119 billion, which he then allocated among the data, news, Analytics, and communications components and the Allocable R&D function. OMS gross receipts will be discussed further infra OPINION Part X.E.1.
[*88] employees that worked on all projects and added the resulting percentages in each component/function group together. The resulting group percentages for 2008 were 4% for news, 21% for data, 20% for Analytics, 4% for communications, and 51% for Allocable R&D. Mr. Peters then multiplied these 2008 percentages by gross receipts assigned to Technology IP (minus OMS revenues, discussed supra note 51) for each year at issue. 52 The result was allocated to the corresponding component or function.
After allocating gross receipts among the components and functions, Mr. Peters reallocated gross receipts from the four functions to the data, news, communications, and Analytics components (but not OMS) only on the basis of direct expenses that he determined were attributable to those components. Mr. Peters separately allocated indirect expenses to all five BPS components (data, news, communications, OMS, and Analytics) “based on the revenues [previously] attributed to each of those []components.” Finally, Mr. Peters returned to the gross receipts allocation and subtracted gross receipts attributable to CR IP from the data, news, communications, and Analytics components. 53
Mr. Peters counted as DPGR only the resulting gross receipts allocated to the Analytics component. He did not count any gross receipts allocated to the data, news, communications, and OMS components as DPGR. Mr. Peters’s alterations to Bloomberg’s calculation method resulted in substantially lower DPGR and allocable expenses than those determined by Bloomberg. Mr. Peters determined that over 80% of BPS plus OMS revenue was attributable to the data and news components (combined) for each year at issue.
After stating his results, Mr. Peters discussed two items that he believed showed his results “were more consistent with how the BPS income should be allocated between Analytics and the other BPS []components.” The first of these two items was the McKinsey Survey, which Mr. Peters believed showed that the “most highly used and highly
52 Mr. Peters used 2008 HIER Node data for each year at issue because of
changes to how Bloomberg recorded 2009 and 2010 HIER Node data. Mr. Peters’ method tracked the method that Bloomberg used for its 2010 return and in its Amended Petitions (with respect to 2008 and 2009).
53 No gross receipts attributable to CR IP were originally allocated to OMS, so
there was nothing to subtract from OMS for this step.
[*89] valued BPS []components are the News, Data and the Communications functions.”
The second item was a 2008 report completed by Houlihan Lokey Howard & Zukin Financial Advisors, Inc. (Houlihan), pertaining to an acquisition of 20% of Bloomberg, L.P., by Bloomberg, Inc., from Merrill Lynch (Houlihan report). The Houlihan report set forth Houlihan’s determined “fair value of certain identifiable intangible assets,” which included “customer relationships, trade name, technology, content and a favorable lease.” Mr. Peters described the technology and content assets as “[t]he two intangible assets that . . . relate to the Technology IP as identified in Bloomberg’s Global TPM and 199 determination.” Houlihan valued the technology and content assets “based on the relief from royalty method under the income approach, which requires [a] valuation specialist to estimate a reasonable royalty rate,” identify relevant projected revenues (and expenses, in the case of the content asset), “and select an appropriate discount rate.”
To value the technology asset, Houlihan divided the asset between Bloomberg’s network architecture, which “enable[d] terminal users to instantly access [Bloomberg’s] servers, an essential feature in trading platforms which is not provided through a traditional internet based system,” and Bloomberg’s “Analytical (code based) servers.” Houlihan described the later item as “the analytic functionality provided by [Bloomberg] . . . inputted and stored on its servers allowing programmers to continually provide up-to-date coding. This is of particular importance to [Bloomberg] as financial products are rapidly evolving and users demand the most current capabilities.” Houlihan “estimate[d] that 70% of the revenues associated with the Technology [asset] relate to the code based functionality while the remaining 30% relates to the network architecture.” Houlihan assigned a 10% royalty rate to the technology asset and multiplied it by Bloomberg’s projected revenues as part of its valuation calculation. 54
Houlihan similarly assigned a 10% royalty rate to the content asset. Houlihan described content as “data for all global capital markets including, security reference information, corporate action announcements, company financials, daily/historical pricing and general business news.” Houlihan divided the content asset between
54 For both the technology and content assets, Houlihan decreased the
projected revenues over time by percentages based on the useful lives of the assets. These adjustments are not relevant.
[*90] current information and historical information. Houlihan estimated “that 60% of the daily functions utilized by customers relate to current information (i.e. real-time exchange based data and news) and 40% to historical information (i.e. that which existed as of the Valuation Date).” Because 60% of the content (current information) was quickly obsolete, Houlihan multiplied the 10% content asset royalty rate by 40% of Bloomberg’s projected revenues (rather than 100% as it did with the technology asset) as part of its valuation calculation.
Mr. Peters stated that “[t]he combined [technology plus content]
20% royalty rate determined by Houlihan Lokey is generally consistent with the implied royalty calculated via Bloomberg’s Global TPM and Section 199 calculation and corroborates my analysis.” Mr. Peters further stated that his “Implied Royalty Rate[] for Technology IP, 2008 to 2010,” was 19%. Breaking things down to focus on the BPS Analytics component, Mr. Peters stated that Houlihan’s “analysis implies that a maximum of 70% of the 10% royalty attributed to the Technology IP could be considered related to the functionality of the Analytics []component. . . . The Analytics []component thus constitutes a maximum of 35% of the Technology IP asset.” Mr. Peters further stated that he “determined that the percentage of Bloomberg’s Technology IP that relates to the Analytics []component of the BPS is approximately 25%. This result is largely consistent with the results of the [Houlihan] valuation analysis.” (Footnote omitted.)
B. Bloomberg’s Expert: Dr. Meenan
Dr. Meenan determined that Bloomberg had DPGR of $3.196 billion for 2008, $3.319 billion for 2009, and $3.505 billion for 2010. Dr. Meenan also determined that Bloomberg’s expenses allocable to DPGR were $1.460 billion for 2008, $1.567 billion for 2009, and $1.558 billion for 2010. Dr. Meenan determined that the total DPGR of $10.020 billion was 61% of total BPS revenue (plus only “Qualified OMS gross receipts” 55) for the years at issue. Dr. Meenan also determined that the
55 Dr. Meenan determined that some OMS gross receipts were attributable to
services or should otherwise be subtracted from total OMS gross receipts to reach OMS receipts that were DPGR. He determined that “[q]ualified OMS gross receipts” attributable to software were DPGR and were $62 million for 2008, $94 million for 2009, and $106 million for 2010. This is discussed further infra OPINION Part X.E.1.
[*91] total expenses allocable to DPGR of $4.586 billion was 50% of total BPS (plus OMS 56) expenses for the years at issue.
Dr. Meenan’s method for calculating Bloomberg’s DPGR and allocable expenses differed from the method used by Bloomberg for its 2010 return and its Amended Petitions (with respect to 2008 and 2009). Dr. Meenan described his
method for allocating BPS receipts to non-DPGR and DPGR . . . as follows: (1) isolate BPS receipts from other [Bloomberg] receipts; (2) identify BPS costs; (3) calculate direct and indirect costs of each BPS component; (4) apply appropriate profit margins determined under the [comparable profits method (CPM)] . . . to the costs of each non-qualifying BPS component to calculate total BPS non- DPGR; and (5) treat the remaining BPS receipts as software-related DPGR.
We will briefly discuss each of these steps.
First, Dr. Meenan sought to isolate “[q]ualified OMS gross receipts” attributable to software and all BPS gross receipts from other Bloomberg gross receipts. In completing this (and many other parts of his report) Dr. Meenan largely relied on summaries of Bloomberg’s general ledger accounts for the years at issue presented in what Bloomberg refers to as the “Railroad income statement” (Railroad). 57 Bloomberg has relied on the Railroad for decades, including to prepare various tax returns, and for transfer pricing purposes, including APA requests. After making adjustments to some amounts shown in the Railroad for each year at issue, Dr. Meenan determined that (1) total Bloomberg gross receipts for all products were $6.068 billion for 2008, $6.264 billion for 2009, and $6.868 billion for 2010; (2) BPS gross receipts were $5.130 billion for 2008, $5.300 billion for 2009 and $5.663 billion for 2010; and (3) “[q]ualified OMS gross receipts” attributable to software were $62 million for 2008, $94 million for 2009, and $106 million for 2010. Adding the qualified OMS gross receipts and the BPS gross receipts resulted in total BPS plus OMS gross receipts of
56 Unlike with OMS gross receipts, Dr. Meenan did not attempt to separate out
OMS expenses attributable to nonqualified OMS gross receipts. See supra note 55. Instead, Dr. Meenan treated all OMS expenses as allocable to DPGR. This is discussed further infra OPINION Part X.E.2.
57 Dr. Meenan also relied on HIER Node data and other Bloomberg financial
documents in preparing his report.
[*92] $5.192 billion for 2008, $5.395 billion for 2009, and $5.769 billion for 2010.
Second, Dr. Meenan sought to isolate BPS expenses 58 by subtracting expenses of three non-BPS products from Bloomberg’s total expenses. 59 Using primarily HIER Node data, Dr. Meenan allocated “R&D expenses . . . between BPS and non-BPS products.” He divided R&D expenses between “Product R&D” pertaining to specific products and “Internal R&D” that supported Bloomberg’s business generally. Dr. Meenan did this to exclude “Product R&D expenses related to . . . products that are not part of the BPS.”
Dr. Meenan determined non-BPS product expenses in several ways, which we will very briefly summarize. For one product with clearly delineated direct expenses, Dr. Meenan was able to simply add direct expenses to Product R&D expenses he allocated to the product. For a product named “Multimedia,” Dr. Meenan used the Railroad and conducted a CPM to determine expenses. Because Multimedia expenses exceeded gross receipts, Dr. Meenan reallocated “Excess Multimedia Expenses” among BPS components (discussed infra in this OPINION Part IX.B) in accordance with his opinion that such expenses served an advertising function for BPS. To determine expenses for a non-BPS data product called Enterprise Data Solutions (EDS), Dr. Meenan aggregated EDS costs with BPS data costs to perform “a CPM analysis of all [Bloomberg] data products together,” then worked backward from revenue allocated only to EDS to estimate EDS product expenses. Adjusting Bloomberg’s total expenses to account for the non-BPS product expenses, Dr. Meenan determined that expenses allocable to BPS were $2.647 billion for 2008, $2.807 billion for 2009, and $3.209 billion for 2010. 60
58 Dr. Meenan did not differentiate OMS as separate from BPS in most of his
report. Unless otherwise specified, references to BPS expenses in the remainder of this OPINION Part IX.B include all OMS expenses.
59 Dr. Meenan also assigned a small amount of gross receipts and expenses to
a miscellaneous category. He excluded the gross receipts in this category from DPGR, but still counted the expenses as BPS-related to be conservative. We will not discuss this de minimis category further.
60 The parties agree that, on one page of his report, Dr. Meenan erroneously
listed “expenses that remain allocable to the BPS” of $2.847 billion for 2008, $2.958 billion for 2009, and $3.421 billion for 2010. These amounts do not equal the sum of the expenses allocated to individual BPS components in other portions of his analysis. The parties agree that Dr. Meenan should have listed “expenses that remain allocable
[*93] Third, Dr. Meenan allocated BPS expenses among four BPS components that he determined BPS subscribers received for their subscription fees. These components were (1) software (that enabled customers to manage, access, and analyze financial market news and data), (2) news (the coverage that Bloomberg News provides to subscribers through the BPS, but not the software that enables them to access/search for it), (3) data (the data that BPS subscribers receive, but not the software that enables them to access or manipulate it), and (4) helpdesk support services.
Dr. Meenan primarily used the Railroad to allocate direct expenses to the news, data, and helpdesk components. He allocated indirect expenses (“Internal R&D Expenses, Excess Multimedia Costs, Selling Expenses, and Mixed Expenses”) pro rata on the basis of direct expenses. Dr. Meenan also addressed certain “wrinkles” in his lengthy analysis, which we need not describe. Dr. Meenan determined that total expenses allocable to (1) helpdesk were $299 million for 2008, $281 million for 2009, and $303 million for 2010; (2) news were $904 million for 2008, $868 million for 2009, and $960 million for 2010; and (3) data were $589 million for 2008, $712 million for 2009, and $766 million for 2010. Using HIER Node data and other information, Dr. Meenan separately determined that total expenses allocable to the software component were $855 million for 2008, $945 million for 2009, and $1.180 billion for 2010.
Fourth, Dr. Meenan allocated gross receipts to the news, data, and helpdesk components. Using the CPM, he determined a profit margin for each of these components, then used that profit margin and previously allocated expenses to calculate gross receipts attributable to the component. The determined profit margins were 5% for helpdesk, 13% for news, and 13% for data. The determined gross receipts for (1) helpdesk were $314 million for 2008, $296 million for 2009, and $319 million for 2010; (2) news were $1.019 billion for 2008, $978 million for 2009, and $1.082 billion for 2010; and (3) data were $663 million for 2008, $802 million for 2009, and $863 million for 2010.
Fifth, Dr. Meenan subtracted gross receipts allocable to the news, data, and helpdesk components from total BPS plus OMS gross receipts.
to the BPS” of $2.647 billion for 2008, $2.807 billion for 2009, and $3.209 billion for 2010. We agree with the parties. Considering the limited nature of Dr. Meenan’s error, we find that it does not adversely affect the credibility of his other calculations. We note that Mr. Peters made at least one minor error himself, which we also find did not affect the credibility of his other calculations. See supra note 51.
[*94] The resulting amounts were $3.196 billion for 2008, $3.319 billion for 2009, and $3.505 billion for 2010. Dr. Meenan allocated these “residual receipts” to the software component, and they make up his determined DPGR amounts.
After determining Bloomberg’s DPGR, Dr. Meenan turned to expenses allocable to DPGR. This was not as simple as using previously determined expenses allocable to the software component. Dr. Meenan (1) allocated Product R&D expenses pursuant to rules in Treasury Regulation § 1.861-17; (2) assigned direct expenses in the same manner as he did in his DPGR calculations; and (3) allocated indirect expenses (which included Internal R&D), interest expenses, and other items between DPGR and non-DPGR on the basis of relative gross income assigned to the four BPS components. Dr. Meenan determined that expenses allocable to DPGR were $1.460 billion for 2008, $1.567 billion for 2009, and $1.558 billion for 2010.
X. Allocation Issue: Analysis and Conclusions
A. Jurisdiction Regarding Expenses Allocable to DPGR
QPAI is DPGR less cost of goods sold and “other expenses, losses, or deductions . . . properly allocable to” DPGR. § 199(c)(1). Although QPAI is a partner-level determination, we have jurisdiction to determine Bloomberg’s expenses, losses, and deductions (collectively, expenses) allocable to DPGR in this partnership-level proceeding. See § 199(d)(1)(A); Treas. Reg. § 1.199-5(b). No costs of goods sold are at issue in these cases.
B. Reasonableness of Bloomberg’s Allocation Method
Treasury Regulation § 1.199-3(d)(1) provides that “[f]or purposes of §§ 1.199-1 through 1.199-9, a taxpayer determines, using any reasonable method that is satisfactory to the Secretary under all of the facts and circumstances, whether gross receipts qualify as DPGR on an item-by-item basis.” Treasury Regulation § 1.199-1(d)(2) reads, in part:
Factors taken into consideration in determining whether the taxpayer’s method of allocating gross receipts between DPGR and non-DPGR is reasonable include whether the taxpayer uses the most accurate information available; the relationship between the gross receipts and the method used; the accuracy of the method chosen as compared with other possible methods; whether the method is used by the
[*95] taxpayer for internal management or other business purposes; whether the method is used for other Federal or state income tax purposes; the time, burden, and cost of using alternative methods; and whether the taxpayer applies the method consistently from year to year.
Bloomberg argued that “under Section 199, if a taxpayer establishes that its method of allocating gross receipts between DPGR and non- DPGR is reasonable and accurate under the circumstances, it has carried its burden of proof, and need not show that its method is the best one or even that it is better than the proposed alternative.” Bloomberg further argued that its allocation method was reasonable. We disagree.
Bloomberg has, at various times, used or argued in support of three different allocation methods. The first method was used for Bloomberg’s 2008 and 2009 returns, the second was used for Bloomberg’s 2010 return and its Amended Petitions (with respect to 2008 and 2009), and the third is reflected in Dr. Meenan’s report, which Bloomberg now argues is correct. Bloomberg has abandoned the two methods that were used to complete its federal returns for the years at issue. None of the three models has been especially accurate; they have all allocated too many (often far too many) gross receipts to the provision of software, rather than the provision of services, as discussed throughout this Opinion. In addition, it appears that Bloomberg used a different method of determining gross receipts allocable to services on state returns. Considering these facts and the Treasury Regulation § 1.199-1(d)(2) factors, we rule that Bloomberg’s allocation method is not reasonable.
C. Discussion of Expert Reports
While the expert reports of both Dr. Meenan and Mr. Peters were helpful, we do not adopt either expert’s DPGR or allocable expense determinations in full.
Dr. Meenan’s analysis suffered largely from the legal assumptions that he made. Specifically, Dr. Meenan assumed that almost all BPS software generated gross receipts that qualify as DPGR, but we have ruled that only gross receipts derived from the provision of access to BPS analytical and graphing software qualify as DPGR. See supra OPINION Part VII. Dr. Meenan thus significantly overstated both DPGR and expenses allocable to DPGR in his report. Because of the methodology Dr. Meenan used, we are unable to isolate gross
[*96] receipts and expenses that he attributed to BPS analytical and graphing software.
Mr. Peters assumed that only BPS receipts attributable to analytical software qualified as DPGR. While Mr. Peters’s results were more accurate than Dr. Meenan’s, Mr. Peters understated DPGR and allocable expenses in his report, for reasons discussed in the remainder of this OPINION Part X.C.
First, Mr. Peters incorrectly omitted all OMS gross receipts and expenses from DPGR and allocable expenses, respectively. We will discuss OMS gross receipts and expenses further infra OPINION Part X.E.
Second, Mr. Peters’s use of HIER Node data was lacking in certain respects. We disagree with Mr. Peters’s use of 2008 HIER Node data for all three years at issue; at trial he agreed with Bloomberg’s counsel that it would have been “better to use 2009 data for 2009” and “2010 data for 2010.” We recognize that Mr. Peters choose not to do so because (1) of changes to how Bloomberg recorded 2009 and 2010 HIER Node data, and (2) he was tracking the method that Bloomberg used for its 2010 return and in its Amended Petitions (with respect to 2008 and 2009). However, we believe that some attempt to adjust for yearly changes was called for. Mr. Peters also misassigned hours attributable to work on (1) charting applications to Allocable R&D rather than Analytics; and (2) several applications such as Bloomberg Law to data, when those hours should have been excluded because the applications they were attributable to were not part of BPS. The misassigned hours accounted for about 7% of HIER Node hours for 2008, which skewed Mr. Peters’s determinations in respondent’s favor.
Third, Mr. Peters’s methodology’s resulting in questionable profit margins for BPS components calls the methodology into question because it suggests that his assignment of gross receipts and expenses was not correct. For 2008 Mr. Peters determined (remarkably similar) profit margins for BPS components of 42% for data, 41% for news, 46% for Analytics, and 46% for communications. Mr. Peters determined similar profit margins for 2009 and 2010. In his rebuttal report, Dr. Meenan criticized Mr. Peters’s heavy reliance on direct costs in allocating gross receipts, alleging that “the exercise here is not measuring [Bloomberg’s] efforts related to each BPS []component, but rather assigning the fair market value of each []component.” While we need not delve into Dr. Meenan’s claims regarding component fair
[*97] market values, we generally agree that Mr. Peters’s profit margins call his ultimate determinations into question. Dr. Meenan’s report, the United Kingdom APA (and respondent’s draft RNP), and testimony at trial all indicate that Mr. Peters’s profit margins were questionable. For example, Mr. Peters was asked at trial: “Nobody was getting a 41 percent return in the news business in 2008, were they?” He responded, “No pure news business, that I know of, was returning that level.” Mr. Peters’s report would have been stronger had he further analyzed the profit margins he determined for the data, news, Analytics, and communications BPS components and adjusted gross receipts and expenses as called for. In particular, we believe that the fact that the profit margin Mr. Peters determined for the news component was too high lowered the profit margins for other components (including Analytics).
Fourth, we disagree with Mr. Peters’s view that the McKinsey Survey and the Houlihan report support his conclusions. The McKinsey Survey generally showed that data, news, and analytical/graphing software were all important parts of BPS. Mr. Peters’s use of the survey results to support his determination that over 80% of BPS plus OMS revenue was attributable to the data and news components (combined) was a stretch.
Regarding the Houlihan report, Mr. Peters did not adequately explain or account for the fact that Houlihan assigned 60% of the content asset to “current information (i.e. real-time exchange based data and news) and 40% to historical information.” Because 60% of the content (current information) was quickly obsolete, Houlihan multiplied the 10% content asset royalty rate by 40% of Bloomberg’s projected revenues (rather than 100% as it did with the technology asset). Yet Mr. Peters added all 10% of the content asset royalty rate to the 10% technology asset royalty rate, concluding that Houlihan determined a “combined 20% royalty rate” for Technology IP. Mr. Peters then used this 20% combined rate to determine that “[t]he Analytics []component . . . constitutes a maximum of 35% of the Technology IP asset.” 61 It appears that Mr. Peters should have removed the 6% of the combined royalty
61 As discussed supra OPINION Part IX.A, Mr. Peters determined that a
maximum of 70% of the 10% technology asset royalty was related to Analytics because Houlihan assigned 30% of the technology asset revenue to Bloomberg’s network architecture. Mr. Peters thus determined that, at most, 7/20 (35%) of the combined royalty rate was attributable to Analytics.
[*98] rate attributable to current information. 62 If so, the Houlihan report supports the proposition that Analytics constitutes a maximum of 50% (7/14) of the Technology IP asset. This is significantly larger than the “approximately 25%” that Mr. Peters determined.
D. Total BPS Plus OMS Gross Receipts and Expenses
Mr. Peters and Dr. Meenan disagreed on the amounts of Bloomberg’s gross receipts and expenses attributable to BPS plus OMS. Mr. Peters used total revenue and expense amounts previously determined by Bloomberg, while Dr. Meenan independently calculated gross receipts and expenses.
Mr. Peters used BPS plus OMS gross receipts of $5.627 billion for 2008, $5.838 billion for 2009, and $6.353 billion for 2010. Dr. Meenan calculated that BPS plus qualified OMS gross receipts were only $5.192 billion for 2008, $5.395 billion for 2009, and $5.769 billion for 2010. The difference between these totals is attributable mostly to the fact that Mr. Peters included gross receipts attributable to EDS, while Dr. Meenan excluded such receipts. As stated by Dr. Meenan, EDS gross receipts were $411 million for 2008, $523 million for 2009, and $580 million for 2010.
Respondent and Mr. Peters both acknowledged that EDS is a separate product from BPS. In his Reply Brief, respondent described EDS as a “non-qualifying [Bloomberg] offering.” Mr. Peters correctly stated that “Bloomberg incorrectly included the revenues associated with the [EDS] offering as allocable within its Section 199 Method.” However, Mr. Peters stated that he “did not have enough information to allocate expenses associated with the [EDS] offering, and thus, did not separately compute the revenue and income related to [EDS].” Mr. Peters then listed “approximate[]” EDS gross receipts for each year at issue. 63
Mr. Peters included hundreds of millions of dollars of EDS gross receipts in his BPS plus OMS gross receipts for each year at issue, even though he knew doing so was incorrect. We find that the BPS plus OMS
62 At the very least, Mr. Peters should have thoroughly explained why he
choose to leave the 6% in his calculations.
63 Mr. Peters’s “approximate[]” EDS gross receipts were somewhat lower than
EDS gross receipts stated by Dr. Meenan. We believe Dr. Meenan’s figures are more reliable.
[*99] gross receipts calculated by Dr. Meenan are more reliable and adopt them for each year at issue.
Mr. Peters used BPS plus OMS expenses of $3.379 billion for 2008, $3.610 billion for 2009, and $3.950 billion for 2010. Dr. Meenan calculated that BPS plus OMS expenses were only $2.647 billion for 2008, $2.807 billion for 2009, and $3.209 billion for 2010. Most of the difference is explained by the fact that Mr. Peters included expenses attributable to EDS, while Dr. Meenan excluded them. As calculated by Dr. Meenan, EDS expenses were $364 million for 2008, $464 million for 2009, and $515 million for 2010. As with total BPS plus OMS gross receipts, we find that Dr. Meenan’s calculations are more reliable than the amounts used by Mr. Peters. We adopt Dr. Meenan’s calculated BPS plus OMS total expenses for each year at issue.
E. OMS Gross Receipts and Expenses
1. OMS Gross Receipts That Qualify as DPGR
The parties stipulated that Bloomberg’s total OMS gross receipts were $84 million for 2008, $100 million for 2009, and $133 million for 2010.
In his attempt to determine OMS gross receipts that qualify as DPGR, Dr. Meenan started with total OMS gross receipts stipulated by the parties. He noted that “[f]or 2008, the OMS revenue details were limited to the period after April 1, 2008. In an abundance of caution, I therefore excluded all first quarter OMS gross receipts from DPGR.” He also determined that some “OMS products . . . include non-QPP services,” and used financial documents to subtract OMS gross receipts that were (or may have been) attributable to services. He concluded that the remaining OMS gross receipts of $62 million for 2008, $94 million for 2009, and $106 million for 2010 qualified as DPGR.
In his report, Mr. Peters determined that total OMS gross receipts were $65 million for 2008, $100 million for 2009, and $133 million for 2010. The 2009 and 2010 amounts are in accordance with the parties’ stipulation. Like Dr. Meenan, Mr. Peters excluded OMS gross receipts from the first quarter of 2008, resulting in a lower 2008 amount than the parties stipulated. Unlike Dr. Meenan, Mr. Peters did not attempt to allocate any specific portion of OMS gross receipts to services. Pursuant to respondent’s counsel’s instructions, Mr. Peters treated all OMS gross receipts as if they did not qualify as DPGR.
[*100] In his briefs, respondent argued that some OMS gross receipts are attributable to SSEOMS services such as providing connectivity to numerous exchanges, dark pools, other trading venues, and broker algorithms. Respondent then made no effort to specify which gross receipts are attributable to such services. Similarly, Mr. Peters determined only total OMS gross receipts and made no effort to distinguish between different types of OMS gross receipts (i.e., those attributable to services and those attributable to the provision of access to software). We recognize that respondent’s primary argument was that no OMS gross receipts qualify as DPGR. However, given his alternative argument about SSEOMS, respondent should have provided alternative calculations.
Unlike respondent/Mr. Peters, Dr. Meenan broke down total OMS gross receipts. Dr. Meenan determined that significant portions of total OMS gross receipts (including portions of SSEOMS gross receipts) were attributable to services and did not qualify as DPGR. 64 Bloomberg’s financial documents support Dr. Meenan’s analysis. Dr. Meenan’s determinations regarding OMS gross receipts that qualify as DPGR were reasonable, and we adopt them. We rule that OMS gross receipts that qualify as DPGR were $62 million for 2008, $94 million for 2009, and $106 million for 2010.
2. OMS Expenses Attributable to DPGR
Dr. Meenan recognized the “difficulty of identifying [OMS]
expenses” attributable to DPGR and did not attempt to allocate total OMS expenses between those attributable to DPGR and those attributable to non-DPGR. He determined that OMS “Product R&D” expenses were $71 million for 2008, $87 million for 2009, and $91 million for 2010. However, Dr. Meenan never stated what he believed total OMS expenses to be, at least in part because he treated OMS expenses “in their entirety as part of BPS expenses.”
Mr. Peters determined that total OMS expenses were $178 million for 2008, $188 million for 2009, and $235 million for 2010. Mr. Peters did not attempt to allocate total OMS expenses between those
64 Dr. Meenan’s calculations were conservative. For example, Bloomberg’s
financial documents did not break down gross receipts for “[p]remium” OMS products between services and the provision of access to software. Dr. Meenan stated, “[r]ather than allocate the relatively small amounts in this subcategory between DPGR and non- DPGR, I conservatively exclude it from DPGR in its entirety; those revenues do not contribute to any claimed deduction.”
[*101] attributable to DPGR and those attributable to non-DPGR, as Mr. Peters considered no OMS gross receipts to constitute DPGR.
Dr. Meenan’s decision not to attempt to allocate total OMS expenses between those attributable to DPGR and those attributable to non-DPGR implicitly shows that Bloomberg did not meet its burden of proof to show what, if any, portion of OMS expenses are attributable to non-DPGR. Furthermore, Dr. Meenan never stated what he believed total OMS expenses to be. Considering the evidence and expert reports, we adopt Mr. Peters’s determined total OMS expenses of $178 million for 2008, $188 million for 2009, and $235 million for 2010. We rule that all these expenses are attributable to OMS gross receipts that qualify as DPGR.
F. BPS Gross Receipts and Expenses
Allocation issues regarding BPS gross receipts and expenses are particularly complex, and we do not adopt the conclusions of either expert witness. We and other courts have recognized that precision in deciding complex allocation issues is unattainable, but that we must do the best we can with the evidence presented. DeMink v. United States, 448 F.2d 867, 870 (9th Cir. 1971) (citing Ditmars v. Commissioner, 302 F.2d 481, 488 (2d Cir. 1962), rev’g and remanding T.C. Memo. 1961-105); Ditmars v. Commissioner, 302 F.2d at 488 (recognizing “that a rough approximation is all that can be expected” in that complex allocation case); Commissioner v. Ferrer, 304 F.2d 125, 135 (2d Cir. 1962) (stating that “no one expects scientific exactness” in complex allocation cases), rev’g and remanding 35 T.C. 617 (1961); Goosen v. Commissioner, 136 T.C. 547, 562 (2011).
1. BPS Gross Receipts That Qualify as DPGR
As stated supra OPINION Part X.D, we adopted Dr. Meenan’s calculated BPS plus qualified OMS gross receipts of $5.192 billion for 2008, $5.395 billion for 2009, and $5.769 billion for 2010. Subtracting qualified OMS gross receipts 65 leaves BPS gross receipts of $5.130 billion for 2008, $5.300 billion for 2009, and $5.663 billion for 2010.
Dr. Meenan determined that Bloomberg had DPGR of $3.196 billion for 2008, $3.319 billion for 2009, and $3.505 billion for 2010. Subtracting his determined OMS DPGR leaves BPS DPGR of $3.134
65 As discussed supra OPINION Part X.E.1, OMS gross receipts that qualify as
DPGR were $62 million for 2008, $94 million for 2009, and $106 million for 2010.
[*102] billion for 2008, $3.224 billion for 2009, and $3.399 billion for 2010. Dr. Meenan thus determined total BPS DPGR of $9.757 billion for the years at issue, which is 61% of total BPS gross receipts ($16.094 billion) for the years at issue. As discussed supra OPINION Part X.C, Dr. Meenan significantly overstated BPS DPGR because he assumed that almost all BPS software generated gross receipts that qualify as DPGR. We do not believe that Dr. Meenan’s conclusion that 61% of BPS gross receipts constitute DPGR is close to accurate.
Mr. Peters determined that BPS DPGR was $760 million for 2008, $704 million for 2009, and $747 million for 2010. Mr. Peters thus determined total BPS DPGR of $2.211 billion for the years at issue, which is 14% of total BPS gross receipts ($16.094 billion) for the years at issue. For the reasons discussed supra OPINION Part X.C, we believe that Mr. Peters understated BPS DPGR.
The evidence in these cases shows that analytical and graphing software was a critical BPS feature. While data and news were also critical features, it is impossible to imagine BPS being a hugely successful product for decades without integrated analytical and graphing software. Considering the evidence, we conclude that the percentage of BPS gross receipts that qualifies as DPGR for the years at issue is approximately 1.75 times the 14% determined by Mr. Peters. Accordingly, we rule that 24% of BPS gross receipts constitutes DPGR. Our ruling is heavily influenced by (1) calculations, explanations, and arguments set forth in the initial and rebuttal reports prepared by Mr. Peters and Dr. Meenan; (2) APA-related materials and Bloomberg’s other financial information; (3) testimony given by BPS customers and employees regarding the importance of the BPS analytical and graphing software; and (4) McKinsey Survey data.
Applying the 24% figure to total BPS gross receipts for each year at issue 66 results in BPS DPGR of $1.231 billion for 2008, $1.272 billion for 2009, and $1.359 billion for 2010.
66 Both expert reports, and other Bloomberg financial information, reflect that
there was little variability in the distribution of BPS revenue and expenses in the years at issue. We believe it is appropriate to use the same percentage of BPS gross receipts that constitutes DPGR for each year at issue. Similarly, we believe it is appropriate to use the same BPS DPGR profit margin (discussed infra OPINION Part X.F.2) for each year at issue.
[*103] 2. BPS Expenses Attributable to DPGR
In determining its QPAI, a taxpayer must subtract from its DPGR those expenses that are properly allocable to DPGR. § 199(c)(1). “A taxpayer generally must allocate and apportion [expenses] using the rules of the section 861 method.” Treas. Reg. § 1.199-4(c). Allocation of most expenses must “reflect[] to a reasonably close extent the factual relationship between the [expense] and the grouping of gross income.” Temp. Treas. Reg. § 1.861-8T(c)(1).
The parties disagreed as to whether Dr. Meenan properly applied section 861 rules, particularly in his application of Treasury Regulation § 1.861-17 regarding Bloomberg’s R&D expenses. Respondent argued that Bloomberg did
not present[] sufficient evidence, to determine what expenses qualify as research and experimentation expenses under [Treasury Regulation §] 1.861-17.
Dr. Meenan’s expense allocation method actually lowers QPAI. Accordingly, Mr. Peters believed the most conservative approach was to follow the method originally used by [Bloomberg].
Mr. Peters did not apply Treasury Regulation § 1.861-17, but stated the following in his rebuttal report:
I have reviewed Meenan’s Section 861 Method, and have determined that the application of such a method would not change my conclusions presented in my Opening Report. The conclusions presented in my Opening Report rely on an expense allocation that directly attributes expenses to each BPS []component and that is consistent with my gross receipts allocation. Meenan’s Section 861 Method, in contrast, does not attribute any expenses directly to the purported “Software Item” despite asserting that Bloomberg does incur such expenses. Furthermore, Meenan’s Section 861 Method and his approach for allocating gross receipts are inconsistent.
Considering issues with both expert reports, Bloomberg’s voluminous financial records, and the allocation issues in these cases, we believe that for purposes of this Opinion it is preferable to determine expenses allocable to BPS DPGR using a profit margin rather than
[*104] attempting extremely complex section 861 calculations ourselves. We will not address the correctness of Dr. Meenan’s section 861 calculations given the other issues with his report (namely, his determination that gross receipts attributable to almost all software qualified as DPGR) and respondent’s admission that “Dr. Meenan’s expense allocation method actually lowers QPAI,” which is favorable to respondent.
As stated supra OPINION Part X.D, we adopted Dr. Meenan’s calculated BPS plus OMS expenses of $2.647 billion for 2008, $2.807 billion for 2009, and $3.209 billion for 2010. Subtracting OMS expenses 67 leaves BPS expenses of $2.469 billion for 2008, $2.619 billion for 2009, and $2.974 billion for 2010.
Dr. Meenan did not separate total OMS expenses from his determined BPS plus OMS expenses. As a result, we cannot say what his determined BPS expenses allocable to DPGR were. However, his determined BPS plus OMS expenses allocable to DPGR were $1.460 billion for 2008, $1.567 billion for 2009, and $1.558 billion for 2010. Subtracting these total expenses ($4.586 billion) from Dr. Meenan’s determined total DPGR ($10.020 billion), then dividing the result by $10.020 billion equals a profit margin of 54% on Dr. Meenan’s determined total DPGR. Because OMS had a negative profit margin, see supra OPINION Part X.E, it is reasonable to assume that Dr. Meenan would have determined a BPS DPGR profit margin slightly higher than 54% for the collective years at issue.
Mr. Peters determined that Bloomberg’s expenses allocable to DPGR were $444 million for 2008, $432 million for 2009, and $448 million for 2010. Because Mr. Peters determined that no OMS gross receipts constituted DPGR, all these determined expenses are allocable to BPS DPGR. Subtracting these total expenses ($1.324 billion) from Mr. Peters’s determined total DPGR ($2.211 billion), then dividing the result by $2.211 billion, equals a profit margin of 40% on Mr. Peters’s determined total DPGR. 68
67 As discussed supra OPINION Part X.E.2, we adopted Mr. Peters’s
determined OMS expenses of $178 million for 2008, $188 million for 2009, and $235 million for 2010.
68 We previously stated that Mr. Peters determined profit margins of or around
46% for Analytics for each year at issue. However, Mr. Peters later excluded CR IP gross receipts from gross receipts allocated to Analytics to determine DPGR. This reduction in gross receipts allocated to Analytics reduced the DPGR profit margin.
[*105] As discussed supra OPINION Part X.C, Mr. Peters determined questionable profit margins for BPS components. We believe that Mr. Peters overstated the profit margin for the news component. Considering the evidence presented in these cases, we conclude that a profit margin of 52% for BPS DPGR is appropriate. This BPS DPGR 52% profit margin is slightly greater than the overall BPS 50% profit margin for the collective years at issue. 69 This reflects our belief that the BPS news component had a lower profit margin than other BPS components, and those other components had similar profit margins that were accordingly slightly higher than the profit margin for BPS as a whole.
Applying a 52% profit margin to the BPS DPGR we determined for the years at issue, see supra OPINION Part X.F.1, results in expenses allocable to BPS DPGR of $591 million for 2008, $611 million for 2009, and $652 million for 2010.
XI. U.S. Wages Issue
In the case of a partnership, section 199 applies at the partner level, though certain partnership-level items are necessary to compute the partner-level deduction. § 199(d)(1)(A); Treas. Reg. § 1.199-5(b). The amount of a section 199 deduction is limited to 50% of the wages that the taxpayer reported on Form W–2 that are properly allocable to DPGR. § 199(b). Respondent claims that Bloomberg was required, and failed, to substantiate Form W–2 wages allocable to DPGR in this partnership-level proceeding.
In FPAAs concerning the years at issue, respondent determined that Bloomberg’s U.S. wages paid ($806 million for 2008, $812 million for 2009, and $968 million for 2010) were zero. This adjustment pertained only to section 199; respondent did not adjust Bloomberg’s claimed total deductions or net income. Respondent stated that adjustments to U.S. wages were made because “Bloomberg was not eligible to determine . . . W–2 wages that are properly allocable to DPGR at the partnership level” and such wages “are computed at the partner level and not at the partnership level.”
69 As stated in this OPINION Part X.F, we determined BPS gross receipts of
$5.130 billion for 2008, $5.300 billion for 2009, and $5.663 billion for 2010, as well as BPS expenses of $2.469 billion for 2008, $2.619 billion for 2009, and $2.974 billion for 2010.
[*106] In his Pretrial Memorandum respondent stated:
On Schedule K of its 2008, 2009, and 2010 income tax returns, Bloomberg reported (1) W-2 wages allocable to DPGR in the amounts of $806,252,021, $876,614,129, and $967,986,820, respectively, and (2) section 199 deductions of $44,622,982, $46,300,689, and $179,371,319, respectively. Bloomberg also reported QPAI of $1,993,014,654 for 2010. In the FPAAs, respondent determined these items are properly computed at the partner level and not at the partnership level.
I.R.C. § 199(b) provides that the amount of the sec.
199 deduction for any taxable year shall not exceed 50 percent of the W-2 wages of the taxpayer for any taxable year. Section 199(d)(4)(A)(iii) provides that each partner is treated for purposes of the W-2 limitation rules in section 199(b) as having W-2 wages for the taxable year in an amount equal to such person’s allocable share of the W-2 wages of the partnership for the taxable year. A partnership determines the partner’s allocable W-2 wages . . . and allocates those wages in the same manner it allocates wage expense among the partners. The determination of whether those W-2 wages are allocable to DPGR . . . is ultimately done at the partner level and not the partnership level. The partner must calculate its total W-2 wages for purposes of the W-2 wage limitation in section 199(b) (including W-2 wages from other sources, if any) by determining the amount of the partner’s total W-2 wages properly allocable to DPGR. Accordingly, to the extent the Court determines that some of Bloomberg’s gross receipts constitute DPGR, it should determine the W- 2 wages allocable to the partner under Treas. Reg. § 1.199- 2(e)(1), but not determine whether the W-2 wages are allocable to DPGR because that is properly determined at the partner level. [Citations omitted.]
In his Opening Brief, respondent then argued that we should rule for him because Bloomberg failed to substantiate the amount of Form W–2 wages allocable to DPGR. Respondent stated:
The W-2 wage limitation in section 199(b)(1) that limits the amount of a section 199 deduction, which is
[*107] allowable to a partner, to 50% of the W-2 Wages allocable to DPGR is a partner-level determination, over which the Court lacks jurisdiction. However, the Court does have jurisdiction to determine W-2 wages that may be included in [Bloomberg’s] expenses and allocable to DPGR because that information is necessary to determine the amount of [Bloomberg’s] expenses allocable to DPGR, which is a partnership item.
Accordingly, to the extent the Court determines that some of [Bloomberg’s] gross receipts constitute DPGR, it should determine the W-2 wages allocable to DPGR so that a partner could calculate a section 199 deduction. Additionally, under section 1.199-5(b)(1), the Court should determine the W-2 wages as defined in section 1.199- 2(e)(1).
The W-2 wages shown on [Bloomberg’s] tax returns are all U.S. wages, but not all these U.S. wages are allocable to DPGR. Thus, the wages determined under section 1.199-2(e)(1) are $806,252,021, $812,160,630, and $967,986,820, respectively.
. . . [N]one of the methods presented to the Court establish the percentage of W-2 wages that should be allocated to DPGR. Therefore, the amount of W-2 wages allocable to DPGR is unsubstantiated and should be determined to be zero. [Citations omitted.]
In its reply brief, Bloomberg argued that respondent’s Opening Brief position “is an ambush in violation of Tax Court practice: until now, Respondent’s (correct) position had been that W-2 wages are not at issue.” Bloomberg argues that we should (1) not consider respondent's argument given the alleged lack of notice, see Genecure, L.L.C. v. Commissioner, T.C. Memo. 2022-52, at *39–40; (2) reopen the record to permit Bloomberg “to make its case”; and/or (3) rule that this issue is a new matter, and that respondent bears the burden of proof, see Rule 142(a). Bloomberg alleges that “[l]ittle would be required for [it] to perfect the record on this issue.”
At best, respondent’s position(s) on this issue at various times have been unclear. We decline to rule on this issue in this Opinion. We will direct the parties to attempt to settle the issue as part of their
[*108] Rule 155 computations. If the parties are unable to reach a settlement, we plan to reopen the record, consider any new relevant evidence, and then rule on the issue.
XII. Conclusion
We hold that Bloomberg had DPGR of $1.293 billion for 2008, $1.366 billion for 2009, and $1.465 billion for 2010. We further hold that Bloomberg’s expenses allocable to DPGR were $769 million for 2008, $799 million for 2009, and $887 million for 2010. We have considered all arguments made by the parties, and to the extent not mentioned or addressed, they are irrelevant or without merit.
To reflect the foregoing,
Decisions will be entered under Rule 155.
Bloomberg L.P., Bloomberg, Inc., Tax Matters Partner (Bloomberg L.P., Bloomberg, Inc., Tax Matters Partner) — published by Counsel Stack Legal Research, free access to 12M+ legal documents.