Recycling Facility Software: Stop Eating Contamination Docks You Cannot Trace

Why recycling facility software makes or breaks a MRF operator

Your material recovery facility runs on three numbers that never reconcile: what came across the inbound scale, what is sitting on the floor as baled commodity, and what left on a truck against a broker contract. The scale house has WeighStation or Paradigm or a Creative Information Systems install from 2016. The bale inventory lives in a spreadsheet the plant manager updates from a clipboard count at end of shift. Outbound sales live in QuickBooks plus the broker's own confirmation emails. Nobody owns the join between them, so the yield number your CFO reports is an estimate dressed up as a fact.

Now the part that costs real money. A hauler drops 22 tons of single stream at 6:40 a.m. The scale operator picks a customer from a dropdown, types a material code, prints a ticket. Nobody grades that load beyond a glance from the tipping floor. Three weeks later a broker rejects a load of mixed paper for moisture and fines, docks you $38 per ton on 24 tons, and you have no way to trace that bale back to which inbound loads fed the line that shift. You eat $912 and cannot bill the hauler whose load caused it, because your ticket data and your bale data have no shared identity. At the MRFs we have worked in, four or five rejections a quarter is normal, which puts $15,000 to $20,000 a year of claims you could have passed through onto your own P&L instead.

Then there is the manual labor. At the 15,000 ton per month facilities we have scoped, the commodity manager loses 10 to 14 hours a week rebuilding an inventory position from scale exports, floor counts and broker confirmations, then another few hours arguing with accounting about which month a shipment belongs to. That is most of a full time role burned on reconciliation, not on selling material into a better market window.

Problem: inbound loads have no identity that survives the sort line

The scale ticket knows the hauler, gross, tare, net and a material code. That is where the data dies. Once the load hits the tipping floor it merges with everything else that shift and the ticket becomes an accounting artifact, not an operational record. So when a bale of PET goes out at 88 percent purity instead of 95, you cannot answer the only question that matters: whose material caused it.

Off-the-shelf scale software cannot fix this because it was built as a weighmaster and billing tool. Paradigm, WeighStation and the rest model a transaction, not a production batch. They have no concept of a sort run, no way to link a set of inbound tickets to a window of line time, and no lineage from ticket to bale to shipment. You can export to CSV and try to join in Excel, but there is no batch key to join on, because nobody ever created one.

A custom build introduces the missing object: the sort run. Every inbound ticket gets stamped with a facility, line, shift and timestamp. The baler emits a bale record with a tag ID, weight, commodity grade and the sort run it came from. Now the lineage is ticket to sort run to bale to shipment, queryable in both directions. When a broker docks you, you pull the sort run, see the six inbound tickets that fed it, and see that one hauler's route contributed 40 percent of the tonnage. That becomes a contamination charge on their next invoice instead of a write-off on yours. The build effort here is not exotic: it is a scale-house integration that reads tickets, a tablet or PLC feed at the baler, and a data model that treats the sort run as a first-class entity from day one.

Problem: bale inventory is a clipboard number that is wrong by Wednesday

Your floor count says 41 bales of OCC. Actual is 37, because two shipped Friday afternoon after the count and two got re-baled as off-spec. The commodity manager quotes a broker against 41, commits, and then scrambles Thursday to make the load. Or the reverse: you are sitting on 300 tons of aluminum you forgot about while the market moved on you.

QuickBooks cannot hold this because it wants SKUs with unit costs, and a bale of mixed paper has neither a stable cost nor a stable grade. Generic warehouse management systems like Fishbowl assume discrete, uniform, barcoded units. A bale is a heterogeneous, degrading, market-priced blob whose value changes daily and whose grade can be downgraded by a QC re-inspection. Every off-the-shelf inventory tool forces you to lie about one of those properties.

