Punchout catalogue maintenance: the ongoing cost nobody quotes you

This is the question that decides your whole maintenance bill, and the word “catalogue” covers three different things that cost very different amounts to keep current. Procurement teams use the word for all three, so establish which one you are being asked for before anyone quotes the work.

A hosted catalogue is a file of your items that lives inside the buyer’s system. On SAP Ariba that is a CIF file, and SAP’s own supplier guide requires a value in the first seven columns of every row, including Supplier ID, Item Description, SPSC classification code, Unit Price and Unit of Measure. Your prices sit in someone else’s software until you replace the file.

A punchout catalogue is the opposite arrangement. In Ariba’s own description it is “stored on your website” and shows the buyer “a hyperlink instead of product or pricing details”, so the buyer punches out and sees live pricing and customer-specific content from your storefront. Nothing about your prices is held on their side.

Level 2 punchout sits between the two, and it is the one people get wrong. It adds a small index file so your items are searchable inside the buyer’s system and a buyer can land on a specific product rather than your home page. The index typically carries no pricing at all: it exists to make items findable, and the price is still resolved on your site during the session. Technically it works by adding a SelectedItem node carrying your SupplierPartID to the cXML PunchOutSetupRequest, and without that node the request simply lands on your home page as a Level 1 punchout would.

If you run a hosted catalogue, a price change is not an edit. It is a publication, and it goes through a queue that belongs to your customer.

On SAP Ariba the sequence is documented and worth reading in full before you promise anyone a turnaround. You upload the replacement, the Ariba Network validates it first for errors, zero prices and basic classification and unit-of-measure compliance, and the file comes back as “Validated, Published or Pending Buyer Validation” if it is clean, or as “Errors Found by Ariba Network” or “Bad Format” if it is not. Passing that is not the end. The customer then runs its own audit, with rules their guidance says “may be more strict than the standard Network rules”, and their approval is mandatory before the catalogue reaches their buyers.

Two mechanical details in that process cost people money. You upload the entire catalogue rather than the changed rows, because the Ariba Network does not merge partial catalogues. And you keep the same catalogue filename for every version, so the buyer’s team can see it as a new version of something they already approved rather than as a new catalogue to evaluate from scratch.

Coupa is structurally the same story with different words. A catalogue in the Coupa Supplier Portal moves through Draft, then Awaiting or Pending Approval once the customer has it, then Accepted, and the portal is explicit that an Accepted catalogue is what makes items “available for purchase within Coupa”. Rejected and Error both mean a conversation with the customer rather than a fix you can make alone. And it is one catalogue per customer: the portal has a customer selector, so five trading partners is five catalogues, five approval chains and five schedules.

So the honest read on turnaround is that you do not have one. You control when you upload. Your customer controls when it goes live, and they are not working to your price list dates.

Put the two facts above next to each other and the design decision makes itself. A hosted catalogue requires Unit Price on every row, and every change to it is a full re-upload through an approval chain you do not control, once per customer. A punchout session reads the price from your storefront at the moment the buyer arrives.

For a seller whose prices come out of an ERP, that difference is the difference between a standing operational job and no job at all. If contract pricingContract pricing is a price that applies to one customer or one group of customers rather than to everyone. In B2B it is normal for the same product to have a different price for every account on the book. What is contract pricing? is calculated in Acumatica and your storefront reads it live, a price change reaches every punchout buyer the moment it is saved in the ERP, with nobody approving anything. If the same price is sitting in a CIF file inside four procurement systems, the same change is four uploads and four queues, and until the last one clears, different customers are looking at different prices for the same item.

That is also the honest reason to get the storefront right before the punchout connection rather than after. Punchout does not compute anything. It signs the buyer in as their company and shows them what your site would show that company anyway, which means it faithfully delivers whatever your pricing logic produces, correct or not, into a system where it becomes an approved requisition.

The practical rule we would apply: keep the index file to identity and classification, keep price out of it, and let the ERP own price at session time. Then catalogue maintenance stops being a pricing problem and becomes an assortment problem, which is a much smaller one.

None of this appears on a punchout provider’s pricing page, and all of it is real. Each item is small. Together they are a standing job that needs an owner rather than a volunteer.

The argument above points at punchout for most ERP-connected sellers, so here is the other side of it, because a comparison with no losing scenario for the option we like is a sales page.

A hosted catalogue is genuinely better when your assortment is small and stable, your prices are fixed for a contract term, and the buyer’s procurement policy wants your items searchable alongside every other supplier’s without leaving their system. In that shape the re-upload problem barely exists, because there is nothing to re-upload, and you avoid the operational load of running a punchout endpoint at all.

It is also the right answer when your storefront cannot yet show a customer their own negotiated prices. A punchout session that resolves the wrong price live is worse than a hosted file with the right price frozen in it, because the wrong price arrives inside the buyer’s approval chain wearing your name. Fix the pricing first, then move the price out of their system and into yours.

And if you are being asked for punchout by exactly one customer, the maintenance load in this page is a reason to price the work honestly and let them see the number, not a reason to absorb it quietly.