Custom Harvesting Software: Settling Acres, Hours and Bushels Before the Crew Crosses the Next State Line

The settlement is written six weeks after the crew has gone

You cut 640 acres of wheat for a farm in Oklahoma in early June. The rate is per acre, but there is a bushel adder over a yield threshold, the grower asked you to haul to two different elevators at different distances, one field was down and got billed at the hourly rate instead, and your grain cart sat two days waiting on trucks that the grower was supposed to supply. In August, in North Dakota, somebody sits down with a notebook, three phone photos of scale tickets and a memory of who said what about the down wheat, and writes an invoice. The grower questions the bushel adder. Nobody can prove the yield because the number came off a combine monitor that has been reset twice since.

That is not a bookkeeping failure. It is the structural condition of the business. A custom crew moves several million dollars of machinery across a two thousand mile run on a compressed season, bills on three different bases, sometimes on the same farm, and has no time during the run to settle anything. The settlement is always a reconstruction, and every week of delay costs you accuracy and bargaining position.

Why nothing packaged fits a custom harvest operation

This category genuinely has no established product, and the reason is that it sits between three software worlds that each assume something false about you.

Farm management software assumes you own the crop. Its whole model is field, crop year, inputs, yield, profit per acre. You do not own the crop. You own the machine hours and the acres, and your revenue object is a rate card, not a harvest. Trucking and dispatch software assumes freight: a load with an origin, a destination and a rate per mile. Your hauling is a fraction of the job, often at a bushel or bushel mile rate, and it is attached to a harvest job rather than standing alone. Field service software assumes service calls at customer sites with parts and labour, which is close in shape and wrong in every detail, because it has no concept of acres, moisture, dockage or a machine that bills by the hour while it waits.

So the operator becomes the join. That works at one machine. At six machines across four states with a crew that turns over annually it becomes the single biggest uncontrolled cost in the business, because every hour of settlement delay is an hour of margin you cannot defend.

What a custom build has to include

• A job object that supports mixed basis billing on the same job: per acre, per hour, per bushel, with thresholds, minimums, move charges and waiting time. Most attempts at this model one basis and treat the others as adjustments, which is exactly why the spreadsheet survives. Model all three as first class from the start.
• Rate cards per customer with effective dates, because you quote in winter and cut in July and the rate that applies is the one agreed, not the one currently on your website.
• Field capture in the cab, offline. Acres started and finished, machine, operator, start and stop times, downtime reason, moisture readings, and a photo of anything disputed. The capture has to work with no signal because a wheat field in the panhandle has no signal.
• Machine telemetry ingestion across brands. A mixed fleet is the norm, and the platforms behind the major manufacturers each expose data differently. Build a mapping layer per brand into your own machine hour and acre record, and reconcile it against what the operator entered rather than trusting either one blindly. The variance between monitor acres and mapped acres is a conversation worth having weekly, not annually.
• Grain and hauling settlement: scale tickets captured at the elevator with gross, tare, net, moisture and dockage, tied back to the job and the truck, so a per bushel or per bushel mile charge is computed from a document rather than a recollection.
• Crew hours by person by machine by day, feeding payroll. If you run H-2A labour, the hour and wage records that come with that programme are a compliance obligation as well as a payroll input, and having them fall out of the same capture the operator already does is worth the build on its own.
• Equipment moves as billable and costed events: the low boy, the permits, the fuel, the days lost. Moves are where custom crews quietly lose money because nobody tracks them as anything at all.
• Fuel and machine cost capture per job so you know your true cost per acre by machine, not an average across the run. The combine that is costing you money is not the one you think it is.
• A settlement statement the grower can read, itemising acres, basis, adders, hauling and adjustments, generated the day the crew leaves the farm rather than the month after.

Settle at the gate, not at the end of the run

The single highest value change a build produces in this business is moving settlement from the end of the season to the end of the farm. When the statement is generated while the combines are still in sight of that grower field, disputes are settled by walking over to the field. Six weeks later the same dispute is settled by discounting, because your standing to argue is gone and your evidence is a photograph. Every operator we have worked with in this category who moved settlement forward reported the same thing: they stopped writing off small differences, and the small differences were not small in aggregate.

That is why the field capture and the rate card engine come first in the build, before telemetry, before portals, before anything else. Ship the ability to settle a farm on the day you leave it, then add the rest.

What it costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this category is at the smaller end and prices accordingly. A first release with offline job capture, mixed basis rate cards and settlement statements runs $40,000 to $95,000 and ships in 10 to 14 weeks. A full platform adding machine telemetry ingestion across brands, grain and hauling settlement from scale tickets, crew hours and payroll feeds, equipment move costing and a customer portal runs $110,000 to $250,000 across 5 to 9 months.

What pushes it up: the number of machine brands you need telemetry from, since each is a separate integration with its own authorisation flow; hauling complexity if you run your own trucks and settle per bushel mile; and payroll integration, which is fiddly if you run H-2A labour with its own documentation requirements. What holds it down: building for one crop and one billing pattern first. Wheat run first, then silage, then corn. Trying to model every service you offer before the first release is how these projects miss a season.

When a spreadsheet is still the right answer

Stay on a spreadsheet if you run one combine and one truck within a couple of counties for a stable list of growers you have cut for a decade. Your settlement is already fast because your memory is short range, and a custom build would be an expensive way to formalise something that already works.

Build when two or more of these are true. You run four or more machines or more than one crew. Your run crosses three or more states. You bill on mixed bases and your invoices are routinely questioned. You have written off differences you believed you were owed because you could not prove them. Or you cannot answer, today, which machine on your fleet earns the least per hour. That last question is the one that usually justifies the project on economics rather than admin, because a custom crew is a capital business pretending to be a service business, and capital allocation without cost per machine is guesswork.

How to choose a developer for a custom harvest build

Ask them to model a job that bills partly per acre and partly per hour with a bushel adder and a waiting charge, on a whiteboard, before you sign. If they reach for a single rate field with adjustments, they will build you an invoicing tool that you abandon in July.

Ask what happens with no cell signal for a full day and two devices editing the same job. Anyone who has built for agriculture answers that without being prompted.

Ask how they will handle telemetry from two different manufacturers and what happens when one changes its data access terms. The answer should be a mapping layer you own, plus operator entered figures as the fallback, never a hard dependency on any one manufacturer.

Ask who owns the code, the repository and the cloud accounts, and settle it in writing before kickoff. At Digital Heroes the client owns the code from the first commit. In a category with no packaged alternative, being unable to change your own system between seasons is not an inconvenience, it is a business risk.