Material declaration rejections are treated as a data quality problem: someone typed the wrong thing, so the fix is to type more carefully. Across the rejection sets we have analysed, that framing explains very little of what actually happens. The overwhelming majority trace back to four structural causes, and each is a process fix rather than an accuracy fix.
Cause one: the substance master is stale
Restricted substance lists move. A declaration built against last year's list is not a typing error, it is a synchronisation failure. Plants that pull the current list at submission time rather than maintaining a local copy see this category almost disappear.
Cause two: supplier data arrives in an unusable shape
Declarations come back as free-form email, scanned PDFs, and spreadsheets with inconsistent headings. Someone retypes them, and retyping is where the transcription errors enter. The fix is extraction with the source page retained, so the value and its evidence stay attached.
Cause three: weight and composition do not reconcile
Component weights that do not sum to the assembly weight, or percentages that do not total 100, are caught by the receiving portal but almost never before submission. This is a validation rule that costs nothing to run locally and is simply not being run.
Cause four: the rulebook differs per customer
The same part submitted to two OEMs can pass one and fail the other, because each maintains additional requirements above the shared standard. Teams that keep one submission template treat the strictest customer's rules as universal, or accept a rejection rate as the cost of doing business.
What changes when validation moves earlier
Moving the check upstream turns a rejection loop measured in weeks into a correction measured in minutes. The second-order effect matters more: PPAP gates stop slipping, and the compliance team stops spending its week on rework it could not have prevented.
The teams that improve fastest are not the ones with better data. They are the ones that stopped treating the customer's portal as their validation step.
Written from deployment experience across multiple sites. Patterns are described without identifying any customer — we are under confidentiality with the operators involved.
Talk to an engineer about this