Keep a product code separate from the description in your preparation records, even when the current tool cannot export it as a dedicated field. A description explains what was supplied. A product code identifies an item within a particular catalogue or identifier system. Neither should be assumed to perform the other’s job.
This distinction supports the line-item workflow by preserving meaning before you choose a delivery format. The current creator provides a description field but no separate seller-item, buyer-item or standard-item identifier fields. A code written inside the description remains text in the application’s exports.
Identify who owns the code
Ask whether the code belongs to your catalogue, the customer’s catalogue or a shared identification system. The same supplied product can have different values in each. A customer stock number should not silently replace your own product identifier in records where the seller’s code is expected.
For example, your replacement cartridge might be RF-8 while the buyer calls it MAINT-042. Both can refer to the same product, but they have different owners and roles. Retain the relationship in the preparation record rather than assuming one value is universally recognised.
Avoid inferring a code’s role from its appearance. A numeric value is not automatically a global identifier, and an alphanumeric value is not necessarily an internal stock code. Confirm the source and intended use before moving the value into another system’s item field.
Preserve the exact value
Treat identifiers as text. Leading zeros, letters and separators can be significant. If a spreadsheet turns 000742 into 742, it may have changed the item identifier even though the resulting number looks reasonable. Check imports and copied values against the original source.
Do not remove punctuation merely to make several catalogue styles look consistent. A hyphen might be part of the code or only display formatting; establish which before altering it. Keep any agreed formatting rule with the source records so future invoices do not repeat an unverified change.
When a product has several variants, check the code for the actual supplied variant. Similar descriptions can hide differences in size, compatibility or packaging. A correct generic name does not establish that the selected identifier matches the delivered item.
Keep the description useful to people
A line containing only an unfamiliar stock code may be difficult for an accounts reviewer to understand. Include a recognisable product name and the distinguishing specification. The code can support matching, while the wording allows someone outside the purchasing team to identify the supply.
If you include a code in the current description, make its role readable where needed, such as “Seller item RF-8, replacement filter cartridge”. Do not imply that this placement creates a typed seller-item identifier in JSON. It remains part of one text field.
Avoid using the buyer’s purchase-order number as though it were a product code. An order reference identifies a procurement document, while an item identifier identifies the supplied product. Those roles remain distinct even when the customer asks for both on the invoice.
Understand a formal field example
Peppol BIS Billing documents a seller-assigned item identifier as its own business term within the item data. That illustrates why a separate field has meaning beyond visible text. A receiving system can address the identifier by its structural location rather than extracting it from a sentence.
The current creator does not implement that mapping or the corresponding standards export. Copying the documented field name into a description does not create the field. If the recipient requires typed item identifiers, use a tool or adapter that genuinely supports the intended profile and validates the resulting document.
Preserve any required identifier type and scheme information in your preparation records. A future mapping needs more than an unexplained value. It should know which party assigned the identifier, what item it represents and any profile-specific information required to express it correctly.
Reconcile codes with the order
Before export, compare the description and identifier against the accepted order and delivery evidence. If the customer ordered one variant but received a substitute, resolve how that substitution should appear. Do not keep the original code beside a description of a different product merely to make automated matching easier.
Check grouped lines carefully. Several variants under one generic row can make a single product code misleading. The guide to quantities for individually sold goods explains how item identity and quantity basis need to agree before the amount is calculated.
Retain the reviewed mapping with the invoice records and inspect any later transfer into a standards-capable system. The exported application JSON and CSV do not promise catalogue validation or typed product-code support. Clear preparation prevents information loss, while formal format requirements still need to be implemented and checked in the system used for final delivery.
Where a buyer supplies a replacement catalogue code, confirm when that code became effective. An old order may still use the previous identifier. Keep both the original order value and the confirmed current mapping so a later reviewer can follow the change without assuming the product itself changed.