Why Spreadsheets Are Costing Your Art Gallery Money (And What Replaces Them)

If your gallery runs on Excel or Google Sheets, the honest answer is: a spreadsheet is enough until it suddenly is not — and the costs arrive before you notice them, because none of them appear on an invoice. This page sets out the five structural risks, the hidden costs they create, the cases where you should genuinely stay on the spreadsheet, and the migration path when you outgrow it. We sell a CRM, so every claim about what replaces a spreadsheet maps to a named module running in production — and we will tell you plainly when you do not need us yet.

What spreadsheets genuinely do well

Credit first, because it is deserved. A spreadsheet is near-free, infinitely flexible, familiar to every hire, and fast to change: a new column takes ten seconds. For one person managing a small, simple catalogue, that flexibility beats any software licence. We will not pretend otherwise — and we will tell you below exactly where that ceiling sits.

The five structural risks

These are not version problems that an update fixes. They follow from what a spreadsheet is: a grid with no schema, no history and no access model.

1. Silent entry errors — with no trail to find them

Nothing stops a typo in a price, a swapped edition number or a paste over the wrong row. In a file there is no validation against a catalogue, no required fields, and — critically — no record of who changed what and when. When a discrepancy surfaces weeks later, the file cannot answer "what was this before, and who moved it?" A system built for galleries answers that in seconds: every create, edit and delete is logged with user and timestamp auditlog.

2. Provenance scattered across cells and notes

Provenance is where a work's value and legality live — previous owners, exhibition history, certificates. In a spreadsheet it lives in concatenated text cells, colour-coded rows and attached files that reference nothing. One artwork, one structured record — with provenance, certificates and editions attached — is the entire premise of an art-specific data model artgallery_custom_fields. A grid has no premise; every row becomes a private dialect.

3. A price history that does not survive the month

The spreadsheet keeps the current price because the old one was overwritten. Yet the story of a work's prices — asked, offered, negotiated, sold, re-offered — is precisely what a gallery reasons with at the next fair. Losing it means re-deriving it from email threads. A gallery system keeps price history per deal on the artwork record, timeline included artgallery_custom_fields.

4. Collaboration that breaks with the second user

Two patterns, both fragile: one shared file with simultaneous-edit conflicts and version soup in email; or copies per person whose divergences someone must reconcile by hand. And access is all-or-nothing — an intern sees every price. A purpose-built system gives each person a login, each role a scope base_user_role base_user_role_profile, and every action a trail. Nobody works on "the copy from Tuesday".

5. Offers rebuilt by hand, every time

The most expensive spreadsheet habit: every proposal reassembled in Word or a design tool — images hunted down, prices copied, layout redone, PDF exported, emailed, re-exported when a work is swapped. Hours per offer, repeated per deal, with each manual copy an opportunity for a wrong price to reach a collector. Generated from the catalogue instead, a multi-artwork proposal becomes a branded, server-side PDF — with a private offer page the collector can open art_proposal artwork_proposal_pdf custom_mail_templates.

The hidden cost, added up

None of these appear on an invoice, which is why they stay invisible:

• Admin time: the recurring, unautomated assembly work — offers, availability checks, list updates — done by the most expensive people in the building.
• Onboarding: every new assistant must learn the file's private dialect — which column really means what, which tab is current. The knowledge lives in one person's head, and leaves with them.
• Missed opportunities: follow-ups that depended on memory, works forgotten between two fairs, offers that arrived days late because assembly took days. Each one is a deal that quietly cooled.

A deliberate honesty note: we will not quote invented percentages or fake case studies to dramatise this. The mechanisms above are structural and checkable in your own gallery: time one offer, from "send me an offer for these three works" to PDF sent. That number is yours, and it is the only one that matters.

When a spreadsheet is genuinely enough

Stay on it, happily, if most of these are true:

• One person manages the catalogue.
• The catalogue is small — under roughly fifty works, with few or no editions.
• You do not send formal written offers; conversations close the deals.
• One location; no fairs juggling multiple lists at once.
• No one has ever asked "who changed this?" — or the answer lives in one memory.

