A B2B procurement platform adopts an industry reference model for its catalogue and order domain. When does that help, and when does it become a liability?

When it helps

A reference model is a vocabulary and a checklist, and both are genuinely valuable in a domain you are entering rather than inventing:

• It names the entities you have not thought of yet — the difference between a purchase requisition, a purchase order and a goods receipt is not obvious until an enterprise customer's finance team explains it during integration.
• It makes integration cheaper, because enterprise buyers' procurement systems already speak the standard, and matching their model removes a translation layer from every onboarding.
• It shortcuts the argument about what a term means, which in a multi-team environment is a large part of the design cost.

When it becomes a liability

• When it is adopted as a data model rather than a vocabulary. Reference models are designed to cover every variant across an entire industry; implementing all of it produces dozens of tables where you needed four, and every one of them is a maintenance obligation.
• When it constrains the product. If your competitive advantage is a way of aggregating supply that the standard has no concept of, conforming to the standard means conforming to the market's existing shape.
• When it is used as authority instead of reasoning. "The reference model says so" ends design discussions that should have happened.

The pattern that works

Use the reference model at the boundary and your own model inside. The integration layer speaks the standard because customers do; the core speaks your domain because that is where the product lives. That is an anti-corruption layer applied to a standard rather than to a legacy system, and it lets you take the vocabulary and the interoperability without taking the ontology.