AI Powered EDI with expert operators

Marketplace

EDI

A marketplace operator does not care how your systems fit together, only that acknowledgements, availability and ASNs land inside the windows its own platform enforces, and that the settlement it sends back can be posted without finance rebuilding it from a spreadsheet. Whether the connection is a flat file or a full API, the scoring, the fee structure and the tax treatment all belong to them. Trading well means working to their rulebook from the first order, not after the first dispute.

Castore
Lounge
Oliver Bonas
Green People
Tatty Devine
Cult

Marketplace failure points

Check these before trading starts.

Marketplace settlement lands as one number, fees already taken out.

  • Finance imports a statement download from each marketplace and reconciles it against the order list by hand.
  • Nobody can say whether a channel's revenue moved because of sales or because of fee changes.
  • A chargeback dispute has no document trail back to the order it was raised against.

Facilitator tax gets posted as if the seller still owes it.

  • The marketplace collected and remitted tax on an order, but the ledger entry treats the full amount as seller liability.
  • A quarterly VAT return needs manual correction because marketplace and direct orders share one tax posting line.
  • The same account trades a direct channel where tax genuinely is owed, and the two get mixed without anyone flagging it.

A listing update reaches one marketplace and stalls on another.

  • A price change in the source catalogue shows correctly on the storefront but late, or never, on a connected marketplace.
  • A missing attribute gets a listing suppressed on one channel while it stays live everywhere else.
  • Stock allocated to one channel doesn't match what another channel's feed is still showing as available.

Let the pattern run itself.

Once a marketplace's settlement structure, tax model and feed behaviour are mapped, the pattern repeats without someone re-deriving it each quarter. The work sits in posting templates and arbitration rules rather than in a person's memory of how that account behaves.

Settlement posting templates

Facilitator and direct tax lines post separately, and fee or adjustment lines stay mapped against the order they belong to, so finance works from the ledger instead of a statement CSV.

Catalogue and stock arbitration

When the storefront and a marketplace disagree on price, stock or an attribute, the difference gets recorded as a named override rather than left as a mismatch no one can explain.

Volume throttling for marketplace feeds

Order and inventory updates get batched and queued rather than fired one at a time, so a sales spike doesn't trigger rate limiting and leave orders unacknowledged.

Treat each marketplace as its own ruleset.

A posting template built for one marketplace's facilitator model and settlement structure does not transfer to the next one unchanged. Jurisdiction rules, fee lines and channel overrides get written down once per account, so adding another marketplace reuses a known pattern instead of starting the diagnosis from nothing.

  • X12
  • EDIFACT
  • AS2
  • SFTP
  • Cloud storage

Start with the question that's actually yours.

Amazon alone splits into Seller Central, Vendor Central and FBA before John Lewis Marketplace, Marketplacer, Mirakl or Virtualstock even enter the picture. How do we work out which page actually governs our account?

Pick based on who issues the document that starts the transaction for you, a purchase order, a seller listing feed or a vendor confirmation, and read the page written for that platform. This hub only covers what every one of them shares: the compliance model stays the partner's, whatever the transport looks like.

We trade through a marketplace running Mirakl on one side and Amazon Vendor Central on the other. Once both are live, what actually changes in how orders get handled?

Each keeps its own posting template, acknowledgement window and settlement structure, nothing merges between them. What changes is the catalogue layer, where price, stock and attribute overrides now need arbitrating across both channels rather than one, since a change made for one audience can quietly break the other's feed.

Before a posting rule separates facilitator-collected tax from the tax we still owe directly, what do we actually need to hand over?

A list of which jurisdictions each marketplace account collects and remits in, which direct channels still require you to calculate and remit tax yourself, and the current chart of accounts split between the two. Without that split written down, the ledger has no way to know which line belongs to whom.

If a marketplace operator changes which fees sit inside the settlement file, who goes back to them to confirm the new structure?

That conversation sits with us. We hold the relationship with the posting templates, so a restructured settlement file gets mapped to the ledger again before finance ever has to query a figure that no longer matches what it used to.

If order volume spikes and a marketplace's connection starts returning rate limit errors, does the acknowledgement still land inside their window?

Updates get queued and retried rather than dropped when that happens, so an acknowledgement delayed by a burst of traffic still clears before the partner's cutoff instead of falling outside it and counting against the account.

Need help with this?

Talk to a Cogent2 operator who has actually delivered this work. We will help you scope, plan and ship — without the agency overhead.