True Margin Per SKU: Why Your ERP Cannot Tell You Which Products and Customers Actually Make Money (2026)

TL;DR: Your ERP holds standard costs, which exist to value inventory, not to tell you which products and customers make money. Cost-to-serve analysis routinely finds 20% to 40% of customers are unprofitable once picking, packing, shipping, support, and administration are counted, and they are frequently the largest by revenue. True margin per SKU requires connecting ERP transactions, MES run data, freight actuals, quality records, and contract terms that today sit in separate systems. This guide covers why standard costing hides the answer, how to build the calculation step by step, where margin actually leaks, what to do with the answer, and a realistic 90-day sequence.

Ask most manufacturers which of their SKUs make money and you will get a gross margin report by product line. Ask which customers make money and you will usually get silence, or a revenue ranking presented as if revenue and profit were the same thing. In distribution and manufacturing, cost-to-serve analysis routinely finds that 20% to 40% of customers are unprofitable once picking, packing, shipping, support, and administration are properly counted. Those customers are frequently among the largest by revenue, which is exactly why nobody questions them.

The reason this stays hidden is not that the math is difficult. It is that the numbers required to do it live in systems that were never connected: standard costs in the ERP, actual run times and scrap in the MES, freight in the TMS or in a stack of carrier invoices, returns in the quality system, discounts and rebates in the CRM and the contract file, and expedites nowhere at all. Averaging across that gap produces a gross margin number that is technically correct and operationally useless, because the average conceals both the SKU heroes and the SKU villains.

This guide covers what true margin per SKU means, why standard costing hides it, what a manufacturing data layer is, how to build the calculation, where the leakage actually concentrates, and a realistic 90-day sequence. It is written for owners, CEOs, CFOs, and heads of operations at mid-market manufacturers.

Key takeaways

• Cost-to-serve analysis typically finds 20% to 40% of customers are unprofitable once fulfillment, service, and administrative costs are allocated rather than absorbed into overhead.

• Treating gross margin as a monolith is the core error. The portfolio average conceals both your best and worst products, and the worst are usually the ones sales is protecting hardest.

• Manufacturers average roughly 800 hours of equipment downtime per year, per Deloitte, and weekly downtime losses across global manufacturing run around $852 million per week per Fluke's 2025 global survey. Downtime is a margin problem before it is a maintenance problem.

• Deloitte's 2026 Manufacturing Outlook finds 80% of manufacturers plan to invest 20% or more of their improvement budgets in smart manufacturing, including data analytics, sensors, and cloud. The spend is committed; the question is whether it lands on connected data or another dashboard.

• Deloitte also notes continuous AI integration with existing ERP, MES, and PLM systems can support up to 40% downtime reduction. The qualifier is "with existing systems," which is an integration statement.

• Input costs are expected to rise about 5.4% over the next year and 78% of surveyed manufacturers cite trade uncertainty as their primary concern. When costs move that fast, a costing model refreshed annually is wrong most of the year.

• Gartner expects more than 40% of agentic AI projects to be canceled by the end of 2027. In manufacturing the usual reason is that the agent had no reliable cost or genealogy data to reason over.

What is true margin per SKU, and why doesn't your ERP show it?

True margin per SKU is the profit a specific product actually generates after all costs attributable to producing, selling, delivering, and supporting it are assigned to it, rather than absorbed into a pooled overhead rate. Your ERP does not show it because the ERP holds standard costs, and standard costs are an accounting convention designed for inventory valuation and variance reporting, not for product-level profitability decisions.

The gap comes from four specific places.

Standard versus actual. The ERP carries a standard cost set at some point in the past, usually annually. The actual cost of a run depends on the machine it ran on, the operator, the changeover before it, the yield that shift, and the material lot's price. Those actuals live in the MES and the purchasing history. With input costs projected to rise about 5.4% over the coming year, an annual standard is materially wrong for most of the year.

Overhead absorbed rather than assigned. Traditional absorption spreads overhead by labor hours or machine hours. A SKU that requires three changeovers, two quality holds, and a manual pack operation absorbs the same overhead per hour as a SKU that runs continuously. The first SKU is subsidized by the second, and the report says both are fine.

Post-manufacturing cost invisibility. Freight, expedite premiums, returns, rework, warranty claims, and customer-specific packaging or labeling are real costs of that product for that customer. They usually sit in SG&A or in a freight account, and they never touch the SKU.

