Oilseed Crush Plant Software: Getting Yield, Shrink, Hedges, and Crush Margin Into a Single Number

You buy one commodity and sell three, and nothing tells you how you did

The crush plant is one of the few operations where the profit calculation is genuinely simple in concept and almost impossible in practice. Beans in, meal and oil and hulls out, and the difference between what you paid and what you realised, adjusted for what the hedge did, is the whole business. Every plant manager can recite that. Very few can produce the number for last Tuesday without three people and half a day.

The reason is that the components live in different systems with different close cycles. Grain receiving sits in a scale and grain accounting system with its own shrink and discount rules. Process yield sits in the control historian and a shift log. Meal and oil sales sit in contracts, sometimes in a trading system, sometimes in spreadsheets. The hedge position sits with the commercial team in a workbook or a broker statement. Accounting closes monthly, weeks after any of it could have been acted on.

So the plant runs on a monthly number that arrives too late and an instinct in between. Meanwhile the actual crush margin moves daily with bean basis, meal and oil values, and your own yields, and the decisions that respond to it, how hard to run, what to buy, when to price, are being made on the instinct.

Problem one: shrink and discounts are where the first slice of margin disappears

Beans arrive by truck or rail and are graded on moisture, foreign material, damage, and splits, with a shrink and discount schedule applied to convert delivered weight into settled weight and settled value. That schedule is a policy decision with real money in it, and it varies by origination programme, by contract, and sometimes by relationship.

Where this leaks is in the gap between what the scale ticket says, what the discount schedule should produce, and what the accounting entry ends up being. Manual application of a schedule across thousands of loads produces errors in both directions, and nobody audits them because auditing them by hand is worse than the error. There is a second, more subtle leak: the dry matter you actually bought differs from the delivered tonnes, and if your yield calculations use delivered weight rather than adjusted weight, your extraction numbers are wrong in a way that looks like a process problem.

A build applies the schedule automatically from grading results captured at the scale, produces the settlement, keeps the adjusted quantity as the number that feeds inventory and yield, and makes exceptions visible. Boring, and it typically pays for a meaningful share of the project in the first year.

Problem two: yield accounting across the crush has to balance or it means nothing

The mass balance across a crush plant is unforgiving. Adjusted beans in, oil out, meal out, hulls out, with moisture movement through conditioning and drying, solvent losses, and inventory changes in every tank and bin. If it does not close, the difference is either a measurement problem or product you cannot account for, and both matter.

Most plants reconcile monthly and treat the unexplained portion as a plug. That is understandable and it hides the signal. Oil content of incoming beans varies by origin and season, extraction efficiency varies with how the plant is being run, and meal protein specification interacts with how much oil you leave behind. The relationship between those variables is where a plant manager earns their money, and it is only visible if the balance is computed frequently and the losses are categorised rather than lumped.

A build pulls process and tank data from the historian and the automation layer, computes the balance daily against adjusted receipts, and separates measurement variance from real loss. Then a drift in extraction is a conversation on Wednesday rather than a discovery in the following month's board pack.

Problem three: the hedge position and the physical position never look at the same clock

Physical purchases and sales are priced against futures, and the plant carries a position that is supposed to offset the physical exposure. Operationally the problem is not strategy, it is bookkeeping. The commercial team knows the futures position. The plant knows the physical inventory and the open contracts. Nobody has one view showing physical long and short by delivery period alongside the hedge, at the same moment, from the same source data.

Where the two views disagree, it is usually because a contract was amended, a load was rolled to a different month, or unpriced tonnes were counted twice. Those are data problems with financial consequences, and they get found late.

What a build provides is a position report: physical inventory and open contracts by commodity and by delivery period, with the hedge position brought in from the broker or trading system, and the resulting net exposure shown as one picture. This is reporting and reconciliation, not trading advice, and any developer offering to automate trading decisions should be shown the door. The value is that the commercial team and the plant argue from the same numbers.

Problem four: renewable fuel buyers want documentation your plant was never set up to produce

