What NetSuite Misses for CPG Brands Selling to Retail

Cinderhaven Provisions runs on NetSuite. The CFO can pull margin by SKU, on-hand by lot, and landed cost to the cent. Walmart's item file still shows the wrong case cube on nine of Cinderhaven's fifty SKUs, and it has for a year. Those nine wrong numbers are the visible edge of a wider gap between what NetSuite knows and what the retailer's system checks, and that gap costs about $93,000 a year in chargebacks.

Cinderhaven is a fictional company and its ledger is a synthetic dataset; the data-quality failures it illustrates, and the retailer validation rules behind them, are real.

Gartner's survey of 154 large enterprises put the average cost of poor data quality at $12.9 million a year. Cinderhaven is not a 154-enterprise survey. But the mechanism scales down without losing its shape: the numbers a brand keeps for itself can be perfect while the numbers it sends the retailer are wrong, and the retailer only charges for the second kind.

NetSuite stores one list of fields. The retailer checks another.

NetSuite is built to answer finance's questions. Its item record carries cost, on-hand, lot, GL account, and reorder point: the fields that close a month. What it does not carry, in the form the retailer needs, are the fields receiving checks.

A case has to publish structured dimensions in GDSN units, a packaging hierarchy where every level has its own GTIN, dimensions, and weight, and allergens entered as GS1 codes rather than text. Enter an allergen as free text instead of the code and Kroger's system cannot read it, and the submission fails validation. A stock ERP item record was not designed to enforce any of that.

These are the master-data fields the retailer actually checks, and they sit at the edge of what an ERP was built to hold. NetSuite is not wrong to leave them out. It was built for the ledger, and the ledger does not care what the pallet height is.

A parallel spreadsheet is where the divergence lives

So the brand keeps those fields somewhere else. The case cube, the Ti-Hi, the retailer item numbers, the GDSN attributes: they go in a spreadsheet, a PIM, or the retailer portal by hand, maintained alongside NetSuite instead of inside it (Cinderhaven's spreadsheet is titled FINAL_v7, and it is neither). Now there are two records for every SKU, and nothing forces them to agree.

Change a case pack in NetSuite and the spreadsheet still says the old count. Fix the portal and NetSuite never hears about it. Two records, no referee. Cinderhaven does not have a product-data problem so much as a reconciliation problem it created by keeping the same fact in two places.

The data pool that publishes those fields to every retailer does not fix this. It publishes what the brand puts in it. It never checks the value against NetSuite, because it cannot see NetSuite.

The retailer's system never forgets a wrong case cube

A wrong field does not fail once. It fails every time the retailer's system reads it. A single keying mistake turns into a chargeback, then into the same chargeback on the next shipment, because none of the downstream steps re-verify it.

The audit that put a dollar figure on Cinderhaven's defects traced $93,000 a year to product-master fields that NetSuite holds in one form and the retailer checks in another. Grouped by the gap each field exposes, the audit's $93,000 falls into three buckets:

| Defect the retailer catches | The field NetSuite doesn't hold in retailer form | Annual | |---|---|---| | Case cube / pallet Ti-Hi mismatch | structured case dimensions in GDSN units | $46,000 | | Item setup rejected and resubmitted | GS1 allergen codes, net content, per-level GTINs | $28,000 | | Invoice UOM / retailer item-number mismatch | retailer-specific item numbers and units of measure | $19,000 | | Product-data chargebacks (the audit's figure) | | $93,000 | | Reconciliation labor (added here) | the spreadsheet that keeps NetSuite and the portal in sync | $10,500 | | Chargebacks plus reconciliation labor | | $103,500 |

The $93,000 is the audit's number: three chargeback rows, all visible on the remittance. The row beneath it is the article's addition, and it is the quieter cost. Keeping two systems aligned by hand runs about six hours a week, 50 weeks a year, at $35 an hour loaded. It buys nothing except the absence of even more divergence, and the reconciliation is never finished, because the week it is, marketing renames a SKU or operations changes a case pack.

NetSuite is right about the inventory. The retailer is wrong about the item. The brand fed them both.

The fields were never hard. They were never anyone's job.

The audit's finding was not that Cinderhaven needed a new system. It was that 27 hours of correct data entry, done once against the retailer's own validation rules, cleared most of the $93,000. Nobody had done it because NetSuite did not ask for those fields and the retailer asked only once, at setup, then billed for the answer every shipment after.

Making it hold takes two things. First, one system has to be authoritative for the retailer-facing fields: NetSuite carrying the right custom fields, a PIM, or the data pool itself. Everything else copies from it, never the other way.

Second, every value gets reconciled against reality before it publishes. The pool's format rules already reject a malformed hierarchy on their own; what they cannot catch is a well-formed number that is wrong. The check that matters is physical: the case cube on file equals the carton on the scale, the GTIN keys to the item the retailer ordered, the pack count equals what ships. A well-formed wrong number is what a chargeback is made of.

Correcting the fields takes hours. Finding out they were wrong, one chargeback at a time, takes $93,000 a year. A brand gets to choose which of those it pays for.

Put your two records side by side

Most brands have never read their NetSuite item record and a retailer's item file for the same SKU in one view. Do it for a single SKU and the disagreements surface immediately; do it across the catalog and you have a chargeback map. I will run that comparison and rank the mismatches by what each one costs a year, and the case cube is usually the first line that does not match. Let's find the first disagreement.