Reconsider when the triggers arrive — they are predictable: a second user, the first formal proposal, the first edition series, a second space or storage site, the first serious audit question. If you are comparing the whole market rather than deciding today, our 2026 six-category comparison covers every option, including staying put.

The migration path, step by step

Migration from Excel is a cleaning project with an import at the end — any serious gallery CRM handles the import; the ordering below is what makes it safe:

1. Audit what you actually have. Count works, count tabs, list what only exists in someone's head.
2. One row per artwork. Split edition children from parent records — the single most common structural fault in gallery spreadsheets.
3. Fix the status vocabulary. "Sold?", "sold (not paid)", "SOLD - ok" become a fixed set of values.
4. Make locations structured. One field, consistent values, no free text.
5. Export to CSV or XLSX — artwork sheet, contacts sheet, sales sheet.
6. Hand the file to the vendor and have them import it during onboarding, with the scoping done on your real data first.
7. Validate together. Spot-check works, prices and provenance against the original before go-live.
8. Run one real cycle in parallel — a fair, an exhibition, a full offer — before switching off.
9. Switch, and keep the spreadsheet read-only as an archive. Do not delete it; future you may want it.

Move the catalogue first — everything else depends on it. Collectors and purchase history come second; proposals last, once the first two are trustworthy. Trying to move everything in one weekend is the most common migration mistake.

What replaces each spreadsheet weakness

• No audit trail → every action logged with user and timestamp auditlog
• Scattered provenance → structured records on the artwork: provenance, certificates, editions artgallery_custom_fields
• Overwritten prices → price history per deal, with timelines
• All-or-nothing access → granular roles and profiles per person base_user_role
• Hand-built offers → proposals and branded PDFs from the catalogue, plus client offer pages art_proposal artwork_proposal_pdf custom_mail_templates
• One lost laptop → scheduled automated backups, daily and off-site, in a standard PostgreSQL database you can export in full

That last pair of rows is worth pausing on: a spreadsheet on one laptop is also a data-ownership problem, not only a workflow one. Where your data should physically live is its own question — we cover EU hosting and GDPR duties here.

FAQ

Is Excel enough for an art gallery?

Genuinely, sometimes yes: one user, a catalogue under roughly fifty works with no editions, no formal written offers and no second location — a disciplined spreadsheet covers that. The limits are structural, not version-related: no validation, no audit trail, no reliable simultaneous editing and no way to generate an offer from the record. The moment a second person, a formal proposal or a second location enters the picture, the risks above start turning into real costs.

How do I migrate from Excel to an art gallery CRM?

In stages: audit what you actually have; restructure to one row per artwork, splitting edition children from parent records; agree a fixed status vocabulary; make locations a structured field; export to CSV or XLSX; have the vendor import the file during onboarding; validate the result against the original with your team; run one real offer or fair cycle in parallel; then switch and keep the spreadsheet read-only as an archive. Every serious gallery CRM imports structured data — the cleaning is the project, not the import.

What do galleries lose by staying on spreadsheets?

Four kinds of things: traceability — no record of who changed a price or deleted a work, and no way to answer an audit question later; provenance — scattered across cells and notes instead of structured on the artwork; time — every offer is reassembled by hand and every new hire learns the file's private quirks; and deals — follow-ups that depend on memory rather than a system. None of it appears on an invoice, which is exactly why it stays invisible.

What is the first thing to move out of the spreadsheet?

The catalogue — artworks, artists, locations and statuses — because everything else depends on it. Collector records come second, together with purchase history. Offers and proposals come last, once the first two are trustworthy in the new system. Trying to move everything in one weekend is the most common migration mistake; moving the catalogue first and validating it is the reliable path.

Next reads: the six-category 2026 comparison, the 12-point buyer's checklist, Artlogic alternatives reviewed honestly, and the full module-by-module comparison.