What is an order management system, and when does a seller need one?
An order management system is the software layer between your sales channels and your warehouse: every order lands in it, and every dispatch, return and stock change flows out of it. You need one when you sell on more than one channel and the time spent switching between seller panels, updating stock by hand and chasing couriers starts limiting how many orders you can ship.
The breaking point is usually overselling. A kurta set sells on Meesho, the same piece sells on Amazon ten minutes later, and only one exists. One order gets cancelled, the marketplace records a seller-side cancellation, and your account health takes a hit. Do that a few times a week and listings get suppressed. A second breaking point is dispatch: orders from four panels printed separately, labels mixed up at packing, and a missed ship-by time on the busiest day of the sale.
An OMS solves both by keeping one stock count per product and one queue of orders. It does not replace the marketplaces or your Shopify store; it sits behind them and makes them work as one business.
- Selling on two or more channels
- Stock updated by hand on each panel
- Cancellations caused by overselling
- Packing errors or wrong labels
- Returns arriving without anyone knowing which order they belong to
- No single view of today’s orders and dispatches
How does an order management system pull orders from Amazon, Flipkart, Meesho and Shopify?
Through each channel’s official integration route where your account has one, and through scheduled imports of order reports where it does not. The goal is the same either way: every order appears in the OMS queue within minutes, tagged with its channel, ship-by time and payment type.
Amazon offers the Selling Partner API, whose Orders API includes operations such as getOrders and getOrderItems for retrieving order and line-item details programmatically. Shopify’s Admin GraphQL API exposes an Order object with fulfilment, return and refund fields; Shopify’s documentation notes that only the last 60 days of orders are accessible by default, and older orders need an additional permission, which matters when you import history. Your own website can post orders straight into the OMS.
For marketplaces or accounts without API access, the OMS imports the order, return and settlement reports you download from the seller panel, on a schedule or with a single upload. We confirm what access each of your accounts actually has during scoping, before any line of the quote assumes an integration exists.
Credentials stay yours
API keys and app authorisations are created under your seller and store accounts. The OMS uses them; we never ask you to share your marketplace password.
WhatsApp and B2B orders too
Orders taken on WhatsApp or from wholesale buyers can be entered or captured into the same queue, so stock stays accurate. Our WhatsApp ordering system page covers capture from chats.
Master SKUs, listing mapping, bundles and combos
SKU mapping links every listing on every channel to one master product in the OMS, so stock and sales are counted once. It is the unglamorous foundation of any order management system, and getting it wrong is the most common reason stock sync fails.
Sellers rarely have consistent codes. The same black cotton kurta in size M might be one code on Amazon, another on Flipkart, a third on Meesho and a variant ID on Shopify. The OMS keeps a master SKU and a mapping table. When an order arrives for any of those codes, the master stock drops.
Bundles and combos need their own rules. A “pack of three” listing consumes three units of one master SKU; a gift combo consumes one unit each of four different products. The OMS calculates how many bundles can be sold from current stock of the components and publishes that number to each channel.
We usually start the project by building the mapping from your catalogue exports, then showing you listings that could not be matched automatically. That list alone often reveals old duplicate listings and variants nobody remembered.
How does stock sync work across marketplaces?
The OMS holds the true stock for each master SKU, subtracts reserved and sold units as orders arrive, and pushes the new available quantity to every channel. When an order comes in on one marketplace, the available count on the others drops shortly after, not when someone remembers to edit it.
Perfect real-time sync is not possible, because each channel accepts updates at its own pace. That is why buffers matter. You might publish the true count on your own website but hold back two units on each marketplace, so a burst of orders during a sale does not oversell before updates land. Fast movers can have larger buffers than slow ones.
Stock comes in as purchase receipts, production output or returns restocked in good condition, and goes out as orders, damages and adjustments. Each movement is logged with the user and reason, so a physical count that disagrees with the system can be traced rather than just overwritten.
- Channel-specific buffers per SKU
- Reserved stock for B2B or offline orders
- Automatic zeroing on a channel when stock hits a floor
- Low-stock alerts for reordering
- Multi-warehouse stock with channel-to-warehouse rules
If you forecast purchases from sales history, the same data can feed demand forecasting so reorders happen before fast movers run out.
Courier integration in an order management system
Courier integration means the OMS books the shipment, fetches the label and AWB number, and pulls tracking updates back into each order, using your own courier contracts or aggregator account. Staff no longer copy addresses between screens, and customers get accurate tracking.
Marketplace orders often use the marketplace’s own shipping, in which case the OMS downloads labels from the channel and records the handover. Shopify and website orders use your couriers. The OMS can choose a courier by rule: pincode serviceability, weight slab, cash-on-delivery availability or your negotiated rate, and you can override any choice by hand.
Labels and tax invoices print in batches sorted by courier, so the evening pickup gets one neat pile per courier with a manifest. Tracking updates flow back automatically, and orders stuck in transit longer than a limit you set appear on an exceptions list for follow-up.
For brands running their own delivery in a city, or a mix of own fleet and couriers, our courier management software page covers rider assignment and proof of delivery.
Picking, packing and dispatch without mix-ups
A picklist groups the day’s orders by product location, so staff walk the shelves once instead of once per order. Packing then checks each item against the order by scanning its barcode before the label is printed, which catches the wrong size or colour before it leaves the building.
For small teams, the picking screen runs on a phone or a cheap tablet. For larger warehouses, handheld scanners or a phone app can mark items picked bin by bin. The OMS records who packed each order and when, which helps when a customer claims a missing item and you need to check the packing video timestamp.
Dispatch closes the loop. At pickup, staff scan each parcel into the courier’s manifest, and the OMS marks orders as shipped on every channel. Parcels not scanned are flagged before the courier leaves.
Ship-by timers
Marketplace orders carry a dispatch deadline. The queue sorts by the nearest deadline and highlights anything at risk, so the busiest day does not end with late shipments.
Packing video habits
Many sellers record packing to support claims. The OMS can store the order number shown on screen at the moment of packing, so matching footage to orders is quick.
How should an order management system handle returns and RTO?
It should log every returned parcel against its original order the moment it arrives, grade its condition, decide whether stock goes back on sale, and track any claim you raise with the marketplace or courier. Returns and RTO (return to origin, parcels the customer never accepted) are where sellers quietly lose the most money.
Customer returns and RTO behave differently. A customer return has a reason, a refund and often a marketplace claim window. An RTO has no refund but costs you the shipping both ways, and for cash-on-delivery orders it is common enough that high-RTO pincodes deserve their own report. The OMS keeps them in separate queues with separate reports.
Grading is usually three or four levels: resaleable as new, resaleable after repacking, damaged, or wrong item returned. Only the first two go back into available stock. Damaged and wrong items open a claim record with photos, the channel’s claim reference and a deadline reminder.
Over time, return reasons by SKU show which products have sizing problems or misleading photos, and RTO by pincode shows where to restrict cash on delivery. Those two reports often recover more money than any other part of the OMS.
Reconciling marketplace payouts with orders
Payout reconciliation matches each settlement from a marketplace to the orders it covers, checks the fees and deductions, and lists anything missing or wrong. Without it, sellers rarely notice an order paid short or a return refunded twice.
The OMS imports settlement reports from each channel and matches line items to orders by order ID. For each order it shows the sale price, marketplace fees, shipping charges, taxes collected at source and the net received. Orders delivered but not settled after the expected period appear on an exceptions list, as do fees that differ from the rate you expect for that category.
This is also the natural bridge to your books. Tally Solutions publishes an Amazon Data Import plug-in for TallyPrime that reads Amazon sales, returns and settlement Excel files; an OMS goes further by combining every channel into one export mapped to your ledgers. Our Tally–Shopify integration and Excel to Tally import pages cover the accounting side in more depth.
Your accountant decides how each fee and tax line is treated. The OMS simply keeps the numbers complete, tied to orders, and ready for them.
Custom order management system or subscription OMS: how to decide
Choose a subscription OMS when all your channels and couriers are on its supported list, your dispatch process is standard and you want to start this week. Choose a custom order management system when you have channels or workflows the tools do not cover, fees scale painfully with your order volume, or you want the data and logic in your own hands.
Subscription tools are strong on the common path. Custom builds win on the specific: a B2B wholesale flow alongside marketplace orders, a production step between order and dispatch for made-to-order products, returns grading that feeds a refurbishment line, or a warehouse layout that does not suit generic picklists. Each of those becomes a daily workaround in a tool not designed for it.
A practical test: list your five most irritating daily tasks. Trial a subscription OMS for two weeks and see how many disappear. If most do, subscribe. If most remain, get a custom quote. Our broader off-the-shelf vs custom software guide applies the same logic to any business system.
How much does an order management system cost in India?
A custom order management system from BtechWaleTech starts at ₹60,000 (US$900) for a web OMS with a unified queue from two channels, SKU mapping, stock sync and core reports. Each additional channel, courier integration, returns desk, pack verification, payout reconciliation and Tally export is an itemised line.
Channel integrations vary most in effort. An API integration with good documentation is predictable. A channel that only offers downloadable reports needs import templates and validation, which is quick to build but depends on the report format staying stable. Multiple warehouses and a warehouse staff app add scope; a native Android and iOS app starts at ₹40,000, though a phone-friendly web screen is enough for many teams.
Running costs are hosting in your own cloud account and any charges from your courier or aggregator. There are no per-order or per-channel fees on a custom build, which is the main reason growing brands consider one. After two free months of maintenance, care starts at ₹8,000/mo, which matters for an OMS because marketplaces change their APIs and report formats from time to time.
How long does it take to build and roll out an OMS?
Six to twelve weeks is typical. We bring channels live one or two at a time rather than switching everything at once, because a problem found with one channel is easy to fix and a problem found with five at once is a crisis.
The first two weeks cover catalogue import, master SKU mapping and the order queue for your busiest channel. By week four, stock sync runs for that channel with conservative buffers, and a second channel joins. Courier booking and labels follow, then the returns desk, then remaining channels, reconciliation and the Tally export.
Plan the rollout away from a big sale. Starting two or three weeks before a festival sale, not during it, gives the team time to trust the queue. During the first days on each channel, staff check the OMS stock against the seller panel every morning, and we tune buffers and fix mapping gaps quickly.
Delays usually come from catalogue data: SKUs with no barcode, variants mapped inconsistently across channels, or bundles nobody documented. Clean catalogue exports at the start save more time than anything else.
Tech stack, reliability and seller data security
An OMS must keep working when a marketplace API is slow or a courier’s tracking service is down. We build channel connections as background jobs that retry, queue updates when a channel is unreachable and alert you if a channel has not synced for longer than normal, so nothing fails silently.
Under the hood we typically use a TypeScript or Python backend, PostgreSQL for orders and stock, a job queue for channel syncing, and hosting on a mainstream cloud in an Indian region, all under your account. Screens work in any browser, so packing staff use whatever phone or PC they have.
Order data includes customer names, phone numbers and addresses, so access is role-based: packing staff see what they need to pack and ship, accounts sees payouts, owners see everything. Data is encrypted in transit and at rest, actions are logged, and backups run daily. Marketplaces set their own rules about how seller-side systems may store and use buyer details; we build to respect those rules for each channel you connect, and your own lawyer can advise on wider data protection duties.
If you later want a branded storefront or app on top, see D2C app development and Shopify app development.
Worked example: an order management system for a hypothetical saree brand in Surat
Say a Surat saree brand sells on Amazon, Flipkart, Meesho and its own Shopify store, ships a few hundred orders a day in the festival season, and keeps stock in one godown with a small packing team. Stock is updated on each panel twice a day, cancellations from overselling happen every week, and returns pile up unopened until the weekend.
The OMS would start with master SKUs for every saree and blouse combination, mapped to each channel’s listing codes, with combos consuming components. Shopify and Amazon would connect first through their APIs; Flipkart and Meesho would follow using API access if the brand’s accounts have it, or scheduled report imports if not. Buffers would be larger on marketplaces than on the brand’s own site.
Courier booking for Shopify orders would use the brand’s aggregator account, with labels printed in batches. Marketplace-shipped orders would download labels from each panel. Returns and RTO would be scanned on arrival, graded into four levels and restocked or claimed. A weekly RTO-by-pincode report would guide which areas keep cash on delivery.
A scope like this would sit several lines above the ₹60,000 starting price because of four channels and the returns desk, and would roll out over about ten to twelve weeks, timed to finish before the festival rush. This is a hypothetical scenario for illustration only.
Order management systems for sellers across India
Marketplace and D2C selling is spread across India’s manufacturing clusters, and each brings its own order patterns. Textile and saree sellers in Surat deal with huge variant counts and festival spikes. Block-print and jewellery brands in Jaipur handle combos and made-to-order pieces. Knitwear sellers in Tiruppur and Ludhiana manage size-colour grids that make SKU mapping the first job.
Footwear brands in Agra face size-driven returns that make grading essential. Home furnishing sellers in Panipat and Karur ship bulky parcels where courier choice by weight slab saves real money. Handicraft and furniture sellers in Jodhpur and Saharanpur deal with fragile items and damage claims. D2C startups around Gurgaon and Bengaluru often want an OMS that feeds their own dashboards and apps.
We work remotely with all of them: calls on video, updates on WhatsApp, staging links for your team to test, payment by UPI or bank transfer against a written quote. We do not visit warehouses, so we rely on short videos of your packing area and a walk-through call to design the pick-pack flow.
Checklist before you commission an order management system
Prepare these before asking for quotes. They decide scope, expose integration limits early and make quotes from different developers comparable.
- List of channels, with daily order volume on each
- Which accounts have API access and which rely on downloaded reports
- Catalogue export from every channel with current SKU codes
- Bundles and combos, and the components each uses
- Warehouses or godowns, and how stock is split between them
- Courier contracts and aggregator accounts in use
- How returns and RTO are handled and graded today
- Settlement reports from each channel for one recent month
- Tally ledger list for sales, returns and fees
- Busy seasons to avoid when going live
Also decide who owns what: the OMS hosting, the database and every API credential should be in your business’s name. For more on vetting any developer, see questions to ask an app developer, and for your storefront, Shopify store setup.