A clothing shop does not sell products. It sells one product in twenty forms, and nineteen of them are wrong for the customer standing in front of you. The panjabi she likes is there in white and navy but the L is gone; the kameez he wants is the right size in the wrong colour; the jeans that sell out first are always 32 and 34, and the 38s are still hanging there in October. Every serious problem in fashion retail: the stockout on the busiest evening of the year, the markdown you take in Shawwal, the dead stock in the loft above the shop, starts in the same place: a system that treats size and colour as a note rather than as separate stock.
This guide covers what clothing shop software has to do differently, for owners in New Market, Bashundhara City, Mirpur, Chattogram's Terry Bazar or a single boutique in Dhanmondi: the variant matrix, barcoding unbranded stock from Islampur or Keraniganj, season tracking, markdown pricing, the Eid rush at the counter, returns and exchanges, alteration jobs, moving sizes between outlets, and the post-season dead stock analysis that decides next year's buy. The Eid-readiness checklist sits near the end so you can work it before Ramadan rather than during it. Fashion retail POS details.
Why a flat item list fails in a clothing shop
Most cheap billing software gives you a list of items. One row, one name, one price, one stock number. That model works for a bottle of oil. Put a clothing shop on it and one of three things happens, and we have seen all three.
The shop creates one item called "Panjabi cotton white" and keeps size in the staff's head, so stock says 30 but nobody can answer "do you have L?" without walking to the rack. Or it creates 20 unrelated items ("Panjabi white S", "Panjabi navy L") which bills correctly but makes every report useless, because nothing tells the software those 20 rows are one style you bought together and will mark down together. Or it gives up and bills a generic "Garments item" at a typed price, at which point the software is an expensive calculator and your stock figure is fiction.
What you need is a two-level structure: a style (also called a template or parent item) carrying the name, fabric, supplier, season and cost, and under it a variant for every size-and-colour combination you physically own. The variant has the barcode, the stock number and the location. The style is what you report on. Get that right and everything else here becomes possible; get it wrong and no list of features will save you. In MondayPOS this sits in the ERPNext-based inventory module, where variants are generated from the attributes you define once per category.
The variant matrix, in plain numbers
Here is one style of cotton panjabi, code PJ-2231, as your stock screen should show it on the 18th of Ramadan. Rows are colours, columns are sizes, and each cell is a variant with its own barcode.
| PJ-2231 cotton panjabi | S | M | L | XL | XXL | Colour total |
|---|---|---|---|---|---|---|
| White | 3 | 8 | 11 | 6 | 2 | 30 |
| Off-white | 2 | 6 | 9 | 5 | 1 | 23 |
| Navy | 0 | 4 | 7 | 3 | 0 | 14 |
| Maroon | 1 | 2 | 3 | 1 | 0 | 7 |
| Size total | 6 | 20 | 30 | 15 | 3 | 74 |
That single grid answers questions a flat list cannot. Navy S is at zero and navy XXL never arrived, so that run is broken and should come off the front rack. Maroon has 7 pieces spread over 4 sizes: a colour that did not work, and your first markdown candidate. And if a second outlet has 6 navy S sitting untouched, a transfer fixes the hole in one van trip.
Ask any vendor to show this screen live. If the demo shows sizes as rows in a long list rather than a grid, ask how a salesperson finds "navy, L" during a rush with fifteen people waiting.
Naming variants so a human can read them
Keep the code short and predictable, because staff will read it off a label out loud. A common pattern is STYLE-COLOUR-SIZE, so PJ-2231 in navy L becomes PJ2231-NVY-L. Fix your colour abbreviations once (WHT, OFW, NVY, MRN, BLK) and never let two people invent two spellings, because "Navy" and "navy blue" as separate colours will quietly split your stock in half. Same for sizes: decide S/M/L/XL or 38/40/42 per category, and whether kids' sizes go by age or number, then write it in a one-page rule new staff read on day one.
Barcoding unbranded local stock
Imported and branded garments arrive with a manufacturer barcode you can scan. Most stock in a Bangladeshi clothing shop does not. Bales from Islampur, cut-and-sew from Keraniganj, saris from Mirpur's Benarasi Palli, Chattogram-sourced kids' wear and one-off boutique pieces come with nothing at all, or with a tag whose number means something only to the supplier.
So you print your own. The workflow: create the style once, generate the variants for the sizes and colours in that lot, receive them against a purchase entry so cost is recorded, then print a label for every piece and tag it before it reaches the floor. The label carries the style code, colour, size and barcode. Some shops add the retail price, which helps at the counter but hurts when you mark down, so many leave price off the label and let the POS decide.
Hardware is modest. A direct-thermal label printer such as the Xprinter XP-420B lists at ৳9,500–10,000 at Ryans and BDStall as of August 2026, with label rolls as an ongoing cost, and a fashion counter kit (80mm receipt printer, 2D scanner, drawer, UPS) typically lands at ৳25,000–35,000 plus the PC. See the hardware page for tested models.
Two habits separate shops where barcoding sticks from shops where it collapses in a month. Tag at goods-receiving, never at the counter: a piece that reaches the rack untagged will be sold untagged. And make the "no-barcode" sale need a supervisor PIN and log the item and the staff member, so untagged sales stay visible and rare. If anyone can bill a free-text item at a typed price, your stock will never reconcile.
Season, collection and style tracking
Fashion stock has a clock on it. A Ramadan collection is worth full price in the last ten days of Ramadan, worth 30 per cent less in Shawwal, and worth whatever anyone offers by the following winter. Your software should carry that clock as data, not as memory.
At minimum, tag every style with a season or collection (Eid-ul-Fitr 2026, Winter 2026, Puja 2026, Basic/Core), a category tree (Men > Panjabi > Cotton), a supplier, and the date the first piece was received. Those four fields make every report later in this article possible. Core items that sell all year (plain shirts, school uniforms, basic kurta) should be tagged core and left out of markdown rules, because a discount on stock that never goes stale is money given away for nothing.
Ageing is the report to watch: days since first receipt per style, bucketed 0–30, 31–60, 61–90, 90+. A style still in the 90+ bucket after its season has closed will almost never sell at full price, and the longer you wait the less you get. Owners who read ageing weekly take small early markdowns; owners who read it in December take one big painful one.
Markdown and clearance pricing
Discounting is where clothing shops leak the most margin, usually because it happens verbally. A salesperson knocks ৳200 off at the counter, the bill is edited, and nobody can tell you at month-end how much was given away or by whom.
The fix is to make every discount a rule in the software rather than a decision at the counter. A pricing and promotions module should let you set:
- Season-wide markdowns: 20 per cent off everything tagged Eid-ul-Fitr 2026 from a fixed date, without touching each item.
- Tiered clearance: 20 per cent in week one, 35 in week three, 50 after that, scheduled in advance so it runs whether or not you are in the shop.
- Bundles: buy two panjabis, get the third at half price, applied automatically when both are scanned.
- Manual discount limits: a salesperson may give up to a set percentage or taka amount; more needs a supervisor PIN, and every override is logged with the staff name.
- Member pricing: a loyalty tier with a standing discount, no manual edit per bill.
Then read the discount report weekly through the season: total discount given, by outlet, by staff member and by style, next to the margin left after the discount. That last column is the one that matters. A 40 per cent markdown on a style bought at 55 per cent margin is still a profitable sale; the same markdown on a thin-margin basic is a loss you are printing a receipt for. Pricing and promotions details.
The Eid rush: what breaks and how to prepare
Eid-ul-Fitr is not a busy week, it is a different business. Footfall builds through the last ten days of Ramadan and peaks on Chand Raat, when shops in Bashundhara City and New Market trade past midnight. Everything that was a minor annoyance in a normal month becomes the reason a customer leaves without buying. Puja and the winter season are smaller versions of the same pattern.
Queue speed
The whole game is seconds per bill. Scan-to-print should take a few seconds per piece with no page loads between items. What decides it: a 2D scanner instead of typed codes, keyboard shortcuts for tender types, a saved default customer so nobody types a phone number to finish a sale, price and stock visible on the scan, and split-tender in two keystrokes when someone pays part bKash, part cash. Multiply six extra clicks by 400 bills on Chand Raat and you have lost hours of selling.
Extra counters and temporary staff
Most shops open one or two extra billing points for the season, often a folding table with a laptop and a printer. Two rules make that work. The extra counter must run the same stock, so a piece sold at counter 3 disappears from counter 1's screen, a separate spreadsheet on a second machine will cost you an oversell. And every temporary hire gets their own login with a restricted role: sell and take payment, yes; edit prices beyond the discount limit, delete a bill, change stock or see cost and reports, no. When the season ends you disable the logins and the audit trail still shows who did what. POS and checkout details.
Offline billing when the mall's internet is saturated
Every shopping complex has the same failure on the biggest nights. Hundreds of shops share the same broadband, thousands of phones sit on the same mobile tower, card terminals and MFS apps fight for the same pipe, and by 9pm on Chand Raat the connection is effectively gone. A cloud-only POS stops selling at exactly the hour you make your year.
Offline-first means the terminal keeps the item master, prices and stock locally, completes and prints the bill with no server round-trip, and syncs to head office when the line returns, with no re-typing and no duplicate bills. Ask to see it: unplug the router mid-demo, complete three sales including a bKash tender, plug it back in and show the bills arriving at head office intact. Confirm too how stock is handled across two offline counters and how conflicts resolve on sync. Our post on offline billing during load-shedding covers the mechanics; a saturated mall line is the same problem. Keep a UPS at every counter and a charged mobile hotspot as a second path.
Eid-readiness checklist
Work backwards from the moon.
8 weeks before (before Ramadan)
- [ ] Season tags created for the new collection; last year's tags closed.
- [ ] Full stock count done while the shop is still quiet, so the matrix you trust in the rush is correct.
- [ ] New software, if you are switching, already live: a single-outlet setup typically takes 2–4 weeks, so do not start in Ramadan.
- [ ] Size curves reviewed against last season's sell-through before the buy is finalised.
4 weeks before
- [ ] Every incoming lot barcoded and tagged at receiving, not at the counter.
- [ ] Prices, MRP and any planned bundle offers loaded and tested on a dummy bill.
- [ ] Return and exchange policy decided, printed on the receipt footer and put on the wall.
- [ ] Extra counter hardware bought and tested: printer, scanner, UPS, cash box.
2 weeks before
- [ ] Temporary staff logins created with a restricted role; each one trained on 10 practice bills.
- [ ] Offline mode rehearsed with the router unplugged, on every terminal.
- [ ] Reorder points set on fast movers, and supplier phone numbers in one list.
- [ ] Cash float, change and MFS merchant limits arranged for late-night trading.
Chand Raat and the last ten days
- [ ] Day-end run and cash counted every night without exception, including the 2am close.
- [ ] Fast-moving sizes checked at midday for inter-branch transfer the same evening.
- [ ] Supervisor on shift for discount overrides and returns.
The week after Eid
- [ ] Returns and exchanges processed under the written policy, not case by case.
- [ ] Sell-through and dead stock report run per style and per size.
- [ ] First markdown scheduled while the stock still has value.
Returns and exchanges, written into the software
The week after Eid is a returns week: wrong size, wrong colour, the gift did not fit, "my brother already got one". How you handle it decides both your reputation and your margin, and the only way to stay consistent across five salespeople and two branches is to let the software enforce the policy.
Decide the policy first, in plain language, and print it on the receipt. Most Bangladeshi clothing shops land on some version of: exchange or credit within 7 days, original tag attached and receipt shown, nothing on sale or clearance items, nothing on tailored or altered pieces, cash refunds only in specific cases. Then configure it.
| Situation | What the POS should do | Money movement | What to control |
|---|---|---|---|
| Exchange with receipt, same value | Pull the original bill by number or scan, return the variant to stock, issue the new variant | None | Time limit and tag condition checked on screen |
| Exchange with receipt, higher value | Same, plus collect the difference as a normal tender | Customer pays difference | VAT recalculated on the new bill value |
| Exchange with receipt, lower value | Same, plus issue a credit note for the balance | Store credit, not cash | Credit note expiry and one-time use |
| Return without receipt | Look up by customer phone or loyalty record; if not found, supervisor decision | Store credit only, at current selling price | Supervisor PIN and a logged reason |
| Faulty piece | Return to stock as damaged, not as saleable | Refund or replacement per policy | Damaged stock ledger and supplier claim |
| Sale or clearance item | Blocked at the counter with a clear message | None | Rule set on the price list, not left to staff |
Two details matter more than they look. The returned piece must go back as a specific variant (navy L, not "one panjabi") or your matrix drifts within days. And if you are VAT-registered, a return changes VAT you have already reported, so the credit or adjustment document must come out of the same system that issued the Mushak 6.3 invoice and stay traceable to the original bill. Confirm the exact document and treatment with your VAT consultant before the season; our Mushak 6.3 guide covers the invoice side.
Track return rate by style and by staff member. A style returning at 15 per cent has a sizing problem to fix with the supplier, not absorb every season.
Alterations, tailoring and made-to-order
Many clothing shops sell a service alongside the garment: a sleeve shortened, a kameez fitted, a suit made to measure, a blouse stitched. Software that only knows how to sell from stock cannot hold that job, so it goes in a notebook, and the notebook is how a customer's piece goes missing on the 27th of Ramadan.
What you want is an order living in the same system as the sale: a job number printed on the receipt, the piece linked to the bill or held as a customer-owned item, measurements and instructions recorded, a tailor assigned, a promised delivery date, an advance taken with the balance due on collection, and a visible status: received, cut, stitching, ready, delivered. Made-to-order works the same way with fabric issued from stock, so cloth inventory drops when the job is cut rather than when the finished piece is handed over.
Two rules from shops that run this well: record the alteration fee as its own line so you can see whether the service pays for itself, and make altered pieces non-returnable in the software rather than leaving a salesperson to argue about it.
Moving sizes between outlets
If you run two or more branches, the most valuable thing multi-branch software does in a season is find the sizes you already own. Gulshan is out of navy L and Mirpur has six sitting still; Chattogram never sold the XXL run that Uttara is asked for daily. Without a shared stock view you buy more of what you already have, and mark down what another branch could have sold at full price.
A workable transfer flow has four properties: live stock at every branch, visible down to the variant; a transfer that is requested and approved rather than pieces just leaving; an in-transit state until the receiving outlet confirms, so nothing disappears in the van; and a scan-in against the transfer note, so discrepancies surface the same day. Set a season rule (request a transfer when a fast-moving size drops below three pieces) so it happens on schedule rather than in a panic. Multi-branch details.
After the season: dead stock analysis
The buy for next Eid is decided by what this Eid's numbers tell you, and three reports do most of the work.
Sell-through by style. Pieces sold divided by pieces received, per style, for the season. Above roughly 80 per cent means you under-bought; under 40 per cent means the style did not work and should not be repeated. Read it next to margin, a fast seller at a thin margin is not automatically better than a slower one at 60 per cent.
Sell-through by size, per category. This is next year's size curve. If men's panjabi sold through at 95 per cent in L and 45 per cent in XXL, next season's order changes shape rather than volume. Most shops find they have been buying the curve their supplier suggested rather than the one their customers wear.
Ageing and dead stock. Everything past 90 days and past its season, valued at cost, listed by style with quantity on hand. That total is money hanging on a rack. Work it in order: mark down while there is still demand, bundle slow colours with fast ones, transfer to the branch where the size sells, and only then consider a wholesale clear-out: all before next season's stock arrives, because floor space is the cost nobody puts in a spreadsheet. Reports and BI details.
Questions to ask at a fashion POS demo
Run these on any vendor, including us, using your own styles rather than the demo data.
- 1Create one style with 4 colours and 5 sizes, and show me the stock matrix on one screen.
- 2Print a barcode label for an unbranded piece, from receiving to a scannable tag.
- 3Unplug the router. Complete three bills including a bKash tender, then reconnect and show the bills at head office.
- 4Apply a 30 per cent markdown to one season tag, and show which items changed and which core items did not.
- 5Process an exchange with receipt for a different size, and an exchange without receipt as a credit note.
- 6Show a Mushak 6.3 invoice, and show what document is issued when that sale is later returned.
- 7Book an alteration job with an advance, and show it in the pending list with a delivery date.
- 8Transfer 6 pieces of one variant from branch A to branch B, with approval and in-transit stock.
- 9Show sell-through by size for last season, and the ageing report at 90+ days.
- 10Give the total first-year cost for two outlets, including hardware, migration, training and support.
The bottom line
Clothing retail in Bangladesh is a variant business with a seasonal clock and a returns tail. Software that gets the variant matrix right makes every later decision cheaper: you know what to reorder, what to transfer, what to mark down and what never to buy again. Software that does not will keep your stock figure approximately true and your Eid approximately profitable, and you will find out which one by counting the loft after the season.
MondayPOS runs POS, inventory, purchasing, pricing and promotions, accounting with Mushak 6.3 invoicing, multi-branch and reports in one offline-first system, published at ৳1,500–6,500 per outlet per month with a 14-day refund window, and a single-outlet setup typically takes 2–4 weeks. If you are switching before a season, start well before Ramadan, and use our guide to choosing POS software to run the same questions past every vendor on your list. Book a demo with your own style list, or start free.
Frequently asked questions
- What software do clothing shops in Bangladesh use?
- Shops use anything from a notebook to a full retail ERP. What separates workable clothing shop software from general billing software is variant handling: one style with a size and colour matrix underneath, its own barcode per variant, season tags, markdown rules and a proper return and exchange flow. Ask for those five things by name.
- How do I manage size and colour variants in a POS?
- Create a parent style that carries the name, fabric, supplier, season and cost, then generate a variant for each size and colour combination you actually stock. Each variant gets its own barcode and stock count, and the stock screen should show them as a grid rather than a long list.
- How do I put barcodes on unbranded garments bought from Islampur or Keraniganj?
- Create the style and variants, receive the lot against a purchase entry, then print your own labels with a direct-thermal label printer (the Xprinter XP-420B lists at ৳9,500–10,000 as of August 2026) and tag every piece at receiving, before it reaches the floor.
- Will the POS keep billing if the mall's internet dies on Chand Raat?
- Only if it is offline-first. An offline-first terminal keeps items, prices and stock locally, prints the bill with no server round-trip and syncs when the line returns. Test it at the demo by unplugging the router. MondayPOS is built this way; ask any other vendor to demonstrate it live.
- How should returns and exchanges be handled in software?
- Decide the policy first (time limit, tag condition, receipt or no receipt, no exchange on clearance or altered pieces) then configure it so the counter enforces it. Returns should pull the original bill, put the specific variant back into stock, and issue a credit note rather than cash where that is your rule. If you are VAT-registered, the adjustment must be traceable to the original Mushak 6.3 invoice; confirm the treatment with your VAT consultant.
- What does clothing shop software cost in Bangladesh?
- Subscription retail POS typically runs about ৳1,500–7,000 per outlet per month depending on modules, plus roughly ৳25,000–35,000 of counter hardware and a PC. MondayPOS publishes its plans: Lite ৳1,500, Business ৳3,500 and Growth ৳6,500 per outlet per month, billed yearly, with extra outlets at ৳2,450 and ৳4,550.
