Grain Elevator Software: Why Tickets, Contracts and Position Never Agree

Why grain software makes or breaks an elevator operator

Harvest morning at a three-house operation. Trucks are stacked back onto the county road at 6:40 a.m. The scale operator is running AGRIS on a terminal that has not been meaningfully updated since the last version bump, probing samples, keying moisture and test weight, and printing scale tickets. Somewhere between the pit and the office, a driver says the load is going against the Anderson contract, not the DP pile, and nobody writes it down. That ticket gets applied to the wrong contract. It surfaces six weeks later when Anderson calls about a settlement that is 1,800 bushels light and swears he delivered it.

Meanwhile the merchandiser is doing the thing every merchandiser does: exporting positions into a spreadsheet at the end of the day because the system's position report nets DP, basis-fixed, and priced-later bushels in a way she stopped trusting two seasons ago. She rebuilds it by hand, cross-checks against the broker statement, and calls the hedge desk. That is roughly 8 to 12 hours a week of a high-paid person doing arithmetic the software was supposed to do. At a facility moving 6 million bushels, a persistent half-cent of unexplained shrink and blend error is $30,000 a year that nobody can trace to a cause.

The incumbent stack is usually some combination of AGRIS, Cultura on the old AgTrax lineage, or a regional grain accounting package, plus something like Bushel or DTN on the grower-facing and market-data side, plus scale automation from Cardinal or Rice Lake, plus probe and grading gear from a GAC 2500 or a Perten unit, plus QuickBooks or a separate general ledger because the grain system's accounting side never quite fit. Between each of those sits a person, a spreadsheet, or a re-key. The gaps are where the money leaves.

Problem: the scale ticket is created before anyone knows what it is

The physical truth arrives before the commercial truth. A truck crosses the scale, and at that moment the elevator does not yet know the commodity grade adjustment, the correct contract application, whether the grower wants it on DP or priced, or whether the load should be blended into a bin that is already carrying a moisture average. So the scale operator picks something. During harvest, at 400 trucks a day, "picks something" means picks the last thing they picked.

Off-the-shelf systems handle this by making ticket correction an office task after the fact. You get an unapplied ticket queue, and someone in accounting spends the winter working it down. AGRIS and its peers were architected when a country elevator handled one commodity and a handful of contract types, so their ticket model is a flat record you fix later, not a live object with state.

What a custom build does differently: the ticket becomes a state machine with a captured-at-scale intent. The scale terminal shows the driver's grower account, their open contracts with remaining bushels, and their standing delivery instruction, pulled live. The operator taps one of three options instead of typing a contract number from memory. If the driver's answer conflicts with the contract's remaining balance, the terminal flags it before the truck leaves the pit, not in February. Grade data flows in from the GAC over serial or the vendor's API instead of being keyed twice. Every downstream number, settlement, position, DP obligation, inherits from one immutable ticket with a full change log, so when Anderson calls, you show him a timestamped record instead of arguing.

The AI worth paying for here: scale tickets, grade certificates, and third-party probe slips arriving from a shuttle loader or a competing house come in as scanned PDFs and photos. A document-extraction model reading those into structured ticket data, with a confidence score and a human review queue for anything under threshold, kills the re-key. We have shipped this pattern for operators handling several hundred inbound documents a week, and the practical result is one clerk's job becoming a 20-minute review pass.

Problem: DP, basis, and priced-later positions never agree

Ask three people at an elevator what the corn position is and you get three answers, because the question is ambiguous. Bushels on hand is a physical number. Company-owned bushels is that minus DP, minus condo storage, minus warehouse receipts, plus in-transit. Priced position is different again once you account for basis contracts where the futures leg is fixed but the basis is not, or HTAs where the reverse is true. The merchandiser needs the third number by 8:30 a.m. to talk to the hedge desk, and the system gives her the first.

Every off-the-shelf grain package claims a position report. The failure is not that the report is missing, it is that the report bakes in assumptions about contract types that do not match your book. If you write condo storage agreements, or you run a seed or specialty program with identity preservation, or you take delivery on a contract that lets the grower roll the futures month twice, the vendor's model does not have a place for it and you end up with an "adjustments" line that grows every year until the whole report is a spreadsheet with extra steps.

