The reason to buy inventory or work-order SaaS is usually honest: stop matching Excel. Two weeks after launch the complaint is rarely the look of the screen. It is “we do not have that field, and the system will not let us do that action.” So the warehouse keeps a second book, and sales still changes dates in the group. You keep paying the subscription. Work is back where it was before the purchase.
Fields SaaS wants you to fill
- Customer
- One code, one tier, one list price
- Line
- SKU + qty + tax-in price; free goods need a “discount line”
- Warehouse
- One order, one warehouse; transfers must hit in-transit first
- Approval
- Below floor price locks the order — no “the boss said yes”
- Ship
- Stock must exist before outbound; no negatives
- After-sales
- Returns are a credit memo; you cannot edit qty on the original
What the floor actually does
- Customer
- One legal name, several ship-to points; price follows the salesperson and the season
- Line
- Buy ten get one lives in a note, or the warehouse grabs two bags to pad the carton
- Warehouse
- One order ships from two warehouses, or a store lends stock and the transfer is backfilled
- Approval
- Rush orders load first; a screenshot hits the group later
- Ship
- Goods are on the road, books have not received them, tomorrow is still promised
- After-sales
- Swap is taken on the spot; the document is backfilled at night — sometimes forgotten
When they do not match, do not force the floor to fit the module
Once people walk around it, SaaS inventory and receivables become display numbers. Month-end still goes back to the spreadsheet. The only difference from buying nothing is the subscription. Spreadsheets also collapse at scale — see Excel inventory breaks once volume grows. If a lot of work still happens in groups, the risks stack — see The risk of taking orders and shipping from WeChat groups.
The right order is: list the exceptions that actually happen each month and that cost money or complaints — free goods, split shipments, borrowed stock, verbal discounts, pre-allocating before inbound. For each one, ask: turn it into a rule the system can run, or write phase one as “we will not do this, keep a written exception.” Choose neither and you stay on two tracks. Packaged vs. custom is about whether those exceptions can be changed — expanded in How packaged software actually differs from a custom system.
Three ways out — pick one and write it into the plan
One: change the floor. Kill verbal shipping and off-book free goods so the packaged product can run. That fits companies with few exceptions and an owner who can hold the warehouse. Two: configure. If the SaaS opens custom fields, approval flows, and multi-warehouse rules, put the exceptions there instead of buying another plugin. Three: custom modules. Build only the stretch that does not match — split shipments, contract milestones, work orders writing quality — and keep the finance or inventory you already run. Whether a mid-size company should buy ERP first or start with modules is in Should a mid-size company buy ERP first, or start with custom modules.
Two tracks look like this: the system holds a “standard order,” the warehouse ships another qty from the group; finance chases receivables from the system, the customer refuses the gap against the delivery note. Extra training hours will not close that split. People are not failing to click. They click and still cannot store the real action. Writing exceptions into rules — or writing phase one as out of scope — is cleaner than buying another industry plugin.
When DaXi Technology builds a business system, we first put SaaS fields and floor actions on one comparison table, then decide configure, integrate, or build separately. Do not idle in “one more training will fix it.” To compare the software you have with how work runs, tell us which fields are stuck on the Business systems service page. Cost and cycle are estimated on the scope after that comparison — see What a custom business system costs and how long it takes.