Working Capital Fund Pricing Policies: Lessons from Defense Finance and Accounting Service Expenditure and Workload Data

Background The federal government is, in some ways, like a very large multiproduct firm. There are agencies within the government whose primary purpose is to provide support services to other governmental entities. One can imagine there would be grave incentive problems if one governmental entity could demand unlimited services from another for free. Private-sector firms often address this problem by establishing internal transfer-pricing mechanisms; Eccles (1985) and Eccles and White (1988) provide reviews of the lengthy literature on transfer pricing. Like divisions in a company, it would seem entirely plausible for governmental entities to charge each other transfer prices for services rendered. Indeed, a number of governmental entities have "working capital funds" that are akin to bank accounts; entities take in fee revenue from clients, then use this revenue to fund their operations. This article focuses on a specific U.S. government working capital fund entity, the Defense Finance and Accounting Service (DFAS). We obtained DFAS's cost and workload data. Analyses of these data shed light on some of the problems with current pricing methods and suggest alternative approaches. We find that the current policy of setting DFAS's fees equal to expected average cost levels is problematic. Customers appear to have excessive incentive, on the margin, to take work away from DFAS. We suggest that DFAS and other working capital fund entities utilize nonlinear pricing. They should receive fixed annual payments from customers or higher levels of the Department of Defense (if a budget-balancing constraint is desired) and then have per-unit fees equal to incremental, not average, costs of production. In the presence of output-invariant costs, average and incremental costs can diverge considerably. DFAS is a Department of Defense (DoD) agency that provides a variety of services to DoD customers such as the Air Force, Army, Navy, and other defense agencies. DFAS services include finance and accounting activities such as payroll, bill payment, and generation of accounting statements (called "monthly trial balances"). DFAS was created in 1991 through the consolidation of military service-specific accounting and finance operations. Thompson and Jones (1994) and the General Accounting Office (1997a) discuss the development of DFAS. Prior to this consolidation, each military service had a relatively autonomous finance and accounting center, and substantial support activities were conducted at local military installations. The Air Force's finance and accounting headquarters was in Denver, Colorado, the Army's in Indianapolis, Indiana, the Marines' in Kansas City, Missouri, and the Navy's in Cleveland, Ohio. The finance and accounting activities for DoD agencies such as the Defense Logistics Agency were centered in Columbus, Ohio. DFAS currently has its headquarters in Arlington, Virginia, five regional centers created from the former service finance headquarters (Cleveland, Columbus, Denver, Indianapolis, and Kansas City), and 18 U.S. operating locations (OPLOCs) as of July 1, 1998. Each OPLOC is affiliated with a particular regional center. Table 1 provides DFAS's regional center/OPLOC arrangements. We refer to the combination of a regional center and its associated OPLOCs as a "region." Though the DFAS regions now do some work for other services, the pre-DFAS work patterns have largely persisted. DFAS has a useful data set that documents its costs and workload over time. We have analyzed these Resource Analysis Decision Support System (RADSS) data. RADSS provides monthly information on both expenditures and work units (such as number of commercial invoices processed) by output and location. DFAS has defined a set of outputs, listed in table 2, and allocates costs to those outputs (as well as locations). RADSS also defines and tallies work units by output and location. Almost all DFAS costs are attributed to some output; we cannot, however, verify the validity of the allocation that has occurred. …