Retail POS Sync (Shopify POS)

Standard order connectors were designed for web checkout, and it shows the moment you open a physical store. A web order has one payment, one shipping address and one fulfilment location. A store transaction has a till, a cashier, a split tender across cash and two cards, a gift card redemption, an exchange against a receipt from another branch, and an opening float that has to be counted at close. Push that through a web-order integration and you get a Cash Sale with a single lumped payment, no register attribution, no cash position, and a bank reconciliation that never matches because card settlements arrive net of acquirer fees days later while cash sits in a drawer nobody has posted.

The inventory side fails just as quietly. Store stock and warehouse stock are the same item in NetSuite unless someone models Locations properly, so on-hand drifts, replenishment is guesswork, and the online channel promises units that were sold in a shop an hour ago. Meanwhile the finance team gets a single daily total per store and no way to explain why the cash banked is short, because there is no record of the opening float, the paid-outs, or the counted close.

What ECOSIRE builds

ECOSIRE builds a retail-specific sync between your POS and NetSuite as a SuiteScript 2.1 SDF project deployed into your own account. It complements rather than replaces whatever handles your online orders, and it models the things a web connector does not: stores, registers, tenders, drawers and per-location stock.

Event ingestion with a reconciliation backstop

A RESTlet endpoint receives POS order, refund and inventory events with HMAC signature verification, staging each into a custom record with the raw payload preserved. Because webhooks are lossy by nature — a store loses connectivity, a device sleeps mid-sync — a scheduled Map/Reduce sweep independently re-queries for the business day and posts anything the webhook stream missed. Idempotency is enforced on the channel transaction identifier held in a unique custom transaction body field, so the sweep can never double-post what the webhook already handled.

Store and register modelling

Each POS location resolves to a NetSuite Location record. Register or device and cashier are written to a custom segment or custom transaction column, which means every downstream report — sales by store, tender mix by register, variance by cashier — is a saved search rather than a data project. Store hierarchy, region and format can be carried on the Location record or an additional custom segment depending on how you already report.

Posting modes you choose, not inherit

Some retailers need a Cash Sale per transaction for line-level traceability and clienteling; others need one summarized posting per store per business day to keep transaction volume manageable. Both are built and the mode is configuration per store, so a flagship with clienteling can post in detail while a high-volume concession posts in summary.

Tender, drawer and deposit accounting

Tenders are mapped to NetSuite Payment Method records with full split-tender support, so cash, each card type, gift card and store credit land in their own clearing or undeposited-funds account instead of a single lump. A cash drawer session custom record captures opening float, paid-in and paid-out movements, counted close and calculated variance, posting over/short to the account you nominate. At end of day the connector creates Deposit records grouping cash and card clearing balances so the bank reconciliation matches the acquirer payout and the cash banking slip, and any short is attributable to a store, a register and a session rather than appearing as an unexplained difference at month end.

Refunds, exchanges and gift cards

Refunds post as Cash Refund or Credit Memo with items returned to the selling store's Location and guards against driving negative on-hand. Exchanges are modelled as a paired return and sale so both the stock movement and the net tender are correct rather than being collapsed into a single adjustment. Gift cards and store credit are tracked on a ledger custom record: issuance recognized as a liability, redemption treated as a tender against that liability, with balance drawdown and ageing available to finance.

Per-location inventory

On-hand by NetSuite Location is published to the POS on a schedule you set, with Inventory Adjustment support for store-level shrinkage and cycle counts, and Transfer Order support for replenishment from a distribution centre and receiving at the store. Item matching resolves by SKU, barcode/UPC and matrix item variant; anything unmatched — typically an item created at the till — lands in an exception queue custom record rather than creating catalogue noise.

Tax and exception discipline

POS-charged tax is validated against NetSuite tax codes and tax groups for the nexus and Location of the selling store. Mismatches route to an exception dashboard instead of posting silently, because a systematically wrong tax code across a store's daily sales is far more expensive to unwind three months later than to catch on day one. A Suitelet close dashboard shows per-store daily sales, tender mix, drawer variance and unposted exceptions, and a Store Manager custom role gives branch staff exactly that view and nothing else.

Who it is for

Omnichannel retailers already running NetSuite as the system of record who have opened physical stores, concessions or pop-ups and are currently reconciling store trading manually or through a web-order connector that was never designed for it. It suits multi-store operators who need store-level profitability and stock accuracy, and finance teams whose close is delayed by unexplained cash variances.

It is not a fit if you have a single register and low volume where a daily manual journal genuinely costs less, or if you have not yet decided how stores map to Locations in NetSuite — though that decision is something we help you make on the call.

How delivery works

Every ECOSIRE app is built to order. Nothing here exists ready-made and there is no trial download.

1. Scoping call. We map your stores to Locations, your tenders to Payment Methods and clearing accounts, your cash handling procedure, your tax nexuses, your item and barcode conventions, and whether each store posts in detail or in summary.

2. Fixed quote. A written scope and fixed price covering posting modes, tender mapping, drawer handling, gift card treatment, inventory lanes, exception handling and the support window.

3. Build. Developed as an SDF project against your sandbox, typically two to four weeks from acceptance, longer where gift card liability, multi-nexus tax and full replenishment are all in scope.

4. Install in sandbox, then production. Tested in sandbox against real store trading days including a full open-to-close cycle with deliberate variances, refunds and exchanges. After sign-off it deploys to production as an unmanaged bundle or SDF deployment you own, usually store by store rather than all at once.

5. Support. Training for head office and store managers, a runbook covering every exception and its remedy, and a post-go-live support window for defects and configuration changes. You own the source, so future changes are never gated on us.