METHODOLOGY

The ERP-commerce readiness framework: 7 operational checks before you pick a platform

A feature checklist tells you what a platform can do. A framework tells you whether your business can do it. This framework, seven operational checks that Acro Commerce runs in discovery, tests whether your ERP and your operational process can support a B2B ecommerce build before you commit to a platform. Architecture before app. If you can't answer these seven checks crisply, no platform is going to save the project.

Why a framework beats a feature checklist

A feature checklist asks the platform questions: does it support customer-specific pricing, can it handle approval chains, does it integrate with our ERP. Every modern B2B platform, BigCommerce B2B Edition, Shopify B2B, Shopware, can credibly say yes to most of those. The yes is real but it's not useful, because the question was the wrong one.

A framework asks the business questions: does your ERP know what 'customer-specific pricing' means in your company, are your approval chains documented anywhere outside Karen-in-finance's memory, is your ERP integration scope a one-day connector or a six-month rebuild. These questions don't get yes/no answers. They get useful answers. They surface the work that needs to happen before the platform conversation can be honest.

The framework below is seven checks. Each tests one operational dimension. Each describes what 'good' looks like and the common failure modes. Run it against your own organization before you write an RFP. If you'd like help running it, that's what Acro Commerce's Discovery & Strategy practice is for, but the framework is self-administerable, and most manufacturers benefit from doing a first pass themselves.

Check 1

ERP data hygiene and master data

What to look for: a single primary identifier per SKU, consistent unit-of-measure conventions, a complete and current item master, and a documented data ownership model. Master data is the substrate everything else sits on. If the substrate is inconsistent, no amount of platform tooling fixes it; the inconsistency just gets exposed to customers.

What good looks like: one SKU = one record with one identifier, used consistently across ERP, PIM, and any downstream channel. Unit of measure is explicit and convertible. Discontinued items are flagged, not deleted. Someone, a named role, not a committee, owns the master data and signs off on changes.

Common failure modes: the same physical product has three SKUs because of historical mergers or system migrations; the unit of measure differs between the item master and the price list; product attributes are duplicated across fields with no canonical source; master data is 'owned' by no one and changed by anyone. If you see these patterns, the readiness work is master data, not commerce.

Check 2

Pricing logic, customer, contract, volume, promo

What to look for: pricing logic that lives in the ERP as structured data, not in spreadsheets or sales rep filing systems. Customer-specific lists, contract pricing tied to negotiated agreements, volume-break tables, and promotional overrides should all be expressable as ERP records that an API can resolve in a single call given a customer ID and a SKU.

What good looks like: a customer logs in to your site, the commerce platform makes one API call to the ERP with the customer ID and the SKU, and the correct price comes back. The price respects contract terms, volume breaks, current promotions, and any customer-specific override. The same price would be quoted on the phone or by a sales rep, because it's coming from the same source.

Common failure modes: contract pricing held in PDFs; volume breaks calculated by hand; sales reps applying discounts the ERP doesn't know about; pricing rules that require human interpretation to resolve. Across the manufacturer engagements we've seen, pricing is the most common readiness gap. The fix is not technical; it's documenting and encoding pricing logic in the ERP before commerce is added. Standards bodies recognize this as CPQ (Configure, Price, Quote) discipline; it applies even when no formal CPQ tool is in use.

Check 3

Customer and account hierarchy

What to look for: a customer model that can represent a parent organization, multiple billing entities, multiple ship-to locations, and named individuals with distinct permissions. Most B2B customers are not single records; they are organizations with structure. The ERP should already model that structure, even if imperfectly.

What good looks like: a buyer logs in as a named individual, is recognized as belonging to a buying organization, sees pricing tied to that organization's contract, can ship to any of the organization's locations, and can place orders that route to the correct billing entity. The named buyer's permissions (browse only, order up to a threshold, approve orders from others) are explicit. Platforms like Shopify B2B and BigCommerce B2B Edition model company accounts natively, but the ERP must be able to feed them the right hierarchy data.

Common failure modes: each ship-to location is modelled as a separate customer; named buyers are not modelled at all (the customer is the company, and every order looks the same); permissions are managed informally by sales reps. Customer hierarchy is the readiness gap most often deferred to phase two, and phase two is where it gets expensive. Building the hierarchy retroactively means rebuilding the data model and reissuing accounts.

Check 4

Inventory and availability rules

What to look for: an inventory record that reflects available-to-promise (ATP), not just on-hand. On-hand is what's in the warehouse; ATP is what the company can actually commit to a new customer order, net of existing commitments, work-in-progress, and reservations. Commerce needs ATP, not on-hand.

What good looks like: the commerce platform asks the ERP 'can I promise X units of SKU Y by date Z', and the ERP returns a yes/no with the relevant ship date. The answer respects multi-warehouse logic, transfer lead times, safety stock rules, and customer priority where it applies. The answer is the same answer a phone order would get.

Common failure modes: showing on-hand quantities as if they were available; updating inventory in commerce on a nightly batch (which guarantees overselling); ignoring multi-warehouse logic and assuming a single stock pool; treating drop-ship inventory as if it were on-hand. The fix is rarely the commerce layer; it's the ATP calculation in the ERP and the API that exposes it.

Check 5

Quote-to-order workflow

What to look for: a documented quote workflow that handles negotiation, revision, approval, and conversion to order. B2B buying is conversation. The quote is the front door, not the cart. A readiness check on quotes asks whether the process the sales team runs today can be modelled digitally without losing the conversational flexibility customers expect.

