Anaerobic Digester Management Software Problems: The 7 That Cost Projects Real Money

Why does feedstock measurement basis get skipped in scope?

Projects get scoped as build an intake log, which assumes the hard question is already answered. It is not. At a dairy, manure moves by pump and flume rather than across a weighbridge, so quantity comes from flow meters, pump run times or estimates based on herd numbers. Imported substrate arrives by truck, sometimes weighed at origin, sometimes at a scale several miles away, sometimes not weighed at all. Solids content varies enormously and drives gas yield, yet it is often sampled occasionally rather than per load.

Nobody has written down what the measurement basis actually is per feedstock stream. So the software gets built with a quantity field, and the field quietly accepts numbers of four different provenances that are then summed as if they were the same kind of fact.

The consequence appears at verification, when the population of intake records for the year turns out to be a mixture of instrument readings, timed estimates and third party paperwork with no consistent basis, and the verifier starts sampling.

The fix is to decide and document the basis per stream before any build, then enforce it. Every intake record carries a source, a supplier, a measurement method, a quantity, a quality or solids figure where you take one, and a timestamp. The method is part of the record, not an assumption about it. That single design decision is what makes the difference between a verification that runs to schedule and one that becomes an investigation.

What goes wrong migrating historical intake and meter records?

Two archives, both messier than expected.

The intake history is usually spreadsheets and delivery tickets. Supplier names are free text with variants. Material descriptions differ between the person who logged them and the contract that governs them. Quantities are recorded in whatever unit was convenient. And a proportion of loads have no ticket at all because the driver arrived after hours.

The meter history is worse in a different way. Historians and control systems hold time series that look complete until you check the periods around a controller replacement or a communications outage, where either data is missing or a default value was written and looks like a real reading. Nobody flagged it at the time because nobody was reading the archive.

The instinct is to import everything and normalise later, which produces a system whose historical totals nobody trusts and whose current totals are then also doubted.

The better approach is a clean start with a bounded history. Load reference data properly, meaning suppliers, contracts, material types and measurement methods, then import history only for the periods within your current reporting and verification window, with anything unresolvable flagged rather than silently converted. Keep older records readable in place. Then run reconciliation on the imported window against whatever you previously reported, and resolve every difference before go live rather than discovering them in front of a verifier.

Why do control system and utility meter integrations break after launch?

The integration usually works on day one because someone configured it while standing next to the panel. It degrades quietly afterwards.

Three failures recur. A tag gets renamed during a control system change and the feed stops populating that path, so the gas balance closes using fewer inputs and the residual grows without anyone noticing. A meter is replaced and the new instrument reports in different units or with a different totaliser rollover behaviour, so a step change appears in the data that looks like a process event. And the utility injection data, which is authoritative for what you get paid, arrives on a portal or a statement rather than through an interface, so it is entered by hand and stops being entered when the person who did it is on leave.

The blunt fix is to monitor for absence rather than for error. Alert when a tag has not produced a value in the expected interval, when a daily total falls outside its normal range, and when the gas balance residual exceeds a tolerance you set deliberately rather than one that drifts.

Keep the raw values as received alongside any derived figure, so a units change or a rollover can be diagnosed rather than argued about. And treat manual entry as a first class path with its own reminders and its own audit trail, because at least one of your critical inputs will be manual for the life of the system.

What happens when contemporaneous evidence capture is not covered?

This is the gap that costs verifier hours. Verification is an evidence exercise: the verifier samples reported figures and traces them to source. What makes it expensive is not the sampling, it is the waiting while somebody finds the underlying document, or discovers it does not exist and builds an explanation instead.

Without evidence capture designed in, the predictable outcomes are these. Intake photographs were never taken, so the origin scale ticket cannot be produced. Calibration certificates for the instruments you rely on are in a filing cabinet and one has lapsed. Utility invoices are filed by month rather than attached to the reporting periods they cover. And a correction made three months ago is invisible, because the number was simply changed, so the record now disagrees with what was reported without saying why.

