Etsy & Handmade Marketplace Connector

Craft, homeware and small-batch brands that outgrow spreadsheets usually land on Dynamics 365 Finance and Supply Chain Management for a reason: multiple legal entities, real inventory valuation, proper VAT handling, a warehouse that needs directed picking. What almost never changes is the sales channel. Etsy still carries a meaningful share of the revenue, often the highest-margin share, and it keeps running on its own listing structure while everything else moves into F&O.

So the same three problems appear. Stock is right in F&O and wrong on Etsy, because the last sync was manual and happened on Tuesday. Orders arrive as a CSV that somebody keys into sales orders, which means the warehouse mobile app has nothing to pick against until the afternoon. And the finance team cannot reconcile a payout, because the deposit that hits the bank is gross sales minus listing fees, transaction fees, payment processing fees, shipping labels and refunds, none of which appear as separate lines anywhere.

The tax treatment makes it worse. In many jurisdictions the marketplace collects and remits sales tax or VAT itself. If that amount is posted as your own output tax, your return is wrong. If it is ignored entirely, your revenue does not tie to the payout. Both mistakes are common and both are found late.

This connector is built to close those three gaps.

What ECOSIRE builds

The connector is delivered as an X++ extension model, deployed into your F&O environment through your normal LCS or self-service pipeline. No standard objects are overlayered: everything sits in a dedicated model using Chain of Command, event handlers, new tables and new forms, so it survives platform updates. It does not require the Commerce module — it works against core sales, inventory and ledger functionality, which is what most brands on F&O actually have licensed.

Connection to the marketplace uses the documented Etsy Open API over OAuth 2.0 with a dedicated application registration, refresh-token handling and rate-limit-aware request pacing built in.

Listing and variation mapping

This is where most marketplace integrations fall over. A single Etsy listing with size and colour options maps to a product master in F&O with product dimensions, and each Etsy inventory offering maps to a distinct released product variant. The connector holds that mapping explicitly in a form, so you can see which offering corresponds to which item and warehouse. New offerings that arrive without a mapping are not guessed at — they are queued for a human decision, because guessing is how a customer receives the wrong colour.

Stock synchronisation

Available quantity is pushed to the marketplace on a configurable schedule per item group. The quantity published is a calculated availability figure, not raw physical on-hand: the connector subtracts reservations, optionally excludes named warehouses or locations, and can apply a buffer per item so a slow sync cycle cannot oversell a one-off piece. Where you run the warehouse mobile app, quantities reflect what is genuinely pickable rather than what is sitting in a quarantine or quality location.

Order import

Marketplace receipts are pulled and converted into F&O sales orders through SalesTable and SalesLine, with the buyer created or matched as a customer, or grouped under a consolidated marketplace customer where you prefer not to hold thousands of individual accounts. Shipping charges become a charge code rather than a hidden line, gift messages and personalisation notes land on the order so they reach the picker, and the marketplace receipt identifier is stored on the order for traceability. Orders are idempotent on that identifier: a repeated poll cannot create a duplicate.

Tax treatment that matches reality

Each marketplace order is evaluated for whether tax was collected and remitted by the marketplace or is your liability. Marketplace-collected amounts are posted to a separate liability or clearing account through a dedicated tax group and item tax group configuration, so they appear in the payout reconciliation without inflating your own output tax. Where you are liable, the order uses your normal tax group and item tax group logic. The mapping is configuration, per legal entity and per shipping destination, because the rules differ by country and change.

Shipment, tracking and refunds

When a sales order is packed and shipped in F&O, the connector posts the shipment and tracking number back to the marketplace so the buyer receives the notification without anyone opening a browser tab. Refunds and cancellations flow inbound and create credit notes or order cancellations under the rules you configure, with a review step for partial refunds where a human should decide what is returned to stock.

Fee capture and payout reconciliation

Listing fees, transaction fees, payment processing fees, shipping label costs and advertising charges are captured and posted to the ledger accounts you nominate, through LedgerJournalTable and LedgerJournalTrans with financial dimensions defaulted per your configuration. Payouts post against a clearing account, and a reconciliation form shows deposit amount against the gross sales, fees and refunds making it up, with the variance highlighted. That form is usually the single most-used screen we deliver, because it turns a monthly guessing exercise into a five-minute check.

Operational visibility

Everything runs as SysOperation batch jobs with per-object recurrence. A message log records each API call, its direction, its correlation identifier and its outcome. Failures retry with backoff and park in a dead-letter list an administrator can inspect and replay. Unmapped offerings, held partial refunds and reconciliation variances all surface as work lists rather than silent log entries.

Who it is for

This is built for craft, homeware, jewellery, apparel and giftware brands that have moved core operations onto F&O while continuing to sell on the marketplace, particularly those running variant-heavy catalogues where the offering-to-variant mapping is the hard part. It suits businesses with more than one legal entity or shop, and businesses whose warehouse already uses the mobile app and needs orders available to pick within minutes rather than at end of day.

It is not a listing creation tool. The connector keeps stock, orders, shipments, refunds and money aligned. Creating and merchandising listings stays where your team already does it.

How delivery works

Scoping call. We look at your catalogue structure, how variants are modelled in F&O today, how many shops and legal entities are in scope, which countries you ship to and how tax is currently handled, and whether your warehouse uses the mobile app.

Fixed quote. You receive a written scope listing every synchronised object, the tax mapping approach, the fee accounts and the reconciliation output, with a fixed price and a delivery window. Nothing starts until you accept it.

Build. ECOSIRE develops the model against your F&O platform and application version, with API integration tested against a sandbox application registration. Code goes to an Azure DevOps repository.

Install in test. We deliver a deployable package to your sandbox, install it, map a representative slice of your real catalogue with your team, and run live order import, stock push, shipment writeback and a payout reconciliation against real data.

Production. After sign-off the package promotes through your pipeline to production, and we supervise the first days of live syncing and the first payout reconciliation.

Support window. A defect-fix window follows go-live, covering the delivered scope against the F&O version it was built for.

Lead time is typically two to four weeks from accepted quote to test installation.

Honest limits

There is no instant download and no trial. This is built after your scoping call because the variant mapping, tax treatment and fee posting are specific to your catalogue and your legal entities, and a generic version of those is worse than useless. We also depend on the marketplace API: rate limits, field availability and permitted operations are set by the platform, not by us, and if the platform changes them the connector needs maintenance. We will tell you during scoping which parts of your requested scope sit closest to those limits, so nothing about the delivered behaviour is a surprise later.