Using Product Feeds to Align Counterpoint and Your New Store

When NCR Retail Online was discontinued, many Australian retailers had to move their online operations to another ecommerce platform while continuing to rely on NCR Counterpoint for point-of-sale, stock control, and back-office management. The technical migration can be manageable; the harder problem is keeping product prices consistent while systems, integrations, and business rules change.

A product feed provides a structured way to move catalogue information between Counterpoint and a new store such as Magento or WooCommerce. When designed properly, it can carry retail prices, sale prices, tax settings, product identifiers, stock status, and promotional dates without forcing staff to update each channel manually.

Pricing inconsistency is highly visible online. A customer in Parramatta may see one price on a mobile product page, while the same item scans at a different amount in the shop. In regional areas, where customers may compare delivery costs and availability before driving to a store, a mismatch can quickly undermine confidence.

The goal is not simply to copy a spreadsheet into a new website. It is to establish a dependable pricing workflow in which Counterpoint, the ecommerce platform, and the feed agree about which value is current, when it should change, and how it should be displayed to Australian shoppers.

Why pricing drift begins during migration

A retail migration usually involves several sources of truth. Counterpoint may contain the standard sell price, a supplier cost, a promotional price level, and customer-specific pricing. The new store may have its own catalogue fields, tax configuration, coupon rules, and rounding behaviour. If these systems are connected without a clear hierarchy, each can quietly produce a different result.

Legacy data can add another layer of confusion. Product records may contain old prices, duplicated SKUs, incomplete brand names, or descriptions that were edited directly in NCR Retail Online. Before deciding how to synchronise prices, review what should happen to historical orders, customer information, and catalogue records using this sales data guide.

Australian retailers also need to account for GST-inclusive pricing. Most consumer-facing prices must be displayed in a way that clearly reflects the amount payable, while business systems may store values differently. A feed that imports an ex-GST figure into a storefront configured for inclusive prices can create a ten per cent error without any obvious integration failure.

Create a dependable product feed

Start with a product feed schema that identifies every field required by both systems. A practical core includes SKU, barcode, product name, brand, category, regular price, promotional price, sale start date, sale end date, tax class, stock quantity, availability, and last-updated timestamp.

The SKU should be the primary matching key, not the product name. Names change, punctuation varies, and Australian catalogues often include pack sizes such as “500mL”, “500 ml”, or “6 pack”. A stable identifier prevents the new store from creating duplicate listings or applying a price to the wrong variant.

Use a single export format wherever possible. CSV may be suitable for an initial migration, while XML or JSON is often better for scheduled feeds and nested product variations. Each record should include a clear status for active, discontinued, out-of-stock, and temporarily unavailable products, rather than relying on blank prices or missing rows to communicate meaning.

The feed should also record the currency as AUD and preserve decimal precision until the final display stage. Avoid manually rounding values at several points in the process. Repeated rounding can produce small discrepancies across bundles, discounts, and tax calculations.

Decide which system owns each price

Counterpoint should generally remain the authority for everyday store pricing when it is the system used by staff at the register. The new ecommerce platform can then receive that price through a feed and publish it online. This approach reduces the risk that a website-only change conflicts with the amount used at checkout.

There are valid exceptions. An online-only campaign, marketplace price, or shipping-region promotion may be managed in Magento or WooCommerce. If so, label it as a channel-specific override rather than allowing the ecommerce platform to overwrite the base price in Counterpoint.

Create a price hierarchy before building the integration. For example, the standard price may be the default, an approved promotional price may take priority during defined dates, and a channel override may apply only to the online store. The hierarchy should state what happens when two prices are active, when a promotion expires, and when a product is missing from one system.

This is also the right time to document staff permissions. A shop assistant in Melbourne should not need to edit a website product manually to correct a price that belongs in Counterpoint. Conversely, an ecommerce manager should have a controlled process for online-only offers without changing the price used at physical tills.

Map categories, tax, and promotions carefully

Category mapping affects more than navigation. It can determine tax treatment, feed destinations, product templates, shipping rules, and promotional eligibility. Books, toys, apparel, and giftware may all require different attributes, even when they share the same basic price fields.