Revenue-side leakage unmodeled. The invoice price is not the realized price. Discounts, rebates, payment terms, price protection, freight allowances, and off-invoice concessions reduce it. If your margin math starts from list or invoice price, it starts wrong.

Moving from gross margin reporting to true product profitability requires connecting data that lives in separate systems: ERP transactions, production schedules, quality records, and time tracking. That is the whole problem in one sentence.

What is cost-to-serve, and how many customers actually lose money?

Cost-to-serve is the full cost of serving a customer once order handling, picking, packing, shipping, returns, support, and administration are counted, not just the cost of the goods sold to them. Studies of distributors and manufacturers consistently find that 20% to 40% of customers turn out to lose money once that analysis is done properly.

The drivers are behavioral rather than product-related, which is why product-level costing alone misses them:

• Order pattern. A customer ordering weekly in small quantities costs multiples of one ordering monthly in full pallets, at identical revenue.

• Order channel and accuracy. Phone and email orders requiring manual entry, plus the correction cycle when they are wrong, carry real labor cost.

• Expedite behavior. The customer who calls for a rush every third order is consuming premium freight and disrupting the production schedule, which pushes cost onto other orders.

• Returns and claims rate. Restocking, inspection, credit processing, and disposal.

• Payment behavior. Days sales outstanding is a financing cost, and slow payers plus deduction disputes carry collection labor.

• Service intensity. Engineering support, custom documentation, quality certifications, vendor portals, and EDI maintenance vary enormously by customer.

• Customer-specific requirements. Special packaging, labeling, kitting, palletization, or dedicated inventory held for them.

The uncomfortable pattern is that the highest cost-to-serve customers are often the largest by revenue and the loudest in negotiations. Without the number, that conversation is decided by volume and volume alone. Our SKU and customer margin demo shows booked versus kept margin with cost-to-serve on fictional data.

Why does standard costing hide the answer?

Because standard costing is designed to explain variances against a plan, not to attribute cost to the thing that caused it. It answers "did we spend more than we expected on labor this month" and not "does this product, sold to this customer, in this order size, make money."

Three mechanics do the hiding.

Cost pool averaging. Overhead collected into pools and applied at a blanket rate transfers cost from complex products to simple ones. The complex SKU always looks better than it is.

Fuzzy COGS policy. Manufacturers frequently lack a clear, written definition of what belongs in COGS, how landed costs including tariffs and freight-in are allocated, and how absorption is handled during under- or over-production. Without that definition, two analysts produce two answers and neither is reproducible.

Absorption during volume swings. Under-production leaves unabsorbed overhead that has to go somewhere. Over-production capitalizes overhead into inventory, which flatters current margin and creates a future write-down. Neither is a product profitability signal, but both move the reported number.

The fix is not to abandon standard costing, which the ERP needs for valuation. It is to build the decision-grade view alongside it, from actuals, in a layer, and to keep the two reconciled so finance can defend both.

What is a manufacturing data layer?

A manufacturing data layer is a governed layer between your operational systems and your decisions that connects ERP, MES, CRM, warehouse and transportation systems, quality, and procurement; resolves the entities those systems describe (parts, SKUs, customers, suppliers, work orders, machines, lots) into single persistent identities; and holds the canonical cost and margin logic your business uses, so one number means one thing everywhere.

Entity resolution matters more in manufacturing than most people expect. The same part carries an internal part number, a customer part number, a supplier part number, and a distributor SKU. The same customer exists as a corporate parent, three ship-to locations, two bill-to entities, and a buying group membership. The same material appears under two vendor names after an acquisition. Until those resolve, spend leverage, margin by customer, and supplier consolidation analysis all return partial answers. Our direct spend demo shows the classic version of this: the same part purchased at three plants at three prices, invisible because the part numbers differ.

The layer also has to be genealogy-aware. A finished good traces to work orders, to material lots, to supplier receipts, to the machines and shifts that made it. That chain is what lets you answer why margin on a SKU dropped in March, and it is also what a quality recall depends on. We described the general architecture in Knowledge Graphs for Enterprise AI and the operator-facing version in What Is an AI Context Layer?.

What systems does it need to connect?

ERP. SAP, Oracle, NetSuite, Microsoft Dynamics, Epicor, Infor, or Sage. Source of orders, invoices, standard costs, bills of material, inventory, and the general ledger.

