Oilseed Crush Plant Software Problems: The 5 That Hide Where the Margin Actually Went

Why does the scope of a crush plant build get set too small so often?

The project is nearly always sold on the crush margin dashboard, because that is the number everyone wants and it demos in five minutes. So the scope becomes a reporting layer over whatever data already exists, and the plant gets a confident daily figure computed from receiving weights nobody has adjusted and yields nobody has reconciled. That is worse than having no margin number, because people act on it. Runs get pushed, purchases get timed, and the decisions are being made against arithmetic with a known defect.

The reason this happens in crush specifically is that the profit calculation is trivial to describe and hard to source. Beans in, meal and oil and hulls out, adjusted for what the hedge did. Every plant manager can recite it. The components live in a scale and grain accounting system, a control historian, a shift log, contracts, and a workbook held by the commercial team, each with a different close cycle. A dashboard joins those five sources and inherits every weakness in all of them.

The fix is a sequencing rule you should write into the contract: do not build margin reporting before receiving and yield data are clean. Release one is receiving with grading, shrink and discount automation, adjusted inventory, and a daily mass balance. The margin view comes after that, when the inputs can be defended. Plants that invert this order usually end up with a dashboard nobody trusts and a spreadsheet running beside it, which is the exact position they paid to leave.

What goes wrong when grading, shrink and discount rules get encoded?

Beans arrive by truck or rail and are graded on moisture, foreign material, damage and splits, with a shrink and discount schedule converting 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. Encoding it looks like a table exercise and is not.

The first trap is that the schedule in the file and the schedule in practice differ. Somebody has been applying a courtesy on a particular grower, or rounding a moisture band a certain way, and it has been running for years. Import the documented schedule and settlements shift for a set of suppliers who will notice immediately.

The second trap is the one named above: keeping delivered weight as the quantity that feeds inventory and yield rather than the adjusted quantity. Everything downstream inherits it, so extraction efficiency, meal protein economics and crush margin are all computed against a tonnage you did not buy.

The fix is to capture grading at the scale, apply the schedule automatically to produce the settlement, and make the adjusted quantity the number that feeds everything else. Then run the new schedule against three months of historical loads before go live and review every settlement differing from what was paid. Each difference is either an error you have been carrying or an undocumented practice needing a deliberate decision. Exceptions should stay visible afterwards rather than being silently absorbed.

Why do historian and control system integrations break after launch?

The mass balance depends on process and tank data, which means pulling from a historian and an automation layer that were installed for control rather than for accounting. The failure is rarely the connection. It is the meaning of the tags.

Tank levels are calibrated for operations and may not be trustworthy as inventory. A meter reads flow that includes a recycle stream. A tag was renamed during a project three years ago and the old name still exists with stale values. A shift log entry that the balance depends on is entered by hand and is sometimes entered at the end of the week. None of this is visible in a tag list, and all of it produces a balance that fails to close in a way that looks like process loss.

The second breakage is scheduled maintenance. A control system upgrade changes tag naming or scan rates, the interface keeps returning values, and the balance quietly drifts. Because the mass balance never closes perfectly anyway, drift hides inside the normal noise.

The fix starts before the estimate: get the historian data path assessed in the first two weeks rather than assuming a clean interface exists, because on older control systems it is the largest schedule risk in the project. Then build the balance to separate measurement variance from real loss rather than reporting one unexplained figure, and hold a per tag reference with its source, calibration basis and owner. Any developer who assumes the balance will close has not worked in a plant.

What happens when sustainability documentation is not covered?

Oil going into renewable diesel and biodiesel carries documentation obligations that oil going to 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 any software vendor.

What does not change is that the evidence must be attached to physical movements and captured at the time. Origin data cannot be retrofitted to loads received last quarter, and plants discover this the first time a renewable buyer sends a document request and the honest answer requires calling farmers. A build scoped without this leaves the plant able to produce the oil and unable to sell it into the market it built for.

The fix is to capture origin and any supplier declaration or certification at receiving, in release one, even if the sustainability reporting itself lands later. Carry it through the mass balance under the chain of custody model your certification requires, generate the evidence pack per shipment, and put expiry management on the declarations so the system warns three weeks before one lapses rather than after a load has been received against it. Running more than one certification scheme at once is a genuine cost multiplier, because each has its own chain of custody rules, so scope that explicitly rather than assuming one implementation covers all of them.

Should you build custom or configure what you already own?

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, do not build. The arithmetic fits in a spreadsheet and the discipline you need is bookkeeping. If your commercial system already produces a reliable daily position and the only gap is plant yield, that is a narrower and cheaper project than a platform.

Be specific about why the packaged options fall short rather than dismissing them. Packaged process manufacturing systems model recipes and work orders competently, and if you have one, configure its production module before building anything. Where it stops is that it does not produce a daily crush margin from adjusted receipts and does not carry feedstock origin documentation. Your grain accounting and scale system genuinely owns receiving, shrink and settlement, and rebuilding that is usually waste, so integrate it and let it stay the record for loads. The same applies to contract management if your commercial system handles it well.

The build case is the join. You are crushing continuously with a hedge position against physical, selling into renewable fuel buyers with documentation obligations, and your monthly close regularly produces surprises nobody can explain. The clearest single symptom is that your plant manager and your commercial lead routinely disagree about the numbers, which is expensive in ways that never appear on a report.

How do hidden costs get into the quote?

A first release covering receiving with shrink and discount automation, adjusted inventory, a 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 quality certificates, position reporting, sustainability documentation and rail management runs $200,000 to $500,000 across 8 to 14 months. Four things move the number and none of them are surprises if anyone asks.

Multiple plants is the first, and it is not linear, because grading practice and discount schedules differ between sites more than owners expect. Multiple certification schemes running simultaneously is the second, since each carries its own chain of custody rules. Rail and barge logistics is the third and deserves to be scoped as its own workstream rather than assumed: rail brings car management, placement and release timing, and demurrage exposure that accrues quietly. Integration with a legacy control system that has no clean data path is the fourth, and it is the one most often discovered after signing.

The way to hold the estimate is to make it name your historian product, your scale and grain accounting system, your certification schemes and whether release one includes rail. A quote that says process integration without naming the control system is a quote that will move.

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

Order of work, first. Receiving, then adjusted inventory, then mass balance, then margin, then position and certification. Every plant that has tried to start at the top has ended up rebuilding from the bottom anyway, at full price.

Second, an explicit boundary around the hedge. The right scope is reporting and reconciliation: physical inventory and open contracts by commodity and delivery period, with the hedge position brought in from your broker or trading system, so net exposure is one picture built from one set of source data. That is what stops commercial and plant arguing from different numbers. Any developer offering to automate trading decisions should be declined, and the boundary belongs in the written scope rather than in a conversation.

Third, treat the mass balance not closing as the normal condition. The design that works separates measurement variance from unexplained loss and categorises losses rather than reporting one plug, because the categorisation is what turns a drift in extraction into a conversation on Wednesday instead of a discovery in next month's board pack.

Finally, settle 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 margin and position numbers your commercial decisions run on, needing a supplier's permission to change a calculation is a dependency no plant should accept.