Auction House Management Software
Auction software for consignment to settlement, in one place.
Consignment intake, cataloguing, bidding, invoicing, and consignor settlement live in one record, so your team stops copying the same lot between separate tools and spreadsheets.
Bring one stuck sale workflow. Leave with a buy, repair, own, or wait recommendation.
Trusted by
The brief
Start with what is not working.
Good software decisions begin with the constraint, not a list of features or a preferred technology.
Consignment details arrive in one tool, the catalogue is made in another, and settlement is worked out somewhere else again.
A catalogue correction has to be entered twice, and nobody is sure which version the bidders saw.
Sale day runs on memory: who is approved to bid, which lots met reserve, and which buyers have actually paid.
Plain answer
Auction house management software runs one sale from consignment intake to settlement in a single record: consignor and lot details, catalogue, bidder registration, timed or live bidding, invoicing, and consignor payment. It replaces separate tools and repeated entry, so staff, buyers, and consignors work from the same lot, bid, and payment facts.
What to remember
- Use this when the same lot is entered in more than one place and the re-entry is where errors and delays start.
- The first release should complete one sale path end to end, from intake to consignor payment, not collect disconnected features.
- The code, cloud accounts, data, and operating notes should stay usable by another capable team.
- Quote your team's own screens as their own scope: consignor records, catalogue checks, clerk controls, bidder approvals, invoicing, and settlement are a second product, not a single admin-panel line.
- Buy a maintained auction platform when it fits your sale types; own software when your sale workflow, fee rules, or settlement rules do not fit it.
The first decision is not what to own.
It is whether software is the right answer at all. We use four possible recommendations before discussing a development scope.
- 01
Buy
Choose a maintained auction platform when it handles your sale types, fee rules, and settlement rules, and the remaining gaps can be solved with configuration, a connector, or a small process change. Paying for software you do not have to maintain is often the better trade.
- 02
Repair
Keep the tools you already use when staff still get value from them and the gaps are narrow. Start with evidence: where each lot record lives, how your data is organized, what is tested, which outside services the sale depends on, who can access what, and how updates go live.
- 03
Own
Own the system when your sale workflow shapes margin, consignor trust, or bidder experience, or when a product customers pay through cannot represent your rules. Start with one complete sale path and the system connections that path cannot work without.
- 04
Wait
Do not turn changing sale rules into permanent software. Stabilise the fees, terms, and settlement timing, name the sale owner, and measure the cost of the current process before paying for a product.
Not sure which path is yours? Bring it to a 30-minute call. Leave with the answer in writing.
Fit
Auction software should earn its maintenance burden.
A feature request is not enough. The case is real when the same goods are entered twice, settlement is disputed, or sale day depends on memory.
One lot record is re-entered across tools, and the re-entry is where errors and delays start.
Sale types, fee rules, or settlement rules do not fit a maintained platform cleanly.
The house can name a sale owner and what 'done' looks like for the first release.
A maintained auction platform fits with reasonable configuration and process change.
The team wants software to settle unresolved sale, fee, or settlement rules.
The brief is a feature list with no sale, consignor, or bidder result attached.
Not sure which side you are on? Use the first call to make that decision. A useful answer may be to buy, connect, repair, or wait.
Start with the sale, not the software.
An auction software problem usually starts as a sale problem. Staff enter the same goods twice. A catalogue correction reaches one system and not the other. On sale day, nobody can say with certainty which bidders are approved, which lots met reserve, or which buyers have paid.
Take a house that takes in consignments on paper, catalogues in a spreadsheet, runs bidding on a platform, and settles in accounting software. The visible complaint may be "we need a better website." The real cost may sit elsewhere. No one can see what is blocked. Staff apply fee rules in different ways. Consignors only get an update after they ask.
A second product hides inside the first. Bidders see one catalogue; your team lives in another: consignor records, catalogue checks, clerk controls, bidder approvals, invoicing, and settlement. Quotes that squeeze all of that into an "admin panel" line item are where budgets most often break. On a real platform, your team's screens are routinely the most underestimated part of the build, so we quote them as their own job, with their own users, from the start.
Auction house management software makes sense when one owned system can remove that constraint better than a platform, connector, or process change. The first release should take the smallest useful path from intake to settlement. It should not replace every tool at once.
We start where it hurts.
The catalogue is only one part of the job. The real scope includes the sale rules, the lot data, the connections to your other systems, what happens when a bid or a payment fails, who can see and change what, and who runs it after release.
Consignment intake and cataloguing
Take goods in once, with the consignor, the terms, and the condition notes attached. Turn those goods into lots with descriptions, images, estimates, and reserves, and publish the catalogue from the same record, so a correction is made once and seen everywhere.
Timed and live bidding
Run timed sales that close lot by lot, and live webcast sales where the auctioneer, the room, phone bidders, absentee bids, and online bidders meet in one bid record. Reserves, closing extensions, and tie rules follow the settings for that sale.
Invoicing and consignor settlement
Turn results into buyer invoices and consignor statements from the same sale record. Commission and agreed costs are deducted lot by lot, and only cleared buyer payments release settlement, so one unpaid buyer does not hold up the rest of the sale.
Bidder and consignor records
Keep one record per bidder and per consignor: registration, approval, bid history, purchases, payments, and outstanding items. Staff can see at a glance who is approved, who owes, and whose lots are still in the building.
Sale day controls for the clerk
Give the clerk one screen for the lot on the block: current bid, reserve state, absentee bids waiting, and what happens when a bid fails or a connection drops. The sale keeps moving on the house rules, not on memory.
Which one is yours?
Bring it to a 30-minute call. Leave with a buy, repair, own, or wait recommendation in writing. Free, whether or not we ever work together.
Let the work pick the shape.
The way people work should decide the form of the software. Start with where the user works, which device they have, whether the signal drops on the saleroom floor, what data they need, and how fast the system must respond. Those facts tell us what belongs in the first release.
Web app
Work done across roles and locations. Each user gets the same current information in a browser: no installs, no versions, no device limits. When in doubt, this is usually the right first surface.
Mobile app
Work away from a desk: intake photos, catalogue checks, and lot lookup on the saleroom floor.
Desktop app
The clerk station in the saleroom: local hardware, large files, work without a browser.
One product may need several surfaces. Each one should support the same complete sale, not start another feature list.
How it works
Close one expensive risk before opening the next.
Each stage answers a buyer question and leaves behind a decision you can inspect. The next stage only opens when the expensive uncertainty in the current one is small enough to accept.
- 01Understand
Trace the real sale
Where is the cost or failure actually coming from?
Follow one lot and one consignor from intake to settlement. Include the workarounds, manual judgement, duplicate entry, waiting, and failure paths that a tidy process diagram usually misses.
Decision produced
A map of the sale, exceptions, owners, systems, and the baseline cost or delay worth changing.Risk closed
Paying to automate the visible symptom while the expensive constraint remains. - 02Shape
Choose the first useful release
What needs to exist together for one useful sale result to work?
Choose the shape from the way the work happens, not from a preferred technology. Name the user, the device, the data, the system connections, who can access what, the exceptions, and the result the first release must complete.
Decision produced
The right mix of web, mobile, desktop, or behind-the-scenes connection work, with the first-release boundary and a clear definition of done.Risk closed
A small-looking feature list that quietly depends on several interfaces, systems, and owners. - 03Prove
Review working software
Will it hold up outside a controlled demo?
Review the product against the agreed sale workflow, not a tour of finished screens. Record changed assumptions and test what happens when data is missing, access is wrong, or a connected system fails.
Decision produced
Working checkpoints tested with realistic data, real user types, system connections, recovery plans, and the people who will use or run the system.Risk closed
Discovering the important gaps during settlement or after consignors depend on the release. - 04Transfer
Release, measure, and hand over
Did the new workflow improve the original constraint, and can another capable team operate it?
Move a controlled set of sales or records first. Compare time, errors, completion, or another agreed measure with the starting point before adding the next sale type.
Decision produced
A controlled release, comparison with the baseline, operating notes, account ownership map, and a recommendation for what should happen next.Risk closed
Measuring development activity instead of the business result, or depending on the original vendor to keep the system running.
What stays out of the black box
These are operating conditions to put in the engagement, not claims to take on faith.
The scope names one complete sale
The user, the trigger, the decisions, the data, the exceptions, and what 'done' looks like, all written down before paid work starts. A screen list is not enough.
Progress is visible in working software
Reviews against the product at agreed checkpoints, while there is still time to act.
A scope change has a price before it has code
A new sale type or system connection shows its effect on cost and timing before anyone approves it.
Ownership exists throughout, not only at handover
Code, cloud, data, and provider access stay visible and under your control from day one.
The work is checkable without being technical
Checkpoints are working software you use yourself, reported in plain language, so you can judge progress without reading code.
Related software.
Start from the closest fit. Each area below connects to the auction workflow.
Which sale workflow is costing you the most right now?
Bring it to a 30-minute call. Leave with a buy, repair, own, or wait recommendation in writing. Free, whether or not we ever work together.
What it costs
Every project starts at $10000.
The first phase turns the costliest patched sale workflow into a scoped release with scope fixed in writing.
Starting investment
Starts at $10000
Sale types, systems to connect, data to move over, and user roles set the scope. After a 30-minute call, you get a written buy, repair, own, or wait recommendation plus first-phase direction. Free, whether or not you build with us.
Not ready to talk? Start here.
Four useful next paths: decide whether to own the software, estimate the cost range, understand what moves the price, or inspect a comparable recovery.
Run the build-vs-buy calculator
Compare the cost and operating trade-offs before turning a sale workflow into a development brief.
Estimate the cost range
Get a working cost range for your scope before you talk to any vendor. Use the range to test whether a quote sits in the right area, not as a final price.
Read the cost guide
See the scope factors that move price, timing, team shape, and long-term maintenance.
Inspect a product recovery
See what changed when one product moved from failed vendor attempts to a controlled migration. It is a comparable recovery, not an auction house case study.
Buy or own
| Buy an existing platform | Own software made for your house | |
|---|---|---|
| Best fit | Handles your sale types, fee rules, and settlement rules with reasonable setup, and its pricing makes sense | The way you run sales is itself the advantage |
| Manual work | Configuration and process changes can remove the constraint | Repeated manual work across intake, catalogue, bidding, and settlement has a measurable cost |
| Connections | Existing connections work with reasonable setup | A critical connection to your accounting or other systems cannot be done cleanly any other way |
| Sale rules | One template covers your sales, or the differences are small | Each sale type needs its own fees, terms, registration rules, and settlement timing |
Work with us
Bring one stuck sale workflow. Leave with a decision.
In a 30-minute call, we will help you decide whether to buy, connect, repair, own, or wait. If owning software is not the sensible next move, that is still a useful answer.
- One named sale owner and one complete sale path for the first phase.
- Scope, price, what 'done' looks like, and exclusions agreed before paid work starts.
- Code, cloud, data, and provider access remain under your control.
- Post-launch warranty cover for defects in the agreed scope.
Common questions
Auction house management software runs a sale from consignment intake to settlement in one record. It covers consignor records, lot and catalogue details, bidder registration and approval, timed or live bidding, invoicing, and consignor payment. Its job is to keep every lot, bid, and payment fact in one place, so staff, buyers, and consignors are not working from different versions.
Buy an existing auction platform when it handles your sale types, fee rules, and settlement rules with reasonable setup and its pricing makes sense. Have software made for your house when your workflow is itself the difference: sale types, charges, or settlement rules the maintained products cannot represent cleanly, or connections to your accounting and other systems that cannot be done cleanly any other way. If your sale rules are still changing every week, settle them first.
One connected workflow covers consignment intake, cataloguing, bidding, invoicing, and consignor settlement. Intake records the consignor, the goods, and the agreed terms. Cataloguing turns those goods into lots with descriptions, images, estimates, and reserves. Bidding records timed or live bids against those lots. Invoicing turns results into buyer and consignor documents. Settlement pays the consignor from cleared buyer payments, less commission and agreed costs. This page covers that scope plainly; it does not claim adjacent coverage that does not exist.
A timed auction runs online over days, with no auctioneer in the room. Lots close at set times, and many houses extend a lot briefly when a bid lands near the close. A live webcast auction is run by an auctioneer at a set time, with bidders in the room, on the phone, by absentee bid, and online at the same time. A lot opens when the auctioneer offers it and closes when the auctioneer declares it sold. The software must enforce whichever closing and extension rules your house has set for that sale.
An absentee bid is a maximum left with the house before the sale. It is executed at the lowest price the competition allows, not automatically at the maximum. When two bids tie, the outcome follows the rule your house has set in advance: for example, the earliest bid wins, or the bid from the room wins. The rule must be written down before the sale, because a tie decided on the day looks like favouritism, even when it is not.
The hammer price is rarely the whole price. Buyers usually also pay a buyer's premium, a percentage added to the hammer, plus tax on that premium where it applies, and sometimes an extra charge for bidding live online, plus packing, shipping, or collection costs. Rates vary by house, so the terms of each sale must state them plainly. Software should show the buyer the full figure before they commit, not after.
A lot that does not reach its reserve goes unsold and produces no sale. After the sale, the house and the consignor agree what happens next: the lot may be offered again in a later sale, offered after the sale at or above reserve, repriced with the consignor's approval, returned to the consignor, or disposed of under the consignment agreement. The agreement should state the choice, the collection window, and any storage charge, before the goods are accepted.
Consignors are paid from buyer payments that have actually cleared, less commission and agreed costs such as transport. Lots whose buyer has not yet paid are normally held back, while lots whose buyer has paid are settled on their own. Your house sets the settlement timing in its terms; the software must track each lot separately, so one unpaid buyer does not hold up every other consignor in the same sale.
Registration and approval are house rules enforced by the software, not decided by it. The house sets who may bid, what identification or deposit it requires, and which bidders need approval before they can bid. Consignor checks work the same way: the house sets what it verifies before accepting goods and when it may refuse a consignment or delay settlement until checks are complete. Every approval, refusal, and payment should leave a record of who did what.
Yes, when the accounting product offers suitable access and your finance lead owns the mapping. Define which system owns consignors, lots, invoices, payments, and settlement, and test duplicates, closed periods, retries, rejected postings, and reconciliation before sale day. RaftLabs builds the connection; your finance team approves the accounting treatment and controls.
Yes, when each sale carries its own settings: fees, terms, registration rules, dates, and bidding format. An art sale and a machinery sale can then behave differently inside the same system, instead of forcing every sale into one template. The settings that change a sale's money rules should be visible and changeable only by staff roles your house has approved.
The first paid phase may cover a bounded audit, a proof of concept, a recovery plan, or a small first release. The final price depends on how many sale types it must support, how many kinds of users it serves, what it needs to connect to, whether data needs moving over, whether phones or tablets are involved on the saleroom floor, and the condition of existing code. The agreed phase is priced in writing before it starts.
You judge what you can see, not the code. Every checkpoint is working software you click through yourself, tested against the sale workflow agreed at the start: take in a consignment, catalogue it, run bids against it, invoice it, and settle it. Progress is reported in plain language: what changed, what is next, and what it costs. Because you own the code, the accounts, and the operating notes throughout, nothing about the work is locked inside our heads. Our job is to make the work checkable; your job is to check it against your business.
You own the code built for you and control where it lives, the cloud accounts, the data, analytics, and third-party subscriptions. Outside services and open-source pieces keep their own licence terms. The operating notes and handover material stay current so another capable team can take over.