Packaging Artwork Management Software: Why the Wrong Proof Reaches the Printer

Why the wrong proof reaches the printer

A packaging change is a small edit with a large blast radius. The recipe changed slightly, so the ingredient list moves and the allergen statement gains a line. Marketing wants a new claim on the front. Legal has a view about the claim. Regulatory has a view about the allergen formatting. The design agency produces a proof and emails a PDF. Comments come back from five people in five emails, two of them contradictory. The agency produces version 4. Somebody forwards version 3 to the printer because it was the most recent one in their inbox.

Twenty thousand units get printed with the old allergen statement. The cost is not the print run, although that is real. The cost is the decision about whether product already in trade has to be withdrawn, and that decision is made under time pressure by people who cannot quickly establish what was approved and by whom.

The mechanics of this failure are always the same. Version control by filename. Approval by email. Regulated copy retyped by a designer from a Word document that was itself a copy of a copy. Nobody holding a single locked record of what the approved artwork actually is.

Problem 1: regulated copy is retyped by people who are not accountable for it

The ingredient list, allergen statement, nutrition panel, net quantity, storage and use by instructions, country of origin and responsible business address are all regulated content. In the United States, FDA rules require the major food allergens to be declared, and sesame joined that list, which meant a large number of labels had to change and every one of those changes was retyped somewhere. In the European Union, allergens must be emphasised within the ingredient list rather than only listed separately.

In most businesses that content originates in a specification system or a recipe document, gets copied into a Word file, emailed to an agency, and typed into a design tool by a designer who is not a food technologist and cannot evaluate whether a change is significant. Every one of those handovers is a chance for a character to go missing.

What a custom build does: make regulated content a controlled component rather than free text. It comes from the specification or recipe source, it is versioned, it has an approver, and the artwork references it rather than containing a retyped copy. When the specification changes, every artwork referencing that component is flagged as affected, which answers the question nobody can currently answer quickly: if this ingredient changes, which packs are impacted and which of them are already at the printer.

Problem 2: proofing is done by eye and eyes miss the small things

A human comparing version 4 against version 3 will catch the moved logo and miss a single digit change in a net weight or a dropped word in an allergen line. This is not carelessness, it is how reading works, and it gets worse on the fifth proof of the day.

GlobalVision does this specific job well and is the reason many quality teams have it. Its limitation is that it is a comparison tool rather than the workflow, so you still need something to hold the version of record, route approvals, capture who signed what and when, and manage the handoff to the printer. Esko WebCenter is the heavyweight and genuinely capable across the whole chain, and the honest caveat is that it is a platform programme with a long configuration tail, priced and staffed accordingly. Mid size food and cosmetics brands buy it and use a fraction of it. Kallik is strong in highly regulated labelling for pharmaceutical and medical device work, and its content model reflects that origin, which makes it heavy for a food brand with seasonal packs and frequent promotional variants. Twona is light and pleasant and runs out of room once you need market specific claim libraries and controlled regulated components.

What a custom build does: integrate automated comparison into the approval gate rather than leaving it as a separate tool someone remembers to use. Text extracted from the proof gets compared against the approved regulated components character by character, and a difference blocks the gate until it is explained. Layout comparison against the previous approved version highlights everything that moved. Then the human review is focused on judgement rather than proofreading, which is what humans are actually good at.

Problem 3: approval is a chain of opinions with no record

Brand, legal, regulatory, quality, the supplier and sometimes the retailer all have a say. In email, those views arrive out of order, some conditional, some contradictory, and somebody synthesises them into an instruction to the agency. If asked six months later whether legal approved the claim on the front of the pack, the honest answer is that there is an email somewhere.

What a custom build does: define approval as a sequenced workflow with named roles, where each approver signs a specific version and their approval is void if the artwork changes afterwards. That last part is the control that matters. Most email based processes carry forward an approval given on version 2 into version 5 without anyone deciding to. Reset on change, with a clear view of who needs to re approve and why, is the difference between a record and a folder. For businesses operating under electronic records requirements, this is also where signature and audit trail obligations land, and that is a scoping conversation to have with your quality team before design rather than after.

