Keep Product Data Consistent Across ESP, SAGE, and DistributorCentral

One tote, three different answers

At 9:20, Mira at Harbor Stitch, a made-up promo supplier, gets a distributor's screenshot of a navy tote. The price is wrong. She opens another listing to check it, and that price is different too. The tote hasn't changed its mind. Three catalogs have been allowed to develop separate opinions.

ESP has the old price. SAGE calls the color "Navy blue." DistributorCentral has the new photo but still shows a setup charge the product team removed. Mira was planning to work on the spring catalog. Apparently, October isn't finished with her.

The people and company are made up, but the morning probably isn't. When your products live in several places, updating your own records doesn't tell you what a distributor can see. And a successful upload doesn't tell you that the right color, price break, or image changed.

The fix is straightforward: decide which record to trust for each detail, match the right listing, review the differences, and check what's actually published. Track ESP, SAGE, and DistributorCentral separately. One green check can't speak for all three.

Decide which record wins for each detail

Harbor Stitch's order system has the item numbers and stock counts. The product team keeps descriptions, images, and imprint details elsewhere. Pricing comes from an approved price list. None of those records gets to win every argument just because it's easier to export.

Write down which record you trust for each important detail, and give each one an owner who can settle a disagreement. Don't pick whichever spreadsheet someone edited most recently.

Someone also needs to approve new products, price changes, discontinued items, replacement images, and claims about production time. Software can find a mismatch and prepare the change. It shouldn't decide that a cheaper price or a faster turnaround sounds reasonable.

Keep the approval, the price list version, and the start date with the change. Mira has next week's price list already, but next week's price isn't today's price. Preparing an update early is fine. Publishing it early isn't.

Match the item, not just its name

"Harbor tote" is a useful description and a poor way to match records. Product names get shortened, rewritten, and reused. Match on your item number instead.

At Harbor Stitch, HARBOR-TOTE is the tote in general, and HARBOR-TOTE-NAVY is the navy one. A platform might list those as one product with color options, or as separate items. Know how each platform does it before you change anything.

If Mira's change is for the navy tote, a match to the tote in general isn't enough. Applying that price to every color would turn one correction into several new problems. Anything unclear stays out of bulk updates until someone who knows the catalog sorts it out.

The same care applies to photos and discontinued items. A navy photo shouldn't replace every color's photo. Retiring one size shouldn't remove the whole product. Before changing anything, you should be able to see exactly which listing and color was matched.

Agree on which differences matter

Mira doesn't need a daily warning that "Navy" and "Navy blue" differ if the product team has approved them as the same color. She does need a warning when the minimum quantity or net price changes. Treating both as equally urgent makes the review list easy to ignore.

Write down your cleanup rules for the harmless stuff: extra spaces, agreed color names, units written two ways. Keep the original values so someone can see what was compared. Don't turn an unapproved guess about two colors into a rule.

Compare the details that affect orders: colors, quantity breaks, prices, setup charges, imprint methods, minimums, and production time. Keep currency and units clear, and keep blank-product pricing separate from decorated pricing. "Same price" means very little if one listing includes an imprint and the other doesn't.

Approved marketing copy can differ from platform to platform. The facts need to agree. Every sentence doesn't need to match.

Know how each platform takes updates

Each platform has its own rules, access, and timing. Check what your account supports before building a process around it, because having a feed doesn't mean you can change every field through it.

• ESP: ASI describes a few ways to update products, including ESP Direct Connect, spreadsheet submission, and ESP Updates. Confirm which one your account can use and which fields it covers.
• SAGE: SAGE's supplier update page describes spreadsheet-based Bulk Product Update, edits in Supplier Center, and SAGE Connect. These work differently and on different schedules. A spreadsheet can be the right choice without being instant.
• DistributorCentral: OneSource shares supplier product data in a common format. That doesn't mean every catalog field can be changed through it. Confirm what your own setup supports.

Whichever route you use, don't call an update finished when the file leaves your desk. Wait until you've checked the published listing.

Check the listings before changing them

Start with an export or a supported look at each platform, and note when you took it. Yesterday's snapshot can explain yesterday's mismatch. It can't tell you what a distributor sees now.

Compare each platform with your approved information and make a review list. Every proposed change should show:

• The item number and which listing it's for.
• The field, what's published now, and what it should be.
• The reason for the change and where it came from.
• Who approves it and when it should take effect.

Put wrong prices, wrong minimums, and discontinued items ahead of small wording differences. A missing setup charge can affect an order. An extra adjective usually can't. Leave uncertain matches visible but on hold. Hiding them doesn't make the catalog cleaner.

