There is no single correct part numbering scheme for your hardware parts, but there are many wrong ones.

When building your hardware products and using a BOM (Bill of Materials) to define the discrete components, a Customer Part Number (CPN) is required for each individual line item. A more human readable name is also used, but these can be abstract and open to interpretation. So, fixed, alphanumeric strings with consistent formats is much more reliable, and the default reference used by professional hardware manufacturing teams.

Every hardware company is entitled to design their own CPN scheme that best fits the requirements and characteristics of their own products and processes – but it’s crucial to think it through properly and design one that won’t lead to mistakes in production.

The most important concept to keep in mind when designing your scheme is that:

There must not be any room for subjectivity or interpretation. The rules for assigning a CPN to a new part must be clear and concise.


Let’s start with some basic terminology. There are two extremes when picking a CPN scheme: Intelligent and Non-Intelligent, and then variations in between.

Non-intelligent CPNs are simple, usually 5-10 digit numeric values that are sequentially incremented and assigned for each new part as it’s added to your company’s part library – regardless of what the part is or does.

Intelligent CPNs are complex alphanumeric strings where each character has a significance and meaning to it, usually tied to the parametrics and usage of the part.

Non-Intelligent CPNs are simple and fast to implement, and require no thought process when assigning new values. They are effectively limitless and infinitely expandable as your product evolves and new parts and part categories are added to your library. However, as a result of this flexibility, they are very hard to “read” and know what the part may be, without cross-referencing some other piece of information. This additional work can lead to delays and mistakes.

Intelligent CPNs on the other hand, usually can be deciphered from simply reading the CPN value itself (following a ruleset that explains the meaning of each character), such that one will know exactly what the part is just from the written CPN value. This provides a lot of efficiency in the procurement and assembly processes. However, it requires a lot of upfront design work and foreshadowing so you don’t design a scheme that ultimately paints you into a corner and doesn’t allow for a unique CPN value for some new part or part category added to your library. The worst thing to do is to modify the CPN scheme part way through production to accommodate a new part category that wasn’t thought of at the beginning.

The best solution is a hybrid of the two – where there is a short (3 or 4 digit) prefix code which defines the part category, with a longer (5 to 7 digit) counter suffix that is incremented with each new instance of the category. This is often referred to as a Semi-Intelligent CPN scheme. The design of these CPN solutions makes it easy to add new prefixes as new categories are added to your product in the future, but the granularity is coarse enough that it’s fast and simple to assign new CPN values when new parts are added to your library.

The Chosen One

My favorite scheme is a <3> – <5> format, with a 3-digit numeric category prefix, a 5 digit numeric suffix counter, and a hyphen between the two to create an easy visual separation to enhance readability. This allows for 999 unique categories and 99,999 unique parts per category. I challenge any team to run out of unique part numbers using this scheme!

Do’s and Don’ts

When designing your CPN scheme, there are several key things to remember:

  • Do use consistent fixed length numeric CPN schemes

  • Don’t use alphabetic characters

  • Don’t use a mix of coarse and fine granularity in your category list

  • Don’t use variants

  • Don’t use leading 0’s


When selecting your list of categories, the only decision to make is how coarse or fine you want to make them. For example, you could simply have only two categories:

  • Purchased

  • Custom

For some teams this works just fine. Or you can go the other extreme and list out every possible category imaginable

  • Resistor

  • Diode

  • LED

  • Capacitor

  • Screw

  • Bold

  • Nut

  • Washer

  • etc..

The only important thing is to make sure there’s no room for interpretation, where two different people could reasonably have picked two different categories for the same physical part. This happens when category lists include a mix of some generic (coarse) terms and some specific (fine) ones.


I’m probably going to get some pushback on this next topic, since I still see many engineering teams implementing it – even though I think it’s a horrible idea. I’ve seen teams use a 3rd field in their CPN scheme to define variants of a part or assembly. It’s often represented as a 2 or 3 digit suffix, which defaults to 00 for the first instance of a part. When a “variant” of a part is added to the library, the base CPN value is kept the same, but the variant field is incremented. It’s used to show there is some form of relationship between two parts, but not enough for them to be considered exactly the same.

Why is this bad? Because it leaves room for interpretation. Two people may reasonably disagree on whether two parts are completely unique or just variants of each other. This can happen when the rules for what constitutes a variant aren’t clear.

Parts are defined by their parametrics. Anytime two parts have different parametrics, they are not considered the same, in a strict literal sense. But, all parametrics are not assigned equal priority by all people. So, engineers will result in subjectively selecting which parametrics constitute two parts being different and which parametrics are considered equivalent.

When you have a variants field in your CPN technology scheme, it exacerbates the problem, by empowering someone to make a subjective decision on the matter, which ultimately leads to inconsistencies in your parts library. It always happens: one group of parts were considered unique enough to warrant their own CPN values, but another group of parts were not. In isolation, these individual decisions may have made sense, but objectively, two different rules were ultimately used to make these decisions. Anyone not involved with these decisions (i.e. a 3rd party Contract Manufacturer or supplier) may get confused by the inconsistencies and result in making a costly mistake in production. Just don’t do it. The value of “grouping” like parts into variants with CPN software is far outweighed by the risk of making a mistake in production.

What CPN schemes have you used that you’ve found efficient and easy to enforce?