Is your ERP ready for ecommerce? Ten checks you can run this afternoon

These ten checks are designed to be run by someone who knows their way around Acumatica or Cin7 and has export rights. You do not need a developer, you do not need a vendor, and you do not need permission from anyone. Most of them are a list screen, a filter and a sort.

The reason to run them before you shortlist a platform is that a failed check does not mean you cannot do B2B commerce. It means the cost and the sequence change. Dirty item descriptions push effort into content and delay launch. Prices living in spreadsheets rather than the ERP push effort into the ERP itself and can turn a commerce project into an ERP project. Duplicate customers cause the storefront to log a buyer into the wrong account, which is the single defect most likely to end a project’s credibility in its first week.

Score each check as pass, partial or fail, and keep the evidence. A vendor who sees an honest fail list will give you a better estimate than one working from a requirements document, and the checks map one for one onto what the Celeste diagnostic asks you.

Item data is where the most calendar time hides, because unlike an integration defect it cannot be fixed by anyone other than your own staff. Open your item list in Acumatica or your product list in Cin7 Core, export your top 200 selling items, and look at three columns.

The description check is the blunt one. Read twenty descriptions as though you were a customer who has never seen your catalogue. If they read like a picking slip, "BRKT ASSY 3/8 ZP", you have a content project in front of you, and its size is the number of items in phase one rather than the number of items in the ERP. That is the single most useful reason to narrow phase one before you start writing.

The identity check catches a problem that surfaces late and hurts. A commerce platform needs one stable key per sellable thing, and it will hold that key as a SKU. If your business refers to the same product by an Acumatica Inventory ID in the warehouse, an Alternate ID on the customer purchase order, and a manufacturer part number in the sales conversation, you have to decide which one is the SKU before anything syncs, and you have to decide what happens to the other two. Search on your storefront will need them all.

The attribute and image check tells you whether the ERP can be the source for the storefront at all. Acumatica holds attributes and web content, with character limits that bite on long marketing copy, and Cin7 Core carries a product image and limited additional fields. If the answer is that images live on a shared drive and specifications live in supplier PDFs, then either the storefront becomes the place that data lives, or you need a product information system between them, and that is an architecture decision with a cost attached rather than a data cleanup task.

This is the check that changes projects. A storefront can only show a customer their real price if something authoritative can produce that price on demand. If the authoritative version of a negotiated price is a spreadsheet a sales manager maintains and keys in manually at order entry, then the ERP does not hold your pricing, and no connector on the market can rescue that. The work is to get pricing into Acumatica or Cin7 first, and that is an ERP project sitting in front of your commerce project.

Run it concretely. Take your five largest customers, pick three items each of them buys regularly, and find the price in the ERP without asking anyone. If you can find all fifteen, and they match the last invoice, the ERP holds your pricing. If you find eight and somebody says "check with Dave", you have your answer.

The second check is about the shape rather than the location. Count how many of the four pricing layers you use: a list price, a price classA price class is a label on a customer account that decides which set of prices they see. Acumatica and most ERPs use price classes so a seller can maintain one price list for a whole tier of customers instead of one per account. rate, a customer-specific negotiated price, and volume breaks. Then check whether any of them carry effective and expiry dates. Layer count drives how much mapping the integration needs. Dating drives the architecture, because a dated price cannot be safely pushed to a platform price list on a schedule and left there; something has to make sure yesterday’s expired price is not still on the page this morning.

Cin7 users have a specific version of this check. Cin7 Core prices through price tiers, and there is a documented ceiling on how many tiers exist, so if your real pricing needs more distinct groups than tiers available, the gap has to be closed outside Cin7. Confirm your tier usage against the Cin7 help documentation before you design around it.

A B2B storefront authenticates a person and then has to decide which account that person buys on behalf of. Everything downstream, price, entitlement, credit, shipping addresses and order history, hangs off that decision. A customer master with duplicates will get it wrong, and it will get it wrong for exactly the large accounts that have been with you longest and have been keyed in more than once.

