Noon Marketplace Connector

Selling on a Gulf marketplace at any volume creates a second operational reality that the ERP never sees. Orders arrive in the seller portal. Someone exports them to a spreadsheet, keys them into NetSuite as Sales Orders or Cash Sales, and hopes the SKU mapping is right. Stock is decremented twice or not at all, so the listing oversells and the account takes a performance penalty. At month end the payout lands in the bank as a single net figure — gross sales minus commission, fulfilment fees, shipping, coupon funding, return deductions and adjustments — and nobody can decompose it into the GL accounts it belongs to, so it sits in a suspense account until someone reverse-engineers the settlement statement line by line.

The accounting side is worse in the Gulf than elsewhere, because a seller commonly operates across both Saudi Arabia and the UAE with different VAT rates, different registrations, different currencies and often different subsidiaries in a OneWorld structure. Marketplace-collected tax has to be recognized correctly against the right nexus, and fee deductions have to be posted against the right subsidiary rather than netted off revenue. Doing that manually is not merely slow — it is the reason margin per SKU is unknowable and the bank reconciliation is perpetually a month behind.

What ECOSIRE builds

ECOSIRE builds a bidirectional connector between your Noon seller account and NetSuite, implemented as a SuiteScript 2.1 SDF project deployed into your own account. It is not a hosted middleware subscription — the integration runs inside NetSuite, on your scripts, with your credentials.

Order ingestion that cannot double-post

A scheduled Map/Reduce job polls the seller APIs your account is provisioned for and stages every order into a custom record, retaining the raw payload for audit. A second stage transforms staged records into Sales Orders or Cash Sales according to the posting model agreed in scoping. Idempotency is enforced by the marketplace order identifier held in a unique custom transaction body field, so a replayed poll, a retried job or a manual re-run can never create a duplicate transaction.

Item matching resolves listings to NetSuite items by item name, partner SKU or UPC. Anything that does not resolve goes to an exception queue custom record with the offending payload attached, rather than failing silently or creating a placeholder item that pollutes the catalogue.

Customer, subsidiary and currency routing

How marketplace buyers are represented is a decision, not a default. During scoping you choose between a single marketplace customer per channel and country — the common pattern where buyer PII is limited — or per-buyer customer records built from the order payload where the data permits it. In OneWorld accounts the connector routes each order to the correct subsidiary, Location, currency (SAR or AED) and revenue account based on the selling country and store, and stamps a channel custom segment on every transaction so marketplace performance can be sliced independently of your other channels.

Fulfilment, stock and price

For self-shipped orders the connector creates Item Fulfillment records, captures carrier and tracking, and writes the shipment back to the marketplace. For orders fulfilled from marketplace-held stock, the fulfilment lane is separated and mapped to distinct Location records so on-hand in a marketplace warehouse is never confused with your own.

Availability push is built from a saved search of on-hand less committed less a configurable per-SKU buffer, batched and throttled to respect API rate limits, with a run log so you can prove exactly what quantity was published and when. Price push follows the same pattern, driven by whichever price level or pricing custom field you nominate.

Returns, cancellations and credits

Cancellations before fulfilment close the Sales Order cleanly. Post-fulfilment returns create Return Authorizations and Credit Memos or Cash Refunds, restocking to the correct Location and flagging items marked unsellable for a separate disposition. Return-related fee deductions are carried through to the settlement lane rather than being lost against revenue.

Settlement and payout reconciliation

This is where most spreadsheet-driven marketplace operations break. The connector parses payout statements and posts each deduction category — commission, fulfilment, shipping, coupon and promotional funding, penalties and adjustments — to the GL accounts you nominate, as Journal Entries or Vendor Bills according to your policy. A reconciliation Suitelet then matches the computed net against the actual bank deposit and lists any unmatched or unexplained lines for investigation, so the suspense account stops being a filing cabinet.

Tax, security and failure handling

Tax codes and tax groups are mapped per subsidiary for UAE and Saudi VAT, and the connector validates that marketplace-charged tax matches NetSuite's own calculation, routing mismatches to an exception dashboard instead of posting a silent discrepancy. If you already operate an e-invoicing process, we map the connector's output into it; we do not make regulatory certification claims of our own.

API credentials are held using NetSuite's secrets management for N/https calls rather than in plain custom fields. The integration runs under a least-privilege custom role. Every lane has bounded retries with dead-letter records, and saved-search-driven alerts notify a named owner when anything is stuck, so a silent outage cannot run for a week.

Who it is for

Gulf-based sellers and brands already running NetSuite who are shipping meaningful volume through the marketplace and currently bridging it with exports, and multi-country groups whose Saudi and UAE operations sit in different subsidiaries. It is also for finance teams who can no longer close the month because marketplace settlements are unallocated.

It is not for you if you do not yet have an active seller account, or if your volume is low enough that manual entry genuinely costs less than an integration. We will say so on the call.

How delivery works

Every ECOSIRE app is built to order. Nothing is pre-built and there is no download.

1. Scoping call. We review your seller account, the API or export access you actually hold, your subsidiary and Location structure, item and SKU conventions, tax registrations, and how you want marketplace revenue and fees posted.

2. Fixed quote. A written scope and fixed price covering lanes, record types, mappings, exception handling and the support window.

3. Build. Developed as an SDF project against your sandbox. Typical build is one working week from acceptance, longer where multiple subsidiaries, both fulfilment models and full settlement automation are all in scope.

4. Install in sandbox, then production. Deployed to sandbox first and tested against real orders and a real settlement statement. After your sign-off it goes to production as an unmanaged bundle or SDF deployment that you own.

5. Support. Training, runbook documentation covering every exception type and its remedy, and a post-go-live support window. Because you own the source, future marketplace API changes can be handled by us, by your team, or by any developer you choose.