We have connected to hundreds of ERP environments across manufacturing portfolio companies. The data is always messy, not because the teams are careless, but because ERP systems were built to process transactions, not to anticipate ten years of acquisitions, floor workarounds, and configuration drift. Here are the fifteen data challenges we see most often, and what they actually cost you analytically.
When a PE portfolio company acquires another manufacturer, it inherits a second customer master. Three acquisitions later, revenue by customer is a reconciliation exercise. Deduplication is manual, taxonomy is improvised, and no record is authoritative. Consolidated cross-site revenue visibility requires resolving records that were never designed to align.
"Acme Inc (Do Not Use)." "Meridian Attractions (CLOSED)." "Global Parts (Use 4782 Instead)." The ERP doesn't have a status field that flows cleanly into reporting, so teams write the status into the name. Your AR team may be chasing a company that shut down two years ago. Nobody did anything wrong. The ERP didn't give them a better option.
Cross-site inventory visibility requires knowing that Part A100 at Plant 1 and Part 100A at Plant 2 are the same component. Without a unified item master, consolidated purchasing spend, vendor consolidation negotiations, and cross-site demand planning all run on guesswork. Translations add another layer: the German plant's description for the same SKU may share nothing with the US record.
The variance between what the ERP thinks a product costs and what it actually costs has been growing quietly since implementation. Without an accurate standard to compare against, cost analysis is an estimate dressed up as a calculation. Planned costs are often missing entirely, which means there is no baseline for variance analysis at all. You cannot measure improvement you cannot baseline.
Without hours posted to production orders, you know total payroll but cannot measure shop floor efficiency. The floor could be running at 70% or 95% of routing standard. The ERP has no way to tell you which, and neither does your operations report. Labor efficiency becomes a gut feel rather than a managed metric, and the gap between standard and actual stays invisible.
A receiving clerk processes a shipment of 1,000 units. The purchase order was written in cases. The ERP unit of measure is each. The clerk receives 1,000 (meaning 1,000 cases) against a UOM of 1 (each). The ERP accepts the transaction. Of course it does. Inventory is now overstated. Cost is exploded by the case-pack multiple. The posted transaction cannot be cleanly reversed, and every weighted average cost calculation downstream reflects it permanently.
Global list price, customer-specific price curves, long-term agreements, and pricing trade agreements interact in ways that make effective price visibility nearly impossible to maintain. What the customer actually paid versus what your pricing policy said they should pay often lives in a spreadsheet on someone's desktop, not in the ERP. The ERP records the transaction. It doesn't explain the logic behind it.
When every customer has a negotiated deviation from list, the list price loses meaning as an analytical benchmark. Price-volume-mix analysis needs a defensible starting point. Without one, the analysis reflects whatever proxy assumptions the analyst constructed. You end up measuring the deviation from a fiction, which doesn't tell you much about pricing power.
When a customer moves from a standard component to a higher-spec replacement or service part, PVM analysis classifies the margin change as a mix shift because the item number changed. The real story is a price change. The distinction matters when deciding whether to raise prices or rationalize the portfolio. Replacement and service parts need to be tagged and handled separately or the analysis gives you the wrong answer.
A quote that should have expired in Q1 is still sitting in open backlog in Q4. Conversion rate analysis, pipeline forecasting, and backlog accuracy all depend on timely status updates that sales teams have no structural incentive to provide. The ERP backlog is technically accurate. Practically, it is not, and measuring sales velocity against it produces results nobody trusts.
Quotes live in Salesforce. Orders live in the ERP. The space between them is where your quote-to-cash analysis disappears. Win rates, average deal size, sales cycle length, and customer lifetime value all require bridging two systems that were designed with no intention of sharing records. Most teams maintain both manually and hope they stay synchronized.
Lead times are stale. Safety stock levels were set when the business was half its current size. Reorder points reflect a supplier relationship that no longer exists on the same terms. Planners compensate by maintaining Excel files and overriding the ERP daily. The system is technically in control. Operationally, it is not, and the spreadsheets become the system of record nobody can audit or inherit.
Multi-site manufacturers operating in multiple currencies often have someone manually updating a rate table, sometimes quarterly, sometimes only when the numbers look suspicious. Exchange rate inconsistencies across plants and portfolio companies create phantom margin shifts that are hard to explain and harder to trust. Two sites reporting in nominally the same currency but using different rates will never reconcile at the portfolio level.
DSA (Daily Sales Average) divides revenue by the number of days in the period, but the right denominator is sales days: the days on which orders are actually placed or shipped. ERPs carry a production calendar for work center scheduling. They do not carry a sales calendar. A plant may run five days a week, but orders only come in four. A distributor channel goes quiet the week of a regional holiday the ERP doesn't know exists. Using calendar days or production days as the denominator inflates or deflates DSA by a predictable but uncorrected amount, and the result is trend lines that move for structural reasons, not commercial ones. Comparing DSA across regions with different sales day patterns is comparing different denominators dressed up as the same metric.
A misconfigured sub-assembly in the bill of materials propagates upward through every finished good that uses it. A single BOM error can corrupt cost rollups across dozens of items before anyone notices. The first symptom is usually a margin exception report with a number nobody can explain. The cause, once found, is often a configuration decision made years earlier by someone who no longer works there.
The data will never be perfect. That's okay.
Every challenge above is one we have seen, worked through, and built for. Not one of them is a reason to delay getting better information. The better move is a platform that works with manufacturing data as it actually exists, improves it as a byproduct of use, and gets your team to better decisions from where you are today.
Data quality isn't a project with a completion date. It's a continuous process. Every flagged anomaly, every corrected master record, every question the platform can't quite answer yet becomes a signal about where to focus next. Progress compounds, even when perfection isn't the destination.
Marquis IQ connects to manufacturing ERP environments as they actually exist. We handle customer and supplier mastering across multiple ERPs, fragmented item records, stale standard costs, complex pricing structures, and missing planned costs as part of the integration process, not as blockers to getting started.