How to Automate Ceres

The scale ticket is where a grain business actually starts

A truck pulls onto the scale, the load is probed, and a ticket is written. Gross, tare, net, moisture, test weight, damage, the producer and the contract it applies to. Nearly everything a grain facility does for the rest of the year is built on that one record.

Ceres is where it goes. Vertical Software has been writing grain software since 1983, when a manager at a river elevator in Pekin, Illinois wanted a better way to account for grain, and the company runs out of Peoria now as part of Valstone. Ceres is the web-based platform: scale ticketing, contract data, inventory and reporting centralised in one system, with ScaleTrac and GrainTrac alongside it and unattended ticketing through RFID and self-service kiosks.

It is used by grain elevators, feedmills, ethanol plants, farms and co-ops, and by the merchandisers who cannot trade a position until they know it. Those are different businesses running the same chain: a ticket becomes an inventory figure, the inventory applies to a contract, and the contract becomes a settlement and a payment.

The bids that set the day are posted somewhere else

The facility owns its own numbers. It does not own the prices that decide what to do with them.

Bids are posted by the processors, terminals and ethanol plants you actually ship to, each on its own site, each first thing in the morning. Somebody opens four or five tabs and copies the numbers down. Futures and basis move all day on another screen again.

The physical side has the same shape. A rail car's status sits on the railroad's site, and whether cars got placed decides whether a contract ships this week. Truck freight is quoted on carriers' pages. The buyer's portal holds delivery appointments and, later, the grade and discounts they actually settled on, in a layout that will not match yours. Whatever licence or bond the facility holds has its status on a state site nobody thinks about until renewal. Each one is a login, and together they are somebody's whole morning.

Ceres

Bids beside the position This morning's posted bids at the destinations you actually ship to, dropped in next to the open position and the bushels still unpriced.

Rail and delivery status checked daily Car placement read off the railroad's site and delivery appointments off the buyer's portal, against the contracts waiting on both.

Settlements checked against your own ticket The grade, shrink and discounts a buyer actually paid on, read from their portal and compared with the scale ticket you wrote.

Ceres balances the bushels that crossed your own scale

The accounting side is genuinely strong, and an elevator still running two systems should know how much of this is already covered.

Weights are captured at the scale with shrink and moisture applied automatically, so a ticket lands correct instead of corrected. Scale ticket sync carries it into accounting, and tickets turn into settlements, storage charges and EFT-ready invoices without anyone re-keying. Grain contract management tracks a contract down to the last bushel, applying deliveries as they happen. The real-time DPR builds the daily position report by linking contract data, tickets and inventory, so the position is a live figure rather than a spreadsheet somebody updates at four o'clock. Multi-site and multi-user access lets several locations report into the same position.

That is a closed loop, and it closes without a number being typed twice. But look at the boundary. Every figure in it came off your own scale or out of your own contract file. The DPR is exact about what you own and silent about what it is worth this morning. Ceres has no way to open a processor's bid page, no way to check whether the railroad placed the cars, and no way to read what a buyer's portal says about next week's appointments.

A position report with this morning's bids beside it

The position report is built from the inside out. The prices that decide what to do with it are not, and that gap is the whole opportunity.

Say the bid pages of the destinations you actually ship to are read at six each morning and dropped in alongside the DPR, so the open position, the bushels still unpriced and today's best net bid to each destination sit on one page before the phone starts ringing. The merchandiser spends the morning deciding rather than collecting.

The same reading pays off further down the chain. Each producer's open contract balance set against the bid they could price into today, so the call you make is the one worth making. Rail car status read off the railroad's site against the contracts waiting on placement, so a shipment slipping is known on Monday and not Thursday. The buyer's portal read for delivery appointments and then, when settlement posts, for the grade and discounts they paid on, checked line by line against the ticket you wrote.

The reading is finished before the first truck arrives

The work in all of that is not analysis. It is signing in to six websites at six in the morning, every morning, in harvest.

WebRun does that part. It drives a real browser, signed in as you, on the schedule you set: the bid pages, the railroad, the buyer's portal, the state site. What it finds arrives as a sheet, a message, or a page waiting next to the position report.

Reading runs unattended. Anything that prices grain, applies a delivery, settles a contract or sends a producer a statement is drafted and held for a person to release. Those move money and they are hard to unwind, so a human makes the call. The cards below are the jobs grain facilities usually start with.