CommerceHub catalogue sync with Acumatica: what actually has to be true

CommerceHub, ChannelAdvisor and Dsco were folded into one brand, Rithum, announced in December 2023. CommerceHub and Dsco survive as names inside documentation and in third-party connector listings, which is why a search turns up three names for what is now one company. The live product names for the dropship side are Dropship, Private Marketplaces, SupplyExplorer and Advanced Catalog.

One warning if you go looking for history. Rithum has rewritten its own archived press releases to use the new brand, so a 2018 release now describes a company that didn’t exist until 2023. Take dates and entity names from the original announcements rather than from the current press archive.

Nothing native. Acumatica ships built-in connectors for Shopify, BigCommerce and Amazon, and CommerceHub is not among them. Two ISV connectors are listed on the Acumatica Marketplace, both published by BizTech Services: a CommerceHub Connector and a separate DSCO Connector. Both list support back to 2024 R2 and forward to 2026 R1.

The important detail is what they move and how. The CommerceHub connector is badged Connected with Acumatica, which is the lower marketplace tier rather than Acumatica-Certified, and its mechanism is governed SFTP file exchange rather than an API. Its documented flows are purchase order import, inventory sync, invoices, fulfilment confirmations, and acknowledgements. Item handling is cross-reference mapping between Acumatica Inventory IDs and CommerceHub item identifiers.

Read that list again for what is missing. It’s order and inventory plumbing plus an ID map. It doesn’t claim to publish catalogue attributes or images, which is the part of the job people mean when they search for catalogue sync. Middleware is the other route: Pipe17 publishes both a Dsco and a Rithum integration, though we couldn’t verify the depth of either.

At the platform level the requirements are almost nothing: title and SKU are the only mandatory fields. Everything else, including description, UPC, category and images, is optional as far as the platform is concerned.

The real requirements sit one layer up, and they belong to the retailer. A supplier downloads a retailer-specific spreadsheet template in which green attributes are required by that retailer and blue are recommended. The documentation tells suppliers to download the latest template each time, because retailers frequently change their categories and requirements. That sentence is the whole design of the thing: attribute drift is an expected operating condition, not an edge case.

A worked example makes it concrete. Academy Sports and Outdoors, running on the platform, requires long and short description, vendor part number, item differentiators such as colour and size, UPC, unit cost, retail price and MAP, and product dimensions. Images must be 300 PPI and at least 2,000 pixels on the longest edge, on a white or transparent background. Onboarding is quoted at eight to twelve weeks. Another retailer will ask for a different set, and Nordstrom requires separate connections for Nordstrom and Nordstrom Rack.

So the question to ask before anyone scopes an integration is not whether Acumatica can export a catalogue. It’s how many retailers you intend to trade with, because each one is a separate connection with its own template, its own category tree and its own required fields, and your item master has to satisfy all of them at once.

The documented failure modes are shape failures, and they’re exactly what an unattended ERP export produces. Uploads are validated against the retailer’s requirements and rejected with an error notification on failure, and retailers review a catalogue exceptions page for content and image errors. Image reference columns must be either fully populated across every row or removed entirely. Unused columns must be deleted from the sheet rather than left blank. Category and subcategory must match the retailer specification exactly.

A second class of problem is timing rather than shape. The platform exposes six SLA metrics that retailers configure: created to acknowledged, created to shipped, cancel request to cancelled, shipped to invoiced, return request to acknowledged, and inventory update frequency. Dynamic SLA lets a retailer set violation intervals per supplier, per SKU and per ship method, and the calculated deadline becomes the ship-by date on the purchase order. Your integration is being scored on latency, not just correctness.

One thing we couldn’t verify, and it matters because people assert it confidently: there is no documented mandatory interval for resubmitting catalogue content. Inventory is different, and Academy requires daily inventory updates with items at zero for 30 consecutive days removed from the site automatically. Don’t let anyone scope a project around a catalogue refresh cadence that nobody publishes.

Cost changes deserve their own line. At Academy, a cost change needs 30 days’ notice submitted on a spreadsheet to a named contact, which means it travels outside the catalogue feed entirely. If your Acumatica pricing changes on a schedule your retailer won’t accept, no connector fixes that.

On a marketplace you’re the seller of record, you hold one schema for the whole channel, and the marketplace takes a referral fee. Dropship through Rithum is a purchase order transaction: the documented EDI set is an 850 purchase order in, an 855 acknowledgement, an 856 ship notice and an 810 invoice. You’re invoicing the retailer at wholesale cost and the retailer owns the customer, the listing and the price.

Rithum frames the difference the same way. In dropship the retailer usually controls the product listing, the customer experience and the pricing structure. In a marketplace model the seller has more control over pricing, shipping and service.

The practical consequence for catalogue work is the one from the previous section. One Amazon schema serves all of Amazon. Ten retailers on Rithum is ten templates, ten category trees and ten sets of required attributes, and that’s the number that should drive your estimate rather than the number of SKUs.