MES and shop floor. Actual run times, changeovers, downtime events and reasons, scrap and yield, operator and machine assignment, OEE components. This is the source of actual conversion cost and the system most margin analyses omit.

CRM and pricing. Salesforce, HubSpot, or a quoting system. Source of quoted price, discount approvals, and the customer relationship structure.

Contracts and rebate agreements. Volume tiers, rebate accruals, price protection, freight terms, and payment terms. Usually PDFs, and usually the reason realized price differs from invoice price.

Warehouse and transportation. WMS pick and pack labor, TMS or carrier invoices with actual freight per shipment, accessorial charges, and expedite premiums.

Quality and warranty. Nonconformance records, rework hours, returns, scrap disposition, warranty claims, and customer complaints.

Procurement and supplier data. Purchase price history by part and plant, lead times, tariff and duty classifications, landed cost components.

Maintenance. Work orders, mean time between failures, and downtime attribution, which is how throughput and margin connect.

The MES, freight, and contract categories are the three most commonly skipped, and they are where the majority of the hidden cost sits.

How do you build a true margin calculation?

Seven steps. The order matters, because each step depends on the resolution done in the prior one.

1. Write the costing policy down. Define precisely what belongs in COGS, how landed cost including freight-in and tariffs is allocated, how absorption is handled during volume swings, and which cost categories are attributed to product versus customer versus order. Twenty lines of written policy prevents a year of disputed numbers.

2. Resolve the entities. Parts to a single identity across internal, customer, and supplier numbering. Customers to a hierarchy with ship-to and bill-to distinct from the parent. Suppliers deduplicated across name variants and acquisitions.

3. Compute actual conversion cost per unit produced. From MES run data: actual machine time, actual labor, changeover time attributed to the run that caused it, energy where metered, and scrap at actual rather than standard yield. Compare to standard and keep the variance visible rather than smoothing it.

4. Compute realized revenue per line. Invoice price less all discounts, rebate accruals, price protection, freight allowances, and off-invoice concessions, attributed to the specific SKU and customer.

5. Assign order and customer costs by driver. Pick and pack labor by lines picked and units handled. Freight by actual shipment cost, not an average rate. Expedite premiums to the order that caused them. Returns, rework, and warranty to the SKU and customer. Order entry labor by channel. Credit and collection cost by payment behavior.

6. Produce the four-way view. Margin by SKU, by customer, by SKU and customer combination, and by order. The combination view is where the decisions live: the same SKU can be strongly profitable with one customer and deeply negative with another, and only that view tells you whether to fix the price, the order pattern, or the product.

7. Reconcile to the general ledger. Total allocated cost has to tie to the GL, with any difference named and explained. Without this, finance will not stand behind the number, and if finance will not stand behind it, sales will not act on it.

Where does the margin actually leak?

In roughly this order of frequency at mid-market manufacturers:

Price erosion through discount drift. Concessions granted for a specific reason years ago that never expired, and never got reviewed because nobody had realized-price-by-customer visibility.

Small order and mixed pallet economics. Orders below a break-even line that no one has calculated, accepted because the customer is important.

Freight and accessorials. Actual freight per shipment versus the rate assumed at quote, plus liftgate, residential, redelivery, and detention charges that never reach the SKU.

Expedites. Premium freight plus schedule disruption. The disruption cost is real and almost never measured: a changeover inserted for a rush order costs the capacity of the run it displaced.

Rework and scrap concentrated in a few SKUs. Portfolio-level scrap rates look acceptable while two SKUs carry most of it.

Changeover-heavy short runs. Setup time is a fixed cost per run, so a SKU ordered frequently in small quantities carries far more setup per unit than the standard assumes.

Slow-moving and obsolete inventory. Carrying cost, then write-down. This is the working capital side of the same problem, shown in our working capital and inventory demo.

Unclaimed supplier recoveries. Rebates not claimed, price increases accepted without contractual basis, and the same part bought at different prices across plants.

Downtime. With average equipment downtime around 800 hours per year per manufacturer, and global weekly losses estimated near $852 million, unplanned downtime is a direct margin item. Deloitte's 2026 outlook notes that continuous AI integration with existing ERP, MES, and PLM systems can support up to 40% downtime reduction, which is a throughput and therefore an absorption story. Our throughput and capacity demo shows OEE with a downtime Pareto on fictional data, and the full set of workflows sits on our manufacturing page.

