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.

See our work

Bring one stuck sale workflow. Leave with a buy, repair, own, or wait recommendation.

Trusted by

Perceptional logoMusgrave GroupUrShipper logoBrux Dental SolutionsBella Skin Institute LogoEnergia RewardsDraftly logoTuneClub LogoSekou LMS logoLogo of food order management app gulaSnelwegDealsGrubly logoPSi logoInstantor Rewards logologo of Mobile app for events, membership clubs, and communitiesAldiFest retail campaign logoVidmattic logoEMS Connect logoWorx Squad logologo of Online Web App For Making Intrologo of Referral and Viral Marketing PlatformConcurrences logoGE logoTicketstop logo

The brief

Start with what is not working.

Good software decisions begin with the constraint, not a list of features or a preferred technology.

01

Consignment details arrive in one tool, the catalogue is made in another, and settlement is worked out somewhere else again.

02

A catalogue correction has to be entered twice, and nobody is sure which version the bidders saw.

03

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.

    Run the build-vs-buy numbers

  • 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.

A fit

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.

Not a fit

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.

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.

  1. 01
    Understand

    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.
  2. 02
    Shape

    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.
  3. 03
    Prove

    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.
  4. 04
    Transfer

    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.

Buy or own

Buy an existing platformOwn software made for your house
Best fitHandles your sale types, fee rules, and settlement rules with reasonable setup, and its pricing makes senseThe way you run sales is itself the advantage
Manual workConfiguration and process changes can remove the constraintRepeated manual work across intake, catalogue, bidding, and settlement has a measurable cost
ConnectionsExisting connections work with reasonable setupA critical connection to your accounting or other systems cannot be done cleanly any other way
Sale rulesOne template covers your sales, or the differences are smallEach 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.