Groundwater Agency Software: Will Your Pumping Numbers Survive a Legal Challenge?

The allocation ledger is the only product your agency actually sells

A landowner's attorney stands up at the board meeting with a printout. It says his client pumped 1,240 acre feet last year. He says the meter was swapped out in June, the replacement started at zero, and staff added the two totals wrong. Your engineer looks at it and quietly thinks he might be right. The spreadsheet that produced the number has been edited by four people over two years, lives on a shared drive, and nobody can say who changed cell K212 or when. Whatever the board decides that night, the agency has lost something more expensive than the disputed volume. If that number was wrong, every other number in the basin is now fair game.

Groundwater agencies are unusual buyers of software because their output is not a service, it is a set of numbers that will be litigated. A California groundwater sustainability agency under the Sustainable Groundwater Management Act, a Texas groundwater conservation district, an Arizona active management area participant: all of them assign a right to pump, measure whether the right was exceeded, charge a fee against it, and occasionally penalise an overdraft. Every one of those steps is a legal act performed by a small staff with a general fund budget and, usually, a spreadsheet.

The failure mode is not that the spreadsheet is wrong. It is that the spreadsheet cannot prove it is right. There is no record of who entered a meter read, what the raw telemetry said before staff corrected it, which version of an allocation was in force on the day a transfer cleared, or why a credit balance changed. Agencies lose challenges on process, not on hydrology.

Problem one: an allocation is a ledger entry, not a number in a column

Staff usually start by putting one row per well in a sheet with an annual allotment. That model collapses within two seasons. Allocations attach to parcels in some basins and to wells in others, and a well can serve several parcels while a parcel can be served by several wells. Parcels split. Owners change mid year. A landowner fallows ground and carries forward unused allotment. Another borrows against next year. A multi year carryover window means the balance is a running account, not an annual figure.

What a build must do is treat allocation as a double entry ledger. Every event is a posting: an initial assignment, an annual accrual, a metered debit, a carryover, a transfer in or out, an adjustment with a reason code and the staff member who made it. The balance is derived, never typed. Once the ledger exists, the report an attorney demands is a statement of account, which is a form of evidence everyone in the room already understands. That structural choice is worth more than any dashboard the agency will ever build.

Problem two: half your wells are telemetered and the other half are not

Basins end up with a mix of cellular meter loggers from several manufacturers, a handful of SCADA connected agency wells, and a long tail of pumpers who read a totaliser and submit a card or a web form. Each device vendor exposes data differently: some push to their own cloud portal with an export, some offer an interface, some produce a file per device per day. Reads arrive in gallons, acre feet, cubic metres, and in totaliser values that roll over.

An honest ingestion layer normalises all of it into one shape: device, well, timestamp, raw value, unit, and a derived volume with the conversion recorded. It stores the raw reading permanently and treats every correction as a new record that supersedes rather than overwrites. Meter change events are first class, because the June swap in the story above is a routine occurrence and the software should carry the old totaliser final read and the new starting read as linked facts, not as two orphan numbers a clerk has to reconcile. Gap filling matters too: when a logger drops offline for eleven days, the estimate that fills the gap must be flagged as an estimate forever, and the report must show how much of an annual volume is measured versus estimated. That single column has ended more disputes than any amount of extra precision.

Problem three: self reporting and enforcement are a workflow, not a form

Pumpers who self report need a submission window, a reminder cycle, a way to report on behalf of a tenant, and a correction path. Staff need a review queue where an implausible read is challenged before it becomes an official figure, because a decimal error caught in November is a phone call and the same error caught in a hearing is a problem. Then comes the uncomfortable part: notices of exceedance, cure periods, penalty assessment, appeals, and settlements. Each of those is a status with a statutory or ordinance driven clock attached.

Agencies keep this in Outlook folders and it is where the process risk concentrates. If a notice was sent late, the penalty is voidable. If two staff sent conflicting guidance, the agency is bound by the friendlier one. A build should generate the notice from the ledger, timestamp the service, hold the response, and make it impossible to advance an enforcement step without the prior step evidenced. It is unglamorous case management, and it is the difference between an agency that collects and an agency that settles.

