Grain Elevator Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does a grain project get scoped as an office system?

The commonest scoping failure in this category is building everything except the scale house. The proposal covers contracts, settlements, position reporting and a grower portal, and the ticket arrives in that system the way it always has: keyed by an operator into whatever screen exists, or imported from the incumbent overnight. It is the cheapest half of the project to leave alone and it is the half that creates every error the other half then has to correct.

The reason is timing. The physical truth arrives before the commercial truth. A truck crosses the scale and at that moment nobody knows the correct contract application, whether the grower wants it on deferred price or priced, or which bin the load should blend into. So the operator picks something, and at four hundred trucks a day picks something means picks the last thing they picked. Off the shelf systems accept this by design and give you an unapplied ticket queue that somebody works down over the winter.

It also happens because the pit is unpleasant to design for. Dust, gloves, a queue backed onto the county road and an operator who will abandon anything that takes more than two taps. Developers who have not stood there build a form.

The fix is to make the scale terminal the first deliverable, not the last. It should show the driver's grower account, their open contracts with remaining bushels and their standing delivery instruction, pulled live, so 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, flag it before the truck leaves the pit. Ask any prospective developer to describe the scale screen in detail before they describe the dashboard. If they cannot, the office system will spend its life correcting the pit.

What goes wrong migrating deferred price balances and storage history?

The code is not the risk in a grain migration. Open obligations are. Deferred price bushels, unpriced contracts, condo storage agreements, warehouse receipts and storage accrual history all have to arrive intact and reconcile to the penny, because a grower will ask about a 2019 delivery and expect an answer.

Three problems recur. Deferred price and priced later balances are frequently held in the old system with adjustments layered on top, so the balance shown and the balance derivable from the ticket history do not agree, and nobody noticed because nobody ever derived it. Storage accrual carries per grower exceptions such as free periods, prepayments and condo terms, and those exceptions are typically undocumented. And contract types that the incumbent could not model were implemented as workarounds, so the data says one thing and the business means another.

The fourth is identity. Farms appear under multiple names, entities have split or merged, and history attaches to whichever account was open that season.

The fix is a parallel run across a full settlement cycle, and a spring start. Reconcile every open deferred price balance, unpriced contract and storage accrual against the old system before you switch anything off, grower by grower, and resolve the workaround contracts into real contract types while the person who invented the workaround still works there. Budget real time for data mapping out of AGRIS or Cultura; on the projects we have run it is often twenty to thirty percent of a first phase. Then plan the cutover so the first release is live and shaken out before harvest, because a mid harvest migration with open positions is the one genuinely avoidable disaster in this category.

Why do the scale, probe and broker integrations break after launch?

Half the technical risk in a grain build lives in interfaces that were never designed to be integrated with, and they degrade in predictable ways.

Scale indicators from Cardinal or Rice Lake talk over serial or Ethernet with documented protocols, and they work reliably until the PC beside the scale is replaced, the port mapping changes, or a surge event during a storm resets a converter. Moisture and grade units such as a GAC 2500 or a Perten instrument change result formats after a service visit or a firmware update, and the parser stops matching without throwing anything an operator will see. Broker and market data files from your futures commission merchant, from CQG or from DTN arrive on a schedule until the day the file naming convention changes.

What makes this specific to elevators is that the failure window is harvest. Everything holds through a quiet August and breaks in the third week of October, when nobody has an afternoon to investigate and the fallback is a pen.

The fix is heartbeat monitoring and a documented fallback at the pit. Every feed needs a check that alerts when data stops arriving rather than leaving a blank field, and the scale terminal needs a defined manual path an operator can use in thirty seconds without calling anyone. Ask the developer to name the specific hardware and protocol they have shipped against rather than claiming integrations generally, and agree who fixes a broken converter during harvest and how fast.

What happens when warehouse licensing and the audit trail are not covered?

If you are licensed, your software is part of your compliance posture, and this is the area generalist developers get functionally right and audit hostile.

