Grain Merchandising Software: Knowing Your Real Position Before the Board Opens

Why the position is the only thing you actually sell

It is 4:40pm. The merchandiser wants to know what he is long and short by commodity and by futures month before he decides what to do at the open tomorrow. The answer requires the contract file in the grain accounting system, a spreadsheet of hedges that the assistant updates from the broker's fills, a second spreadsheet where unapplied deferred price bushels are tracked because the main system cannot hold them properly, an inventory number from the scale house that is a day behind, and a judgment call about how much of the wheat in the north bin is committed. Assembling it takes forty minutes and it is right to within about twenty thousand bushels. In a market that moved eighteen cents today, twenty thousand bushels of uncertainty is real money, and the merchandiser makes tomorrow's decision on it anyway because that is the number he has.

The systems in this business are legitimate. AGRIS has run grain accounting at co-ops and elevators for a very long time and knows what a scale ticket, a discount schedule, and a settlement are. Eka is a serious enterprise commodity trading and risk platform. Agiblocks is well built for soft commodity trading houses. The gap is not that these products are bad, it is that their centres of gravity differ from where a mid sized origination and merchandising firm actually lives. The elevator systems are strong on tickets and settlements and thin on hedge analytics and modern integration. The trading platforms are strong on contracts and risk and were not designed around a scale house, a farmer relationship, and a discount schedule that changes with the crop year. So firms end up with one of each and a spreadsheet in the middle, and the spreadsheet is the position.

The cost is specific and it is not theoretical. Positions that are stale by a day produce hedging decisions made against yesterday's exposure. Unapplied bushels that sit in a side file get double counted or missed. Quality discounts applied inconsistently between the scale house and settlement create both margin leakage and farmer disputes. And when the person who maintains the position spreadsheet is on holiday, the firm trades with reduced visibility for a week, which is a risk no board would accept if it were stated out loud.

Problem 1: contract types that no general system can hold

Grain contracts are not simple purchase orders. Deferred price and delayed price bushels sit as an obligation with pricing to come, accruing service charges. Hedge to arrive contracts fix the futures and leave basis open, and they roll. Basis contracts do the reverse. Minimum price contracts embed an option. Each of these behaves differently in the position, in the accounting, and in the risk report, and each has rules about when and how a producer can price.

What a custom build does: model the contract as an object with a pricing state machine rather than a price field. A contract knows what is priced, what is unpriced, which futures month it is attached to, what rolls have occurred, what basis has been established, and what remains open. Every pricing event, roll, and application is an immutable record with a timestamp. That single change removes most of the side spreadsheets in one move, because the reason they exist is that the primary system stores a price where a process belongs.

Problem 2: the position is assembled rather than derived

A correct position is physical inventory, plus purchase contracts by pricing status, minus sale commitments, netted against futures and options, by commodity and by delivery month, with basis separated from flat price. If any of those inputs lives in a different system, the position is an assembly job, and an assembly job happens once a day at best.

What a custom build does: every event that changes exposure writes to one ledger as it happens. A scale ticket applies to a contract at the scale house and the position moves. A fill comes back from the broker and the position moves. A sale is executed and the position moves. Then the position is a query rather than a report, available at any moment, and the merchandiser can see it on his phone at the elevator.

Problem 3: quality discounts are where margin leaks quietly

Moisture, test weight, foreign material, damage, and where relevant mycotoxin results all carry discount schedules, and shrink applies on top. The schedule is set by the firm, changes by crop year and sometimes mid season, and gets applied at the scale house by a person under time pressure with trucks queued behind.

Elevator systems do apply discount schedules and this is a genuine strength of a product like AGRIS. Where firms get hurt is inconsistency across locations, manual overrides that nobody reviews, and the absence of any analysis of what the discounts actually collected versus what the schedule implies. Margin leaks in small increments across thousands of tickets and no report shows it, because the report would have to compare applied discounts against the schedule and against the grade record.

What a custom build does: the schedule is versioned with effective dates, applied automatically from grade data captured at the probe and the scale, and any override is captured with a person and a reason. Then the exception report writes itself: overrides by location and by employee, discount collected versus schedule, and shrink applied versus policy. Firms that put this in place usually find one location with a habit that has been costing money for years, and it is almost never dishonesty, it is a workaround that became a practice.

