ONIX Metadata Feed vs Book Metadata Spreadsheet: What Should Authors Use?
A book metadata spreadsheet can be perfectly adequate for one author and still be the wrong operating system for a growing catalogue. An ONIX metadata feed can automate distribution at scale and still fail if its source data is incomplete. The practical question is not which format sounds more professional. It is which workflow gives every book format accurate, current information in the places that sell, catalogue and recommend it.
The simplest distinction is this: a spreadsheet is usually a working document for people, while ONIX for Books is a structured way for systems to exchange book-product data. Many publishers use both. They maintain controlled source data in a database or spreadsheet, then generate ONIX for partners that accept or require it.
What a book metadata spreadsheet does well
A spreadsheet makes metadata visible. Each row can represent an ISBN or product format, and each column can hold a field such as title, contributor, publication date, price or subject. That visibility is useful when a small team needs to collect missing information, compare formats, approve copy and spot inconsistencies before submission.
Spreadsheets are also flexible. A distributor may provide a template with its own required columns, validation notes and accepted values. An author can often complete that template without learning XML or installing specialist software. For a limited catalogue with occasional updates, the lower setup cost is a genuine advantage.
The weakness is that flexibility can become ambiguity. Columns get renamed. Cells contain free-form notes. One file is emailed while another remains on a desktop. A price changes in one version but not another. A spreadsheet only works as a reliable source when ownership, field definitions, validation and version control are explicit.
What an ONIX metadata feed changes
ONIX for Books is maintained by EDItEUR as an international standard for communicating book-product information. Instead of relying on column positions and local labels, an ONIX message uses defined elements and controlled code lists. That structure helps receiving systems understand whether a value is a subtitle, a contributor role, a subject scheme, a market, a price condition or an availability status.
The benefit is repeatability. A publisher can send new titles and later issue structured updates without rebuilding a different spreadsheet for every recipient. A valid feed can carry richer relationships among formats, markets, prices, rights and supporting resources. It is particularly useful when a catalogue has many ISBNs or changes often.
ONIX does not guarantee good metadata. Validation can confirm that a message follows technical rules, but it cannot decide whether a description is persuasive, a subject is accurate or a contributor name is consistently styled. The feed is a delivery mechanism. Editorial judgment and data governance still determine quality.
ONIX feed vs spreadsheet: the decision table
Choose a spreadsheet-first workflow when the catalogue is small, the recipient supplies a template, updates are infrequent and a person can review every record before submission.
Choose an ONIX-capable workflow when multiple trading partners accept feeds, the catalogue or format count is growing, updates are frequent or repeated manual entry is creating errors.
Use both when a spreadsheet or database is the editorial source of truth and an ONIX export distributes approved records to the supply chain.
Do not create ONIX merely to look established. Use it when the receiving partners, catalogue complexity and update volume justify the process.
Start with identifiers and product boundaries
Metadata should be organized by product, not only by work. A hardcover, paperback, ebook and audiobook are related expressions of the same work, but each can have its own identifier, format details, price, availability and territorial rights. Combining them into one vague row makes later distribution difficult.
Treat the ISBN as the anchor for the exact product it identifies. Keep the title and contributor presentation consistent where appropriate, while preserving format-specific facts. If a distributor assigns another identifier, record it without replacing the ISBN. Avoid copying a paperback price or page count into an ebook record simply because the titles match.
Build a controlled source of truth
Whether the source is a spreadsheet, publishing database or title-management system, define each field before collecting values. State who owns the field, which values are allowed, whether it is required, and which downstream channels receive it. A data dictionary prevents a column such as “date” from mixing announcement, publication and on-sale dates.
Add validation close to the source. Required fields should not be blank. Currency should accompany price. Dates should use one format. Contributor roles should be explicit. Subject codes should name their scheme and version. Descriptions should not contain accidental markup or claims that cannot be substantiated.
Use a change log. Record the product, field, old value, new value, approval date and destinations. This matters because retailer and wholesaler pages do not always update simultaneously. A log makes it possible to distinguish a delayed downstream refresh from a source-data mistake.
Map the recipient before choosing the format
Ask each distributor, wholesaler or retailer what it accepts, which ONIX version or spreadsheet template it supports, which fields are mandatory, and how updates are acknowledged. The correct technical format is the one the intended recipient can process. Sending a technically elegant feed to a partner that only accepts its portal template creates work rather than reducing it.
A submission is not complete merely because a file was sent. Confirm whether the recipient produced an acknowledgement, validation report or error file. Review rejected records and warnings. Then check representative product pages after the expected processing period, paying particular attention to identifiers, title, author name, format, price, availability, cover and description.
Common failure modes to prevent
Multiple sources of truth: the distributor portal, spreadsheet and ONIX generator contain different values.
Weak product separation: print and digital formats share incorrect prices, dimensions, dates or availability.
Free-text overload: controlled fields contain inconsistent spellings or unsupported values.
One-time thinking: launch metadata is submitted, but later price, cover or description changes are not propagated.
Unverified conversion: a spreadsheet is converted to ONIX without checking field mappings or validation results.
No downstream audit: successful transmission is assumed to mean every public listing is correct.
A practical workflow for independent authors
First, list every format and its identifier. Second, create one master record per product with required descriptive, commercial and rights fields. Third, validate the master data and approve the reader-facing copy. Fourth, identify the submission route for each partner. Fifth, export or enter the data in the required format. Sixth, save acknowledgements and errors. Seventh, audit live listings and maintain a change log.
This workflow can remain spreadsheet-based until volume or partner requirements create a clear reason to automate. The important step is separating the controlled master record from ad hoc submission copies. When the source is clean, moving to ONIX later becomes a mapping project rather than a catalogue rescue.
When the investment is worth it
An ONIX-capable system is more likely to be worth the investment when the catalogue contains many active ISBNs, several formats per work, frequent price or availability changes, multiple markets, or several data recipients. Automation reduces repetitive entry, but only after field rules, mappings and responsibilities are stable.
For one or two titles distributed through a platform that already collects and transmits metadata, direct ONIX production may add complexity without adding reach. In that case, invest first in accurate source data, persuasive descriptions, appropriate subjects, consistent contributor names and a disciplined update process.
Frequently asked questions
What is an ONIX metadata feed?
An ONIX metadata feed is a structured message used to communicate book product information between publishers and supply-chain partners. It can carry identifiers, contributors, titles, descriptions, subjects, prices, availability, territories and other data in a consistent machine-readable format.
Is ONIX the same as a spreadsheet?
No. A spreadsheet is a human-friendly table used to collect, review or submit metadata. ONIX is a structured exchange standard designed for systems to send detailed book-product records and updates. A spreadsheet can be an input to an ONIX workflow, but it is not itself an ONIX message.
Do self-published authors need ONIX?
Not always. If a publishing platform or distributor accepts metadata through a dashboard or template, an author may never need to create ONIX directly. ONIX becomes more relevant when a publisher manages many titles, supplies multiple trading partners or needs repeatable automated updates.
Can I convert a book metadata spreadsheet into ONIX?
Yes, if the spreadsheet contains the required fields and the conversion process maps each column correctly to valid ONIX elements and code lists. Conversion does not fix missing, inconsistent or inaccurate source data, so the spreadsheet should be validated before export.
Which metadata fields matter most in either format?
Start with the correct ISBN for each format, title and subtitle, contributor names and roles, publication date, language, format, page count, subjects, audience, description, publisher or imprint, territorial rights, price, currency and availability. Each recipient may require additional fields.
How often should book metadata be updated?
Update metadata whenever a material fact changes, such as price, publication date, availability, cover, description, contributor information or territorial rights. Use one controlled source of truth and record when and where each update was sent.
Can bad ONIX data hurt book discoverability?
Yes. ONIX can distribute metadata efficiently, but efficiency also spreads errors efficiently. Incorrect subjects, weak descriptions, mismatched identifiers, missing prices or stale availability can reduce the accuracy and usefulness of retailer, library and wholesaler listings.
Should I hire someone to manage ONIX metadata?
Consider specialist help when trading partners require ONIX, your catalogue is growing, updates are frequent or validation errors are delaying distribution. A small catalogue using one distributor may be manageable through that distributor’s own forms and templates.
Comments