Furniture Store Software That Actually Tracks Special Orders, Delivery, and Warehouse Stock

Why inventory and order software makes or breaks a furniture retailer

Furniture is the only retail category where you routinely sell an item you do not own, cannot show, and will not deliver for four months, then have to remember every detail of it. A customer picks a Smith Brothers 8000 series sofa in a cut-and-sew fabric with contrast welt, nailhead trim, and a firmer seat cushion. That is one line on a sales order and about nine attributes that have to survive a purchase order, a vendor acknowledgment, a container, a receiving dock, a staging rack, and a two-man crew on a Tuesday morning. Lose one attribute anywhere in that chain and you own a sofa nobody ordered.

Most multi-location dealers run this on STORIS, ECi PROFITsystems, Genesis Advantage, or Myriad Eclipse, plus a Shopify or Lightspeed front end for the website, a shared drive of vendor acknowledgment PDFs, a DispatchTrack or Elite EXTRA account for routing, and somewhere between four and nine spreadsheets that exactly one person understands. Shopify POS Pro is publicly listed at $89 per location per month. The furniture ERPs do not publish pricing at all, which tells you what kind of purchase it is.

The expensive version happens on a Saturday at 2:40pm, two customers on the floor and one on hold. A buyer wants to know where her sectional is. The salesperson opens the order, sees "On Order," and calls the warehouse. The warehouse manager finds a PDF from the vendor dated six weeks ago promising week 31, and does not know that the vendor emailed a revised week 38 date last Tuesday to a purchasing address nobody watches on weekends. The salesperson says three weeks. Five weeks later she cancels a $6,400 order and the sectional goes to clearance at 40 percent off. In the dealers whose data we have migrated, this is not one bad Saturday. It is a steady leak of written business into cancellations, clearance, and refunded deposits.

Problem one: the special order goes dark the moment it is written

You write 300 special orders a month across three stores. Each generates a vendor PO. Ashley, Flexsteel, La-Z-Boy, Hooker, and Rowe all acknowledge differently: some through a portal, some through SPS Commerce EDI, some through a PDF attached to an email from a rep's personal address. The ack carries an estimated ship week. That week changes, usually twice, and the change arrives as a new PDF that replaces nothing.

STORIS and PROFITsystems both have a purchase order module and both can store an expected date. What they cannot do is treat the acknowledgment as a living stream. They store the date somebody typed in. Nobody types in the third revision. The tools model the PO as a document, not as a promise with a history and a confidence level.

A custom build ingests every acknowledgment: PDF, EDI 855, or scraped portal row, and runs document extraction on it. A model pulls vendor SKU, customer PO number, quantity, ship week, and exception codes off a PDF that has never had a consistent layout, and writes a dated revision against the PO line. This is where AI is worth paying for, and it is extraction, not chat. Every ack becomes a row in a promise history table, so the sofa now has a current promise, a promise age, and a slip count. Three slips on a Rowe PO is a signal you can fire to the salesperson and the customer before the customer calls. You also get vendor scorecards that are real: median slip days by vendor by category, which is the number you take into a buying meeting at High Point.

Problem two: the truck leaves at 7am knowing less than the office does

Fourteen stops, two crews, roughly $70,000 of merchandise on the truck. Stop six is a bedroom set where the nightstands arrived and the dresser did not. Nobody flagged it, because the pick happened at 5:30am and the sales order flips to complete the moment the last line has any received quantity. The crew arrives, cannot deliver, the customer took the day off work, and you burn 90 minutes of crew time plus a reschedule. In our client data a failed white glove stop lands between $140 and $260 in direct cost, plus a one-star review.

DispatchTrack and Elite EXTRA route well. They are routing systems fed by an order export. They do not know your allocation logic, they do not know the dresser is a special order with a slipped ack, and they cannot decide that stop six should never have been built into today's route. Meanwhile the ERP knows the inventory and has no concept of a route.

The build puts the delivery readiness rule inside the same system that holds the order lines. A delivery becomes routable only when every line in the delivery group is physically received, tagged to that customer, staged in a scanned bin, and free of open damage flags. The warehouse crew scans to a bin with a phone, and the bin scan is what flips the line to ready. Route building then pulls only ready groups. Add a COD balance check so no crew shows up to collect money the customer already paid online. Add crew-side capture: photos, signature, and a damage note against the specific line rather than the order.

Problem three: warehouse stock is three numbers that never agree

A 120,000 square foot DC, a stockroom behind each showroom, and floor samples that are technically sellable. The ERP says four of a recliner. The website says two. The warehouse has one, and that one is tagged to a customer, sitting on a rack, being counted as available. Somebody sells it.

Off-the-shelf retail inventory is built on a single available quantity per SKU per location. Furniture needs at least five states per unit: on order, in transit, received and unallocated, received and allocated to a specific sales order line, and delivered. Floor samples need a sixth. Off-the-shelf systems either flatten these into one number or bolt on a reserve flag that nothing enforces. It shows up on the website first, because Shopify syncs a quantity and has no idea what allocated means.

The build models the unit, not the SKU: bin-level unit records with an explicit state machine and an allocation edge to a sales order line. Available to promise becomes a computed value, and it is the same computed value the website, the POS, and the sales floor read. Transfers between locations become real objects with an in-transit state instead of a subtract-here-add-there. Cycle counts become a scan against expected bin contents. Forecasting is the second place AI helps: a model trained on your own three years of sell-through by SKU, by store, by season, joined to vendor lead-time reality from the promise history table, gives your buyer a reorder point that knows a Vietnam container is 11 weeks and a domestic Amish build is 16.

