A custom POS requirements document answers seven questions: what happens at the counter, how prices and taxes are worked out, how stock moves, which hardware you use, what must keep working offline, which other systems the till must feed, and who is allowed to do what. Write the answers down before you ask any vendor for a quote, and the quotes become comparable.
Most failed POS projects fail at the requirements stage, not in the code. A vendor is told "we need a POS like the one we have, but better", builds something generic, and the cashiers discover in week one that the till cannot do the thing they do forty times a day. This checklist is written for the person who has to hand a vendor a brief: an owner, an operations manager or an IT lead at a retailer or restaurant. Use it to find your own gaps, then use the answers to decide whether you need a custom build at all. If you do, the custom POS software development page explains how we approach one, and the same checklist works for any vendor.
Start with the decision: do you need custom at all?
Custom POS earns its cost when at least one of these is true: you run several branches that must share stock and prices; your pricing or tax rules cannot be expressed in a packaged product without workarounds; the till must post into your ERP, accounting system or online store; you own a hardware mix a packaged product does not support; or the counters must keep selling through outages. If none applies, a ready-made product is quicker and cheaper, and a free single-shop app may be enough. We are open about that; the signals are laid out in when to move from a free CRM or POS to a custom build.
1. The sale: what actually happens at the counter
Describe the busiest five minutes of your day in sequence, as a cashier would. For each step, note what the screen needs to show and what the cashier must be able to do without asking a manager.
- Entry methods. Barcode scan, quick-key buttons for common items, search by name or code, weighed items from a scale, items sold by length or volume, and open-price items.
- Bill actions. Hold and recall a bill, split a bill, merge bills, transfer a table (restaurants), add a note, change quantity, remove a line.
- Discounts. Line and bill discounts, percentage and amount, staff discounts, coupons and vouchers, and which of these need a supervisor PIN above a limit.
- Payments. Cash, card, bank transfer, wallet, store credit, gift card, split tender, tips, partial payment and credit sale on account.
- Returns and voids. With or without the original receipt, refund to the original tender or as store credit, who may approve, and how stock is restored.
- Receipts. Layout, language or languages, tax breakdown, a QR code or invoice number if a tax authority requires one, email or messaging copy, and reprint rules.
Restaurants add table maps, courses, modifiers (no onion, extra cheese), kitchen tickets by station, split-by-seat bills, delivery and takeaway order types, and a way to void an item after it has been sent to the kitchen. Retailers add size and colour variants, serial or batch numbers, layaway, exchanges and price labels.
This is where custom systems justify themselves, so be specific.
| Question | Why it matters |
|---|
| How many price lists exist (retail, wholesale, staff, branch-specific)? | Each list needs its own maintenance and approval route. |
| Are prices tax-inclusive or tax-exclusive, and does that differ by item? | Rounding and receipt layout depend on it. |
| Which tax rates apply, and can one receipt carry several? | Mixed-rate receipts need line-level tax and a clear breakdown. |
| Which promotions run (buy-X-get-Y, bundles, happy hour, tiered discounts)? | Overlapping promotions need a stated precedence rule. |
| Can a promotion stack with a customer discount or voucher? | Without a rule, the cheapest combination wins by accident. |
| Who can change a price, and does the change apply immediately or from a date? | Scheduled prices need a start date and a record of the old price. |
Write the rules as examples with numbers: "A 2-litre bottle at 250 with a 10% staff discount and a 17% inclusive tax prints as follows." A vendor who builds from examples builds what you meant.
3. Items and stock
- Item master. Code, barcode (several per item), name in each language, category, unit and pack sizes, cost price, selling price(s), tax class, supplier, reorder level, and whether the item is stocked, a service or a bundle.
- Variants and batches. Size and colour, expiry dates and batch numbers (pharmacy and food), serial numbers (electronics).
- Stock movements. Sale, return, purchase receipt, transfer between branches, adjustment (damage, theft, count), and production or recipe usage in a restaurant. Decide whether each branch holds its own stock and how a transfer is approved.
- Counts. Full and cycle counts, who counts, who approves the difference, and what happens to sales made during a count.
- Valuation. Whether cost is tracked by average or by batch, and whether the books live in this system or in an accounting package. If stock value matters to your accounts, read inventory and accounting systems alongside this list.
- Purchasing. Purchase orders, goods received notes, supplier returns and supplier price history, if the POS owns purchasing.
4. Customers, credit and loyalty
Decide which of these exist on day one: customer records with phone number as the lookup key, purchase history, credit accounts with limits and ageing, loyalty points with earn and redeem rules, tier levels, gift cards and vouchers with expiry. Loyalty is the area where requirements drift most. Write down the exact earn rate, what counts towards points (is a discounted item eligible?), when points expire, and whether a return reverses the points earned.
5. Hardware inventory
List every device at every counter, with model numbers, because hardware drives more integration work than screens do.
- Receipt printers (thermal, 58 mm or 80 mm), label printers, kitchen printers or kitchen display screens
- Barcode scanners (handheld, presentation, wireless) and how they connect
- Weighing scales and the protocol they speak
- Cash drawers, and whether they open through the receipt printer
- Customer-facing displays
- Card terminals and the payment provider behind each
- Tablets, touch monitors or desktop PCs, and their operating systems
- Network: wired or Wi-Fi, one router or several, and what happens when the line drops
If you plan to buy hardware, say so. It is cheaper to choose devices the software already supports than to write drivers for obscure ones. Our offline-first POS architecture guide explains how printers, scanners and drawers actually connect.
6. Offline behaviour
Define what must work without internet, because the answer sets the architecture.
- Can the cashier keep billing, with prices and stock from the last sync?
- Can a customer be looked up, and can credit be extended offline?
- What happens to a card payment when the terminal cannot reach its provider?
- How long can a counter run offline before it should stop selling restricted items?
- When the connection returns, what happens if two counters sold the last unit of an item?
Agree the answers per item type. A grocery shop may accept a negative stock number and fix it at the next count; a jeweller may not.
7. Integrations
For each system the POS touches, record the direction of data, the owner of each record, and the frequency: accounting or ERP (day-end summaries, purchases, tax), e-commerce (stock levels out, online orders in), payment terminals, delivery platforms, loyalty or messaging services, and tax-authority invoicing. In Pakistan, retailers who must report to FBR should read the FBR POS integration guide and agree with their vendor that the integration is "designed to support" the authority's published interface, confirmed with the credentials your business holds. For how integrations are usually built, see systems and API integration. If the till should feed a full ERP, compare custom ERP software.
8. Roles, controls and audit
| Role | Typical rights |
|---|
| Cashier | Bill, hold, accept payment; no price override, no void after payment |
| Supervisor | Approve voids, refunds and discounts above a limit with a PIN |
| Branch manager | Stock adjustments, cash reconciliation, branch reports |
| Head office | All branches, price lists, user management, exports |
| Auditor / accountant | Read-only access to reports and the audit log |
Ask for an audit trail of voids, refunds, price changes, stock adjustments and logins. In a cash business this log is the main defence against shrinkage.
9. Reports
List the ten reports you read every week, with the exact columns. Common ones are sales by day, hour, item, category and cashier; margin by item; stock on hand, slow movers and reorder list; cash shift summary and variance; tax summary; refunds and voids; customer credit ageing; and branch comparison. Reports specified as screenshots of the spreadsheets you use today are the clearest brief a vendor can receive.
10. Migration, training and go-live
- Data to migrate: the item list with barcodes and prices, opening stock per branch at an agreed count date, customer balances and loyalty points.
- Parallel running: will the old and new tills run side by side for a day or a week?
- Training: who trains cashiers, and in what language?
- Rollback: how do you return to the old till if go-live fails at 11 a.m. on a Saturday?
- Support: who answers the phone during trading hours? See software maintenance and support.
How to use the checklist with a vendor
Send the completed list with your item file and a photo of each counter. Ask each vendor to respond section by section, mark every item as included, optional or not possible, and show a working demonstration on your own items. Timeline Digital builds a free pilot of 2 to 3 key modules for exactly this purpose. There is no fixed timeframe: the schedule is set from your requirements in the Plan step. The free pilot of 2 to 3 key modules is ready in about 2 days, and with 1,200+ developers we have the capacity to deliver a complete system in as little as 2 weeks. The full project starts after you approve the pilot, and the scope, milestones and terms are agreed after it. Long-term support under a service level agreement (SLA) follows launch. Timeline Digital does not publish prices for custom software, because every project is custom.
About the author and publisher
Timeline Digital is a custom software development company founded in 2013 and headquartered in Islamabad, Pakistan. This guide was written by Usama Asif to help retailers and restaurants prepare a brief for custom POS development; it describes general practice and is not a quotation.
