What is a book management system? From the library catalogue to the publishing system

“Book management system” is the shared name of two separate worlds, and search results reflect it: of two people typing that phrase, one wants circulation software for a library and the other wants a production system for a press. They mostly get the same results.

The source of the confusion is simple. The word “book” names both an object (the volume on the shelf) and a work (content written, reviewed, published). When software calls itself a book management system without saying which of the two it manages, two entirely different needs are bound to meet on the same results page.

This piece splits the term: the question that tells you which world you are in, what a system actually manages in each, and what to look at when choosing.

The question that decides it

Did you produce the book you are managing?

If the book arrives from outside — purchased, donated, transferred — what you manage is a copy. Your record centres on an accession number, a shelf location, a loan status and a patron. The system you want is a library management system.

If you produce the book — taking submissions, running review, signing contracts, commissioning typesetting, registering an ISBN, printing it — what you manage is the life of a work. Your record centres on authors, versions, decisions, editions, print runs, royalties and sales. The system you want is a publishing management system.

Neither substitutes for the other. A library system knows nothing of a work’s reviewer reports; a publishing system knows nothing of who borrowed a copy. Both are correctly designed — they simply manage different things.

World one: managing the copy

On the library side the category is mature and standardised. Cataloguing, circulation, patron management, serials control, inventory; librarianship standards such as MARC21 and Z39.50. Koha is the widely used open-source option, alongside commercial systems.

A press with its own library needs one of these. It contributes nothing to publishing workflow — which is the design, not a shortcoming.

World two: managing the work

On the publishing side the term has been written about far less and defined far less. Yet “a book’s record” is much more crowded here. What a single book has to carry:

Identity and imprint. Title, subtitle, contributors and their roles (author, editor, translator, chapter author), subject headings, abstract, language.

Process history. Submission date, desk decision, reviewer assignments and reports, revision rounds, the acceptance decision and its reasoning. Which decisions a book passed through is an inseparable part of that book’s record — not a separate folder.

Contract and royalties. The royalty contract, rate, term and parties; which sale accrues how much. We wrote separately about the arrangement from contract to payout.

Production. Copyediting, translation, typesetting, cover and illustration tasks; what is waiting on whom, and which file is final. “Which file is the final one” is the most expensive question in production run over email.

Editions and printings. Impression number, print run, format (paperback, hardback, ebook, audio), each format’s own ISBN and price. We take that relationship apart in printings, editions and ISBN.

Inventory. Units in the warehouse, units on consignment, returns, spoilage; every movement recorded with its history (inventory, consignment and returns).

Sales and access. The storefront page, the price, digital access entitlements, sales figures.

Keeping these seven in the same record is the definition of the category. If they live in seven programs, what you have is not a book management system but a collection of programs.

Why “one record” matters this much

Take a concrete case. A book goes to a second printing and its price changes. In a scattered setup that single event spawns: an edition update in the catalogue, a price correction on the shop, a new print run in the stock sheet, a cost entry in accounting, and a new rate in the author’s royalty table. Five places, five people, five chances to forget.

In one record, a second printing is one event: the impression is added, and the rest follows from it. The entire claim of the category fits in that sentence — we costed the invisible price of scattered tools separately.

Six things to check when choosing

If you are evaluating a system on the publishing side:

1. Breadth of work types. Books only, or do journals, articles and edited-volume chapters live in the same model? If your institution also publishes journals, this question will find you in six months.
2. Version discipline. Is every resubmitted file kept as a distinct version, or overwritten?
3. Edition–format–ISBN relationship. Do the print and digital versions of one work live under that one work, or as two unrelated products?
4. Inventory control. Is every movement recorded with its history; is negative stock blocked; are consignment and returns recognised at all?
5. The royalty chain. Does a sale accrue a payout on its own, or does it end up in a spreadsheet in December?
6. Separation of duties. Can the accountant see reviewer reports, or the shop operator see author correspondence? (Roles and permissions in publishing)

Using the term correctly

In short: if you are searching for a “book management system” and you print the books yourself, the full name of the category you want is publishing management system — book management is its core, and journal and article management its sibling. We defined the category here, and collected which word takes you where in the software category glossary.

Nasirus is a system of that second world: a book’s whole life, from submission to after the sale, runs in one record. Have a look at the modules, or book a demo and we will walk through your own book workflow together.