Understanding Multi-item vs. Multicomponent products in ONIX: Making sense of one of ONIX's trickiest distinctions

EDItEUR just released a new series of Application Notes. These notes are short white papers that look in-depth at a single ONIX topic that users are asking about or that EDItEUR is aware can be problematic.

You can see and download the full list of Application Notes here, but we wanted to take the opportunity to highlight one of them: Multi-item and multi-component products. This new Application Note tackles what Executive Director Graham Bell calls "one of the trickier aspects of ONIX": the difference between multi-item and multicomponent products.

If you've ever struggled to properly code a boxed set or kit in ONIX, this Application Note will help to end the struggle. The distinction between these two product types matters more than you might think — especially for retailers trying to understand what they're ordering and whether individual items can be sold separately.

Why this matters

Getting these codes right helps answer critical supply chain questions:

• Are the pieces essential to the product, or can they stand alone?

• Can retailers break up the set and sell items individually?

• What's actually included in the package?

• Do the individual items have their own ISBNs?

These aren't just technical metadata questions — they have real business implications for inventory, pricing, and sales strategy.

The core distinction

Multi-item products (Think: Boxed sets and dumpbins)

Use multi-item coding when:

• Individual items in the set are available for purchase separately

• Each item has its own ISBN

• The set is a bundle of independent products

Example: A boxed set of three novels. Each novel is also sold individually, each with its own ISBN. The boxed set has a separate ISBN for the bundle.

ONIX ProductComposition code: 11 (Multiple-item retail product)

Multicomponent products (Think: kits)

Use multicomponent coding when:

• Components are NOT available separately

• The product only makes sense as a complete unit

• Individual pieces may not have ISBNs (or if they do, they're marked as not-for-separate-sale)

Example: A language learning kit with a workbook, flashcards, and audio CD. The components aren't sold separately. The kit is the product.

ONIX ProductComposition code: 10 (Multiple-component retail product)

Where it gets interesting

Here's where Graham Bell's "trickier aspects" come in: A boxed set can sometimes be a multicomponent product. The deciding factor isn't the format, it's whether the items inside are available separately.

Real-world example: The boxed set scenario
Imagine a premium box set containing three titles that are only available in this slipcase and you can't buy any of the titles individually.

How to code this in ONIX:
<ProductComposition>10</ProductComposition> <!-- Multicomponent -->
Use <ProductPart> (P4 block) to describe the three titles inside. You have options:

• Don't assign ISBNs to the individual titles (since they're not sold separately)

• Or assign ISBNs but clearly mark the relationship showing they're not-for-separate-sale

ONIX gives you this flexibility — you just need to make the relationships clear.

The philosophy of "things"

As Graham notes in the Application Note, one challenge with ONIX is defining the "thing" you're describing. You need to:

• Define your product

• Define the relationships to other products

• Do it all from the perspective of the product you're describing

It's a bit philosophical, and it's where metadata providers often spend considerable time — trying to describe their product clearly enough that buyers can find it and understand exactly what they're getting.

The takeaway

The flexibility ONIX provides for describing multi-item and multicomponent products is powerful, but it requires thoughtful implementation. The good news? When used correctly, these codes eliminate ambiguity and help the entire supply chain understand exactly what's being sold.

Key questions to ask yourself:

• Can any items in this product be purchased separately?

• Do individual items have their own ISBNs that are available elsewhere?

• What's the "main" product from the customer's perspective?

Answer these, and you'll know whether you're dealing with a multi-item or multicomponent product.

Learn more

Read the full Application Note on EDItEUR's website for detailed examples, edge cases, and complete technical guidance. It's worth the time — getting these distinctions right benefits everyone in the book supply chain.