Grain Merchandising Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does contract modelling turn out to be the biggest scope failure?

Grain contracts get described in a scoping meeting as purchases and sales, and a developer who has built order management hears purchase orders. The estimate reflects that, and it is wrong by a wide margin.

A deferred or delayed price contract is an obligation with pricing still to come, accruing service charges while it waits. A hedge to arrive contract fixes the futures and leaves basis open, and it rolls. A basis contract does the reverse. A minimum price contract embeds an option. Each behaves differently in the position, in the accounting and in the risk report, and each carries rules about when and how a producer may price. Most firms also run one or two variants invented to win a specific piece of business, and those never appear in any documentation.

The fix is to write the contract catalogue down before anyone estimates. List every structure you actually use, including the local variants, and for each one state what is priced, what is unpriced, which futures month it attaches to, whether it rolls and what the producer is permitted to do. Then ask the developer to model a hedge to arrive contract and a basis contract on a whiteboard. If they cannot explain the difference back to you, they will build a purchase order system with a price field, and you will keep every spreadsheet you have today plus a new login.

What goes wrong when you migrate open contracts, unapplied bushels and hedges?

Closed history migrates easily and nobody needs it urgently. The difficulty is the open book, and the open book is what you trade against on day one.

Open deferred price contracts carry unapplied bushels that in most firms live in a side file precisely because the main system could not hold them. Those bushels have a history: partial pricings, rolls, service charges accrued at a rate that may have changed mid season. Hedges carry rolls that were recorded as new positions rather than as linked events, so the lineage of a hedge across three futures months exists only in the assistant's memory of what she did. Scale tickets applied against contracts may have been corrected days later by adjustment rather than by a clean event.

The fix is a reconciled opening position, signed off, before any cutover date is promised. Agree a cut date, freeze the old book, and prove that the new system's position matches the old one bushel for bushel and lot for lot by commodity and by futures month, then prove it against the broker's statement as well. Do not migrate the side spreadsheets as data. Re-enter the open items as proper contract events with their real history, because importing an unapplied bushel as a balance carries the original problem into the new system on day one.

Why do the broker, market data and scale house feeds break after launch?

Three feeds carry a merchandising system and none of them is a web integration in the usual sense. Broker fills and statements come first. Formats differ by broker and change without notice, and the failure is silent: an unmatched fill or a missed roll sits unnoticed while your position quietly disagrees with the broker's, sometimes for weeks if reconciliation is monthly.

Market data is second, and its problems are commercial as much as technical. Licensing terms govern who may see a quote and where it may be redistributed, and a producer portal showing live futures is a different licence from an internal screen. Firms discover this after the portal is built.

Scale house and probe integration is third, and it is industrial work rather than web work. Serial connections, indicator firmware, a moisture tester that a technician replaced with a different model, and a scale operator who needs the ticket printed in under a few seconds with trucks queued behind.

The fix is exception queues rather than success paths. Import fills and statements daily, match them automatically to intended hedges, and put anything unmatched on a list somebody works each morning. Settle market data licensing before the portal is designed, not after. And treat scale house work as its own phase with time on site, because a scale integration that fails at a busy elevator at harvest is not a bug report, it is a queue of trucks on the road.

What happens when discount schedules and overrides are not covered?

Discount handling gets deferred because the existing grain accounting system already applies a schedule, and that is genuinely true. What gets deferred with it is the part that costs money: consistency and review.

Moisture, test weight, foreign material, damage and where relevant mycotoxin results all carry discounts, with shrink on top, and the schedule changes by crop year and sometimes mid season. It gets applied at the scale house by a person under time pressure. Where there is no versioned schedule with effective dates and no record of who overrode what and why, three things follow. Locations drift apart, so the same load is graded differently at two of your houses. Overrides become habits that nobody reviews. And no report compares discounts actually collected against what the schedule implies, so the leakage is invisible by design.

The fix is version the schedule, apply it automatically from captured grade data, and require a person and a reason on every override. Then the exception report writes itself: overrides by location and by employee, collected discount against schedule, shrink applied against policy. Firms that put this in usually find one location with a long standing workaround. It is almost never dishonesty. It is a shortcut that became a practice, and it has been costing money for years.

Should you build custom or configure what you already own?

A single location elevator originating from a couple of hundred farms with simple contract types should not build. AGRIS has handled grain accounting, scale tickets, discounts and settlements at elevators for decades, it knows what those objects are, and a bespoke system would be an expensive route to the same place. At the other end, a large international trading house with cross border logistics should look at Eka or Agiblocks rather than reproduce years of work.

Before building anything, find out what your current system can actually do once configured. Discount schedules with effective dates and settlement statement formatting are frequently left at defaults, and fixing that costs days rather than months.

Build when two or more of these are true. Your position is assembled daily from more than two sources. You use contract structures your current system cannot hold, so they live in spreadsheets. You carry positions across more than two commodities or across crop years. You originate from more than roughly 300 farms and settlement quality affects your volume. Or one person is the only reason the position is right, and everybody knows it.

How do hidden costs get into the quote?

Five items move a merchandising quote. Commodity count is first, and specialty or identity preserved grain is not one more commodity, it brings segregation, contract and traceability logic of its own. Market data licensing is second and it is a negotiation as much as an integration, with a cost that recurs. Scale house and probe integration is third and it is field work with travel attached.

Rail and barge logistics is fourth and it is a separate domain with its own vocabulary and its own external systems, which is why a build that quietly includes it is usually a build that has not thought about it. Accounting integration is fifth, because the general ledger has to receive everything without re-keying, and that interface is where quarter end pressure lands.

The fix is to build the position engine first and buy nothing else in phase one. Contracts with a proper pricing state machine, ticket application, hedges and a live marked position by commodity and month is a coherent release that removes the side spreadsheets and delivers the thing the business actually trades on. Logistics, settlement portals and producer facing features are better decisions once the position is provably right.

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

Working systems derive the position from an immutable event ledger. Every ticket application, pricing, roll, fill and executed sale writes an event, and the position is a query rather than a report. That single architectural choice is the difference between a merchandiser seeing his exposure on a phone at the elevator and a merchandiser waiting forty minutes for an assembly job.

Ask a developer specifically what happens when a scale ticket is corrected three days later. In a balance based design that correction is a manual adjustment somebody has to remember, and the audit trail is a note. In an event based design it is a new event that supersedes, the position moves automatically, and the history shows what was believed at each point in time. That question separates people who have built ledgers from people who have built inventory systems, and the answer takes ten seconds to evaluate.

The second marker is that reconciliation is continuous rather than monthly. Broker statements matched daily, unmatched items on a worked queue, rolls recorded as events linked to the original hedge so its life across months is traceable, and margin balances tracked alongside because working capital is the constraint that actually binds in a fast market. If your firm applies hedge accounting for financial reporting, contemporaneous records make the documentation considerably easier to produce, though the treatment itself is your auditor's determination rather than a software decision.

The third is the settlement statement, because it is one of the few documents a producer reads carefully. If it computes continuously from the same events the position uses, it is available the moment bushels are priced rather than after a batch run, and it either wins you volume next year or it does not. Settle code and infrastructure ownership before kickoff, with export in an open format available at any time, because in this business a week of waiting on somebody else's release schedule is a trading loss rather than an inconvenience.