Auction House Management Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why do auction house projects try to replace everything at once?

Because every part of the operation touches every other part, so the scope grows naturally from settlement to cataloguing to the website to bidding. That last step is the expensive one. Building your own bidding audience is the biggest scope failure in this sector, and it is a category error: Auction Technology Group properties and Invaluable exist to bring you bidders, and bidders are the one thing software you own cannot manufacture.

The fix is to define what the custom system owns before anyone quotes. It owns the lot and everything that hangs from it: consignment terms, reserve and guarantee, the premium and tax computation, the invoice, the consignor statement line, and the bidder record with your vetting decision. The bidding platforms remain the audience and their listings are child records carrying the external identifier. The accounts package remains the ledger and receives postings. Draw that line in writing, because in this sector the scope grows in small, reasonable steps until the project is a year long and the next sale is still being settled by hand.

What goes wrong when you migrate a decade of past sales?

Past results are genuinely valuable. Specialists use them for estimates, provenance enquiries depend on them, and a house that loses its own sale history loses part of its expertise. The trouble is that the history was never recorded as data with stable identities.

Lot identifiers diverge across re-cataloguing, group splits and platform listings. A lot passed in March, re-offered in June as a different lot number, then split into three in September has four identities and no link between them except a mapping sheet somebody kept. Historical consignor terms exist only inside PDF agreements, so the negotiated commission that produced a settlement figure cannot be reconstructed. Buyer identities were created separately on each bidding platform, so the same collector appears as five buyers with five purchase histories.

The fix is to scope migration honestly as partial. Move structured results plus attached documents rather than attempting a perfect reconstruction of every historical settlement, and say so at the quoting stage so nobody discovers it in month four. Give every historical lot a stable internal identifier at load and record the legacy identifiers against it rather than replacing them, so the mapping sheet becomes data. Attempt buyer identity resolution across platforms with a review queue rather than an automatic merge, because merging two collectors is a worse outcome than leaving them separate. And keep the source export queryable, because a specialist will ask a question the migrated model does not answer.

Why do bidding platform and accounting integrations break after launch?

Each bidding platform has its own listing format, its own bidder feed and its own results export, and they change on their schedule rather than yours. The failure is rarely dramatic. A platform adds a field, your listing upload starts rejecting a category of lots, and the lots are simply absent from that audience on sale day, which nobody notices because nobody counts listings per platform.

Results imports fail in a more damaging way. A hammer file arrives with a lot numbering convention that shifted because the sale was re-ordered after the catalogue printed, and rows land against the wrong lots. Once that flows into invoicing, you are issuing wrong invoices to real buyers and correcting them by hand.

Accounting integrations drift differently. Postings go to the wrong nominal account after a chart of accounts change nobody told the auction system about, and the client money position, which is the number you must be able to produce on demand, quietly stops being right.

The fix is validation at the boundary rather than trust. Reconcile listing counts per platform per sale before the sale opens and raise an exception on any lot that failed to list. On results import, match on a stable identifier you supplied rather than on lot number, and refuse the file if the match rate falls below a threshold rather than importing what matched. Reconcile the client money balance daily between your system and the bank, not monthly, because in a business holding other people's money a slow divergence is the one thing you cannot afford to find late.

What happens when premium, tax and bidder vetting are not modelled?

Buyer premium is tiered, and the tiers differ by sale, by department and sometimes by agreement with a specific buyer. Tax on the premium is a different question from tax on the hammer. In the UK the margin scheme and the standard rate produce different numbers on lots in the same sale depending on how the property was acquired. In the US the delivery state decides sales tax treatment and a resale certificate is per state and carries an expiry. The artist resale right applies in bands, only to qualifying works, only above a threshold. Model all of that as a percentage field plus a note, and the real control is a person who remembers.