For a retailer selling books and entertainment products, use a consistent category structure for items such as fiction, children’s books, vinyl, DVDs, and games. A relevant catalogue example is the books and entertainment collection, which illustrates why product grouping should remain clear when content moves between systems.

Do not use a general discount percentage as a substitute for actual promotional pricing. A sale price should include an effective date and, where relevant, a campaign identifier. This makes it possible to audit whether a discount was active when an order was placed.

Australian promotions also need careful wording and timing. If a retailer advertises a discount across a weekend market in Adelaide or during a local event in Brisbane, the feed should use a defined start and end time rather than assuming the promotion ends at midnight in an unspecified timezone. Store operating hours and daylight saving differences between states can affect scheduled changes.

Match the new store’s display rules

A correct feed can still produce an incorrect customer-facing price if the new store applies its own rules after import. Review currency, tax display, decimal places, sale badges, catalogue price labels, and rounding settings before launching.

Decide whether the feed sends a GST-inclusive consumer price or a tax-exclusive base value. Do not mix approaches between categories. The ecommerce platform should know which tax class applies to each product and should not add GST again to a price that already includes it.

Bundles and product variations require special attention. A shoe style may have one base price with size-specific stock, while a gift basket may have a fixed bundle price that should not be rebuilt from component products. Test parent and child SKUs separately, including sale pricing and out-of-stock behaviour.

Check how the platform handles blank, zero, and deleted prices. A blank value might mean “leave unchanged” in one connector and “set the price to zero” in another. Define explicit actions for missing data, and block publication when a required price field fails validation.

Test the feed before customers see it

Use a staging store or restricted catalogue to test the first full import. Select products from different departments, price bands, tax classes, and promotional states. Include items with barcodes, variants, bundles, and Australian shipping conditions.

Compare the values in Counterpoint, the feed file, the ecommerce database, and the rendered product page. The comparison should include regular price, sale price, tax treatment, stock status, and the amount shown in the cart. A product page that looks correct can still calculate an incorrect checkout total.

Set up automated checks for common failures. Useful alerts include a sudden increase in price changes, products with no price, sale prices higher than regular prices, duplicate SKUs, unexpected currency codes, and large numbers of products removed from the feed.

Keep an audit trail for every scheduled run. Record when the feed was generated, how many records it contained, how many were accepted or rejected, and whether the store completed the update. This evidence helps staff isolate whether a problem began in Counterpoint, the export process, the connector, or the storefront.

Keep the workflow manageable after launch

Pricing alignment is an operating process, not a one-off migration task. Assign ownership for catalogue data, promotion approval, integration monitoring, and emergency correction. A small retailer may give several responsibilities to one person, but each responsibility should still be explicit.

Content and pricing should be treated as related but separate streams. If you are also replacing the old content workflow, document the CMS migration approach so product descriptions, landing pages, and pricing fields do not become mixed together in ad hoc imports.

Schedule feeds according to trading needs. A daily update may suit stable specialty products, while high-volume categories may need hourly or near-real-time changes. Consider Australian sales patterns such as Saturday shopping, Click and Collect cut-offs, and public holiday trading before selecting an interval.

Controls worth putting in place

• Use SKU or barcode as the matching key for every product record.
• Store regular and promotional prices in separate fields with start and end dates.
• Set AUD and GST treatment explicitly in both the feed and the storefront.
• Reject records with missing, negative, or implausible prices before publication.
• Keep a log of each import, including accepted, rejected, changed, and deleted records.
• Review a sample of live products after every major price update.
• Define an approval path for online-only discounts and urgent corrections.

A short operational runbook should explain how to pause a faulty feed, restore the previous price file, and notify store teams. This matters when a connector fails overnight and customers begin placing orders before anyone notices.

Make the first synchronisation deliberate

The safest launch uses a controlled batch rather than publishing the entire catalogue immediately. Begin with a representative group of products, confirm that prices and tax display correctly, and then expand in measured stages. Keep Counterpoint and the new store’s change windows coordinated so staff know which system is authoritative during the cutover.

After launch, compare a daily sample of online prices with register prices for several weeks. Include popular products, discounted items, products bought through Click and Collect, and products sold in different states. This will expose practical problems that a technical test may miss.

The first concrete step is to export a current Counterpoint sample containing SKU, regular price, promotional price, tax class, and effective dates, then compare it with the corresponding records in the new store.