River and reservoir basins are operated for various purposes including power production, irrigation, environmental purposes, recreation, and water quality. In many of those basins, it is necessary for water managers to track not only the volume and flow of water throughout the basin, but managers must also track the water ownership and type of the water. Operating decisions in the basin are dependent on many aspects including a user’s available water, legal restrictions, physical constraints, and any exchange mechanism. In addition, many of the basins in the United States are governed by the doctrine of Prior Appropriation which says that the right to use a water supply is based on "first in time, first in right". Because of these constraints, it is necessary for water managers to have a tool to simulate the operating decisions and their effect in the basin including water type and water ownership.

RiverWare meets these requirements through water accounting. Simply, water accounting is a layer added to a simulation model used to track the ownership and/or type of the simulated water. In an accounting model, accounts, slots, and data are added to track why water is released, stored, or diverted. This network is separate from the simulation network but there are methods that allocate physical water to the accounting network.

Accounts are linked to one another on both the same object and on different objects. These links indicate the possible transfers of water in the system. By defining a link, the user indicates that at some timestep, water could move between the two linked accounts. Legal accounts, including Storage, Diversion, and Instream Flow, are used to model a legal water right. Passthrough accounts are used to track the transfer of water through basin features. With both legal and non-legal accounts, the user can look at any object in the basin and determine the type and ownership of all of the water in that object.

Accounts solve whenever sufficient known slot values are present to run a solution method. This is analogous to dispatching in the simulation network; however, in the case of the accounting system, this means that accounts may solve when a user edits the account values through the user interface, a rule sets a value, or a method sets a value. Therefore, a run is not required to make a single account solve. Each time an account slot is given a value, the account holding the slot is notified, and performs its own checks for over- and under-determination, and possibly solves at one or more timesteps.

Outside of a run, accounts solve for as many timesteps as there is the required known data. This means that the account solution behaves similarly to a spreadsheet solution. If the user inputs an Outflow for each timestep in the accounting period for a storage object and all of the inflows, slot inflow and Gain Loss are known, then the account will solve for Storage at each timestep.

Rules can access the account solution but can also control and set the releases from the accounts. User inputs can also drive the account solution. Using rules and other accounting utilities, the user can simulate typical accounting functionality including accrual, exchanges, carryover, and allocation. In addition, a special predefined rule function and set of methods serves as a water rights allocation solver to allocate water to legal accounts based on prioritized water rights.

For details about the RiverWare Accounting, see “Accounting Overview” in Accounting.