Warehouse receipts, position reporting to your state department of agriculture or under the federal warehouse programme, records retention and an examiner's ability to follow a settlement back to the original scale ticket without a person narrating it are all requirements, not reports. A system that lets a ticket be edited in place, or that recalculates a historical settlement using today's discount schedule, will produce numbers that cannot be defended even when they are correct.

The second gap is reproducibility. Settlement policy changes during a season: the drying charge steps when your gas cost moves, a damage discount schedule is revised, a shrink factor is corrected. If those changes overwrite the previous values, every settlement before the change becomes unreproducible, and the first time anyone notices is when a grower or an examiner asks you to show the working.

The fix is immutability and effective dating. The ticket is created once and never edited, with corrections recorded as linked adjustments carrying a reason and a user. Discount, shrink, drying and storage schedules are versioned with effective dates, so a settlement computed in October reproduces exactly in March. Ask a candidate developer what regulated inventory environments they have shipped into before you talk about features, because retrofitting an audit trail is far harder than designing one.

Should you build custom or configure what you already own?

If you run a single country elevator moving under roughly two million bushels a year, handling one or two commodities, writing cash and forward contracts with no condo storage and no identity preserved programmes, do not build. AGRIS or a regional grain accounting package costs a fraction of a development budget and its assumptions will fit you well enough. Building at that scale buys you a maintenance obligation you do not need, and we tell operators exactly that.

The middle path is right more often than either extreme. Keep the incumbent for the general ledger and basic accounting, and build the operational layer on top: ticket capture with real hardware integration, contract application, the position engine and a settlement preview. That is a smaller first phase than a replacement and it de risks the whole programme, and you can migrate the accounting later if the integration proves it is genuinely the bottleneck. Bushel and DTN cover parts of the grower facing and market data picture perfectly well and should stay if they are working.

Build the operational layer when three or more of these are true. You run multiple houses. Your merchandiser rebuilds the position in a spreadsheet 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. A grower facing capability a competitor has is costing you bushels. Or your vendor's answer to the thing you need is a custom report at their hourly rate.

How do hidden costs get into the quote?

Four items reliably arrive after signature. Contract types, because each distinct type is a modelling exercise and a book with eight is a materially different project from one with three, and nobody counts them accurately at proposal stage. Hardware integration, where a vendor hands you a serial protocol and a manual from another decade instead of an interface. Warehouse licensing work, if you are licensed and the proposal treated compliance as reporting. And migration, which as noted is often twenty to thirty percent of a first phase.

The fifth is identity preserved and multi commodity programmes, which multiply the quality attributes you track through every bin, blend and settlement calculation.

What does not drive cost much, and is often padded, is the number of locations. Once the model is right, the third house costs almost nothing after the second.

The fix is to count your contract types out loud before you accept a number. List every distinct type you actually write, including the awkward ones, and ask which are in release one. Ask which scale and probe hardware is included by make and protocol. Ask who owns migration reconciliation. And ask what changes if you add a fourth location, because a quote that scales linearly with houses has not modelled the business properly.

What separates a grain build that works from one that fails?

The builds that work put the position engine in the first release and prove it against the broker file automatically. Reconciliation with a variance flag, so anything over a threshold you set gets surfaced, is what earns the merchandiser's trust. Expect a full season of shadow checking before she stops rebuilding it by hand, and treat that as healthy rather than as resistance. Trust arrives because the system catches something first, not because anyone was told to trust it.

They model contract types as first class objects rather than as adjustments. Each contract carries its own pricing legs, roll rules, service charge schedule and delivery window, and the position is a computation over those objects plus tickets plus hedges. When you add a type next season you add a type, not another column on a report that is drifting towards being a spreadsheet with extra steps.

They show the grower the derivation. A settlement statement that displays gross bushels, shrink at your schedule, the moisture band applied and the resulting net, with a preview available before the check runs, removes more phone calls than any other feature in this category. Farmers do not object to discounts. They object to numbers they cannot recompute, and the ones who cannot recompute them start hauling to the co op across the county.

And they settle ownership before the first invoice: the repository, the infrastructure accounts and the data, with no licence back to the developer and no runtime dependency on them. If a firm resists, the software is a leash, and you already know how that feels from the last system.