I was recently asked about my take on how to configure material/system commodity codes in ERP/Procurement systems. Here are my main takeaways from multiple implementations of a set of commodity codes.
When implementing a new Source-to-Pay solution, you can usually either put in your own hierarchy or use a standard nomenclature such as the United Nations Standard Products and Services Codes (UNSPSC). For companies that have refined their own nomenclature in legacy systems over time to have a really good, industry/business specific list that is fine tuned for their context, I advise against trying to convert to UNSPSC because the benefit is marginal in comparison with the change management impacts this will inevitably bring on. The principal benefit to using a standard like UNSPSC is that you are using a common language with the outside world. This may make your Business Network Vendor Onboarding process a bit easier as you won’t have to maintain UNSPSC to custom commodity code mappings but the majority of your vendors are not maintaining this data for their products. The real value of commodity codes is use within the company’s walls therefore you always have to consider how the data will be used later in the process to determine the best way forward.
Concrete Examples
To illustrate, here is what I view as the most important points to consider when selecting your commodity code nomenclature – the underlying assumption being that the commodity code is a set of data which should serve and be owned by procurement:
1. How are your Sourcing teams and Category Managers organized?
At the very least, you want to be able to segregate purchasing and invoicing data by responsibility. This enables reporting by category manager / procurement stream for performance tracking and RFP/go to market planning. In addition, if you can get to a granularity level where you can filter within a category to sub-categories of products which you can convert to lists with which to go to RFP, than a further granularity level adds value. But beware, complexity is the enemy of efficiency if not mastered by your team
2. How detailed do you want to get in your spend analysis?
How fragmented is the current spend environment in the company? Other than satisfying borderline OCD analysts like myself with more data, what are the tangible/intangible benefits attached to going down into further levels of granularity than, for example, “writing instruments” for everything you can write with that is purchased? I am much more of the opinion that if your maturity is low, you should start out with a simple, effective nomenclature to address your big buckets of potential savings and that you can elaborate more detailed commodity code levels for areas of spend that require it when your sourcing organization gets to higher maturity levels
3. What else will the commodity code be used for? (ie. Search, Process behavior, accounting)
If you are leveraging a commodity for for things like search (which is often done for MRO), then this can sway your nomenclature towards being much more complicated and precise so as to enable maintenance technicians and planners to find the right parts for example. Personally, I think this is a perversion of the commodity code and that the data to enable search should be captured in the material number nomenclature or in a classification mechanism (such as in SAP ECC where you assign classes and characteristics to material masters).
If you are using commodity codes to drive different processes (in solution enhancements or configurations), then you may get your hands tied later on when you want to make changes to this commodity code structure as configuration or blocks of code will require modifications before you can change your commodity codes. Therefore, be weary of mapping to these. However, that being said, it is sometimes the only valid discriminator to route a process.
If you are using commodity codes to default accounting for non-stock purchases, then you may want to bring the chart of accounts into the fold when designing your nomenclature. Usually, you will only be able to map a single General Ledger (GL) account to each commodity code so this has to be considered in the design. Usually, the business will opt for adding complexity to the commodity code structure instead of simplifying the GL structure but it’s always a valid fight to fight!
Conclusion
In short, it doesn’t really matter which nomenclature you use… As long as you have a single, common one in your organization and that it serves your purposes while being as simple as possible, you have a good commodity code nomenclature policy. People will stop spending time arguing about which codes should be included/excluded, which codes new materials should be mapped to and which configurations/developments need to be changed and will spend more time doing what you need them to be doing which is cultivating potential savings with sourcing activities.
———————————
What has been your experience with commodity code nomenclatures? How does your view differ from mine? Have you seen any organizations benefit from tremendously granular commodity code structures? Let me know in the comments.
If you liked this post, why not Subscribe
Last Updated on February 26, 2021 by Joël Collin-Demers
2 thoughts on “A Perspective on ERP/Procurement System Commodity Codes”
Joel, Thank You , Nice and brief article on usage of commodity codes. Enjoyed it.However I had a question , If I take an example of ‘Software’. If a software is purchased for marketing purposes . Which category code users should be picking up ? Should they use the category ‘Software’ or should they use category ‘Marketing expenses’ considering both category codes are available in the list. As an additional information , these category codes are mapped to GL codes according to COA. Please advise with the rationale.
Hi Sandeep,
Thanks for reading!
In my opinion, from a procurement and accounting perspective, all software should be purchased under an IT commodity code like ‘software’ regardless of the department ultimately using the product. The more illustrative example is ‘shared’ hardware like a server. Software used by many different departments will sit on this server but you won’t split the cost of the server on the purchase order into many different general ledger (GL) accounts based on potential usage. It’s just not practical or informative when you later try to analyze your costs.
This commodity code would be mapped to an IT GL account. As procurement analyzes spend based on commodity code this gives them a complete picture of spend on software. As accounting uses GLs to analyze expenses, this also gives them a complete view of software expenses for the financial statements.
However, if you have internal rules in your company about software/hardware cost chargebacks to departments based on usage, then you should manage this with Management Accounting principles like profit centres / cost centres. This gives you the flexibility to charge a % or all of the software expense to the marketing cost center.
With the combination of these three principles (commodity code, GL and Cost Center), you should be able to give everyone the information they need and support the internal business rules. The same type of logic would be applied to all other purchases (i.e. office supplies, laptops, office furniture, transportation, etc.)