Problem 4: the printer handoff is the least controlled step and the most expensive

After approval, someone sends a file to a printer or a packaging supplier. That transfer is usually email or a file transfer service, and the file that goes is whichever one the sender believes is final. The printer, reasonably, prints what they receive.

What a custom build does: make the printer collect rather than receive. The approved version is published to a supplier accessible location, superseded versions are locked and clearly marked, and the download is logged against a specific job. Then when a press proof comes back, it gets checked against the same approved record rather than against whatever was emailed. This single change removes the most common route to an expensive print error, and it costs very little to build compared to everything else in this list.

Problem 5: claims and market variants multiply and nobody tracks the matrix

The same product sells in six markets. Claims that are permitted in one are not in another. Nutrition formats differ. Language requirements differ. Recycling and packaging labelling requirements differ by market and are changing steadily as extended producer responsibility schemes expand. A product family with four flavours across six markets is 24 artworks, each with its own approval state.

What a custom build does: model the artwork as a product plus market combination drawing on a shared claim and component library, where each claim carries its permitted markets and its supporting evidence. Then a claim withdrawn or restricted in one market flags every affected artwork immediately, rather than being discovered when a regulator or a retailer asks. Managing this in a folder structure is how brands end up with the same claim live in a market where it should not be.

What this costs and how long it takes

A focused first release, meaning the artwork record with locked versions, controlled regulated components sourced from your specification system, sequenced approvals that reset on change, and printer publication with download logging, runs $70,000 to $150,000 and ships in 12 to 16 weeks. A full platform adding automated text and layout comparison in the approval gate, a claim library with market permissions, agency and supplier portals, briefing workflow, and integration to specification and item systems runs $180,000 to $420,000 phased over 7 to 12 months.

What pushes cost up in artwork work specifically: the number of markets, since each brings its own regulated content structure and labelling rules; whether electronic signature and audit requirements apply, because that raises the bar on validation and documentation; the number of external parties, as each agency, printer and packaging supplier is an access model and an onboarding cost; and file handling, since working with large native design files rather than PDFs changes storage, rendering and version comparison considerably. What keeps it down: one brand family, one market, PDF proofs only in release one, with native file handling deferred until the workflow is proven.

Build versus buy, and when buying is the right call

Buy Esko WebCenter if you are a large business with many brands, many markets and a packaging function big enough to own a platform properly. It does the job and the ecosystem around it is real. Buy Kallik if you are in pharmaceutical, medical device or another environment where a validated labelling system is expected and the content model matches. Buy GlobalVision regardless of what else you do, if proofing accuracy is your immediate pain and you can live with a separate workflow. Buy Twona if you are small, your regulated content is simple and you mainly need to get out of email.

Build when two or more of these are true. Your regulated content lives in a specification or recipe system and you want artwork to reference it rather than retype it, which is the single highest value integration in this whole category and is rarely available off the shelf. You operate many market variants of the same product family and need a claim library with market permissions. Your approval chain includes external parties whose access needs to be tightly scoped. You have had a print error or a near miss and the investigation could not establish who approved what. Or you have bought a heavyweight platform and use a fraction of it while still running approvals in email, which is more common than vendors would like to admit.

The honest tipping point is the link to specification data. If your regulated content is already governed somewhere and the only problem is that artwork does not read from it, that connection is where the risk actually lives and it is the strongest reason to build.

How to choose a developer for artwork management software

Ask how regulated content is represented. If the answer is that the artwork holds text, they have missed the point. You need components that reference a governed source, with versioning and impact flagging when the source changes.

Ask what happens to approvals when a new version is uploaded. If prior approvals persist, the system is worse than email because it produces false confidence. Reset on change is not a preference, it is the control.

Ask about the printer handoff specifically and listen for publication with logged downloads rather than sending files. Ask them to describe how a superseded version is prevented from being used.

Ask who owns the code, the artwork archive and the approval records, and get it in writing before kickoff. At Digital Heroes the client owns the repository and the infrastructure accounts from the first commit. Your approval history is the evidence you will rely on if a pack is ever questioned, and it must be in a system you control and can export completely at any time.