Are Catalogs Fleecing Procurement of the Best Deal? 5 Arguments in Favor and Against the P2P Catalog

olly/AdobeStock olly/AdobeStock

This is the second installment of a series in which we are rhetorically going to war against catalogs (kind of like a certain presidential candidate bulldozing over everything and everyone in his path – for the better or the worse, we might add, depending on your perspective!). When we first gave the topic of killing the catalog some thought, we came up with a post in which we ending up sharing the pros and cons of catalog-based procurement today — and some of the options we would wager are coming down the pike.

But let us take aim at catalogs in a different way today by positing arguably the most important procurement assumption of all: namely that catalogs are fleecing procurement of the best possible pricing in numerous ways. On the surface, they’re a number of reasons that using a catalog does not always mean your organization is getting the best deal. Here are a few, provided by Jason Busch. Pierre Mitchell plays “counterpoint” on each of Busch’s arguments.

Point 1: Pricing that is above market in the first place (especially if a given SKU was a tail-spend item that was not competitively bid as part of a market basket – or the market basket sourcing approach was an incorrect one to use for an item in question).

Counterpoint: How can you blame the catalog item on bad sourcing?

Point 2: Missing out on deep discount items (e.g., old/discontinued stock, large volume discounts, special deals, manufacturer incentives not passed along to the end customer, etc.).

Counterpoint: Is this the catalog's fault? Firm must decide whether it's OK with folks scrounging for deals w/non-approved vendors on p-cards (even if they're single use ghost cards) or not. Now, if you want the catalog to constantly be benchmarked against spot market pricing and you want to use agent technology to alert you and you want to deal with dynamic updates and negotiating w/ supplier to manage all this, it's possible, but is it worth it? Maybe, but maybe not.

Point 3: Line-level pricing that matches a negotiated deal, but not pricing on a total landed cost basis

Counterpoint: Sourcing should've negotiated TLC and that should be reflected in catalog. Don't blame the catalog!

Point 4: Incorrect line-level invoice billing, which in the most nefarious situations, might match to a contract, but not the pricing presented to a user when shopping. The SKU variance within the same organizations can be dramatic even when purchased from the same supplier (Tungsten Network has some great data on this).

Counterpoint: The catalog should reflect contracted SKU pricing and invoices must match contracted SKU price in the catalog that is in the PO. Pricing in the catalog is controlled and user shouldn't see different prices unless it's a punch out and user is not monitoring prices getting paid. If firm is paying lots of different prices, don't blame the idea of a catalog, blame the lack of internal controls.

Point 5: SKU/item number changes (substitute SKUs) and lower cost substitutes become available

Counterpoint: If lower cost substitutes are available, then a next generation catalog could actually help find alternate SKUs from other MFRs with same product attributes. if a retailer/distributor is playing games by discontinuing items and replacing with other higher priced ones, then that's a sourcing issue — and good catalog management reporting should highlight that.

This last item actually helps make the case for a broader point: Many organizations have not competitively benchmarked pricing for catalog items on a regular enough basis. At best, companies go to market annually from a sourcing perspective for items that they’re competitively bidding out (but many simply roll over pricing).

I’ll continue to share my thoughts on the subject as I conclude this series in the coming days. But in the meantime, I’ll pose a rhetorical question to ponder: are current catalog approaches helping suppliers or procurement more?

Discuss this:

Your email address will not be published. Required fields are marked *