If you've ever sent an ONIX file to a retailer or distributor and heard nothing back, you probably assumed everything was fine. In most industries, no news is good news. In ONIX, silence can mean your data was quietly set aside and never used.
Most platforms that receive ONIX feeds run automated validation before they do anything with the data. If a file fails that check - wrong structure, missing required fields, values that don't match the expected codelist - it doesn't generate an error report that gets emailed back to you. It just doesn't get processed. The retailer moves on, your titles don't get updated, and unless you happen to notice something is wrong on a product page, you may not find out for weeks or months.
What validation actually checks
"Valid ONIX" means two related but different things, and it's worth understanding both.
The first is structural validity - does the XML file conform to the ONIX schema? This is the technical layer: are the tags correct, are required elements present, is the file well-formed enough for a machine to read it? A file that fails here usually won't be processed at all.
The second is business rule validity - does the data make sense in context? This is less binary and more about completeness. A file might be technically valid XML but still be missing information that a particular retailer requires: no pricing for a print edition, a subject code from an outdated version of the Thema classification, a contributor listed without a role code, a product with no availability status. Each of these is technically "valid" by the schema but creates problems downstream.
Different receivers have different tolerances for the second category. A small independent retailer might accept a fairly sparse ONIX record and fill in the gaps manually. Amazon, Ingram, or a national library supplier will expect the data to be both structurally valid and complete to their specific requirements - and they won't chase you for the missing pieces.
Where things typically go wrong
The most common issues in publisher ONIX files tend to be unglamorous rather than catastrophic. Outdated codelist values are a frequent culprit - ONIX codelists are updated regularly, and a subject code or availability code that was correct in 2019 may now be deprecated. Using it won't necessarily cause a hard error, but it may cause the field to be ignored or misinterpreted.
Missing or incorrect contributor role codes are another common problem. ONIX has specific codes for authors, illustrators, editors, translators, foreword writers, and many others. If a contributor is listed without a role, or with a role that doesn't match the actual relationship, the data may not display correctly on a product page - or at all.
Rights and territory information is often incomplete, particularly for publishers who are newer to ONIX. For international distribution, receivers need to know which markets a title is available in. Without that, some platforms will default to "not available" rather than making assumptions.
And then there's version mismatch. ONIX 2.1 is still in use in some parts of the supply chain, but ONIX 3.0 (and 3.1) is now the required format for most major platforms, including Amazon, which moved to requiring ONIX 3.0 data in early 2026. A publisher still sending 2.1 files to a platform that expects 3.0 will find their data rejected - again, usually without a clear notification.
How to know if your ONIX is valid
The honest answer is that you can't rely on downstream feedback to tell you. The best approach is to validate before you send.
EDItEUR, the organisation that maintains the ONIX standard, publishes the official schemas and codelist documentation. There are also validation tools available - some built into metadata management platforms, some standalone - that will check a file against both the schema and common business rules before it goes anywhere.
PASA (the Publishers' Association of South Africa) published updated product metadata guidelines in late 2024 specifically for South African publishers working with ONIX 3.0 and 3.1. If you're publishing in South Africa and sending ONIX data into the local or international supply chain, those guidelines are worth reading - they translate the full ONIX standard into practical guidance for the local market.