SkinKandy is a rapidly expanding retailer, with more than a hundred stores across Australia and New Zealand as well as an online shop, and every sale, refund and stock movement has to end up in the books. We built the enterprise integration hub that does it: 18 pipelines, around 15,000 records a day, with every record audited.
The challenge
SkinKandy runs best-in-class tools for each job. NetSuite is the system of record for finance and inventory. The stores trade on Lightspeed, with a separate instance for Australia and New Zealand. The online shop runs on Shopify. Inventory used to live in Cin7, and NetSuite took that role as part of a migration we supported.
Each tool is good at its own job. The trouble is that a business like this does not live inside one tool, and a business that keeps opening new stores cannot stop to fix its plumbing each time. A sale at the till has to become an invoice. An online order has to become a sales order, then a shipment, then a payment. A new item created by the buying team has to reach every till in every one of those stores. Stock moving between stores, from suppliers and between group companies has to be reflected on both sides before anyone can trust a stock figure.
Done by hand, that means exporting from one system and importing into another, over and over, and that is where numbers drift. It is also harder than it sounds, because the systems do not describe the same event in the same way.
- NetSuite holds prices without tax and calculates its own tax. Shopify and Lightspeed show prices with tax included, and the customer’s payment is based on that tax-inclusive total. The two calculations are often a few cents apart, and they have to align.
- Australia and New Zealand run on separate point of sale instances and different currencies.
- One till sale can mix purchases, returns and several ways of paying.
- One online order can ship in several parts, be edited after it is placed, and be partly refunded.
The finance team needed every document in NetSuite to match what the customer actually paid. Close enough was not close enough.
What we built
We built a custom integration hub: 18 focused pipelines, each moving one kind of record in one direction. Each one is independent and runs on its own schedule, so a problem in one flow never holds up another.
The pipelines group by where the data is going.
- Stores to finance. Closed sales in Lightspeed become invoices, credit memos, customer payments and refunds in NetSuite. Completed stocktakes become inventory adjustments.
- Online shop to finance. Shopify orders become NetSuite sales orders within about 20 minutes during trading hours, and the cycle carries on through fulfilment, invoice and payment. Edits made to an order after it is placed are picked up and the lines rewritten. Refunds reverse the whole cycle, including whether the stock goes back into inventory.
- Finance to stores. The NetSuite item master is pushed to the tills in each region, so a new or changed item reaches every one of the 100-plus stores.
- Stock moving around the business. Stock is only useful if every system knows where it is, so each kind of movement has its own flow.
- Supplier to store: approved purchase orders in NetSuite become inbound consignments at the store, so staff can scan and receipt against them, and the receipt updates NetSuite.
- Warehouse to store: when stock ships from the warehouse in NetSuite, it arrives at the store as a consignment to receive, and the receipt flows back.
- Store to store: a transfer between stores becomes a transfer order in NetSuite, with cost and exchange rate applied, so both stores and the books agree.
- Store back to warehouse: store returns become a transfer, fulfilment and receipt into the returns warehouse.
- Finance to online stock. Receipts and adjustments in NetSuite keep Shopify availability aligned.
- Cin7 and the move to NetSuite. Cin7 was SkinKandy’s original inventory system, so the first flows were built around it. We then supported the migration of inventory to NetSuite, and the hub still brings in intercompany transfers that begin in Cin7, in unlinked supplier consignments, or in an ad hoc file import, as transfer orders in NetSuite.
Reading the same event three ways
Most of the work was teaching the hub what each system means.
Tax is backed out of every price, shipping line and refund, so NetSuite can calculate its own tax. Gift cards are treated as tax-exempt. Because NetSuite’s tax often differs slightly from the till’s, each document is checked after it is created: the total NetSuite returns is compared with what the customer actually paid at the point of sale, and a rounding line closes any gap so the two match exactly. Till cash rounding is handled in the same way.
A till sale that mixes purchases and returns is split into an invoice and a credit memo, with the returned items linked to the original sale and the credit applied automatically. Payments of the same type are merged and mapped to the right payment method for the region.
Region is worked out from the record itself, by currency, shipping country or outlet, and exchange rates are applied to costs, supply prices and Shopify payments so the NetSuite amount matches what the customer paid. Stores are matched to NetSuite locations by name, and a name that does not resolve sets that one record aside instead of guessing.
Online orders that ship in parts, include backordered lines, or are cancelled or partly refunded after the event were listed as a set of edge cases and worked through with the SkinKandy team.
Built to repair itself
The hub is designed so that problems fix themselves wherever they safely can. Temporary errors from a system are retried automatically before a record is set aside. A record that cannot be processed holds up only itself, and the run carries on. For the flows where it matters most, such as purchase orders, transfers and Shopify updates, records that were set aside are picked up again on the next run, so once the cause is corrected at the source they go through without anyone re-triggering anything.
That is safe because every record written to NetSuite carries a reference back to where it came from. A second attempt updates the document rather than creating a duplicate, and every record is logged individually so the team can see exactly what happened.
Seeing what happened
The audit log feeds a Power BI monitoring dashboard showing every run and how many records went through cleanly. Alerts email the team within five minutes if the service itself errors. Separately, a daily report lists every record that could not be processed in the last 24 hours.
Those records are almost never technical faults. They are cases where a source system was used incorrectly, such as a product code that does not exist in the other system, or a store name that does not match. The audit catches each one, says exactly what is wrong, so the problem is corrected at the source and the next run picks it up.
The same data fits into SkinKandy’s wider platform. Operational data from these systems and others also feeds Databricks and Power BI, which is the platform described in our retail insight transformation case study.
Tested before it touched live data
We built and proved the flows in stages against a Lightspeed sandbox. The items flow was run across the whole catalogue, and stocktakes went through repeated test, fix and re-run cycles before going live. Automated tests cover the main flows, and each flow has a written business process guide so the logic is documented as well as coded.
The impact
In a recent ten-day period, the hub moved around 148,000 records between the systems, roughly 15,000 every day. Volumes swing from day to day and are absorbed without anyone stepping in.
The volume is split roughly evenly between sales and payment transactions on one side, and inventory transactions on the other: item and catalogue updates, purchase orders, transfers between warehouse and stores and between stores, receipts and stocktakes. The full item catalogue is checked against the tills in every store, in both countries, on every run.
What that means in practice:
- A sale at any till or on the website becomes the right document in the books without anyone exporting or importing anything. Returns, refunds, split shipments and mixed payments are handled by rule.
- The tills and the online shop reflect what is happening in finance, and finance reflects what is happening in the stores. A new item, or stock moving from supplier to warehouse to store, or from store to store, reaches the other systems on the next run.
- Every transaction matches the source to the cent, so finance can trust the figures.
- Where a source system has been used incorrectly, the audit spots it, reports it every day, and the record repairs itself and goes through safely once the source is corrected.
- The team can see every run and every record, instead of wondering whether something got through.
With 18 pipelines running every day and every record audited, SkinKandy can keep growing its network of stores with confidence that every system stays in sync.