What can AI agents do once the layer exists?

They can run the analysis continuously that finance currently runs annually, and they can prepare the specific conversations that recover money.

Realistic:

• Monthly margin decomposition by SKU, customer, and combination, with variance attributed to price, mix, volume, conversion cost, freight, and quality.

• Quote guardrails. At quoting time, surface the true margin of similar historical business for that customer at that order size, so the quote reflects cost-to-serve rather than list less standard discount.

• Renegotiation packets. For a negative-margin customer, assemble the order pattern, freight actuals, expedite history, returns, and payment behavior into the specific asks: minimum order quantity, lead time, packaging, or price.

• SKU rationalization candidates ranked by margin contribution, strategic role, and shared tooling or material dependencies, because killing a SKU that shares a setup with a profitable one can make things worse.

• Supplier consolidation opportunities found through resolved part identities across plants.

• Downtime attribution to margin, connecting a recurring failure on one line to the specific SKUs and customer commitments it puts at risk.

Not appropriate unsupervised: the pricing decision, the customer exit decision, and the costing policy itself. Deloitte's finding that over 81% of manufacturing task hours are projected to remain human-controlled is a reasonable frame. The agent does the assembly; the operator decides. See AI Agents, Workflows, and Knowledge Graphs in Manufacturing for the wider workflow set.

What do you do with the answer?

This is where most SKU profitability projects die. The analysis lands, it says 30% of customers lose money, and nothing happens because every fix has a relationship attached. Four moves in escalating order of difficulty:

1. Fix order behavior first. Minimum order quantities, order channel changes, consolidated shipping schedules, and lead time discipline. These recover margin without a price conversation, and customers often accept them.

2. Reprice the specific leak. Not a blanket increase. "Your average order is 40% below our break-even quantity, so orders under X carry a handling charge, or we move to a monthly consolidated shipment."

3. Change the product or process. Reduce changeover time on the short-run SKU, requalify a material, or redesign packaging for the customer-specific requirement.

4. Rationalize or exit. Last resort, and only with the shared-tooling and shared-material dependencies mapped, plus a view on what the freed capacity earns instead.

Sequencing matters because the first two recover most of the money and cost the least political capital.

What does a realistic 90-day sequence look like?

Days 1 to 15: policy and scope. Write the costing policy. Pick one product family and one plant, plus your top twenty customers by revenue. Resist the urge to do the whole catalog; the pattern you find in one family transfers, and the credibility you build lets you expand.

Days 16 to 45: connect and resolve. Connect the ERP, MES, WMS or carrier invoices, CRM, and the contract and rebate files for that scope. Resolve parts and customer hierarchies. Expect to find that part numbering is less consistent than anyone believes.

Days 46 to 70: compute and validate. Build the true margin calculation for that family, reconcile total allocated cost to the GL, and review the twenty worst SKU and customer combinations with the plant manager and the sales lead. Their objections are how you find the allocation errors, and their agreement is what makes the number actionable.

Days 71 to 90: act on three. Pick the three highest-value fixes and execute them: one order pattern change, one repricing, one process or freight fix. Measure the margin delta. That delta is the business case for the rest of the catalog.

Then expand family by family. The second family takes a fraction of the time, because policy, resolution patterns, and allocation logic are reusable.

What goes wrong

Boiling the ocean. Attempting all SKUs and all customers at once turns a 90-day project into an 18-month one that produces a model nobody trusts because nobody validated it.

Skipping the MES. Using standard cost for conversion because actuals are harder to get produces a number that differs from gross margin only cosmetically, and the whole exercise loses its point.

Allocating by revenue. Allocating overhead or freight as a percentage of revenue guarantees that large customers look efficient and small ones look expensive, which is often the opposite of the truth. Allocate by driver.

Not reconciling to the GL. An unreconciled model is a model finance will disown at the first challenge.

Presenting the analysis without the actions. A list of unprofitable customers with no proposed fix is an argument waiting to happen. Bring the order pattern change and the specific ask.

No refresh cadence. With input costs moving around 5.4% annually and tariff exposure shifting, a one-time study is stale within two quarters. The value comes from making it a monthly output, which is the entire argument for building the layer instead of running a consulting engagement.

How do you measure whether it worked?

• Percentage of revenue covered by a validated true margin model. Start near zero, target a majority within a year.