A custom build models the bale correctly: unique tag, weight at bale time, commodity, grade with a revision history, storage location, age in days, and a mark-to-market value pulled from your published index feed or your own contract pricing. Scan a tag with a phone at the loading door and inventory decrements in real time. Age triggers matter here: a rule that flags any OCC bale sitting past 21 days, or any mixed paper past 14 in humid months, prevents the slow rot that turns a sellable grade into an off-spec bale you argue about with a broker two weeks later. Forecasting pays for itself here too. Feed 18 months of inbound tonnage by material, by day of week, by route, and a model gives your commodity manager a credible 3-week forward position on each grade, so they can commit to a broker at Monday's price with a number they trust instead of a number they hope for.

Problem: outbound sales, brokers and settlement live in email

A broker confirms 4 loads of #1 PET at $0.32 per pound. The confirmation arrives as a PDF attachment. Someone re-keys it into a spreadsheet. The truck ships. Six weeks later a remittance advice arrives showing a moisture deduction, a freight adjustment and a price different from the confirmation because the contract was indexed to a published market rather than fixed. Nobody catches the delta. In the books we have opened, a year of unchallenged deductions adds up to a number nobody wants to say out loud, simply because no human has time to compare 400 remittances against 400 confirmations line by line.

No off-the-shelf tool closes this, because it requires understanding your specific contract terms: index-linked versus fixed, freight allowance, moisture tolerance, quality dock schedule. That logic is your business, not a vendor's feature backlog.

This is the single best AI application in the category and it is not speculative. Document extraction on broker confirmations, bills of lading and remittance advices pulls structured fields out of the PDF or emailed image, matches them to the shipment record by BOL number and weight, and computes the expected settlement from your contract terms. Anything off by more than a threshold you set, say $250 or 2 percent, opens an exception with the source document, the expected number and the actual side by side. Your commodity manager reviews 8 exceptions a week instead of reading 400 PDFs. The same extraction handles inbound: a hauler's manifest photographed at the gate becomes a ticket before the truck reaches the scale, which matters at 6 a.m. when the queue is 5 trucks deep and the operator is one person.

Problem: multi-site means you cannot see the network position

Three MRFs, three scale systems, three spreadsheets, three definitions of what "mixed paper" means. Site A grades conservatively, Site B does not, and neither knows that Site C is 60 tons short of a full load of the exact grade Site A has been sitting on for two weeks. So you ship two half loads at freight you did not need to pay, or you miss the consolidation entirely.

Off-the-shelf scale software is single site by architecture. Rolling it up means someone exporting three CSVs and reconciling them in a workbook, which happens monthly at best, which means your network position is always a month stale.

The build gives you one commodity taxonomy enforced across all sites, live inventory rolled up to the network, and a consolidation view that says: Site A has 62 tons of grade 8 news aging past 18 days, Site C has a 24-ton gap on a committed load leaving Thursday, transfer costs $340, contribution is $1,900. It also lets you compare sites honestly. Yield per inbound ton, residue rate, downtime by shift, cost per ton processed, all on the same definitions. That comparison is usually where an operator finds their first six-figure win, because one site is quietly running 4 points worse on residue and nobody could prove it before.

Problem: reporting to municipalities and regulators eats a week per quarter

If you run contracted municipal single stream you owe diversion reports, residue rates and tonnage by jurisdiction, on their format, on their cadence. Some want monthly, some quarterly, some want a specific spreadsheet template. If you handle e-waste or any regulated stream you have chain-of-custody and downstream certification obligations on top. Today someone builds these by hand from exports, and every quarter they rebuild the same pivot from scratch.

Generic tools cannot help because the report format is contract-specific, and every municipal contract is a snowflake. But if the underlying data model already carries jurisdiction on the inbound ticket and follows lineage through to outbound with downstream buyer certification on file, the report is a query, not a project. Build the report templates once per contract and generate them on a schedule. A week of quarterly work becomes an hour of review. For the R2 or e-Stewards side, the same lineage that lets you trace a contamination dock is exactly what an auditor wants when they ask where a specific inbound lot ended up.