Bidder vetting is the parallel gap. Registering a bidder is easy. Deciding how much they may spend on credit, with no deposit, on property they may not collect, is a risk judgement. UK art market participants fall under money laundering regulations for transactions at or above ten thousand euros, so identity evidence and screening results need to be stored and retrievable per bidder rather than reconstructed per sale. Meanwhile the aged debtor check before a sale is usually done by eye.

The fix is an explicit, versioned rule set evaluated per lot per buyer, producing a full breakdown of every rule that fired, stored immutably against the invoice. Change your premium structure next season and old sales still compute the old way. On the bidder side, one record carrying vetting state, credit and paddle limit, screening results with date and provider, documents held against a retention policy, deposits taken and released, and outstanding balances, with every platform registration resolving into it. The room screen then shows the auctioneer a limit rather than a name.

Should you build custom or configure what you already own?

Stay with what you have if you run general line or estate sales with a standard commission structure, one tax jurisdiction and consignors who are individuals. AuctionFlex covers that operation properly for a few hundred a month, and a custom build would be an expensive route to the same place. Bidpath is a reasonable answer if the priority is running your own timed and live bidding rather than the back office. If your real problem is bidder reach, spend the money on Auction Technology Group properties and Invaluable rather than on software.

Before building, check how much of your incumbent is configured. Many houses run a capable back office with charge types never set up, department structures never used and reports never built, then conclude the product cannot do what it has simply never been asked to do.

Build when two or more of these hold. More than a quarter of your lots carry negotiated rather than standard terms. You sell into more than one tax jurisdiction, or the artist resale right and the margin scheme apply to part of your catalogue. You take cash advances or guarantees against property, which turns settlement into a lending product with its own accounting. You are consigned to by institutions, estates or corporates whose reporting requirements are their format rather than yours. Or settlement is taking a senior person more than a week per sale, which means you are already paying for the software and calling it salary.

How do hidden costs get into the quote?

Jurisdiction count first. A house selling into both the US and the UK carries two tax models and two regulatory regimes, and that is genuinely double the rule work rather than a configuration switch. It is also the item most often described in a first meeting as a small addition.

Platform count second. Each live bidding integration has its own listing format, bidder feed and settlement export, so budget per platform rather than assuming one integration covers all of them. The valuable and expensive part is not importing the hammer file, it is resolving each platform's bidder into a single record carrying your vetting decision.

Category depth third. A wine sale, a classic car sale and a jewellery sale need different intake attributes, different condition vocabularies and different logistics. A quote written against one department and delivered across four is a different project.

Fourth, advances and guarantees, which convert settlement into lending and bring their own accounting, interest treatment and unwind logic. Fifth, and the usual schedule risk, is getting your own commission, charge and tax rules written down precisely. In most houses they exist as a mix of template agreements and one specialist's memory, and extracting them takes weeks that belong in the plan rather than in the overrun.

What separates a build that works from one that fails here?

The working build has one lot entity with a stable internal identifier from the moment property arrives, with platform listings as child records. Grouping, splitting, withdrawing, passing and re-cataloguing are state transitions on that entity rather than new spreadsheets, so consignment history stays intact across sales. This sounds obvious. It is the thing almost nobody has, and it is why reconciliation exists as a job in your building.

The second difference is settlement as a ledger rather than a report. Every commission, charge, advance and receipt posts against a specific lot and consignor with a date, so a consignor statement is a query and the client money position is available at any moment. Buyer non payment triggers a defined unwind that reverses the settlement line and moves the lot to a re-offer or rescission state, rather than a manual correction someone has to remember.

The third is that the premium and tax rules are versioned and every computation stores the rules that produced it. Disputes then resolve with evidence rather than goodwill, and a change of structure does not rewrite history.

The fourth is ownership, in writing before kickoff: the repository, the hosting accounts and the right to hire anyone else. At Digital Heroes the code is yours from the first commit. A saleroom whose settlement engine belongs to somebody else is a saleroom with a supplier risk sitting directly on its client money, and we would tell you to leave the room if a developer hedges on that question.