A build-to-order X++ connector that syncs Etsy listings,
variations, stock and orders with Dynamics 365 F&O, including marketplace-collected tax and payout reconciliation.
Built to order
A build-to-order X++ connector that syncs Etsy listings, variations, stock and orders with Dynamics 365 F&O, including marketplace-collected tax and payout reconciliation. Built to order by ECOSIRE for Dynamics 365 F&O (build-to-order) — indicative price from $999.00 USD; request a quote for a scoped proposal.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 one working week from accepted quote to test installation.
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.
A short call to confirm the workflow, your platform version and where the integration boundaries sit.
You receive a written scope and a fixed price. Nothing is built until you approve it.
We develop against a copy of your configuration and test it there. Typically two to four weeks.
We install on your instance, hand over the source, and include two weeks of go-live support. Defects in the code we deliver are fixed free of charge.
Fights a daily gap between marketplace stock and real stock, and pays for it in cancellations and bad reviews on one-off pieces. Scheduled availability pushes that account for reservations and per-item buffers mean the published quantity reflects what the warehouse can actually pick.
Cannot tie a marketplace deposit to revenue because fees, refunds and marketplace-collected tax are all netted inside one number. Fee capture to nominated ledger accounts plus a payout reconciliation against a clearing account turns that into a variance figure that either is zero or points at the specific transaction.
Receives marketplace orders too late in the day to include them in the morning wave, and gets personalisation instructions second-hand. Orders import continuously into F&O with notes attached, so they appear in the normal release-to-warehouse flow and reach the mobile app with the picker's instructions on them.
| Criterion | ECOSIRE | Custom Build | Competitor | Dynamics 365 Finance & Operations Native |
|---|---|---|---|---|
| Offering-to-variant mapping held explicitly with an unmapped work list | Included | Partial support | Partial support | Not included |
| Availability push net of reservations with per-item buffers and location exclusions | Included | Partial support | Partial support | Not included |
| Marketplace-collected tax separated from your own output tax at posting | Included | Partial support | Not included | Not included |
| Fee capture posted to nominated ledger accounts with financial dimensions | Included | Partial support | Not included | Not included |
| Payout reconciliation against a clearing account with variance drill-through | Included | Not included | Not included | Not included |
| Shipment and tracking writeback from packing slip or warehouse mobile app despatch | Included | Partial support | Included | Not included |
| Works without the Commerce module on core sales and inventory | Included | Included | Partial support | Partial support |
| Available as an instant download with no build phase | Not included | Not included | Included | Not included |
Build-to-order dual-write extensions for Dynamics 365 F&O and Dataverse: custom table maps, field transformations, a declared source of truth per field, and an error replay workspace.
A build-to-order eBay integration for Dynamics 365 Finance & Operations. ECOSIRE scopes, quotes and builds it for your estate as X++ extensions, then installs it in sandbox and production.
A build-to-order X++ extension that tracks voyages, apportions duty, freight, insurance and clearance charges into inventory cost, and holds customs documentation inside Dynamics 365 Finance & Operations.
Forward and backward lot and serial genealogy across production and shipment in Dynamics 365 Finance & Operations, with a recall workbench for rapid customer identification. Built to order by ECOSIRE.