Oil going into renewable diesel and biodiesel carries documentation requirements that vegetable oil going into a food customer never had. Depending on the market and the buyer, that means feedstock origin evidence, sustainability certification such as ISCC, chain of custody through the plant, and data supporting a carbon intensity claim. Requirements differ between the federal renewable fuel programme, state low carbon fuel programmes, and export markets, and they change, so your compliance adviser is the authority rather than a blog post.

What does not change is that the evidence has to be attached to physical movements, and it has to have been captured at the time. Retrofitting origin data to loads that were received last quarter is not possible. Plants discover this the first time a renewable buyer sends a document request and the answer requires calling farmers.

A build handles it by capturing origin and any declaration or certification at receiving, carrying that through the mass balance under the chain of custody model your certification requires, and generating the evidence pack per shipment. It also flags gaps in advance, meaning it tells you a supplier declaration expires in three weeks rather than after a load has been received against it.

Problem five: loadout is where contracts, logistics, and quality collide

Meal and oil go out by truck, rail, and sometimes barge, against contracts with delivery windows, quality specifications, and pricing terms. Rail introduces car management, demurrage, and its own scheduling logic. Quality certificates have to match what was actually loaded, from the actual tank or bin, not from a standard specification.

The failure here is mundane: a load shipped against the wrong contract line, a certificate generated from a template rather than from results, demurrage accrued because nobody was watching cars. Each is small. Together they are a full time person's worth of avoidable work and a steady drip of credits.

What a crush plant platform must include

The spine: receiving with grading, shrink and discounts, adjusted inventory; process runs with yields and mass balance from historian data; product inventory by tank and bin; contracts for purchase and sale; loadout events tied to contract lines with quality certificates; and a daily margin calculation that ties all of it together. That daily margin view is the reason to do the project.

Around it: supplier settlement, origin and sustainability documentation with expiry management, position reporting including the hedge, rail car management if you ship by rail, laboratory results integration, demurrage tracking, and accounting integration. Grain contract management can be its own module and may already exist in your commercial system, in which case integrate rather than rebuild.

Cost, timeline, and what moves the number

A first release covering receiving with shrink and discount automation, adjusted inventory, daily mass balance from process data, and the crush margin calculation runs $80,000 to $160,000 over 12 to 18 weeks. A full platform adding contracts, loadout with certificates, position reporting, sustainability documentation, and rail management runs $200,000 to $500,000 phased across 8 to 14 months.

What increases the cost: multiple plants, rail and barge logistics, multiple certification schemes running simultaneously because each has its own chain of custody rules, and integration with a legacy control system that has no clean data path. What reduces it: one plant, truck only in release one, and treating position reporting as a later phase once the physical data is trustworthy.

One sequencing rule worth stating: do not build margin reporting before the receiving and yield data are clean. A margin number computed from unreliable inputs is worse than no margin number, because people will act on it.

When not to build

Do not build if you run a small mechanical press operation selling meal locally and oil into a spot market, with no hedge position and no renewable fuel customers. Your arithmetic fits in a spreadsheet and the discipline you need is bookkeeping, not software. Do not build if your commercial system already produces a reliable daily position and your only gap is plant yield, because that is a narrower and cheaper project.

Build when you are crushing continuously with a hedge position against physical, when you sell into renewable fuel buyers with documentation obligations, when your monthly close regularly produces surprises nobody can explain, or when your plant manager and your commercial lead routinely disagree about the numbers. That disagreement is the clearest symptom, and it is expensive in ways that never appear on a report.

How to choose a developer for crush plant software

Ask them how they would handle the mass balance not closing, because it will not close. The answer you want distinguishes measurement variance from unexplained loss and treats both as data to investigate rather than a plug to bury. A developer who assumes the balance will close has not worked in a plant.

Ask what they will do about moisture and adjusted weight, specifically. Getting this wrong makes yield look like a process problem when it is an accounting problem, and it is the single most common modelling error in this category.

Ask what they have pulled out of a process historian before, by product name. Ask them explicitly to confirm they are building reporting and reconciliation around your hedge position rather than anything that touches trading decisions, and get that boundary written into the scope.

Then settle code ownership before kickoff: repository, cloud accounts, and the right to hire anyone else to continue the work. At Digital Heroes the client owns the code from the first commit. When the system produces the numbers your commercial decisions run on, you cannot afford to need permission to change it.