Product master data and high-volume e-invoicing: the error that multiplies
A food manufacturer issues ten thousand invoices a day. None of them is complicated: product, quantity, price, tax. The problem is not in any single invoice — it is that the same wrong master-data decision repeats ten thousand times before anyone notices.
At low volume, a bad product record is an annoyance: someone fixes it by hand and life goes on. At high volume, a bad product record is a divergence factory. And the divergence does not show up at issuance — it shows up weeks later, at assessment, when three hundred thousand invoices already carry the same defect.
The four fields that decide everything
A material record has hundreds of fields. Four of them decide almost every tax divergence in consumer goods.
Tax classification code. It determines the rate, tax substitution and any benefit. A wrong code does not block issuance — the invoice is authorized normally — and only becomes a problem when the authority cross-checks the classification against the rate applied.
Substitution code. Required when the product is subject to tax substitution. Missing where it should be, or present where it should not, causes rejection in some states and passes in others — which makes the error look intermittent.
Goods origin. The digit stating whether the product is domestic, imported, or domestic with imported content. It looks like paperwork until an imported-content audit arrives.
Taxable unit of measure. The one on the invoice is not necessarily the one the business uses. Selling by the case and taxing by the kilo requires a conversion factor — and that is where rounding enters.

Finding the defect before assessment
The practical question is: how do you know a master-data problem exists without waiting for the close? The answer is comparing the master data against itself — similar products should carry similar classification, and when they do not, someone got one side wrong.
One survey that yields more than it looks, straight against the database:
-- products with similar description and divergent classification
SELECT a.matnr, b.matnr, a.ncm, b.ncm, a.maktx, b.maktx
FROM zv_material a
JOIN zv_material b
ON LEFT(a.maktx, 18) = LEFT(b.maktx, 18)
AND a.matnr < b.matnr
AND a.ncm <> b.ncm
WHERE a.mtart = 'FERT'
ORDER BY a.maktx;
The result is rarely short the first time. And a good share of it is false positives — a similar description does not require identical classification. The value is not in the list: it is in the fact that every line is a question nobody had asked.
The other three checks worth the effort:
- Product with a substitution code and a classification that does not allow substitution — and the reverse, which is more common.
- Imported-content origin without the supporting content record — the field exists, the document backing it does not.
- Missing conversion factor on a product whose sales unit differs from the taxable unit.
What goes wrong, with names
The record created in the middle of an order. A new customer orders a product that does not exist, the order cannot wait, someone creates the material by copying a similar one. The copy carries the original’s classification — and nobody goes back to check. It is the most common source of divergence in consumer goods, and it is organizational, not technical.
The fix that does not go backwards. Correcting the classification today fixes tomorrow’s invoices. The three hundred thousand already issued with the old value are still there, and the authority looks at the whole period. Fixing master data without deciding what to do about the past is half the job.
Rounding by case. Selling in cases of 12 and taxing by the kilo produces a repeating decimal. Rounding per line, per invoice or per total gives different results — and at ten thousand invoices a day the difference stops being cents.
The rejection that happens in only one state. A different state rule makes the same record pass in one place and fail in another. The team concludes “the problem is that state’s authority” and creates a local exception, instead of fixing the record.
Where AI genuinely helps here
Tax classification is interpretation of the norm and stays human. But three expensive parts of the work are reading and comparing at volume — exactly where the economics change.
Grouping products that should share a classification. Free-text descriptions, written by different people over ten years, hide the fact that “SODA CAN 350” and “Soft drink can 350ml” are the same thing. Grouping by similarity and showing the classification divergence inside each group turns a base of thirty thousand materials into a list of two hundred decisions.
Reading the norm and pointing out what changed. Classification tables and substitution agreements change. Finding which of your products are affected by a published change is reading at volume with a clear criterion.
Explaining the rejection. The authority’s message usually points at the symptom, not the cause. Cross-referencing the rejection against the product record shortens the investigation from hours to minutes.
Where it does not belong: deciding the classification, signing the assessment and answering for the correction. Those three stay with people, with names and with accountability.
The honest limit
None of this eliminates divergence. Tax classification has a genuine grey zone — two competent professionals disagree about the same product, and both can defend their position. Anyone promising master data without divergence is selling something that does not exist.
What changes is different: the divergence stops being discovered by the auditor and starts being chosen by you. A classification you know is debatable, with the reasoning recorded, is a defensible position. The same classification with nobody aware it was there is an assessment notice.
And there is a second-order effect that only appears later: once the master data has an owner, the question “why is this product classified this way?” has an answer in minutes. Today, in most companies, it has no answer at all.
If the starting point is understanding what exists before touching anything, start with the IT diagnostic. For the sector overview, see IT for consumer goods and food. And if the problem is already the volume of invoices arriving, the path is reading the XML and classifying inside SAP — and, before any load, cleansing the master data.