Anaerobic Digester Management Software: Feedstock Records, Gas Accounting, and Evidence a Verifier Will Accept

The question that decides your revenue: how do you know that number

A verifier sits down with your annual submission and points at a figure for feedstock received. The question is not whether the number is plausible. It is how you know it, what measurement produced it, who recorded it, and whether the record was made at the time or reconstructed later. If the honest answer involves a hauler's estimate written on a clipboard and a monthly total typed into a workbook, you have a problem, and the problem is attached to the revenue line the project was financed against.

This is the structural tension in digester projects. The revenue model is sophisticated: environmental credits earned against verified feedstock, gas production, and pathway data, sold into programmes with real oversight. The physical operation is agricultural. Manure comes from a pit at a dairy, substrate arrives on a truck from a food plant with a delivery note that says approximately, and the people doing the work have a hundred other jobs. Farms do not naturally produce audit grade records, because nothing in farming ever asked them to.

The gap between those two worlds is where projects lose money, and it is almost entirely a data capture problem. Nobody is trying to misreport anything. The records just were not built to be evidence.

Problem one: feedstock intake is measured badly or not at all

At a dairy digester, manure moves by pump and flume rather than across a weighbridge, so quantities come from flow meters, pump run times, or estimates based on herd numbers. Imported substrate arrives by truck, sometimes weighed at origin, sometimes weighed at a scale several miles away, sometimes not weighed at all. Solids content varies enormously and is what actually drives gas yield, yet it is often measured occasionally rather than per load.

What that produces is a feedstock record that is a mixture of instrument readings, timed estimates, and paperwork from third parties, with no consistent basis. When a verifier asks for the population of intake records for the year, the answer is assembled rather than retrieved.

A build starts here, and it starts with a decision about what your measurement basis actually is per feedstock stream, documented, then enforced. Every intake becomes a record with a source, a supplier, a measurement method, a quantity, a solids or quality figure where you take one, and a timestamp, captured at the point of delivery on a phone or tablet by the hauler or operator, with photographs of tickets where the origin scale is the source of truth. It is not glamorous work. It is the difference between a verification that runs smoothly and one that does not.

Problem two: substrate typing changes both the economics and the pathway

Codigestion changes everything. Adding food waste, fats, oils and greases, or processing residues raises gas yield and brings tipping fee revenue, and it also changes the composition of what you are claiming, the digestate you have to manage, and potentially the pathway your credits are generated under. Programme rules differ and they change, so the specifics belong with your verifier and your compliance adviser rather than a blog post.

Operationally the requirement is clear enough. Every load needs a material type from a controlled list, a supplier, and where relevant a declaration or analysis, and the system needs to know which combinations are acceptable under your current pathway approval. Then an operator receiving an unfamiliar substrate at seven in the evening is stopped by a rule rather than by their own recollection of a conversation from March.

The same records support the commercial side. Tipping fees vary by material and supplier, gas yield differs by substrate, and the question of whether a particular waste stream is worth accepting is answerable only if intake, gas, and revenue are joined. Most projects have a strong opinion about this and thin evidence.

Problem three: gas accounting has more paths than anyone models

Raw biogas is produced, some is used in parasitic load, some is flared, the rest goes through upgrading with its own losses and its own utility consumption, and the product is injected into a pipeline or dispensed. Each of those flows has a meter, and the meters do not agree, because meters never do. Injection metering is typically the utility's and is authoritative for what you are paid, while your own meters describe what happened inside the fence.

Projects that reconcile these monthly by hand end up with a set of numbers that mostly hang together and an unexplained residual that grows. Since credit generation depends on gas quantity and quality, that residual is not a curiosity, it is exposure.

A build ingests meter data automatically wherever the instrumentation allows, defines a gas balance with named paths including flare and parasitic use, computes it daily, and flags divergence beyond a threshold you set. Flare time in particular is worth surfacing: a flare running more than it should is both lost revenue and a question you would rather answer proactively than in a verification.

Problem four: cluster projects have supplier economics nobody automated

