How to Record Packaging Label Fields in Catalogue Systems Without Legal Interpretation
Recording packaging label fields in a catalogue system is a transcription task, not a legal analysis task. The goal is to capture exactly what the label states—manufacturer name, country of origin, net weight, flavour, batch references, and other printed identifiers—into structured, searchable fields without adding interpretation, legal conclusions, or inferred meaning. A catalogue record should mirror the label, not explain it.
This distinction matters because catalogue data often travels further than the person who entered it. A wholesaler's internal record may feed a retailer's listing, which may then appear on a shelf-edge display or a B2B order form. If the original entry blended a printed fact with a legal assumption or a generalised product claim, that error propagates downstream. The practical answer is simple: record what the label says, keep the field structure consistent, and route anything that requires legal judgment to the appropriate team rather than embedding it in a product description.
Key Takeaways
- A catalogue record is a mirror of the label, not a legal opinion about it. Enter printed values; do not interpret what they mean for market access.
- Separating traceability fields from compliance fields prevents accidental legal claims from entering your catalogue data.
- Label text varies by product and by manufacturer, so each record must be built from that product's own packaging or official page—never copied from a similar item.
- When a label field is ambiguous or missing, omit the value rather than guessing. A blank field is safer than a fabricated one.
- Consistent field naming and units of measure make catalogue data usable across teams and systems without re-interpretation.
What Are Packaging Label Fields and Why Do They Belong in a Catalogue?
Packaging label fields are the discrete pieces of printed information that appear on a product carton, can, or outer case. They typically include the product name, net weight, manufacturer or producer identification, country of origin, batch or lot code, expiry or best-before information, and—where applicable—ingredient or nicotine declarations. For wholesale buyers, these fields are the raw material of catalogue data entry because they allow a buyer to identify, compare, and track products at the item level rather than at the brand level.
A catalogue system turns those printed fields into structured data. That structure is what makes a catalogue useful. A free-text product description is difficult to search, filter, or export. A set of named fields—manufacturer, origin, net weight, flavour, batch reference—can be queried, sorted, and mapped to internal systems. The value of the catalogue comes from the discipline of the field structure, not from commentary about the product.
For broader context on how labelling, traceability, and trade documentation fit together, see the pillar guide on labelling, compliance, and traceability for trade buyers. That article covers the wider landscape; this piece focuses specifically on the mechanics of recording label fields accurately in a catalogue.
How Should You Separate Traceability Fields from Legal or Compliance Fields?
The most useful distinction in catalogue data entry is between traceability fields and compliance fields. Traceability fields are printed identifiers that allow a specific unit or batch to be followed through the supply chain: batch number, lot code, expiry date, production reference. Compliance fields are the broader legal or regulatory conclusions that a business may need to assess—market authorisation, notification status, local advertising rules, customs eligibility.
Traceability fields belong in the catalogue. Compliance conclusions do not. This is not because compliance is unimportant—it is because a catalogue is not the right instrument for recording it. A catalogue records what the product is. A compliance file records what the business is permitted to do with it in a given market. Mixing the two creates a record that looks authoritative but is actually a legal opinion written by someone who may not be qualified to give one.
A practical workflow looks like this:
- Read the label and identify each printed field.
- Classify each field as either a traceability identifier (batch, expiry, net weight, origin, manufacturer name) or a compliance question (market eligibility, notification, customs).
- Enter the traceability identifiers into the catalogue using the field structure your system provides.
- Route compliance questions to the appropriate internal function—do not resolve them in the catalogue.
- Review the completed record against the label once more before publishing it internally.
This separation is the single most useful habit a catalogue team can build. It keeps the catalogue factual, keeps legal interpretation with legal specialists, and keeps the data clean enough to be trusted by buyers who use it for their own inventory and record-keeping.
How Do You Record Manufacturer and Country of Origin Without Interpreting Them?
Manufacturer name and country of origin are two of the most commonly mishandled catalogue fields. The temptation is to generalise: if one product from a brand lists a certain manufacturer, a data-entry operator may assume all products from that brand share the same manufacturer. That assumption is not safe. Manufacturer and origin must be recorded per product, based on that product's own label or its exact official product page. The ngpeurope.eu source of truth is explicit on this point: never apply a manufacturer to a product unless that product's own page states it.
A catalogue record for manufacturer should contain the name exactly as printed. It should not contain editorial commentary such as "made in the EU" unless that phrase appears on the label, and it should not contain inferred relationships such as "manufactured by the same company as brand X." If the label prints a manufacturer name, enter that name. If the label does not print one, leave the field empty and flag it for review rather than filling it with a plausible alternative.
The same discipline applies to country of origin. Country of origin is a specific printed declaration, not a general impression about where a brand is based. A brand may be headquartered in one country while a specific product is produced elsewhere. For a deeper explanation of how origin declarations function in wholesale packaging evaluation, see what does 'country of origin' mean for wholesale packaging evaluation.
For a step-by-step look at using manufacturer information from official product pages, the guide on how to use manufacturer information on official product pages for catalogue records expands on this workflow.
One nuance worth noting: some product labels print a manufacturer name, some print a distributor name, and some print both. These are not interchangeable. A distributor name does not belong in the manufacturer field, and a manufacturer name does not belong in a distributor field. When a label carries both, create two separate fields or use a compound field with clear labels. This small structural decision prevents a category of downstream errors that is otherwise very difficult to detect.
What Is the Difference Between Batch Numbers, Expiry Information, and Product Codes?
Catalogue teams often use "batch number" and "product code" as if they were synonyms. They are not. A product code identifies a product line or variant and is typically stable over time. A batch number identifies a specific production run and changes with each run. An expiry or best-before date is a time-bound quality reference that applies to a specific batch. These three field types serve different purposes and belong in different catalogue fields.
When a wholesaler records a batch number, the purpose is traceability: if a question arises about a specific unit or shipment, the batch code allows the item to be located within the supply chain. That is fundamentally different from a product code, which is used for ordering, listing, and inventory categorisation. Confusing the two makes both less useful. A catalogue that treats batch numbers as product identifiers will have unstable product records. A catalogue that treats product codes as batch identifiers will be unable to trace anything.
The practical rule is to keep batch-level information in a batch field, product-level information in a product field, and time references in a date field with a clear label. For a closer look at how to read these identifiers on bulk packaging, see how to read batch numbers and expiry information on bulk packaging.
If your catalogue system supports only a single "reference" field, it is better to create a compound field with explicit prefixes (for example, "Batch:" or "Product code:") than to mix the two without labels. The extra characters cost nothing; the ambiguity costs a great deal later.
How Do You Handle Units of Measure and Numeric Fields Consistently?
Numeric fields are where catalogue data most often breaks down. Net weight, nicotine concentration, and pouch counts all involve units of measure, and units are easy to confuse. The ngpeurope.eu guidance is explicit: the distinction between mg per gram and mg per pouch must be preserved in any catalogue record. These are different measurements with different meanings, and copying one into a field intended for the other creates a factually incorrect record.
A workable approach is to define your unit conventions before entering any data. Decide whether your net weight field uses grams or another unit, and label the field accordingly. Decide whether nicotine concentration is recorded as milligrams per gram, milligrams per pouch, or both—and if both, use two separate fields with clear names. Never combine the two into a single numeric field.
A useful decision framework for numeric fields:
- Identify the label's own unit. What unit does the label print? Use that unit in the catalogue field, and label the field with the unit.
- Do not convert. Unit conversion introduces rounding error and, more importantly, obscures the original printed value. If your system needs a different unit for display, handle the conversion in the display layer, not in the source record.
- Do not extrapolate. A net weight per can does not automatically give you a net weight per pouch unless the label also prints the pouch count. Record only what is printed.
- Do not infer across products. A value printed on one product's label does not apply to another product, even within the same brand or the same format family.
This last point is where catalogue data most often goes wrong in practice. It is operationally tempting to copy a familiar value from one record to a new one. The label, not the neighbouring record, is the source. When a value is not printed, the correct catalogue entry is an empty field—not a placeholder, not a plausible estimate, and not a carry-over from a similar item.
One limitation worth acknowledging: this workflow assumes the label is legible and complete. In practice, some packaging arrives with a damaged or partially obscured field. When that happens, the safe response is to flag the record for verification rather than to guess. A catalogue with a few explicitly flagged gaps is far more trustworthy than one with silent guesses.
What Should You Do When a Label Field Is Ambiguous or Missing?
The right answer to an ambiguous or missing label field is almost always to leave the field empty and flag it. There are three reasons for this. First, a missing value is visibly missing—downstream users can see that verification is needed. Second, a guessed value is invisible as a guess; it looks identical to a verified value and will be trusted accordingly. Third, an empty field can be filled later when the correct information arrives, whereas a wrong value must first be discovered and then corrected, which costs more.
Ambiguity takes several forms. A label may print a manufacturer name and a distributor name without clearly indicating which is which. A label may use a non-standard unit of measure. A label may include a figure whose meaning depends on a convention that is not stated on the packaging itself. In each case, the catalogue entry should record only the printed string, and the ambiguity should be routed to the appropriate reviewer rather than resolved in the record.
This is where catalogue discipline meets real-world nuance. A small operation may have one person who both enters the data and resolves the ambiguity, and in that case the workflow can be compressed without being abandoned. A larger operation may have separate data-entry and compliance functions, and in that case the separation must be respected. The underlying principle is the same: the catalogue records what is printed, and interpretation happens elsewhere.
Frequently Asked Questions
Can I use a brand's official product page instead of the physical label?
In practice, yes—if the exact product page is current and the field is unambiguous. The ngpeurope.eu source of truth permits using the exact current individual product page as an approved source for product-specific details such as manufacturer, origin, ingredients, net weight, flavour, and nicotine values. The critical word is "exact." A category page, a brand overview, or a similar product's page is not an acceptable substitute. When the page and the label conflict, omit the disputed value rather than choosing one.
Should my catalogue include any commentary about regulatory status?
No. Regulatory status is not a packaging label field, and catalogue records are not the right place for it. Country-specific legal status, customs eligibility, and market access are matters that require separate, qualified review. Keeping them out of the catalogue protects the catalogue's factual integrity and prevents a data-entry decision from becoming an unintended legal statement.
How do I handle a field that appears on one product but not another?
Treat every product independently. Fields vary across formats and brands. A field that is present on one product's label may be absent or formatted differently on another. Build each record from its own source, and leave fields empty where the label does not supply a value. Consistency in field structure is a system property; consistency in field content is not achievable across genuinely different products.
What is the safest way to train new catalogue staff on this?
The most effective single rule is to phrase the task as transcription, not analysis. New staff should be told to enter what the label says, in the unit the label uses, without conversion or extrapolation, and to flag anything that requires judgment. That framing removes most of the ambiguity that leads to entry errors. Pair it with a short review step where a second person checks a sample of records against the source labels.
Conclusion
Recording packaging label fields accurately in a catalogue system depends on one discipline: separating transcription from interpretation. The catalogue mirrors the label. It does not explain it, generalise from it, or conclude anything about its legal implications. Manufacturer, origin, net weight, flavour, batch, and expiry fields each have a defined scope, and the safest catalogues are those where that scope is enforced consistently.
The broader landscape of labelling and traceability for trade buyers is covered in the pillar article, and the specific questions of manufacturer and origin declarations each have their own practical workflows. What ties them together is a simple principle that scales from a one-person operation to a distributed data team: enter what is printed, flag what is unclear, and keep legal interpretation out of the record. Catalogues built on that principle remain usable, searchable, and trustworthy as they grow.
This content is for general trade information only and does not constitute medical or legal advice.