A custom build models your contract types as first-class objects: each contract carries its own pricing legs, roll rules, service charge schedule, and delivery window, and the position engine is a pure function over those objects plus tickets plus hedges. When you add a new contract type next season, you add a type, not an adjustment column. The daily position report reconciles automatically against the broker statement (CQG, DTN, or your FCM's file drop) and flags variances over a threshold you set, say 5,000 bushels or $2,500 of unexplained exposure, rather than requiring someone to eyeball two PDFs side by side. That is the single highest-value thing we build in this category and it usually pays for itself inside a year on merchandiser hours alone.

Problem: settlement math is a hundred small policies nobody wrote down

Shrink schedules by commodity. Drying charges that step at moisture bands and change when your dryer's gas cost changes. Damage discounts that follow the USDA grade table until they do not, because your terminal customer applies a different one. Storage that starts free through a date and then accrues per bushel per month, unless the grower is on a condo agreement, unless they prepaid. Deductions for check-off, for a co-op equity retain, for an open feed bill at the agronomy side. Advance payments against DP with an interest carry.

Off-the-shelf handles the common 70 percent and pushes the rest into "miscellaneous deduction" lines that a settlement clerk keys by hand from a laminated card. The math is right most of the time. The wrong times cost you either money or a grower relationship, and both matter. When a farmer gets a settlement he cannot recompute, he starts hauling to the co-op across the county.

What a build does: an actual rules engine, versioned and effective-dated, that encodes each policy once. Change the drying charge on October 3rd and every ticket after that date uses the new schedule while everything before it stays reproducible. The settlement statement shows the grower each line's derivation, gross bushels, shrink at your schedule, moisture band applied, resulting net, rather than a single adjusted number. We put a settlement preview in the grower portal so the farmer sees what he will be paid before the check runs, which cuts the phone calls to the office more than any other feature we have shipped in this category.

Problem: multi-location is not multi-company, and your software thinks it is

Once you run three or five houses plus a shuttle facility, the operational questions change. Where should the next 40 loads go given current bin space, blend targets, and rail car placement? Which house has the room and which has the wrong average moisture? Can I move 60,000 bushels between locations on paper to satisfy a delivery without a truck moving?

The incumbent systems mostly treat each location as a separate books entity that consolidates on a schedule, because that is how the accounting was designed. So your ops team makes routing decisions from a whiteboard and a phone tree while the software reconciles overnight. At high volume, that whiteboard is worth real money: a badly routed harvest day means overfilled piles, a demurrage hit on a car you could not load, or a blend you cannot make without buying quality you should not have to buy.

A custom build carries a live inventory-by-bin model with quality attributes on the bin, not just quantity, and exposes it to whoever is directing trucks. Blend calculation becomes a solver: given target spec and current bin quality, tell me the mix. Inter-company transfers become a documented paper move with the accounting entries generated, not a phone call plus a journal entry someone forgets. And a forecasting model over your historical delivery patterns, current open contracts, and weather-adjusted harvest pace can tell the ops manager on October 8th roughly how many bushels are coming Thursday, which is useful for staffing the scale and staging trucks. That is a legitimate machine learning application here, unlike most of what gets marketed as AI to this industry.

Problem: the grower experience is a phone call to an office that closes at 5

Your farmer wants to know his DP balance, price his bushels, see settlements, and get a scale ticket copy. Today he calls Deb. Deb is excellent and knows every account by memory, and Deb is the single point of failure and she is retiring in three years. Meanwhile the co-op down the road put a portal in and their growers are pricing at 9 p.m. from the combine cab.

Some vendors bolt on a grower portal. The ones we have seen are read-only, or they are a separate login with a separate password reset flow, or they show a balance that is 24 hours stale because it syncs on a batch. Read-only is not the point. Pricing is the point.

The build here is a portal wired to the same contract objects and the same live cash bid, so a grower can price DP bushels against your posted bid inside a window you control, with hard limits (max bushels, bid validity, cutoff time) enforced server-side. The pricing action creates a real contract, hits the position, and notifies the merchandiser. After-hours booking is the second AI feature that earns its cost: a bot on text or the portal that answers "what's my DP balance," "what's your December bid," and "price 5,000 bushels," escalating anything ambiguous to a human queue with the full conversation attached. Not a chatbot for its own sake. A way for the elevator to transact at 9 p.m. without staffing 9 p.m.

What this costs and how long it takes

Digital Heroes has delivered over 2,000 projects, and across the operational-software work the bands hold up well. A focused first release for a grain operation, meaning scale ticket capture with hardware integration, contract and application logic for your actual contract types, settlement rules engine, and a position roll-up, typically runs $60k to $130k and ships in 12 to 16 weeks. A full platform, adding grower portal with pricing, hedge and broker reconciliation, multi-location inventory and blend, and general ledger integration, runs $150k to $400k phased over 6 to 12 months.

What drives price up specifically in this category: the number of distinct contract types you actually write (each one is a modeling exercise, and eight is a very different project than three); scale and probe hardware integration where the vendor gives you a serial protocol and a 1990s manual instead of an API; whether you need federal warehouse licensing under the United States Warehouse Act or your state's equivalent, which carries audit requirements and warehouse receipt handling and is not optional to get right; historical data migration from AGRIS or Cultura, where the old system's DP and storage history has to come across intact because growers will ask about it; and multi-commodity plus identity-preserved programs, which multiply the quality attributes you track. What does not drive price much: number of locations, once the model is right. Location three costs almost nothing after location two.

The migration question is the one people underestimate. Cutting over mid-year with open DP balances and unpriced contracts is the risk, not the code. We run these as parallel-run cutovers across a settlement cycle, usually starting the build in spring so the first release is live and shaken out before harvest.

Build versus buy: take a position

Buy if you are a single country elevator under roughly 2 million bushels a year, writing cash and forward contracts and not much else, with one commodity and no condo storage. AGRIS or a regional package will cost you a fraction of a build, and the pain of its assumptions will be smaller than the pain of owning software. That is a real answer and we have told operators exactly that.

Build when three or more of these are true: you run multiple houses; your merchandiser rebuilds the position in Excel more than twice a week; you have added a contract type in the last two years that the software cannot model without a workaround; you have unexplained shrink or blend variance you cannot trace to a cause; a grower-facing capability your competitor has is costing you bushels; or your vendor's roadmap does not include the thing you need and their answer is a custom report on their hourly rate. The economics are simple at volume. A merchandiser at 10 hours a week of manual reconciliation is 500 hours a year of your most expensive operational hire doing something a computer does perfectly, and that is before the errors.

The middle path we recommend often: keep the incumbent for general ledger and basic accounting, build the operational layer on top with real integration, and migrate the accounting later if ever. That is a $60k to $130k first phase, not a rip-and-replace, and it de-risks the whole thing.

How to choose a developer for grain elevator software

Ask them to model DP on a whiteboard in ten minutes. Not the UI, the data model. If they cannot explain how a deferred price bushel differs from a priced-later bushel and what each does to your position and your balance sheet, they will learn on your money. Domain fluency in this category is not optional and it is not something a generalist picks up from a discovery call.

Ask what scale and probe hardware they have integrated and make them name the vendor and the protocol. Cardinal, Rice Lake, GAC 2500, Perten. If the answer is vague or "we would use an API," they have not done it. Half the risk in a grain build lives at the pit, in serial ports and truck traffic and a scale operator who will not use anything that takes more than two taps.

Ask how they handle warehouse license and audit requirements. If you are licensed, your software is part of your compliance posture: warehouse receipts, position reporting to your state department of agriculture or USDA, records retention, an audit trail that survives an examiner. A developer who has not shipped into a regulated inventory environment will build something that is functionally correct and audit-hostile.

Ask who owns the code and get it in writing before the first invoice. You should own the repository, the infrastructure accounts, and the data, with no license back to the developer and no runtime dependency on them. If a firm resists that, the software is a leash, and you already know what that feels like.