Many projects gather manure from several farms into one digester, or run satellite digesters feeding a central upgrading facility. In those structures the farms are suppliers with a revenue share, and the share is usually a formula involving delivered volume, solids, and sometimes the credit price realised in the period.

That calculation gets done in a workbook by whoever built it, from records that are already approximate, and the farms have no visibility into it. Suspicion follows, because a farmer receiving a payment they cannot verify assumes the worst eventually. Cluster projects live or die on farmer relationships, so this is not a back office matter.

A build calculates the share from the same intake records that feed the credit claim, and gives each farm a portal showing their deliveries, quantities, quality, and the resulting payment with the arithmetic exposed. It removes an argument and it makes the project easier to expand, because the next farm can see how the existing ones are treated.

Problem five: verification is an evidence exercise and evidence has to be contemporaneous

Annual verification by an accredited third party is a normal part of these programmes. The verifier samples records and traces them to source. What makes verification expensive is not the sampling, it is the time spent waiting while somebody finds the underlying document, or discovers it does not exist and constructs an explanation instead.

The design goal is straightforward: every reported figure should be one click from its evidence, and the evidence should have been captured when the event happened. That means intake records with photographs and timestamps, meter data with its raw source retained, calibration certificates for the instruments you rely on, utility invoices attached to the periods they cover, and an immutable audit trail on every change so a correction is visible as a correction rather than as a quietly different number.

Projects that work this way describe verification as a scheduled week of work. Projects that do not describe it as the worst month of their year, every year, and they pay verifier hours for the privilege.

What a digester platform must include

The spine: feedstock intake by supplier with measurement method and quality, digester feeding records, gas production and balance across all paths, upgrading and injection with utility metering, credit generation inputs, and an evidence store organised by reporting period. Around it: supplier revenue share calculation, a farm and hauler portal, digestate and nutrient management records because that material has to go somewhere and it has its own rules, maintenance and downtime, and the reporting cadence each programme requires.

Integrations that matter: your control and SCADA system for meter and process data, the utility interconnect data where you can get it, weighbridge or origin scale documents, and accounting. Mobile capture for haulers is not optional, because the intake record has to be created at the delivery, not typed later from a pile of tickets.

Cost, timeline, and what moves the number

A first release covering feedstock intake with mobile capture and controlled material types, gas balance from meter data, and the evidence store runs $65,000 to $140,000 over 12 to 16 weeks. A full platform adding supplier revenue share and portal, credit reporting packs, digestate management, maintenance, and multi site consolidation runs $160,000 to $400,000 across 6 to 12 months.

What increases the cost: portfolios with several sites reporting under different programmes, satellite digester structures with gas transported between locations, and control systems that expose no clean data path so meter capture becomes an engineering exercise. What reduces it: one site, one programme, manual meter entry in release one with automation scoped after the data model is settled.

When not to build

Do not build if you run a single on farm digester using the gas in a genset 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. Do not build if a developer partner already provides an operating platform that produces your verification evidence cleanly, because duplicating it is waste.

Build when credit revenue is the majority of project income, when feedstock comes from multiple farms or haulers with different measurement bases, when supplier revenue share is calculated in a workbook that 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 the second and third sites will otherwise each invent their own conventions and consolidation becomes its own project.

How to choose a developer for digester software

Ask them how an intake record gets created when a hauler arrives at nine at night in the rain with no signal. If the answer is a web form, they have not built for this environment. What you want is offline capable mobile capture with photographs, queued sync, and a record that cannot be silently edited afterwards.

Ask how they handle meter reconciliation when meters disagree, because they will. The answer should involve named gas paths, a daily balance, a tolerance, and an exception workflow, not an assumption that the numbers will match.

Ask what they have integrated on the control side, by system name. Then be explicit about the compliance boundary: they build capture, calculation, and evidence, while your verifier and compliance adviser own the rules, and the calculations must be configurable because programmes change.

Finally, agree code ownership before kickoff: repository, cloud accounts, and the right to bring in another firm. At Digital Heroes the client owns the code from the first commit. When the software holds the evidence behind a credit revenue stream that a lender underwrote, nobody outside your organisation should control access to it.