Infor FACTS to Shopify Integration

That migration may well be the right long-term answer. It is also a multi-year program with a business case of its own, and in the meantime your customers are asking why they cannot order online.

This page is about the meantime, because nobody else writes about it.

More than you might expect, and more than any competing page mentions.

Infor maintains current documentation for FACTS, with the 9.4.0 documentation set generated in January 2026. That is an actively maintained documentation library, not an abandoned one.

Within it there is an integration list, and inside that an eCommerce Catalog Integration and Setup Guide. Infor wrote a document about connecting FACTS to an ecommerce catalog. It exists, it is published, and not one page competing for this topic mentions it.

There is also a community-maintained FACTS API call reference, which we flag as community rather than official. Useful to know about, not something to design a fixed-price project around.

The practical characterization you will hear from people who run FACTS, and it matches the documentation's shape, is that it is a batch-oriented system. That is not a criticism. It is the design era, and it is the single most important thing to build around.

A lot of ecommerce advice assumes an ERP that answers instantly. If yours does not, the answer is not to give up on the channel. It is to be deliberate about which data has to be live and which does not.

Both prompt runs we did on this question reached the same architecture independently, and it is the right one. Catalog and customer data batch. Price and availability run as close to real time as your system supports. Orders submit back to the ERP authoritatively.

That split is not a compromise. Catalog content genuinely does not need to be live, because a product description does not change between page loads. Price and availability do, because those are the two numbers a buyer will hold you to. Getting the split right is what separates a storefront your customers trust from one they verify by phone.

Worth adding that this discipline pays off later. An architecture that already distinguishes batch data from live data is far easier to repoint at a new ERP than one that assumed everything was instant.

This is the part that matters most if CloudSuite Distribution is somewhere on your horizon.

A storefront project done badly ties itself to FACTS specifics throughout: field names in the theme, ERP logic in the checkout, assumptions about batch timing baked into the customer experience. Migrate the ERP and you rebuild the channel.

Done properly, the ERP-specific work is a thin, isolated layer. Your storefront, catalog, customer accounts, pricing presentation and buying experience sit above it and do not care what is underneath. When you move to CloudSuite Distribution, you replace the connector. The channel keeps running, your customers notice nothing, and the migration gets easier rather than harder because one more thing is already decoupled.

That is a design instruction to hold any proposal against, and it is why we would rather build this now than tell you to wait.

FACTS customers become Shopify companies, with ship-to locations and buyer logins, so each buyer signs into their own pricing and their own order history.

Items become products with units of measure and pack sizes represented the way you actually sell them, and with catalog content that almost certainly needs to come from somewhere other than the item master. Both prompt runs flagged catalog readiness as the thing distributors underestimate, and that matches our experience on every ERP in this class.

Contract and quantity-break pricing resolves for the logged-in account rather than being flattened into a price file.

Availability distinguishes what is on hand from what can actually be promised, across warehouses.

An order placed in Shopify reaches FACTS with the account, ship-to, reference and terms attached, and its status, shipment and invoice come back to the buyer.

Uncap Connect keeps pricing, inventory, customer data and orders current in both directions, built for B2B so customer-specific pricing, credit terms and tax behave the way they do in your business.

On a batch-oriented ERP the answer has to be more careful than usual, because the gap between the storefront and the system of record is wider by design.

Orders queue rather than disappear. Transient failures retry on a backoff. Permanent failures hold with the payload and the exact FACTS error preserved, somewhere your team already looks, and replay without asking the customer to reorder. Replay is idempotent, so a retry cannot create a second order.

The buyer's Shopify order stays visible to them the whole time. From their side the order exists, and on a system where confirmation is not instantaneous, telling them clearly what has happened matters more than usual.

A discovery pass against your FACTS instance establishing what is reachable and how, including whether the documented ecommerce catalog integration path suits your setup.

A deliberate split between batched data, live data and authoritative writes, documented rather than assumed.

Company accounts, ship-to locations and buyer logins from your customer master.

Contract and quantity-break pricing resolved per account.

Availability that distinguishes on hand from promisable, across warehouses.

Order capture into FACTS with status, shipment and invoice returning to the buyer, plus a held-order queue with idempotent replay.

A thin, isolated ERP layer so a future CloudSuite Distribution move replaces the connector rather than the channel.

Industrial Supply and MRO, where catalogs run past a hundred thousand items and procurement buys through its own systems.

Construction Supply, where will call and job accounts decide whether the site gets used.

Packaging and Shipping Supplies, where each, case and pallet pricing has to resolve correctly for every account.

FACTS is one of several Infor products we connect to Shopify. The Infor integration overview covers SX.e, M3, SyteLine and the rest.

Bring your FACTS version, your CloudSuite Distribution timeline if you have one, and one account's contract pricing. If a migration is already funded, say so, because it changes what we would recommend building rather than whether to build it.

Book a strategy session, or start with a Blueprint, the paid discovery engagement that maps the integration surface, the pricing model and the phased plan before development begins.