Industrial Pretreatment Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the permit get modelled as a document rather than as data?

Because that is how the programme experiences it. The permit is issued as a signed PDF, filed and mailed to the industrial user, and everyone treats the document as the thing. So the requirement that reaches a developer is document management with a due date, and what gets delivered is a filing cabinet with search.

Inside that PDF, though, are limits per pollutant, per outfall, with units, sample types, averaging periods and effective dates, plus monitoring frequencies and special conditions such as a slug control plan. Then the permit is amended, a categorical standard under Parts 405 through 471 applies to one process line while your local limits apply to another, and the operative limit for a specific sample becomes a question only a coordinator who has been there ten years can answer.

The fix is to model the permit as a set of effective-dated limit rules attached to outfalls and monitoring points, with the PDF stored alongside as the legal instrument rather than the source of truth. Every limit carries its basis, whether local limit, categorical standard or a condition negotiated at renewal, because the first question in any challenge is which authority the number came from. Renewals clone forward with a difference view so the coordinator sees what changed instead of rereading fourteen pages. Hand a developer your three most complicated permits and ask how each limit would be stored and evaluated. If they need to simplify your permits to fit their model, the model is wrong.

What goes wrong with migrating historical results and past determinations?

Two problems, and the second one is uncomfortable. The first is that historic results arrive in shapes that lose meaning. A spreadsheet column headed Cu with a number in it does not say whether that was a daily maximum or a composite feeding a monthly average, which monitoring point it came from, or whether the reported figure was below the detection limit and was entered as zero, as half the detection limit, or as the limit itself. Those three conventions produce three different violation histories from the same laboratory report.

The second is that once you load history into a system that evaluates limits automatically, it will evaluate the past too. Programmes routinely discover historical determinations that were wrong in both directions: violations never recorded, and a user published in the significant noncompliance list on a calculation that does not reproduce. Better to find it during a parallel run than to have a user's consultant find it.

Handle it deliberately. Migrate two years of results with the detection limit convention recorded per laboratory and per period, run the new violation and significant noncompliance evaluation against that history in parallel, and reconcile the output against what your programme actually reported before anyone trusts the new system. Where the results differ, document why, and talk to your approval authority early rather than after publication. Budget this reconciliation as its own task, because it is usually the longest single item in the project.

Why do the laboratory and billing integrations break after launch?

Electronic laboratory deliverables are the first failure. Every laboratory formats them differently, the format changes when the laboratory upgrades its information system, and the import either rejects a file loudly, which is fine, or silently maps a field to the wrong column, which is not. Units are the specific trap: milligrams per litre and micrograms per litre in the same file, or a laboratory that switches reporting units on a subset of parameters and tells nobody. A quiet factor of a thousand turns a violation into a clean result, or the reverse.

Utility billing is the second, and usually the hardest technical piece in the project. Municipal billing systems are old, their interfaces are undocumented, and the vendor may only support a scheduled file drop. That is workable, but it has to be confirmed with the billing vendor before the estimate is written.

The fixes are unglamorous. Validate every imported result against expected units and an expected range for that parameter and that user, and route anything outside it to a review queue rather than straight into the compliance record. Keep the raw deliverable file attached to the sampling event so a disputed number traces to what the laboratory actually sent. For billing, agree the interface and a test file with the billing vendor during scoping, and build the charge list as a reviewable artefact a person releases.

What happens when significant noncompliance and enforcement are left to a coordinator?

They stay correct until the coordinator is on leave, and then they are not. The significant noncompliance criteria in 40 CFR Part 403 are defined arithmetic, not judgement: a chronic violation when 66 percent or more of measurements in a six month period exceed a limit, and a technical review criteria violation when 33 percent or more exceed the limit multiplied by 1.4 for most pollutants and 1.2 for pH and oil and grease. Computing that in a spreadsheet once a year has two failure modes, and both are expensive. Publishing a user who should not have been published is a legal problem. Omitting one who should have been is an audit finding.

Enforcement has a parallel gap. Your response plan was adopted by your own board and sets out notice of violation, then administrative order, then penalties, with escalation for repeat offenders. The audit question is whether you followed it consistently, because inconsistent enforcement is both a finding and a defence a user will raise later.

The fix is to evaluate every result against the operative limit at the moment it is imported, and to maintain the significant noncompliance evaluation on a rolling basis rather than annually. A coordinator then sees a user approaching the chronic threshold in month four, while there is still time to work with them. Encode the escalation ladder so a violation proposes the response your own plan requires with the deadline attached, and generates the notice with the actual results and limits merged in. Crucially, allow deviations, because judgement is part of the job, but record them with a reason. A system that only permits the rule-following path gets worked around, and the record becomes fiction.

Should you build custom or configure what you already own?

Configure, if your programme is small. With a dozen or two industrial users, a stable list and straightforward local limits, Linko or SwiftComply will handle it, cost far less than a build, and free your coordinator to do inspections instead of data entry. That is the right answer for a large share of publicly owned treatment works. Aquatic Informatics is the sensible choice where the water data side is the bigger problem.

The build case starts when two or more of these are true. You permit more than roughly 60 significant industrial users. You have satellite communities whose industrial users discharge into your system, which layers the permitting relationships and effectively doubles the model. Your surcharge programme is a meaningful revenue line and the calculation lives in a spreadsheet. Your last programme audit produced findings on recordkeeping or enforcement consistency. Or determining the operative limit for a sample requires institutional knowledge rather than a lookup. The packaged products handle the common shape of a programme well. What is genuinely local is your headworks-derived limits, your board-adopted response plan, your ordinance surcharge formula and a billing system somebody bought in 2011.

How do hidden costs get into the quote?

Four places, in our delivery experience. Categorical standards are the first: each one your users fall under has its own structure, and a quote that treats categorical users as a single line has not counted them. Combined waste stream formula users are the second, and they are genuinely intricate rather than merely fiddly. Ask whether any of your users need it before the estimate is fixed.

Utility billing integration is the third and the item most likely to eat the schedule. Multiple laboratories with different electronic deliverable formats is the fourth, and it scales per format rather than per laboratory.

Satellite programmes deserve their own mention because they are a second permitting model rather than a discount on scope. If you receive flows from other municipalities with their own industrial users, say so in the first conversation.

What keeps the number down is sequencing. Start with permits, sampling and violation evaluation for significant industrial users only, and let non-significant users, fats oils and grease, and hauled waste wait for a second phase.

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

The builds that work do all of the arithmetic and none of the judgement, and they record both. Every violation determination stores the operative limit, the rule that failed and the results considered. Every significant noncompliance evaluation stores the criteria version applied. Every deviation from the enforcement response plan stores a reason and a person. That combination is what survives a challenge from an industrial user's consultant and what an auditor is actually looking for.

The builds that fail invert it. Humans do the arithmetic in spreadsheets and nobody records the judgement, which is precisely backwards from what an audit rewards. They also treat the sampling schedule as a calendar. Generate it from permit requirements instead, so every required event exists as a record with a window and an owner before anyone thinks about it, and anything overdue appears on one screen. Proof that a quarterly obligation was met for two years should then be a report rather than a week in the filing cabinet.

Two questions worth asking any developer. Ask them to implement the significant noncompliance criteria on a whiteboard, including the rolling six month window. It is not difficult arithmetic, and watching someone reason about the edge cases tells you whether they will get them right. Then ask what they have integrated, by product name. Settle ownership before kickoff, in writing: the repository, the cloud accounts and the right to hire another firm. At Digital Heroes the client owns the code from the first commit, which matters here because these records may be evidence in an enforcement matter years later.