There is a substrate dimension too. Codigestion changes what you are claiming and can affect your pathway. If material types are free text, an operator receiving an unfamiliar substrate at seven in the evening has nothing stopping them, and the problem is found later by someone reading records.

The fix is that every reported figure is one click from evidence captured when the event happened: intake photographs and timestamps, raw meter data retained, calibration certificates with expiry tracking, utility invoices attached to their periods, and an immutable audit trail so a correction reads as a correction. Material types come from a controlled list with acceptability rules your compliance adviser maintains as configuration, so the rule stops the load rather than a memory of a conversation in March.

Should you build custom or configure what you already own?

Do not build if you run a single on farm digester using the gas in a generator set for the farm's own load with no credit revenue. A meter log and a spreadsheet are proportionate and the money belongs in the plant. That is the honest answer and it applies to a large number of sites.

Configure what you own if you already have a plant historian. Where a time series historian such as the AVEVA PI System is already installed and collecting from your control system, the gas balance and daily reporting can often be produced from it with reporting configuration rather than a new application. That is materially cheaper than a build and it uses infrastructure you are already maintaining. The limit is that a historian is built for process data, not for supplier records, evidence documents or payment calculations, so it takes you part of the way and no further.

Configure also if your operating partner already runs a platform that produces your verification evidence cleanly under an operations and maintenance contract. Duplicating that is waste, and the better conversation is about your access to the data and what happens to it if the contract ends.

Build when credit revenue is the majority of project income, when feedstock comes from multiple farms or haulers on different measurement bases, when supplier revenue share is calculated in a workbook the farms cannot see, or when your last verification took more than two weeks of internal effort. If you are developing a portfolio rather than a single site, build early, because each site will otherwise invent its own conventions.

How do hidden costs get into the quote?

Control system data access is the first and largest surprise. Where the system exposes no clean data path, meter capture becomes an engineering exercise involving the control vendor, and that is a different budget from application development. Establish what is actually available before anyone quotes a fixed price.

Programme variation is the second. A portfolio reporting under several programmes is not one system with a flag. Each programme has its own data model, its own cadence and its own evidence expectations.

Offline mobile capture is the third. Deliveries happen at night, in weather, at rural sites with unreliable connectivity, and building for local storage, photographs, queued sync and tamper evidence is meaningfully more work than a web form. It is also not optional, because a record that failed to save becomes an estimate typed in later.

Digestate and nutrient management is the fourth, and it is frequently left out. That material has to go somewhere, it has its own records, and it usually arrives in scope after the first spreading season.

Configurability of the calculations is the fifth. Programmes change, so the calculation rules must be data your compliance adviser can update, and building configurable rules costs more than hard coding today's version.

Ask for those five as named items with days against them, and ask which require your operator's time on site rather than developer time.

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

The ones that work put capture in the field first. If the intake record is not being created at the delivery, on a phone, by the person who took the load, nothing downstream is trustworthy no matter how good the reporting looks. Test that in the rain, at night, with no signal, before you build anything else.

They define the gas balance explicitly, with named paths for raw production, parasitic use, flare, upgrading losses and injection, a daily computation, a deliberate tolerance and an exception workflow when it is exceeded. Flare time gets its own visibility, because a flare running more than it should is both lost revenue and a question you would rather raise yourself.

They keep the compliance boundary honest. The developer builds capture, calculation and evidence. Your verifier and compliance adviser own the rules. Any developer implying they can guarantee a programme outcome is selling something they cannot deliver.

They make farm payments transparent from the same records that feed the claim, with a portal showing each supplier their deliveries, quantities, quality and resulting payment with the arithmetic exposed. Cluster projects live on farmer relationships, and a payment a farmer cannot verify eventually breeds suspicion regardless of how honest the calculation is.

And they settle ownership before kickoff: repository, cloud accounts, and the right to bring in another firm. When the software holds the evidence behind a credit revenue stream a lender underwrote, control sitting outside your organisation is a financing risk as much as an operational one.