Connected work
Keep a customer reference as a reference, not an accidental number
A code can lose meaning when a spreadsheet or connection treats its characters as a quantity.
A customer supplies reference “00127.” After an export and re-import, the office sees “127.” The value looks similar, but it may no longer match the customer's record. Some fields contain identifiers rather than amounts.
Classify the field by its job
For a fictional Estonia-connected distributor, list order numbers, product codes, customer references and quantities separately. Ask whether leading zeros, punctuation or letters are meaningful. A field containing digits is not automatically a value that should be calculated.
Keep the intended meaning in the specification and sample data. Otherwise a later spreadsheet export or supplier connection can repeat the same conversion even after the website field has been repaired.
Allow an understandable correction
Tell users the expected format where it matters, and avoid rejecting a valid reference merely because it differs from one convenient example. W3C's input-validation guidance discusses helping people avoid mistakes and accommodating input formats appropriately.
If a reference must be changed, decide who may change it and what happens to linked records. Quietly normalising every code can hide a mismatch that staff need to investigate.
Test the complete round trip
Use invented references with leading zeros, a hyphen, a letter and a length beyond the most common case. Enter, export and import them through the actual agreed workflow. Compare the characters and the record relationships, not just whether each stage accepted the file.
A system connection should preserve this meaning. Clear field definitions and a few carefully chosen examples can prevent an apparently successful transfer from changing the business's identifiers.
Further reading: W3C guidance on useful input validation.