Retail teams need tablet point-of-sale systems to do more than accept payments. The device must display the right products, apply accurate pricing and tax rules, connect transactions to NetSuite, and support dependable fulfilment and reporting. SuiteCommerce InStore tablet POS setup requires configuration across NetSuite, SuiteCommerce InStore, payment processing, user permissions, and physical store hardware.
This guide explains how we approach that configuration, with particular attention to the operational details that determine whether a tablet POS rollout works reliably at the sales counter. For the broader question of which POS product fits a NetSuite environment, see our guide to evaluating NetSuite POS solutions by operational requirements.
What does SuiteCommerce InStore do on a tablet?
SuiteCommerce InStore, commonly called SCIS, provides a retail point-of-sale experience connected to NetSuite. On a supported tablet and browser setup, store associates can search products, create sales transactions, apply customer and pricing information, take payment through an approved payment setup, and produce order and fulfilment records in the NetSuite environment.
The key distinction is that SCIS is not simply a tablet-friendly website placed in front of a separate POS database. Its value comes from connecting the selling experience to NetSuite records such as items, customers, locations, inventory, sales orders, payments, and fulfilment information. That connection reduces the need to re-enter store transactions into an ERP after the sale.
A tablet is only the front end. The quality of the result depends on the configuration behind it:
NetSuite item, location, tax, customer, and pricing records
SuiteCommerce InStore roles and permissions
Payment processing and tender configuration
Receipt and peripheral device setup
Store workflows for returns, fulfilment, discounts, and customer lookup
Network, browser, security, and device management standards
SCIS should therefore be treated as a retail operations implementation, not as an app installation. The tablet screen is the visible part of the system, but NetSuite remains the source of many of the rules that determine what the associate can sell and how the transaction is recorded.
Before SuiteCommerce InStore tablet POS setup, define the store model
The most important configuration decision is not the tablet model. It is the operating model the tablet must support.
Start by documenting how each location sells, fulfils, returns, and reports transactions. A small store with one location and a simple catalogue has a different configuration requirement from a retailer operating multiple locations with location-specific stock, customer pricing, transfers, ship-from-store orders, and complex tax treatment.
At minimum, define the following before building the environment:
| Configuration area | Questions to answer |
|---|---|
| Locations | Which NetSuite location represents each store, and who can transact there? |
| Items | Which sellable items, matrix items, kits, warranties, or non-inventory items appear in store search? |
| Pricing | Which price levels, customer-specific prices, promotions, or discounts apply? |
| Inventory | Should associates see available quantity, location stock, or fulfilment options? |
| Customers | Is customer lookup required, and which fields are searchable at the counter? |
| Transactions | Should a sale create a cash sale, sales order, invoice, or another transaction flow? |
| Returns | What proof of purchase, approval, refund, and restocking rules apply? |
| Payments | Which tender types are accepted, and how are payment records reconciled? |
This design work prevents a common implementation problem: configuring the interface before deciding what the transaction must mean in NetSuite. For example, if store staff need to sell an item that is not stocked at the current location but will be shipped from another location, the fulfilment flow must be defined before the button or workflow is tested.
How to configure NetSuite records for SCIS
SuiteCommerce InStore depends on clean NetSuite master data. If item records, locations, tax schedules, or pricing rules are incomplete, the tablet application will reflect those weaknesses rather than correct them.
Prepare item and inventory records
Review every item intended for tablet sale. Confirm that the item has the correct sales description, SKU or UPC information, units, pricing, tax treatment, and inventory behaviour. Barcode scanning is only dependable when the scanned value matches the identifier stored in the item record and when duplicate or ambiguous identifiers have been removed.
Pay particular attention to:
Matrix item options and child item selection
Kits and assemblies that should or should not be sold as individual components
Non-inventory items such as services, fees, warranties, or gift wrapping
Discontinued items that should be hidden from store search
Items restricted to particular locations or channels
Return eligibility and restocking treatment
A useful control is to create a representative test catalogue rather than testing only a handful of simple stock items. Include a matrix item, a promotional item, a taxable and non-taxable item where applicable, a low-stock item, and an item that requires fulfilment from another location.
Configure locations and inventory visibility
Each physical store should map to the correct NetSuite location. Confirm that the location is active, has the appropriate inventory and transaction permissions, and follows the organisation’s numbering and reporting conventions.
Inventory visibility needs a clear business rule. Associates might need to see only the current store’s available quantity, or they might need to locate stock at another store or warehouse. Those are different experiences. Showing an inaccurate available quantity creates more operational damage than showing no quantity at all, especially when committed stock, backorders, transfers, or pending fulfilment are involved.
Test inventory using a controlled change. Update a test item’s quantity or create a test transaction, then verify that the expected availability appears in the store experience and in NetSuite. Do not rely on the tablet screen alone.
Set pricing, promotions, and tax rules
Pricing should be driven by defined NetSuite rules rather than informal cashier workarounds. Confirm the default price level, customer-specific pricing, promotional discounts, employee discounts, and manager approval requirements.
Tax configuration deserves separate testing. A tablet POS should apply the correct tax treatment based on the transaction, customer, item, and location rules established in NetSuite. Test tax-exempt customers, taxable products, mixed baskets, shipping charges, and returns where those scenarios apply.
If staff need to override a price, document who can do it, which reason is recorded, and whether the override requires approval. A discount button without governance creates reporting and margin problems that are difficult to trace later.
How to configure SuiteCommerce InStore users and permissions
SCIS permissions should reflect job responsibilities, not convenience. A cashier needs enough access to complete ordinary transactions, while a supervisor may need access to returns, discounts, voids, cash management, or transaction corrections.
Create role scenarios before assigning users. For example, test a standard associate, a supervisor, a store manager, and an administrator. For each role, verify both what the user can do and what the user cannot do. Excessive permissions are a security risk, but insufficient permissions encourage staff to share credentials or bypass approved procedures.
Review permissions for:
Product and customer search
New customer creation and customer edits
Discounts and price overrides
Returns, exchanges, voids, and refunds
Cash drawer operations
Payment reconciliation
Ship-to-customer transactions
Inventory visibility across locations
Administrative configuration
Use individual employee accounts wherever possible. Shared logins weaken audit trails because NetSuite cannot reliably associate a transaction, refund, or override with the person who performed it.
Also confirm session timeout and device security policies. Tablets used on a retail floor should use managed operating-system accounts, screen locks, automatic updates, and restricted access to unrelated applications. The POS role controls NetSuite access, but device management controls the physical endpoint.
Tablet hardware and payment configuration
A successful tablet POS rollout depends on the complete device chain, not just the tablet. Define the required peripherals before purchasing or deploying equipment.
The hardware plan may include a barcode scanner, receipt printer, cash drawer, customer-facing display, card reader, label printer, or receipt email workflow. Compatibility must be confirmed against the current SuiteCommerce InStore release, browser requirements, operating system, payment processor, and store network design.
Do not assume that a peripheral that works with another retail application will work with SCIS. Test the exact combination of tablet, browser, scanner, printer, payment device, and connection method. Bluetooth pairing, USB access, browser permissions, and local network discovery can each affect performance.
Payment configuration requires particular care. Confirm:
Which tender types are enabled
How card payments are authorised and captured
How declined or cancelled payments appear
How split tender transactions are handled
How refunds return to the original payment method
How payment fees and settlement information reach NetSuite
How end-of-day reconciliation compares POS records with processor records
A payment device should not be treated as a simple accessory. It creates financial records, and a mismatch between the approved amount, the POS transaction, and the settlement report becomes a reconciliation issue.
If the payment workflow requires custom integration or additional systems, our NetSuite integration platform services can help assess API, middleware, and transaction-synchronisation requirements.
Configure the tablet and browser environment
Once the NetSuite and SCIS configuration is defined, prepare the tablet as a managed retail endpoint.
Use a supported browser and keep the operating system and browser versions within the compatibility requirements for the deployed SCIS version. Disable unnecessary browser extensions, prevent casual access to unrelated websites, and configure the tablet to remain awake during normal transaction periods without defeating security controls.
The device setup should also address:
Stable store Wi-Fi and appropriate network coverage
Device naming and asset tracking
Screen orientation and display scaling
Camera and scanner permissions where relevant
Receipt printer or payment device permissions
Automatic updates and maintenance windows
Charging, battery rotation, and physical security
Remote wipe or device recovery procedures
Network testing should happen at the actual selling points, not only beside the router. Walk the tablet through the store and test product search, customer lookup, payment initiation, and receipt printing from the locations where associates will work.
Connectivity planning must also distinguish between a slow connection and a true offline operating requirement. Do not promise offline transaction capability unless the deployed SuiteCommerce InStore configuration and payment architecture explicitly support it. A tablet that displays a cached page is not necessarily able to complete and safely record a sale without connectivity.
Build the core transaction workflows
The most valuable SCIS configuration is the workflow design around common and exceptional transactions. Document each flow in business language, then reproduce it in the tablet interface.
A standard sale should cover item search or scan, quantity changes, customer association, promotion application, payment, receipt delivery, and final transaction review. The associate should know what confirms completion and how to find the resulting record.
Returns require more detail. Define whether the original transaction is required, how returns without proof of purchase are handled, whether an exchange is processed as one transaction or two, how the refund is issued, and who approves exceptions. Test returns against different original tender types and verify the resulting NetSuite records.
Ship-to-customer transactions also need a clear model. Determine whether the tablet creates a sales order, how the shipping address is captured, which location fulfils the order, how shipping charges are calculated, and when the customer receives confirmation.
Gift cards, deposits, store credit, loyalty identifiers, and customer-specific pricing should be treated as separate workflows rather than assumed extensions of a standard sale. Each one affects transaction records, customer records, accounting, or future redemption.
A practical workflow matrix looks like this:
| Workflow | Front-end test | NetSuite verification |
|---|---|---|
| Standard sale | Scan, quantity, payment, receipt | Item, location, tax, payment, and customer values |
| Return | Original sale lookup and refund | Return transaction, inventory, and refund records |
| Exchange | Return plus replacement item | Correct relationship between original and replacement transactions |
| Ship-to-customer | Address and fulfilment selection | Sales order, location, shipping, and status |
| Discount approval | Restricted user attempts override | Approval record, reason, and final amount |
| Split tender | Two payment methods complete | Tender amounts and reconciliation values |
Test SuiteCommerce InStore before launch
Testing should use realistic transaction data and the actual tablet hardware. A successful login proves very little. The launch decision should be based on whether the complete retail process works from product selection through accounting and fulfilment.
Run tests for normal, high-risk, and failure scenarios. Include a large basket, duplicate scans, an invalid barcode, an out-of-stock item, a tax-exempt customer, a failed payment, a cancelled payment, a refund, and a transaction interrupted by a connectivity problem.
Verify both sides of every test:
What the associate sees and can complete in SCIS.
What NetSuite records, reports, and downstream workflows show afterward.
Reconcile transaction totals against payment settlement information in a controlled test period. Check that the correct location, subsidiary, tax code, department, class, and other reporting dimensions are present where your NetSuite design requires them.
User acceptance testing should include the people who will actually operate the store. Ask them to complete tasks without an administrator directing every click. This exposes unclear labels, unnecessary steps, permission failures, and workflow assumptions that technical testing misses.
Common configuration mistakes to avoid
The most damaging mistakes are not dramatic software failures. They are small configuration gaps that create repeated manual work.
One frequent issue is deploying before item data is ready. If product names, barcodes, prices, or tax rules are inconsistent, associates lose confidence in the system immediately. Another is testing only successful card payments. Declines, cancellations, partial payments, and refunds reveal the real quality of the payment design.
Location permissions also deserve attention. A user who can transact at the wrong location can distort inventory, revenue, and reporting. Similarly, allowing unrestricted discounts or refunds without approval creates control weaknesses even when the system technically functions.
Avoid treating receipt layout as a cosmetic matter. Receipts should show the information customers need, including transaction references, return instructions, store details, and payment information required by the organisation’s policies. Receipt content also affects customer service because staff rely on the transaction reference during returns and enquiries.
Finally, do not make customisation the first response to every operational problem. First determine whether the issue comes from a missing NetSuite record, incorrect permission, unsuitable workflow, or genuine product limitation. Custom SuiteScript or integration work should solve a defined requirement, with clear ownership and testing.
How much does tablet POS configuration cost?
SuiteCommerce InStore configuration cost depends on the implementation scope rather than the tablet count alone. The main cost drivers are NetSuite data cleanup, number of locations, role complexity, payment integration, peripheral compatibility, custom workflows, reporting requirements, testing, training, and ongoing support.
A basic deployment with clean records and straightforward payments requires less work than a multi-location rollout with complex pricing, returns, fulfilment, customer accounts, and custom approval rules. Hardware procurement and payment processing fees should also be evaluated separately from professional services.
The most useful way to estimate cost is to create a requirements inventory and classify each item as standard configuration, data preparation, integration, customisation, hardware, testing, or training. That approach produces a more realistic budget than pricing the project as a simple tablet installation. If you need help scoping the work, contact Versich to discuss your NetSuite retail requirements.
Conclusion
A reliable tablet POS deployment starts with NetSuite data and store processes, not with the tablet screen. SuiteCommerce InStore must be configured alongside locations, items, pricing, tax rules, permissions, payment processing, fulfilment, hardware, and reporting controls.
The strongest implementation approach is to define the store model first, configure the NetSuite foundation, test complete workflows on real devices, and launch only after front-end transactions reconcile correctly with NetSuite records. With that discipline, SuiteCommerce InStore becomes a connected retail operating tool rather than another isolated sales application.
