What does a commerce attach add to the ERP deal when it goes well?
Four things, and they are not equally valuable. Licence and services revenue is the obvious one and the least durable. The account grows, the client moves up a tier, and the services line for the year is larger. That is worth having and it is not why experienced partners do this.
The durable benefit is displacement cost. An ERP with an order desk attached can be replaced over a long weekend of pain. An ERP with a storefront that a client’s customers log into every day, holding their prices, their order history and their reorder lists, is a different proposition to rip out. The commerce layer converts the ERP from a back office system into something the client’s own customers touch, and systems that customers touch do not get replaced casually.
The third is visibility inside the client. ERP projects are judged by people who see the invoice and not the benefit. A storefront produces a number the client’s executive team already cares about, which changes who defends your budget in the next planning cycle.
The fourth is the least discussed. A commerce project forces decisions the ERP project can defer forever: who owns product content, what an item description is for, which warehouse a customer is actually served from, what the real lead time is. Those decisions improve the ERP implementation whether or not the storefront ever launches.
What does a commerce attach put at risk?
The ERP go-live, mostly, and by a mechanism that is easy to miss. Commerce is the first system that reads the item master in anger. An ERP go-live tolerates a terse description, a missing unit of measure conversion, a duplicate cross-reference and an item with no image, because the people using it know what the item is. A storefront cannot know, so every one of those becomes a visible defect with a customer attached to it.
Cross-references are the sharpest example because the failure is silent. In Acumatica, the system does not verify the uniqueness of alternate IDs, which was stated plainly in the community thread on assigning the same barcode to multiple inventory items, and the follow-up answer notes that scanning an alternate ID takes the first record in the system. Inside the ERP a knowledgeable user catches that. On a storefront, or in an order import that resolves customer part numbers, it becomes a customer receiving the wrong item and a credit note the client will remember.
The second risk is resource collision. Both projects need the same two or three people at the client: the person who knows pricing, the person who knows the item master, and the person with authority to decide. Adding a commerce project does not add those people. It doubles the demand on them at exactly the point the ERP project needs them most.
The third risk is attribution. If the storefront launches badly, the client will describe the problem by naming whichever system is newest and most visible, and that is often the ERP. A commerce project that fails in month nine can cost you the ERP renewal even where the ERP worked perfectly, which is why instrumenting attribution before launch is worth more than it sounds.
Checked against: Acumatica community 5435: "The system does not verify the uniqueness of alternate IDs in the system", and scanning takes the first matching record. Answers dated May 2021, Acumatica community 12996: taxes recalculated on orders imported from external systems, an example of an order-flow defect that only appears once real orders flow
Which comes first, the ERP go-live or the storefront?
This is the question that actually bites, and most partners answer it by default rather than by decision. The default is "ERP first, commerce later", which is usually right and is not always right.
The table sets out the three real options against what each one costs. Read the last row first, because rework is where the money goes and it is the row clients never ask about.
| Criterion | ERP first, storefront after go-live | Parallel, one combined go-live | Storefront first, on the legacy system |
|---|---|---|---|
| Risk to the ERP go-live | Lowest. The ERP project keeps the client’s scarce people to itself. | Highest. The same two or three client people are the bottleneck for both projects at the same time. | Low for the ERP, but the storefront is being built against a system that is about to be replaced. |
| Catalogue data cost | Paid twice if the item master is loaded without commerce requirements in mind, because descriptions, attributes and images get revisited. | Paid once. This is the strongest argument for parallel and it is a real one. | Paid twice for certain. Content is built against the old item identity and remapped at ERP cutover. |
| Integration rework | Minimal. Field mappings are built against a stable configuration. | Significant and underestimated. ERP configuration changes during build silently break mappings built the week before. | Total. The integration is replaced at ERP cutover, so it is a throwaway build with a real maintenance tail. |
| Time to a visible win for the client | Long. Twelve months of invoices before anyone outside finance sees anything. | Shortest, if it works. | Short, and it buys goodwill that carries the ERP project. |
| When it is the right answerThe row that decides it is usually the first one, not the fourth, however hard the client pushes on the fourth. | Most of the time. Default to this unless something specific overrides it. | When the client has a dated external commitment, such as a retailer demanding EDI or a procurement portal deadline, and the item master is already in reasonable shape. | When the ERP replacement is more than a year out and a named customer will leave without a portal. Scope it as disposable and say so in writing. |
What actually goes wrong when the two run in parallel?
Three failure patterns, all of them mundane, all of them predictable enough to plan around if you decide to run parallel deliberately.
Configuration drift breaks mappings. The commerce team maps a field on Tuesday, the ERP team restructures item classes on Thursday, and nobody tells anyone because both changes were correct in their own project. The fix is procedural rather than technical: one change log for ERP configuration that the commerce team is subscribed to, and a rule that item class, attribute and price class changes go through a named person.
User acceptance testing collides. Both projects want the client’s subject matter experts for two weeks, and they want the same two weeks. Whichever project has the harder deadline wins, and the other project ships with testing that was signed rather than done. Book UAT windows for both projects at the same time you book the go-live dates, not later.
The order flow is tested last and fails first. Sales orders are the point where both systems meet, and the behaviours that go wrong there are specific: tax recalculating on imported orders, payment states not matching, and orders queuing when volume rises. Acumatica’s own Commerce Edition team lead has advised that above roughly 500 synchronizations an hour the recommended connector configuration changes, with real-time sync disabled in favour of batch preparation every 10 minutes and hourly processing. If your parallel plan tests order flow in the final fortnight, you will find that out in the final fortnight.
Checked against: Acumatica community 5392: real-time and scheduled synchronization guidance from an Acumatica Commerce Edition team lead, including the guidance to move above roughly 500 synchronizations per hour to batch preparation and hourly processing. Posted April 2021, Acumatica community 12996: tax recalculation on imported orders
What should go into the ERP statement of work before commerce is scoped?
Write these while the ERP deal is being signed, when they cost nothing. Trying to add them once a commerce project is live reads as a partner protecting itself, because that is what it is.
The point of all five is the same: keep the ERP project’s obligations bounded by the ERP project’s scope, so that a commerce decision made later cannot silently expand what you already promised.
State that the item master scope covers operational use and that publishing items to a public storefront is a separate exercise with its own acceptance criteria.
State that ERP configuration changes requested by any third party are change-controlled through you, with a named approver on the client side.
State that integration to any external system is out of scope unless separately scoped, and name the interface the ERP will expose.
State that ERP go-live acceptance is not conditional on any external system being live.
Reserve the right to re-baseline the ERP timeline if a parallel project consumes the client resources named in the plan, and name those people in the plan.
When should you talk a client out of attaching commerce now?
When they have no one who owns product data. A distributor with tens of thousands of terse manufacturer descriptions and nobody assigned to fix them will launch a storefront where nothing can be found, and the post-mortem will name the platform and the ERP rather than the content. Qualify for a data owner with the same seriousness you qualify for budget.
When the ERP go-live is inside 90 days and the item master is not stable. Adding a second project on top of a wobbling first one does not accelerate anything.
When the stated goal is that the website looks dated. That is a design project, it competes with the ERP budget, and it loses. Note it, park it, and revisit after go-live.
When the only person who wants it is you. A commerce attach that exists because it improves your attach rate rather than because the client has an order desk problem is a project with no internal sponsor, and projects with no internal sponsor stall at the first hard decision about data.
The wider picture
This page answers one narrow question. Acro Commerce covers the strategy around it.
Common questions
- Does attaching commerce to an ERP deal actually improve retention?
- It raises the cost of replacing the ERP, which is the mechanism that matters. Once a client’s own customers log in daily to a storefront that holds their prices, order history and reorder lists, and that storefront is integrated to the ERP, replacing the ERP means rebuilding an interface that the client’s customers use. That is a different conversation from replacing a back office system nobody outside the building touches. We can describe the mechanism; we are not going to publish a retention percentage we cannot source.
- Should the ERP and the storefront go live at the same time?
- Usually not. The same two or three people at the client are the bottleneck for both projects, user acceptance testing windows collide, and ERP configuration changes made during build silently break integration mappings that were correct the week before. Go parallel when there is a dated external commitment such as a retailer requiring EDI or a procurement portal deadline, and only when the item master is already in reasonable shape.
- What is the most common way a commerce project damages an ERP implementation?
- It exposes item data problems that the ERP go-live tolerated. Terse descriptions, missing unit of measure conversions, items with no image, and duplicate cross-references are all survivable when a trained user is reading the screen, and none of them survive a customer reading a product page. In Acumatica specifically, alternate IDs are not checked for uniqueness, so a duplicate cross-reference is silently allowed and turns into a wrong item on an order.
- How do I protect the ERP timeline if the client insists on running both?
- Name the client-side people the ERP plan depends on, in the plan, and reserve the right to re-baseline if a parallel project consumes them. Then book both user acceptance testing windows at the same time you book the go-live dates. Add one change log for ERP configuration that the commerce team is subscribed to, with item class, attribute and price class changes routed through a named person on your side.
- Is a commerce attach worth it on a small client?
- It is when the order desk workload grows with revenue, because that is a business case a CFO will still believe in month eight. It usually is not when the client’s catalogue is small, their pricing is a list with two tiers, and their customers phone because they like phoning. In that second case the honest recommendation is often to switch on whatever portal their existing system already includes and spend the money on product photography instead.
- What should I do if the client already started a website project without telling me?
- Find out what has been signed and what has been built before you have an opinion about it, because the answer changes what is recoverable. Then ask for one specific thing: which prices the site will show and where they come from. That single question surfaces most of the integration risk, it is answerable by a non-technical person, and it gets you into the project as a useful party rather than as the supplier who is annoyed about not being asked.
Last updated 2026-08-20. Facts on this page last checked against source 2026-08-20.