Problem four: transferable credits create a double spend problem

Once a basin allows credits to move between pumpers, the agency is operating a small commodity registry. A credit must exist before it is sold, it must be extinguished when it is used, and it must never be counted twice. Agencies who bolt transfers onto a spreadsheet discover the same failure the first time a landowner sells the same 40 acre feet to two neighbours in the same week.

The pattern that works is a serialised credit with a state machine: issued, held, listed, transferred, retired. Transfers require both parties, an effective date, and an approval record. Validity rules encode the basin plan, because most plans restrict transfers across management areas or subject them to a transport loss factor. Do not implement a marketplace with matching and pricing in the first release even if the board is excited about it. Get issuance and retirement provably correct first, and let the trading happen by phone for another year.

Problem five: fees bill against parcel records the county controls

Pumping fees, per acre assessments and administrative charges usually attach to parcels, and the authoritative parcel record lives with the county assessor. That record changes without telling you. Splits, mergers, ownership transfers, and situs address corrections all arrive as an annual roll file in whatever format the county publishes. If your billing entity is a parcel number you typed once, your invoices will start bouncing in year three.

Build the parcel as a synchronised object with a history: the roll import creates new versions, staff resolve conflicts in a review screen, and every invoice records the parcel version it was issued against. If your county collects assessments on the tax roll on the agency's behalf, the export format and its deadline are hard constraints, and you should confirm both before design rather than during acceptance testing.

What this costs and how long it takes

A first release covering the allocation ledger, meter and manual read ingestion, a pumper reporting portal, and annual statements runs $70,000 to $150,000 and ships in 12 to 18 weeks. A full basin platform adding credit transfers, enforcement case management, fee billing with county roll synchronisation, board reporting and public transparency pages runs $200,000 to $450,000 phased across 9 to 15 months.

What pushes cost up: the number of distinct meter vendors, because each integration is real work and vendor support quality varies wildly. Multiple management areas with different rules inside one basin, which doubles the rule engine. Any requirement to feed a numerical groundwater model, because the model wants time series in its own structure. Public records obligations, which mean redaction rules and an export path built for a records request rather than improvised later. And joint powers arrangements where several agencies share one system but each keeps its own ordinance, which is genuinely a multi tenant build.

What keeps cost down: procuring in phases against your own reporting deadline, launching with the wells that are already metered, and resisting the urge to model the entire basin plan before a single read has been ingested.

Build versus buy, and when buying wins

Be clear eyed here. There is no dominant packaged product for groundwater allocation administration, which is why agencies end up with a hydrology consultant's Access database, a utility billing package bent into an unfamiliar shape, or an ArcGIS deployment doing duty as a system of record. Those are not bad tools. GIS genuinely belongs in this stack for parcel and well geometry, and you should integrate with it rather than rebuild it.

Do not build if you administer under roughly 100 wells with annual paper reporting, no transfers, and no enforcement history. Do not build if your agency is still two years from adopting the rules the software would encode, because you will pay to implement a draft. Do build when a number you published has been contested, when credits are about to become transferable, or when the person who understands the spreadsheet is within sight of retirement. That last one is the most common trigger we see and the most rational.

How to choose a developer

Ask them to model the meter replacement scenario on a whiteboard before you sign anything. A developer who has done regulated measurement work will immediately separate raw reading from derived volume and will ask what happens to the old totaliser. One who proposes a single current_reading field on the well record has built asset trackers, not ledgers.

Ask how they handle a correction. The answer you want involves superseding records and retained history. The answer you do not want is an update statement and an audit log table nobody reads.

Ask what public sector obligations they have handled: records requests, board packet exports, open meeting evidence, retention schedules. An agency system that cannot produce a defensible export on demand creates work rather than removing it.

Ask who owns the code, the database and the cloud accounts, and get it in writing before kickoff. Your allocation ledger is a public record with a retention period measured in decades. It cannot sit inside a vendor's account. At Digital Heroes the client owns the repository and the infrastructure from the first commit, and any developer who hesitates on that question is proposing a dependency your successors will have to unwind.