Ethanol Plant Software Problems: The 6 That Cost Real Money, and How to Avoid Them

Why do period boundaries get decided last instead of first?

Because they look like a detail. Everybody in the kickoff wants to talk about screens, dashboards and the grain receiving workflow, and the question of exactly when a month ends for production, for inventory, for shipments and for utility consumption sounds like something the accountants will settle later.

They will not settle it, because there is no single obvious answer. The control system cuts at midnight plant time. The scale house closes when the last truck leaves. Rail movements are documented when the bill of lading is signed, which may be the following morning. The utility invoice covers a billing period that does not align with your month at all. Left alone, four subsystems each choose their own boundary, and the reconciliation never closes. Every month then opens with someone hunting a difference that was created by design.

Fix it in week one of discovery, in writing. One defined instant per period, applied to production volumes, tank and inventory movements, shipments and utility readings, with a documented rule for anything that straddles it. Where a source cannot be cut at that instant, such as a monthly utility invoice, define the allocation method once and record it against the period rather than letting an analyst decide each month. This single decision is the difference between a close that ends on time and a close that starts with a hunt.

What goes wrong when you migrate grain receipts, shrink schedules and historic production?

The receiving history looks like the easy part of the migration and it is where the compliance layer gets undermined.

Delivered weight is not settled weight. The shrink schedule converts one to the other using moisture and quality discounts, and the version of that schedule in force changes over time, sometimes by contract and sometimes by season. Migrations that load settled weights without the schedule that produced them destroy the ability to explain a settlement, and migrations that load the current schedule and recalculate history rewrite settlements your producers already agreed. Both are wrong, and the second one is worse because it looks tidy.

The same problem appears in production. Yield per bushel is the number the plant is judged on and the number that feeds carbon intensity, and it is only as good as the dry matter adjustment underneath it. If historic yield is loaded as a computed figure rather than as its inputs, you cannot defend it when a verifier traces it back.

Migrate the inputs and the rule version, not the answer. Every receipt carries its grade results, the shrink schedule version applied and the settlement it produced. Every production period carries meter and tank movements rather than a summary. Then a number questioned two years later resolves in minutes instead of becoming an archaeology project across a folder of workbooks.

Why do control system, lab and marketer integrations break after launch?

Three different failure modes, usually estimated as one line.

The historian is the first. Whether you run an AVEVA PI System, Rockwell FactoryTalk Historian or an older package with no clean interface at all, the data you need is time series and the data you are reporting is periodic, so somebody has to define the aggregation. Tag names change during a turnaround. A meter is replaced and the new tag has a different unit. If the integration does not validate what arrives, a scaling error propagates into production volumes and therefore into credit generation before anyone notices.

The laboratory is the second, and it usually breaks on people rather than code. Results entered late, corrected after the period closed, or entered against the wrong batch, all of which are fine until the number is load bearing.

The marketer portal is the third. Ethanol and coproduct sales confirmations arrive in whatever format the marketer sends, and formats change with no notice to you.

Validate every inbound feed against an expected range and raise an exception rather than accepting a value. Reconcile daily rather than monthly, so a tag change surfaces the next morning. And keep the historian as the source it is good at being, which is process data, while the compliance record lives in a system designed to be audited. A historian is not a records system and was never sold as one.

What happens when transfer documents and carbon intensity evidence are not covered?

These are the two gaps that turn a records project into an enforcement problem.

Product transfer documents must accompany shipments and carry specific information under the federal Renewable Fuel Standard. In practice they come from a template inside whatever system produces the bill of lading, and compliance checks samples rather than the whole population. That coping strategy fails silently: a template edited for one customer, a manual shipment created outside the normal path, rail documented differently from truck, and now some fraction of your shipments carry documents that do not say what they need to say. You find out during an attest engagement or when a counterparty queries it.

Carbon intensity is the second. State low carbon fuel programmes require quarterly reporting and annual verification by an accredited third party, and verification is an evidence exercise rather than a summary exercise. Plants that assemble the evidence once a year from folders and workbooks spend weeks on it and pay for verifier time spent waiting.

Generate every transfer document from one controlled template driven by transaction data, record exactly what was issued against each shipment, and block shipment completion without it. For carbon intensity, capture utility consumption at the same period boundaries as production, attach invoices as they arrive, and assemble the verification pack on demand with links back to source. Plants that do this describe verification as an ordinary week rather than a crisis. Your compliance counsel and your accredited verifier remain the authority on what the rules require.

Should you build custom or configure what you already own?

Do not build if you are already inside a comprehensive commercial platform that produces your reporting cleanly, passes attestation without drama, and gives your compliance lead a month end that ends on time. Replacing something that works is a bad trade at any price.

Do not rebuild the parts that are genuinely solved either. If your grain accounting package handles receiving, grading, settlement and producer contracts properly, and AGRIS from Cultura Technologies is a long established example that does, configure it and build only the layer above it. The same applies to the historian: AVEVA PI System and Rockwell FactoryTalk Historian are the right tools for process data and there is no version of this project where rebuilding one of them is sensible. What neither category does is model RIN generation with traceable inputs, control transfer documents across every shipment, or assemble a verification pack, because that is not what they were built for.

Build when the monthly close takes a person several days, when your verification evidence is assembled annually from folders, when you have filed a correction that traced back to a spreadsheet, or when one person is the only one who fully understands the RIN workbook. That last one is a single point of failure attached to a revenue stream.

How do hidden costs get into the quote?

• Credit programmes counted as one. Each programme has its own data model, cadence and evidence expectations. The second one is not a configuration change, it is a parallel dataset with its own reporting.
• Historian access assumed. If your control system is older and has no clean interface, extracting reliable time series is a project of its own, and it is discovered in week three rather than priced in week zero.
• Multiple plants under one reporting entity. Consolidated reporting with per plant boundaries and per plant pathways is meaningfully more than one plant twice.
• Carbon capture claims. These add measurement points, evidence requirements and a verification scope that did not exist in the original estimate.
• Parallel close periods left out. You will run the new system alongside the existing workbooks for at least two months and compare line by line. That comparison is where the undocumented conventions surface, and it is real cost rather than overhead.

The honest bands from Digital Heroes delivery experience: $90,000 to $180,000 over 14 to 20 weeks for a first release covering receiving with shrink, production and inventory on defined boundaries, credit generation with traceable inputs and transfer document control, and $220,000 to $550,000 over 8 to 14 months for a full platform.

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

Ask how they will define period boundaries, and listen for whether they already knew it mattered. A developer who has built a regulated production system raises it before you do. One who has not will discover it during the first close, which is the worst possible moment.

Ask what they will do with your control system by name, and whether they have pulled historian data before. Then ask how they handle a tag that changes during a turnaround, because that is the question that separates experience from a diagram.

Ask how transfer documents are generated and whether the system can prove what was issued for every shipment rather than a sample. If the answer is a report, they have not understood the exposure.

Be explicit about the boundary of their role. They build the system that captures, calculates and evidences. Your compliance counsel and your verifier define the rules it implements. Any developer positioning themselves as the compliance authority is overreaching, and because programme requirements change, calculation logic must be configurable rather than hard coded.

Then settle code ownership in writing before kickoff: repository, cloud accounts and the right to hire anyone else. At Digital Heroes the client owns the code from the first commit. When a system produces the records behind a regulated revenue stream, being unable to audit or modify it because a supplier holds the keys is a governance failure waiting to be found.