Problem four: service tickets and protection plan claims fall into a hole

A crew delivers a sectional and a seam is split. They note it on paper. A week later the customer calls. Someone emails the vendor for a part. The part arrives at the DC with no customer name on it. A technician has to be scheduled. Meanwhile the customer bought a Montage or Guardian protection plan and nobody knows whether this claim goes to the vendor under warranty or to the plan provider. Service in most furniture ERPs is a text note and a to-do, not a workflow with a parts order tied to a vendor PO, a technician calendar, and a claim path decision.

In a custom build, the damage photo from the crew's phone creates the ticket with the order line, vendor, delivery date, and plan status already attached. A rule engine picks the path: inside the vendor warranty window goes to a warranty parts PO, outside goes to the plan provider's claim flow. The parts PO carries the customer reference through receiving so the part lands tagged. Technician scheduling shares the same capacity model as delivery. AI helps in two narrow places here: classifying the damage photo to suggest a part and a path, and drafting the follow-up sequence so the ticket does not go silent for nine days.

Problem five: nobody knows what the written business is actually worth

You wrote $1.8M last month. You recognize revenue on delivery. Your deposit liability is real money you cannot spend. Your commission plan pays on delivery, or on write, or half and half, and your sales manager reconciles it in Excel. Your profitability by vendor is a guess, because freight, defect rate, and clearance markdowns never get attached back to the vendor.

QuickBooks Enterprise and even NetSuite do not natively model sold-not-delivered as a first-class state with a deposit ledger against it. The furniture ERPs do, but their reporting is fixed, and a custom cut usually means paying for a report. A build treats written, delivered, and deposit as separate queryable facts, calculates commission from the delivery event, handles splits at the line, and carries landed freight, warranty parts cost, and clearance recovery back to the vendor record. The point is not a prettier dashboard. The point is that the number is derived from the same events your warehouse and crews are already creating, so month end stops being an archaeology project.

What this costs and how long it takes

Framed only as Digital Heroes delivery experience across 2,000-plus projects: a focused first release typically runs $60k to $130k and ships in 12 to 16 weeks. For a furniture dealer, the right first release is almost always the special order promise chain plus delivery readiness: PO to ack ingestion to unit state to route eligibility. That single loop is where the cancellations live. A full platform, meaning POS, allocation, warehouse mobile, delivery, service, protection plans, financing, and reporting, runs $150k to $400k phased over 6 to 12 months.

What drives price up in this category specifically. Vendor integrations: each vendor with a real EDI relationship through SPS Commerce is discrete effort, and portals with no API mean scraping plus ongoing maintenance. Financing: Synchrony, Wells Fargo Retail Services, Progressive Leasing, Snap Finance, and Acima each have their own flow, so a dealer running four of them is running four integrations. Migration: pulling 15 years of order history, custom option configurations, and open deposits out of a PROFITsystems or Myriad database is commonly four to eight weeks on its own, and it is the line item people underestimate. Warehouse hardware: Zebra scanners, label printers, and offline tolerance inside a metal building. Location count only drives price when the locations genuinely run different processes, which in acquired-dealer groups they always do.

Build versus buy, with a position

Buy. If you are one or two stores under roughly $8M, take STORIS or Genesis and live inside it. The furniture ERPs encode 30 years of category knowledge you would otherwise rediscover at your own expense. You will not beat their sales tax handling or their vendor catalog ingestion for the money, and custom software at that size is a hobby.

Build. The signals are specific. You employ someone full time whose job is reconciling two systems. You have more than one warehouse and you move stock between them by phone call. Your delivery failure rate is above five percent and you cannot explain why. You have a real ecommerce channel and your website quantity is wrong often enough that you stopped showing quantity at all. You are acquiring dealers and every acquisition means another instance to babysit. Or the one that settles it: your process is your edge. If you are the group in your market that actually delivers when promised, and the ERP forces you to operate like everyone else, the ERP is the constraint. The honest middle path is common and it works: keep the ERP as the financial system of record, build the operational layer on top, integrate the two. Most of our furniture work is that shape, not a rip and replace.

How to choose a developer for furniture retail software

Ask about the data model first, on the call. Have them sketch how they would model a cut-and-sew sofa with seven option attributes, allocated to a named customer, sitting in transit on a container. If the answer is "a SKU with variants," they are going to build you a Shopify. The right answer involves a configuration record, a unit record, and a state machine.

Ask what they have actually integrated, not whether they "do integrations." Specifically: have they touched SPS Commerce EDI, an 850 and an 855 and an 856? Have they pulled from a vendor portal with no API? Have they done a financing handoff to Synchrony or Progressive? Have they migrated a dealer off PROFITsystems or Myriad? A yes with a war story is worth ten yeses without one.

Ask about the warehouse and the truck, because that is where the software gets used by people who did not choose it. Ask what happens to a scan when the signal dies at the back of the building, and what happens to a delivery capture when the crew has no bars in a basement. If they have not designed for offline, they have not shipped this.

Ask about PCI and card handling before you ask about price. You take deposits at the counter and balances at the door. The correct answer is that card data never touches your system, that they use a tokenizing processor and a P2PE terminal, and that the build stays out of scope. If they offer to store cards to smooth out balance collection, end the call. Then ask who owns the code, and get "you do, in your repository, from commit one" in writing before anything is signed.