The duplicate check is quick. Search your customer master for your top ten customers by revenue, one at a time, on a fragment of the name rather than the full name. Count the hits. Acquisitions, branch offices entered as separate customers, and the same company spelled with and without "Ltd" are the usual sources. Then check the same names in your email or contact fields, because Cin7 users have found that changing a customer email address can create a duplicate rather than update the existing record, which quietly builds the problem over time.

The structural check is different from the duplicate check and it is the one people skip. Ask whether your ERP models a customer as an organisation with several people attached, each of whom might have different rights, or as a single record with one contact. A company accountA company account is a customer record that holds several people, each with their own login and their own permissions. One buyer might place orders, another might only approve them, a third might only look up past invoices. is what B2B commerce needs: a buyer who can order, a manager who can approve, a clerk who can only look up invoices. Acumatica handles this through customer and contact records, and Shopify B2B expresses it as companies and company locations, so the mapping between the two is a real design decision. If your ERP holds one contact per customer and the real buying organisation has six people, the storefront becomes the place that structure lives, and you should decide that deliberately.

While you are in there, check credit. Does the ERP hold a current credit limit and payment terms for each account, and is the limit maintained rather than set once in 2019 and never revisited? A storefront that enforces a stale credit limit will block good orders, and one that ignores credit entirely will accept orders your finance team then has to unwind.

A single company-wide stock number is a promise your business cannot keep. If a customer in Calgary sees 400 units and 380 of them are in a warehouse that never ships to Calgary, you have taught that customer not to trust the site. Getting availability right is usually what decides whether your own sales team uses the storefront or works around it.

The availability check has two parts. First, does the ERP hold stock at the warehouse level and can it produce a per-warehouse figure on demand? Acumatica and Cin7 both do. Second, and this is the part people miss, does the number you would publish account for what is already committed? Acumatica users have reported unassigned commitments producing an availability figure that does not reflect what is actually sellable, and a storefront that publishes on-hand rather than available-to-promise will oversell during your busiest week.

The unit of measure check is smaller to run and expensive to get wrong. Look at ten items where the customer buys in a different unit from the one you stock in, a case against an each, a box against a metre. Confirm the conversion factor is on the item in the ERP and that the sales unit and base unit are set the way you think. Acumatica users have filed unit of measure mismatches against both the Shopify and BigCommerce connectors, and the failure mode is not an error message. It is a price on the page that is wrong by exactly the conversion factor, which nobody notices until a customer orders a pallet at the each price.

Tax is the check people leave until last and then discover is architectural. The question is simple to ask and revealing to answer: when a new order is entered today, what decides the tax, and could a computer reproduce that decision without a person present?

There are three answers and they lead to different projects. If tax is calculated by Acumatica or Cin7 from rules held in the ERP, including customer tax zones and exemption certificates, the storefront can defer to the ERP or replicate the rules with confidence. If tax is calculated by Avalara or a similar service that both systems can call, you have a clean answer and one thing to settle, which is which system calls it and which system wins when the numbers differ. If tax is decided by a person at the order desk who knows which customers are exempt, then the rule exists nowhere a storefront can read it, and writing it down is a prerequisite.

The specific trap on Acumatica is worth naming because it produces a real reconciliation problem. When an order arrives from a storefront or a marketplace with tax already calculated, Acumatica may recalculate that tax on its own rules, and the two figures will not always match. Acumatica users have documented both how to prevent that recalculation and a separate case where the Avalara integration calculates tax for marketplace orders that should not be taxed there. Neither is exotic and both need a deliberate decision on which system is authoritative for tax before you go live, not after your controller finds a variance.

Exemption certificates are the last piece. In B2B a meaningful share of orders are tax exempt, and the certificate has an expiry date. If certificate status lives in a filing cabinet rather than on the customer record, the storefront will charge tax to exempt customers, who will phone, or will not charge tax to customers whose certificates have lapsed, which is worse.