• Number and revenue share of negative-margin customer relationships, and how many have been fixed rather than merely identified.

• Realized price versus invoice price spread, tracked over time. This surfaces discount drift as it happens.

• Freight cost as a percentage of revenue, by customer, with expedite premiums broken out.

• Margin lift in basis points on the SKUs and customers you acted on, which is the number that funds expansion.

• Time to answer a margin question. If a quote-time margin check still takes an analyst two days, the layer is not in the workflow yet.

Common questions about SKU profitability and cost to serve

How do I calculate true margin per SKU?

Start from realized revenue (invoice price less all discounts, rebates, and allowances), subtract actual material and conversion cost from MES and purchasing actuals rather than standard cost, then assign order-level and customer-level costs by driver: freight by actual shipment, pick and pack by lines and units, expedites to the causing order, returns and rework to the SKU and customer. Reconcile the total to the general ledger.

Why doesn't my ERP show cost to serve?

Because the ERP holds standard costs for inventory valuation and absorbs overhead at a blanket rate, and the costs that drive cost-to-serve (freight actuals, pick and pack labor, expedites, returns, service intensity) sit in other systems or in SG&A. The ERP is not wrong; it is answering a different question.

What percentage of customers are typically unprofitable?

Cost-to-serve studies commonly find 20% to 40% of customers lose money once fulfillment, service, and administrative costs are allocated. They are frequently among the largest by revenue.

Do I need to replace my ERP?

No. The ERP remains the transactional system of record. A data layer reads from it and from the MES, CRM, logistics, quality, and contract sources, and holds the resolved entities and costing logic the ERP was not designed to carry.

What about activity-based costing? Isn't this the same thing?

It is the same intent with a different implementation. Classic ABC failed at many manufacturers because it was a periodic consulting exercise that produced a static model requiring manual data collection. Building the same logic on a connected data layer makes it a monthly output rather than a project, which is the difference between a study and a management system.

How does downtime affect margin per SKU?

Directly, through absorption and through expedite cost. With average downtime near 800 hours per manufacturer per year, lost capacity raises per-unit cost on everything that did run and forces premium freight or overtime on the commitments that slipped. Attributing downtime to the SKUs and orders it affected connects maintenance decisions to margin.

Should I drop unprofitable SKUs?

Only after checking dependencies. A SKU that shares tooling, a setup, or a material minimum with profitable products can make the portfolio worse if removed. Fix order pattern and price first, then rationalize with dependencies mapped and a view on what the freed capacity earns.

How long does this take?

One product family at one plant with the top twenty customers is realistic in about 90 days including validation. Subsequent families are considerably faster because the policy, entity resolution, and allocation logic are reusable.

What is the single highest-value first step?

Writing the costing policy, then computing realized price versus invoice price by customer. Discount drift is usually the largest single leak and requires the least new data to find.

Sources

• Cost & Profitability, "Cost to Serve: true cost per customer" (20% to 40% of customers unprofitable once fulfillment, service, and administrative costs are allocated): costandprofitability.com

• Deloitte, "2026 Manufacturing Industry Outlook" (80% plan to invest 20% or more of improvement budgets in smart manufacturing; input costs expected to rise approximately 5.4%; 78% cite trade uncertainty as their primary concern; over 81% of manufacturing task hours projected to remain human-controlled; AI integration with ERP, MES, and PLM supporting up to 40% downtime reduction): deloitte.com

• Info2Soft, "Unplanned Downtime Cost (2026 Updated)", compiling Deloitte's average of approximately 800 hours of equipment downtime per manufacturer per year and Fluke's 2025 Global Survey figure of approximately $852 million per week in downtime losses across global manufacturing: info2soft.com

• REA Advisory, "The Executive's Guide to Manufacturing Cost Analysis: Finding the Margin Leaks Hiding in Your P&L" (gross margin averaging concealing SKU heroes and villains; fuzzy COGS policy; landed cost and absorption treatment): reaadvisory.com

• GSquared CFO, "Beyond Gross Margin: Calculating True Product Profitability in Manufacturing" (true product profitability requiring connected ERP transactions, production schedules, quality records, and time tracking): gsquaredcfo.com

• Gartner, "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027" (June 2025): gartner.com

OutcomeCatalyst connects the systems you already run into a governed intelligence layer your team and your agents can reason over. Demos on this site use fictional data. To see this on your own SKUs and customers, start a conversation.