What this costs and how long it takes

Across 2,000+ Digital Heroes projects, a focused first release lands at $60,000 to $130,000 over 12 to 16 weeks. For a MRF that is realistically: scale-house integration reading tickets from your existing weighmaster, the sort run and bale data model, tag scanning at the baler and the loading door, live inventory by commodity and grade, outbound shipments against contracts, and one reconciliation view. That release alone usually pays for itself on contamination pass-through and settlement recovery.

Full platforms run $150,000 to $400,000 phased over 6 to 12 months: multi-site rollup, AI document extraction for confirmations and remittances, contract and settlement engine with index pricing, forecasting, municipal reporting, hauler portal, and ERP (Enterprise Resource Planning) or accounting sync.

What drives price up specifically in this category: the number of distinct scale systems you have to integrate with, because a Paradigm SQL database and a legacy Creative Information Systems install are two different projects; whether you need real-time PLC or optical sorter telemetry rather than end-of-shift numbers, which adds OT networking work and a hardened data path; the complexity of your broker contracts, since index-linked pricing with a dock schedule is a genuine pricing engine and fixed-price contracts are a table; the number of municipal report formats; and any regulated stream that brings chain-of-custody and audit requirements. Offline tolerance matters too. Scale houses lose network. If the gate has to keep issuing tickets during an outage and sync later, that is a real conflict-resolution design, not a checkbox.

Build versus buy: the honest line

Buy if you run a single facility under roughly 6,000 tons a month with a simple book of business: a handful of brokers on fixed-price contracts, no municipal reporting obligations, no rebate sharing. A scale package plus QuickBooks plus a disciplined spreadsheet genuinely works at that scale, and a $200,000 build will not return. Buy also if your bottleneck is physical, not informational. If your issue is that your optical sorter is undersized, software will not sort plastic.

Build when you cross specific thresholds. When you run more than one facility and cannot state your network inventory position without a person spending a day on it. When your revenue includes rebate sharing or index-linked pricing, because the math is your business and no vendor will encode your contracts. When you eat contamination docks you cannot trace back to a hauler. When your commodity manager spends more than a day a week reconciling rather than trading. When you have tried Rubicon or a general WMS and found yourself keeping the spreadsheet anyway, that spreadsheet is the specification for what you actually need and the tool has already failed.

The position: at 10,000 tons a month and up with multiple sites, buying is the more expensive option. You just pay for it in reconciliation hours, untraced docks and unchallenged deductions instead of in a line item on the capex budget.

How to choose a developer for recycling facility software

Make them draw the data model on a whiteboard before you sign. Ask them to model ticket, sort run, bale, shipment and settlement, and to explain how a grade revision propagates. If they reach for a generic product-and-order schema, they will build you a warehouse system that cannot represent a bale. This is the single fastest disqualifier.

Ask what they will do about your specific scale system. Not "we can integrate with anything." Ask whether they will read the Paradigm SQL database directly, poll an export directory, or sit in front of the indicator. Ask what happens when the scale house loses network for four hours during a morning rush. A team that has done this will answer with a specific plan for offline ticket issuance and sync conflict handling. A team that has not will say the network should be reliable.

Test them on contract math. Describe one real index-linked contract with a moisture dock schedule and a freight allowance and ask how they would model it. Whether they treat it as configurable rules or hardcoded logic tells you whether the system survives your next contract renegotiation.

Get the code ownership and the exit in writing. Full source in your repository, your cloud account, your database, documented schema, and a handover that includes a working local environment. This system will hold years of ticket and settlement history that you may need for an audit or a sale of the business. Any arrangement where the developer holds the keys is a liability you did not need to take on.

When you are ready to turn this into a specification, Digital Heroes builds and runs its own products, so the people choosing your architecture live with those decisions on their own revenue. You can take that specification to any other firm on your shortlist.