This is the same idea behind a sales order readiness review: finding the information is one step, and deciding it's ready to use is another.

Follow one price change all the way through

Harbor Stitch approves a new price for HARBOR-TOTE-NAVY at the 250-unit break, effective Monday. Mira records the approval against the October price list. The update can be prepared now, but the published price stays put until Monday.

First, match the navy tote on each platform. Suppose SAGE only matches the tote in general, not the navy one. That row waits for a catalog specialist. Nobody spreads the navy price across every color just to finish the batch.

For each match, the review shows the old price, the new price, currency, whether it's list or net, any discount code, the 250-unit break, and the start date. Those meanings have to line up before the numbers can be compared. Otherwise a correct price can look wrong, or a wrong one can slip through.

When Monday arrives, submit through each platform's update route. Keep a separate record for ESP, SAGE, and DistributorCentral, including a job number if the platform gives you one. "Submitted" means the change was sent. It doesn't mean anyone can see it.

After the platform has processed it, look at the published navy tote and its 250-unit break. Mark that platform done only when the right price is showing, and note when you checked. If a change was rejected or didn't take, keep it open with the exact mismatch, not a vague "sync failed."

Fix the unfinished part, not the whole batch

Suppose Mira's next batch changes the tote's price breaks and replaces a photo. In this made-up example, ESP finishes both, SAGE is still processing, and DistributorCentral rejects the image format. Those are three different outcomes, not one failed product.

Keep the finished checks. Wait for SAGE, and fix the image before sending it to DistributorCentral again. Resending everything adds work and makes it harder to tell which attempt produced the listing you're seeing.

Mira's to-do list should name the platform, item, field, current status, owner, and next step. If you're not sure whether an update landed, check before you resend. If it was rejected, keep the reason. If it's still processing, don't treat it as broken or finished.

Discontinuing a product needs its own care. Confirm whether you're retiring one color or size, or the whole product, and what happens to links and distributor listings that point to it.

Check on a schedule that fits the detail

Stock counts and urgent price corrections don't need the same schedule as long descriptions or seasonal photos. Set the schedule around how fast each detail changes, and give the product team a way to request a quick review when something is wrong.

Keep an eye on how many mismatches are still open, how long approved changes take to show up, and which rejections keep repeating. If the same color keeps landing on the wrong item, fix the matching rule instead of celebrating another finished upload. Our guide to measuring AI workflow cost and ROI covers how to weigh the time saved against the checking.

Product data checklist

• Each important detail has a record you trust and a named owner.
• Products are matched by item number, and colors and sizes are matched separately where needed.
• Approved cleanup rules separate harmless formatting from differences that matter.
• Prices include currency, list-or-net, quantity breaks, and relevant charges.
• Each platform has a confirmed way to take updates and its own progress record.
• Price and product changes have an approval, a source, and a start date.
• Published listings are checked before and after approved changes.
• Finished updates stay recorded while pending or rejected ones stay visible.
• Discontinued items target the right color, size, or product, and account for existing links.
• Checks run on a schedule that fits the detail, with a way to request urgent fixes.

Frequently asked questions

1Does one product feed keep all three platforms current?

Not by itself. ESP, SAGE, and DistributorCentral can each cover different fields, process changes at different speeds, and match colors differently. Confirm how each one takes updates and check the published result on each. One platform's success doesn't mean the others changed.

2Which record should win when product details disagree?

The one your team has agreed to trust for that detail. Your order system might own stock counts while the product team owns descriptions and an approved price list owns pricing. Keep the owner, the price list version, and the start date with each proposed change.

3Should "Navy" and "Navy blue" be flagged every time?

Not if your product team has approved them as the same color for that item. Save the rule and keep the original values available. A color shortcut shouldn't hide a different color, and a wording rule shouldn't excuse a wrong price or minimum quantity.

4Is an accepted upload enough to close an update?

No. "Accepted" means the platform received your file, not that the listing changed. Check the published color and the relevant fields after processing, and leave anything that didn't change or was rejected open.

5What should happen when only one platform fails?

Keep the finished updates and work on the one that isn't done. Check an uncertain result before resending, fix rejected rows, and give each open item an owner and a next step. Don't resend successful changes just because another platform is still waiting.

Where Trelium fits

Trelium's workflow use cases start with rules your team can actually follow. For catalog maintenance, write down which record you trust, how items are matched, who approves changes, and what you'll check on each platform before automating the handoffs.

The result should answer three questions: which record is right, where do the published listings differ, and which approved changes still need attention? Those answers reflect what you checked at a specific time. Stock counts and platform-specific details can still change afterward, so keep checking on the schedule you set.