Identifiers should identify things, not accidentally become calculations

Before calculating on a field, ask one question: What is the unit?

Revenue has dollars. Delivery time has days. Quantity has items. A percentage has a defined numerator and denominator.

Now ask the same question of an account ID, invoice number, ZIP Code, GTIN, or internal record key. The answer is usually not “units,” “days,” or anything else that arithmetic can describe. It is an identifier: a token used to point to a specific entity, record, product, place, or transaction.

That distinction is easy to overlook because many identifiers are written with digits. But digits do not make a field a measurement. An average customer ID of 481,203 may be mathematically computable, yet it has no business unit and says nothing about customer value, size, tenure, or behavior.

The issue is not merely a spreadsheet mistake. It is a category error.

Values measure; identifiers refer

A value describes an amount, duration, rate, or other measurable property. Arithmetic changes or summarizes that property in interpretable ways. Adding monthly revenue produces total revenue. Subtracting two dates produces elapsed time. Averaging delivery days can describe typical delivery performance, provided the population is defined.

An identifier has a different job. It supports matching, grouping, tracing, deduplication, and retrieval. NIST describes identifiers as unique labels associated with entities, and its data-format guidance characterizes them as strings that serve as shorthand references.

This produces a practical rule: if changing an ID from 00421 to 00422 does not mean the underlying entity became one unit more of something, subtraction and averaging are not meaningful.

Counting can still be useful. A report may show 2,000 distinct account IDs. But even that needs a definition. Does each ID represent one customer, one legal entity, one account location, or one account that may no longer be active? A distinct count measures the identifier assignments within its stated scope. It does not automatically answer every question about the business population.

Polished nonsense is still nonsense

Many analytical errors involving IDs look credible because the formulas work.

Consider a sales review that includes an average customer ID. The number may contain decimals, trend over time, and fit neatly into a dashboard. None of that gives it meaning. If the question concerns customer value, a useful measure might be average revenue per customer over a stated period. If it concerns tenure, use an appropriately defined start date.

Or consider invoice numbers 7102 and 7115. It is tempting to infer that 12 invoices are missing. That conclusion needs evidence about how the numbers are issued. Sequence-generated values can have gaps from voided work, retries, aborted transactions, migrations, deleted records, reserved ranges, or multiple issuing systems. PostgreSQL documentation, for example, explicitly warns that sequence objects do not provide gapless sequences.

A sequence may help staff locate a record or troubleshoot an issue. It is not automatically a clock, a volume measure, or an ordinal ranking.

The same caution applies to codes with visible structure. ZIP Codes have postal-routing logic, and product identifiers may include issuer information or check digits. Structure can support a documented operational use. It does not authorize a team to average codes, treat their numerical order as geographic distance, or infer facts the issuing authority does not define.

Preservation matters as much as interpretation

Treating identifiers as numbers can also alter them before anyone analyzes them.

A five-character code such as 00501 becomes 501 when a system removes leading zeroes. The altered value may no longer match the reference table that retains the original code. Some identifiers also include letters, fixed-width formatting, or check characters. Product identifiers such as GTINs are digit strings, but their digit representation and check digit are part of the identifier system, not evidence that they are quantities to total.

Long identifiers introduce another risk. In JavaScript, ordinary Number values only represent integers exactly through 2^53−1. Parsing a larger integer-like identifier as a Number can change its identity. Keeping it as a string avoids that particular coercion risk.

“Store every ID as text” is too blunt a technical rule. A system may efficiently use integer, UUID, binary, or a dedicated identifier type. The more durable requirement is semantic: preserve the identifier faithfully and restrict its use to operations that fit its role.

A short review before calculation

A useful data review can begin with four questions:

1. What does this field identify or measure? Name the entity if it is an identifier, or state the unit if it is a measure. 2. What operations are permitted? Exact match, approved normalization, joins, uniqueness checks, grouping, and distinct counts are often appropriate for IDs. 3. What would arithmetic mean? Require a plain-language business definition before allowing a sum, average, difference, minimum, or maximum. 4. Who defines the field? Record the authoritative system, scope, formatting rules, and whether apparent sequence or embedded segments have documented meaning.

A data dictionary can make this durable. For example: “Supplier_ID — identifier; scope: supplier master; format: case-sensitive string; permitted operations: exact match, approved normalization, distinct count, and join; not a measure or chronology.”

There is one narrow exception worth separating from measurement: validation. A checksum may be calculated from identifier characters to catch transcription errors. That calculation tests whether a token is plausible under its format rules. It does not turn the identifier into a business metric.

When a reporting tool suggests Sum(Account_ID), treat the suggestion as a schema warning, not an insight. A good field type does more than prevent formatting damage. It tells people what questions the data can honestly answer.

Identifiers should identify things. Measures should measure them. Keeping those roles separate is one of the simplest ways to prevent tidy-looking analysis from becoming meaningless.