What good looks like: a buyer can request a quote on a configured set of items, the quote routes to the right sales person for negotiation, revisions are tracked, the customer can accept the quote and have it become an order without re-entering anything, and the order appears in the ERP with the correct pricing and customer references. The workflow handles both simple quote requests (price please) and complex ones (custom configuration, multi-line negotiation).

Common failure modes: quotes live in email; quotes go through CPQ but the CPQ doesn't sync with commerce; quote acceptance requires manual re-keying into the ERP; revision history is lost. Quote-to-order is the workflow that distinguishes B2B commerce from B2C commerce. Designing it before platform selection is what makes the build run; designing it during configuration is what makes the build slip.

Check 6

Approval chains and buying rules

What to look for: documented approval logic that reflects how the customer actually buys. Approval chains can be threshold-based (any order over $5,000 needs manager sign-off), category-based (capital equipment needs procurement sign-off), or role-based (the requisitioner submits, the buyer approves). Most B2B customers have rules; the readiness question is whether your system can model them.

What good looks like: a buyer with limited authority places an order over the threshold, the order is held in 'pending approval' state, the approver receives a notification, approves or rejects, and the order proceeds. The state is visible to both the buyer and the approver. The rules are configurable per customer because not all customers approve the same way.

Common failure modes: hard-coded approval rules that don't vary per customer; no notion of 'pending approval' state in either the ERP or commerce; approval handled outside the system via email or phone; approval rules that exist only in the sales rep's head. Approvals are not optional for most enterprise buyers; the absence of approval workflow is a deal-breaker for the buyers a manufacturer most wants to win.

Check 7

Order status and post-purchase visibility

What to look for: a clear flow of order status from the ERP back to the customer, covering at minimum acknowledged, in production or pick-pack, shipped (with tracking), delivered, and invoiced. Post-purchase visibility is what most B2B customers actually rate the channel on; they buy in conversation, but they live in the order portal afterwards.

What good looks like: the customer's order portal shows accurate, real-time order status; tracking links work; partial shipments and back-orders are surfaced clearly; invoices and packing slips are available without a phone call. The status data flows from the ERP via documented events or a polling API; commerce displays it but doesn't author it. For high-volume customers, EDI feeds can carry the same data into the customer's own systems.

Common failure modes: order status updated nightly so customers see stale data; tracking integrations break silently; back-orders are not surfaced until the customer asks; invoices are emailed separately rather than available in the portal. The post-purchase experience is where mid-market manufacturers often differentiate from larger competitors. Getting it right is high-leverage.

How to run this framework in 4 weeks

1. Week one: assemble the room. The framework requires operations, IT, sales, and finance. A representative from each, plus a single owner of the assessment, is enough. Pull together the existing ERP documentation, the current customer master, a sample of contracts that drive pricing, and a list of the top twenty customers by revenue. The goal of week one is alignment on what 'ready enough' means for your organization, not data collection yet.
2. Week two: run checks one through four. Data hygiene, pricing, customer hierarchy, inventory. These are the foundational checks and the ones most likely to produce a long pre-build action list. Document what good looks like in your context, where you are today, and the size of the gap. Use the top-twenty customer sample to test pricing and hierarchy in particular; the patterns are visible in real customer records faster than in abstract discussion.
3. Week three: run checks five through seven. Quote-to-order, approvals, post-purchase. These are the workflow checks and they often reveal gaps between what sales tells customers and what operations actually delivers. Sit with three to five recent quotes from beginning to end. Where does the conversation break? Where is rework happening today? Those breaks are the workflow gaps the commerce layer will need to close, not paper over.
4. Week four: synthesize. Produce a readiness profile across the seven checks, a pre-build action list (the things that need to be true before a platform is selected), and a sequencing plan. Most manufacturer engagements we've seen produce a pre-build list of four to twelve items. None of them require an agency to resolve. All of them shorten the eventual build.

After week four, the platform shortlist conversation gets meaningfully better. Vendors can answer specific questions instead of generic ones. RFPs can be sharper. Estimates can be more honest. Acro Commerce's Gesso accelerator and ERP integration and expansion practice both assume this framework has been run, or that we'll run it together as the first phase of engagement. The framework isn't proprietary. The discipline of running it is what produces the result.

Framework steps

STEP 1

ERP data hygiene and master data

Verify one primary identifier per SKU, consistent units of measure, a current item master, and a named owner of master data changes. Failure mode: duplicate SKUs and ambiguous ownership.

Step 2

Pricing logic, customer, contract, volume, promo

Confirm pricing rules live in the ERP as structured data and resolve via API. Failure mode: contract pricing in PDFs and discounts in sales rep heads.

Step 3

Customer and account hierarchy

Confirm the ERP can represent parent organization, billing entities, ship-to locations, and named users with permissions. Failure mode: each ship-to as a separate customer; no named user model.

Step 4

Inventory and availability rules

Confirm inventory data exposes available-to-promise, not just on-hand, across multi-warehouse logic. Failure mode: nightly batch updates that guarantee overselling.

Step 5

Quote-to-order workflow

Confirm a documented digital quote workflow handles negotiation, revision, and conversion to order without re-keying. Failure mode: quotes in email; CPQ that doesn't sync with commerce.

Step 6

Approval chains and buying rules

Confirm approval logic can vary per customer (threshold, category, role) and produces a visible 'pending approval' state. Failure mode: rules in the sales rep's head; approval over email.

Step 7

Order status and post-purchase visibility

Confirm real-time order status flows from the ERP back to the customer's portal, including partial shipments, back-orders, tracking, and invoices. Failure mode: stale nightly status and silent tracking integration failures.

Frequently Asked Questions

Next step

Get the foundation right before you build.

For readers scoping a platform decision or wanting a full architecture recommendation.