Irrigation District Software: Turning Water Orders, Ditch Rider Cards and Parcel Assessments Into One Ledger

The Friday afternoon phone call

A grower calls the office in August and says he is being billed for 41 acre feet on a parcel that took, by his count, closer to 33. The office has three sources of truth. The ditch rider card, which records gate settings and times in pencil. The SCADA history, which shows flow at a measurement point upstream of the turnout, serving three users. And the billing system, which holds a number that was entered by hand at the end of the run.

The manager will probably split the difference, because arguing costs more than the water. But that same afternoon repeats forty times a season, and every one of them is a small erosion of the district ability to enforce anything. In a district, the delivery record is not an accounting artefact. It is the evidence behind an allocation of a legally defined resource, and if it cannot be defended parcel by parcel, then allotments, transfers and shortage year curtailments all become negotiations rather than administration.

A district is three systems pretending to be one

The reason this is genuinely hard, and not just neglected, is that a district runs three different businesses on the same objects.

It runs a scheduling operation. Growers order water for a delivery window, orders have to fit canal capacity and a rotation, upstream demand affects downstream availability, and a ditch rider makes real time judgements about gates. That is a constrained scheduling problem with a physical system underneath it.

It runs a measurement operation. Flow arrives from telemetry at some points, from staff gauge and flume readings at others, and from a rider estimate at the rest. Reconciling those into a delivered volume per turnout, then apportioning shared measurement points among users, is the part everyone does by hand.

It runs a public finance operation. Assessments attach to parcels, not to customers, they often ride on the county tax roll, they follow the land through sale, and delinquency has statutory consequences. That is a property based billing model, not a utility customer model, and it is where most general billing software quietly fails.

Each of the three has software available. Nothing joins the three, so the district joins them with a clerk, a book and institutional memory.

Where Rubicon Water stops

Rubicon Water is real and good at what it does, which is canal automation and measurement: gates, flow control, and the operational software around modernised infrastructure. If your problem is that manual gates deliver imprecise flows and your canal loses water to poor control, that is the right kind of investment and this article is not arguing against it.

It is not, however, a district administration system, and districts get into trouble when they expect automation to solve administration. Automation gives you better numbers at the gate. It does not give you an allotment ledger in acre feet per parcel with carryover and transfers, an assessment roll that reconciles to the county assessor, a delinquency process, or an audit trail built for a hearing in front of a board where a landowner has counsel. Districts that have modernised their canals and still administer water on paper have improved the measurement and left the disputes exactly where they were.

What a custom irrigation district build has to include

• A register that ties turnout to parcel to water right to account. Everything else depends on this and it is usually the part that takes longest, because the historical record contains splits, mergers and parcels that have not matched the assessor roll since a subdivision in the 1990s.
• Water ordering with capacity awareness. Orders placed against a delivery window, checked against canal reach capacity and the rotation, with the operational consequence visible to the office before the order is confirmed rather than discovered by the rider.
• Ditch rider mobile capture, offline first. Gate settings, times, readings, adjustments and notes captured in the field on a phone or tablet along a canal with no coverage, syncing later without duplicating deliveries.
• Measurement ingestion from telemetry and manual readings into one delivery record, with an explicit method and confidence on each. When a shared measurement point serves three turnouts, the apportionment rule should be recorded and repeatable rather than recalculated by whoever is on shift.
• An allotment ledger in the district own units, whether acre feet, miner inches or a duty per acre, with carryover rules, transfers between parcels or accounts, and shortage year proration handled as a rule rather than a manual adjustment.
• Assessment billing against parcels with the county roll as a reconciled input, handling ownership changes, splits and the fact that the bill follows the land. Where assessments are collected on the tax roll, the system needs to produce and reconcile that file, not just print invoices.
• Delinquency and enforcement workflow with the statutory steps your district follows, dated and documented, because the enforcement action that matters is the one that is procedurally clean.
• Reporting to the state engineer, watermaster or equivalent in the format they require, generated from delivery records rather than assembled each year.
• Canal operations and maintenance work orders tied to the same infrastructure register, so a failed check structure is not tracked in a different place from the deliveries it affects.
• An append only record with attributed corrections, since delivery and assessment history is evidence in a water rights dispute and needs to survive one.

What it costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this category prices as follows. A first release covering the turnout, parcel and account register, water ordering against capacity and ditch rider delivery capture runs $60,000 to $130,000 and ships in 12 to 16 weeks. A full platform adding the allotment ledger with carryover and transfers, telemetry and manual measurement ingestion, assessment billing reconciled to the county roll, delinquency workflow and agency reporting runs $150,000 to $350,000 across 6 to 11 months.

What pushes it up: the state of your parcel data, which is the single most common source of schedule overrun in this category because reconciling a district register to a county assessor roll surfaces decades of unrecorded splits; telemetry integration across mixed device brands; and the complexity of your allotment rules, since districts with carryover, transfers and class based priorities have a genuinely intricate ledger. What holds it down: doing one lateral or one division first, in the off season, so the ordering and rider capture flow is proven on a small population before the whole district depends on it.

When a district should not build

Do not build if you are a small district under roughly 150 turnouts on a single canal with flat per acre assessments, no allotment carryover and no transfer market. A spreadsheet, a scheduling book and an experienced clerk are honestly sufficient, and the money is better spent on structure maintenance.

Build when two or more of these are true. Your allotment rules include carryover, transfers or shortage proration, which is where manual administration produces inconsistency between accounts. Your assessment roll no longer reconciles cleanly to the county. You have had a delivery dispute escalate to your board or to counsel. You have modernised measurement infrastructure and are still administering water on paper, which means you paid for better numbers and are not using them. Or your longest serving ditch rider is within a few years of retiring and a meaningful part of the district operating knowledge is going with him.

How to choose a developer for district software

Ask them how they will model the relationship between turnout, parcel, water right and account, including the case where one parcel is served by two turnouts and one turnout serves two parcels. If they assume one to one, they have not looked at a real district map.

Ask how deliveries are apportioned when one measurement point serves several users. There is no perfect answer, only a recorded and repeatable rule, and a developer who has done this will ask you which rule your board has approved rather than inventing one.

Ask what the ditch rider experience looks like with no signal, in sunlight, in a truck. If the answer is a responsive web page, they have not built for a canal bank.

Ask who owns the code, the repository and the cloud accounts, and get it in writing before kickoff. At Digital Heroes the client owns the code from the first commit. A district is a public body with a long institutional life and staff turnover, and a system your successors cannot maintain or migrate becomes their problem, which is exactly the situation you are trying to get out of.