EPR reporting software organizes the reporting layer. It does not absorb the packaging-data operations layer underneath — supplier outreach, validation, methodology governance, recurring readiness. The retained burden is the question, not the platform choice.
Many producers discover the same thing after implementing EPR software: the dashboard works immediately. The packaging-data work does not disappear.
EPR reporting software is now an established category. The better platforms — Lorax EPI, Specright, Assent, Recyda, Source Intelligence, and others — are real engineering. They centralize calculation logic, map jurisdictional taxonomies, format submissions, track deadlines, and produce defensible audit trails. For producers with mature internal packaging-data processes, they materially compress the reporting cycle.
What they do not do — and what their own documentation increasingly says they do not do — is eliminate the packaging-data work itself. That work sits below the reporting layer. It is larger, more recurring, and more operationally embedded than many producers initially expect.
This article is about that lower layer: what it consists of, why software does not absorb it, and why producers who treat "we bought a tool" as the answer tend to discover, a year in, that the question was different.
The first thing worth saying is that EPR software is genuinely useful. The platforms in this category solve a category of problem that did not have good off-the-shelf answers three years ago: a unified place for jurisdictional fee logic, taxonomy mappings, report templates, portal-ready exports, and audit trails. Some platforms focus on specification management. Others specialize in supplier engagement, global reporting, or jurisdiction-specific calculation logic. These are not commodity tools. They are domain-specific platforms built around a real workflow.
The reporting workflow layer is the part of EPR that scales well with software. Once methodology, taxonomies, and report formats are encoded, repeating the cycle is mechanical. That is the strength of the category, and producers who already have organized data benefit from it directly.
The rest of this article is about what sits beneath that layer.
Most EPR software begins where many producers are still trying to arrive: with structured, current, supplier-verified packaging data.
Software assumes packaging specs are known. It assumes component weights are available. It assumes supplier data is accessible. It assumes material classifications are usable. It assumes records are current. None of these assumptions are wrong — they are reasonable design choices for a reporting platform. They are simply outside the platform's scope to deliver.
The condition of packaging data inside most producers, before any of that infrastructure exists, is fragmented. 4Pack — itself a packaging-data platform — describes the typical pre-software state plainly: "packaging data is spread across design teams, procurement systems, marketing databases, and supplier spreadsheets. Each department tracks data differently, leading to inconsistencies." The G&A Institute frames it structurally: companies "have likely never had to track, collect, or report such data before."
The reporting layer is built for organizations that have already done the data-foundation work.
For most producers, that foundation is the work.
The most useful evidence on what EPR software does and does not do comes from EPR software vendors.
Lorax EPI, which operates one of the most established EPR reporting platforms in the U.S. market, sells the platform in two tiers. The Software-Only tier states explicitly that the producer "retains responsibility for: data collection and preparation; data management and analysis; generating, verifying and submitting reports." The separate Outsourced Compliance tier exists, in Lorax's own description, to handle the operational workload — supplier data requests, gap analysis, BoM construction, data quality recommendations, and submission preparation.
That tier structure is a market acknowledgment. In effect, the vendor has published a separate commercial category for the operational layer the software does not absorb.
Regilient is more direct: "The PRO handles the waste management infrastructure; your job is to provide accurate packaging data… The legal responsibility for compliance still sits with the producer."
Recyda, which automates calculation logic, says it openly in marketing copy: "It's impossible to eliminate all these challenges."
These are not criticisms of software. They are how the category itself describes the boundary of what software does. The boundary is consistent across vendors, regardless of how the product is positioned.
The single largest piece of producer-side work below the reporting layer is supplier engagement.
This is not a button. It is a recurring operating process. Suppliers do not always respond. Specs arrive incomplete. Data comes in inconsistent formats — kilograms versus percentages versus descriptive text. Weights are missing. Recycled-content claims need validation against documentation. Packaging revisions trigger new data requests. A single non-responsive supplier can stall a multi-state filing.
Assent, which built its EPR product specifically around supplier engagement at scale, is explicit about why: "without scalable supplier engagement, fragmented data collection leads to costly reporting errors, potential production disruptions, fines, and reputational risk." The platform offers "multilingual outreach and reminders" — both terms are themselves admissions that supplier engagement is persistent follow-up, not a single request.
Source Intelligence, in practitioner-facing content, puts a duration on it: "sourcing packaging weights from suppliers can take months."
rePurpose Global, in a published playbook, quantified one brand's experience: more than 200 suppliers contacted, 60 percent responded after two months, and roughly half of those responses contained usable data. The exact numbers are particular to that case. The operational shape is recognizable across most producers.
A platform can automate reminders. It cannot make supplier packaging data complete, current, defensible, or operationally usable. The producer still has to own the relationship, escalate non-response, validate what comes back, and run the cycle again next year.
The second misconception worth naming is treating implementation as the end state.
Implementation creates the system. It does not maintain the system. After deployment, the producer still has to manage SKU changes, new packaging launches, discontinued products, supplier updates, methodology consistency year-over-year, evolving state material taxonomies, audit trail integrity, and recurring reporting readiness across cycles.
Recyda names the regulatory dimension directly: "fee rates, material classifications, and calculation methodologies are being revised year after year — forcing companies to re-evaluate and adapt their reporting approach continuously." The same vendor notes elsewhere that when regulations change, prior work sometimes has to be discarded and the cycle started over.
Clearyst's published ten-step compliance framework makes the recurrence explicit: Steps 9 and 10 — monitoring regulatory changes across states, and optimizing packaging design to lower fees — are permanently ongoing. They never conclude.
There is also a software-failure mode worth naming. Tillamook's compliance manager, in a published case study, described a prior third-party tool that "requires you to change your entire bill of materials for every time you want to run a report." The platform was technically functional. It just imposed a maintenance overhead so severe that running it routinely was not viable. The point is not that the tool was ineffective. It is that implementation alone does not produce ongoing usability — the maintenance shape of the system is part of whether software actually serves the producer.
Implementation, in short, is the beginning of the operational workload, not the end of it.
A useful name for the work that remains producer-side after software implementation is the retained operational burden. It is not a function any platform fully eliminates.
It includes supplier data acquisition and follow-up; validation and gap resolution; methodology governance and historical reconstruction; cross-functional coordination across packaging, procurement, sustainability, finance, and legal; and the maintenance of recurring reporting readiness as products, suppliers, and regulations change.
Each of these has a recurring cadence rather than a one-time shape. Each one requires either internal staffing, external contracted capacity, or a managed service to run. None of them is in the scope of what reporting software is built to do.
This is the conceptual center of the article. Once a producer sees EPR as two layers — a reporting workflow layer that software handles, and a packaging-data operations layer that the producer still owns — most downstream decisions become easier. The question stops being "which platform" and starts being "who runs the layer underneath it, and on what cadence."
Software-only is a real and viable model for the right producer. It works well when the producer already has mature packaging-data processes: a centralized spec system, established supplier data relationships, internal owners across compliance and packaging, and a stable cadence for keeping records current. For those producers, the platform layer is the missing piece, and adding it materially compresses the reporting cycle.
Software-only works less well when the producer's foundation is incomplete. The conditions that make it harder are familiar: high SKU counts, fragmented supplier bases, packaging data that has never been centralized, multiple state obligations, no internal compliance owner, or the need to reconstruct historical data for retroactive baselines such as California SB 54's 2023 baseline.
For producers in those conditions, the platform still installs. It still runs. It just runs underneath a data layer that no one is operating, and the resulting reports become harder to defend, slower to assemble, and more dependent on individual heroics each cycle. The result is not platform failure. It is operational under-investment masked by the appearance of platform success.
A managed EPR service is not anti-software. It is the operating layer around software.
If software organizes the reporting layer, managed execution runs the data-operations layer underneath it. That includes supplier data collection, packaging-data normalization, methodology documentation, reporting preparation, recurring readiness across cycles, and the cross-functional coordination that keeps the data foundation current as products change. The two layers are complementary by design.
The structural logic shows up in the vendor landscape itself. Lorax EPI's Outsourced Compliance tier exists alongside its Software-Only tier because the gap between them is real and was being met somewhere — internally, by consulting hours, or not at all. The market is sorting into a layered model: software where structured data already exists, and managed execution where the data work itself has to be done.
Orbitlex was built around the retained operational burden. We do not compete with EPR reporting software, and we do not replace it for producers who already have organized data. We help producers move from "we bought a tool" to "we have an operating model" — the layer underneath the reporting layer, run as a recurring function rather than an annual scramble.
That work includes the things software does not absorb: supplier outreach, data normalization, methodology documentation, packaging-revision tracking, and the ongoing maintenance of recurring reporting readiness across states. The output is not a different report. It is a different posture: the next reporting cycle starts from a maintained foundation, not from a reconstruction project.
Software can make EPR reporting more organized. It cannot do the packaging-data work for you. The question is whether that work will be owned internally, left to ad hoc teams, or managed as an operating function.
Orbitlex runs the retained operational burden: supplier outreach, validation, methodology documentation, packaging-revision tracking, and the recurring readiness layer underneath whatever reporting tool a producer already uses.
Get Free EPR Compliance CheckThis article is for informational purposes only and does not constitute legal advice. Regulatory timelines and program requirements are subject to change. Always verify current obligations with state authorities, PROs, and qualified legal counsel directly. Orbitlex is not a law firm.