The price-volume-mix bridge is only as accurate as the data it runs on. Before you trust its output, five data problems routinely corrupt the inputs - and each one silently misattributes margin movement to the wrong driver.
Price-volume-mix analysis has a clear contract with the analyst: give it clean invoice data, a consistent item taxonomy, resolved customer records, current standard costs, and aligned fiscal periods, and it will tell you exactly where margin moved and why. Break any of those inputs, and the bridge confidently produces the wrong answer.
The five data problems below are not rare edge cases. They are the default state of most multi-ERP manufacturing environments that have grown by acquisition. Each one silently misattributes margin movement to the wrong driver. The bridge doesn't flag the error - it runs the calculation on corrupted inputs and returns numbers that look entirely plausible.
A PVM bridge will confidently tell you price drove margin down 2.3 points. The real cause might be an item recode that made a discontinued product look like 100% volume churn. The output looks authoritative either way.
IQ Insights runs a data quality pass before the bridge executes. Each of the five problems below describes what goes wrong without detection, and how IQ Insights surfaces the issue before it reaches the driver calculation.
When a single customer appears as multiple account records in the ERP - separate entries for each ship-to location, each division, or each acquired entity - their revenue is fragmented. A bridge running on unmastered data sees each account independently. When one account stops purchasing and another increases volume, the bridge reads it as churn and new customer growth rather than the same customer shifting purchasing patterns between sites.
This corrupts the mix driver specifically. Customer mix effect measures whether you sold more or less to higher-margin customers. If the same customer is split across twelve accounts, their aggregate margin profile is invisible. Each account carries its own margin footprint, and the consolidated customer-level move - which is often the most consequential driver - never appears in the output.
Manufacturing ERP systems renumber SKUs at acquisitions, re-platforming events, and product line revisions. From the bridge's perspective, a discontinued item code shows 100% volume decline and the replacement item code shows 100% volume growth. If the underlying product didn't change - only the code did - the bridge has invented churn and new volume that don't exist.
The volume driver overstates both lost and new volume. The mix driver misreads the composition of what was sold. For a business that has completed several acquisitions or undergone an ERP migration in the past five years, this problem affects a meaningful percentage of active SKUs - often without anyone in the business being aware of the scale.
The price driver is computed from realized unit price per transaction. A single invoice with a bad unit price corrupts the price driver for that item-customer combination. The most common sources: data entry transposition errors (a $1.24 item entered at $124.00), credit memos booked against the wrong line (effectively posting a negative price rather than reversing the original transaction), and test transactions never removed from live data.
These don't average out. A single outlier at the item-customer level pulls the mean realized price significantly in either direction, and the bridge computes a price effect for that combination that has nothing to do with actual pricing decisions. The price driver absorbs the data entry error and returns a plausible-looking number without any indication something went wrong.
Statistical detection using the interquartile range (IQR) is the right tool here because it requires no assumption about the shape of the price distribution and works on small transaction histories. IQ Insights builds a fence at Q3 + 2.5× IQR (upper) and Q1 - 2.5× IQR (lower) for each item-customer pair. Legitimate large-volume contract breaks typically land within 1-2× IQR of the median. Transposition errors and mis-booked credits land an order of magnitude outside it.
Standard cost resets, burden rate methodology changes, and cost capitalization policy switches all produce cost movements in the bridge that have nothing to do with actual input cost changes. A burden rate increase reflecting a plant capacity decision looks identical to a genuine overhead cost increase when read from the cost layer. A standard cost reset that catches up to two years of accumulated inflation appears as a single large materials variance in the period when it ran.
Neither of these is useful for operational decision-making. Both make the cost layer appear volatile when the underlying inputs may have been stable. The cost drivers absorb the methodology change and report it as real cost movement - which the operations team is then asked to explain to the board.
A PE-owned manufacturer running three portfolio companies on different ERP systems faces a structural problem: fiscal calendars don't align. One system closes on the 25th, one on the last day of the month, one on the first Monday of the following month. When you build a consolidated bridge across all three, you're comparing different time windows. Revenue attributed to a period in one ERP may belong to a different period in another.
Volume spikes and pricing moves near cutoff dates get compared against stable mid-period data from the other systems. The bridge has no visibility into this - it processes the data as received and produces driver attributions that reflect calendar differences as much as actual business differences. Every driver is affected, and the consolidated output gives no indication that the underlying periods don't match.
Each of the five problems has a specific precondition that must be met before the bridge produces reliable output for that driver. These aren't aspirational data quality goals - they are the minimum prerequisites for each attribution to be meaningful.
When these five checks run automatically before every bridge execution, the output carries a data quality score alongside the margin attribution. Issues that clear the threshold produce a fully reliable bridge. Issues that remain open are documented - so the business knows exactly where the numbers are precise and where they carry a known caveat, rather than treating all output as equally trustworthy.
IQ Insights runs all five checks automatically. See how it works on the IQ Insights page, or explore the underlying data mastering and ERP data enrichment capabilities that feed it.
FAQ
Questions about how common these problems are, whether a bridge can run with known issues, and what IQ Insights does with the flags it raises.
Very common. These five problems are not edge cases - they are the default state of most multi-ERP environments that have grown by acquisition. Customer and item master issues exist in virtually every company that has completed an acquisition without a formal data mastering program. Cost layer issues are nearly universal after an ERP upgrade or platform consolidation. Period misalignment affects every company running multiple ERP systems on different fiscal calendar configurations.
Yes, with appropriate caveats. Known issues constrain the bridge's precision, not its existence. A bridge built on data with unmastered customers still accurately measures aggregate volume and cost effects - it loses precision on the customer mix driver specifically. Running the bridge with documented confidence warnings on known issues is far more useful than waiting for perfect data that may never arrive. The key is knowing which drivers are reliable and which carry a caveat.
Item code discontinuity is hardest to catch without automated matching. Unmastered customers are visible if you look for them - duplicate accounts often share a name pattern. Unit price outliers stand out when you sort by unit price. Cost layer methodology changes become apparent once you look for whole-class synchronous movements. But item recode issues require fuzzy matching discontinued codes against new codes across description, unit of measure, product family, and standard cost simultaneously - extremely tedious in a spreadsheet and easy to miss.
IQ Insights flags and surfaces - the business confirms or corrects. For customer master issues, IQ Insights proposes merge candidates; a data steward accepts or rejects each proposed relationship. For item recode candidates, IQ Insights proposes a lineage link; the item master owner confirms. For unit price outliers, IQ Insights flags the transaction; the analyst decides whether it is a legitimate edge case or an error to exclude. The system never silently corrects - it surfaces issues at the point where a human can make an informed decision before they corrupt downstream analysis.
Customer mastering is foundational to the mix driver. The mix driver measures whether you sold more or less to higher-margin customers. If the same customer appears as multiple accounts, their total margin profile is fragmented - you cannot compute whether their share of revenue went up or down as a whole. Resolving all ship-to accounts to their parent entity is the prerequisite for customer mix analysis to produce numbers that correspond to actual business decisions rather than accounting artifacts.
IQ Insights runs all five data quality checks automatically before every PVM bridge execution - so the numbers you bring to the board reflect what actually happened, not what the data errors say happened.