Problem 4: broker statements, rolls, and margin are reconciled by hand

Fills arrive from the broker, positions roll from one futures month to the next, and margin moves daily. Most mid sized firms reconcile this monthly against a statement, in a spreadsheet, which means an error in a fill or a missed roll can sit unnoticed for weeks while the position report quietly disagrees with the broker's.

What a custom build does: import broker statements and fills, match them automatically to the intended hedges, and produce an exception list for anything unmatched. Rolls are recorded as events linked to the original hedge, so the history of a hedge is traceable through every month it lived in. Margin balances and daily variation are tracked alongside, which matters because working capital is the constraint that actually binds a merchandising business in a fast market. If your firm applies hedge accounting under ASC 815 for financial reporting, the documentation requirements are considerably easier to satisfy when the hedge relationship and its effectiveness testing come from records that were created at the time rather than assembled at quarter end. Confirm the treatment with your auditor, since the accounting policy is theirs to determine and not a software decision.

Problem 5: the farmer settlement is a relationship document, not a receipt

Origination is competitive and the settlement statement is one of the few pieces of paper a producer reads carefully. It carries the bushels, the grade factors, the discounts, the shrink, the price, the service charges on deferred bushels, and any advance or offset. If it is unclear or arrives late, it costs you volume next year, no matter how good your bid was.

What a custom build does: settlement computes continuously from the same events the position uses, so it is available the moment the bushels are priced rather than after a batch run. Producers get a portal showing their contracts, their unpriced bushels, their tickets, their grade factors, and their storage and service charges accruing, which reduces phone calls significantly and, more importantly, makes the firm look like the professional counterparty it is. Electronic pricing requests through the portal, with your rules on cutoffs and limits enforced, remove the ambiguity that comes from a producer calling to price at a level while the market moves during the conversation.

What this costs and how long it takes

Digital Heroes has delivered more than 2,000 projects, and this is the honest shape for grain merchandising. A first release covering contracts with a pricing state machine, ticket application, hedges, and a live marked position by commodity and month runs $95,000 to $190,000 in 14 to 20 weeks. A full platform adding broker reconciliation, discount schedules and grade capture, freight and logistics, storage and service charge accrual, producer settlement and a portal runs $240,000 to $560,000 across 9 to 15 months.

What drives price up specifically here: the number of commodities and whether any of them are specialty or identity preserved, since those bring contract and segregation logic of their own. Market data licensing and integration, which is a commercial as well as a technical item. Scale house and probe integration, which is industrial rather than web work. Rail and barge logistics, which is a separate domain with its own vocabulary and its own systems. Multi location inventory with in transit and consignment positions. And accounting integration, since the general ledger must receive everything without re keying.

What keeps price down: two commodities, one crop year, and building the position engine first, before any of the logistics scope.

Build versus buy, and when buying is right

Do not build if you are a single location elevator originating from a couple of hundred farms with simple contract types. AGRIS or a comparable grain accounting package handles tickets, discounts, and settlements properly and a bespoke system would be an expensive way to arrive at the same place. If you are a large international trading house with complex logistics across borders, Eka or Agiblocks represent years of work you should not attempt to reproduce.

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 everyone knows it.

The tipping point is that in merchandising the software is not an administrative tool, it is the instrument you trade with. A firm whose position is forty minutes old and approximately right is trading with a delay it has chosen to accept. That is a defensible choice at a small scale and an indefensible one once the position is large enough that a day of staleness costs more than the system would.

How to choose a developer for merchandising software

Ask them to explain the difference between a hedge to arrive contract and a basis contract, and to model both. If they cannot, they will build you a purchase order system with a price field and you will keep every spreadsheet you have now.

Ask how the position is computed. The right answer is derived from an immutable event ledger, not maintained as a running balance that a nightly job recalculates. Ask specifically what happens when a ticket is corrected three days later, because in a balance based design that correction is a manual adjustment and in an event based design it is a new event with a clean audit trail.

Ask who owns the code and where the data sits, and settle it before kickoff. Position and contract history is a regulated and commercially sensitive record, and it should live in infrastructure you control with export available in an open format at any time. At Digital Heroes the client owns the code from the first commit, and in a business where a week of downtime is a trading loss, any other arrangement is a risk you are taking for someone else's benefit.