Posted in Digital Commerce
June 8, 2026
DECISION GUIDE
ERP as source of truth vs commerce as source of truth: a decision guide for manufacturers
There is no single source of truth in B2B ecommerce. There are several, one per domain, and naming them correctly prevents most of the integration pain manufacturers experience after launch. This guide compares ERP and commerce as systems of record across five domains (pricing, inventory, customers, orders, products), shows when each should own the record, and offers a decision matrix you can run against your own architecture.
Key takeaway
There's no single source of truth, there are several, and naming them per domain prevents most integration pain.
What 'source of truth' actually means in B2B commerce
A source of truth is the system that owns the authoritative record for a given data domain. Other systems may read it, cache it, or display it, but they don't get to overwrite it. In B2B commerce architectures, the source-of-truth question is rarely 'ERP or commerce.' It's 'ERP or commerce, per domain.' The mistake we see most often is treating sourcing of truth as a single decision rather than five.
Across the manufacturer engagements Acro Commerce has run, the domains that need explicit source-of-truth decisions are pricing, inventory, customer accounts, orders, and product information. Each behaves differently. Each has a default that suits most manufacturers and exceptions that suit some. The objective of this guide is to make those decisions explicit before the integration is built, not after.
The framing matters because the cost of misnaming a source of truth compounds. When two systems both think they own a record, the cheapest version of the conflict is duplicate data; the more expensive version is silent overwrites that customers see as errors. The architecture rule we use in discovery & strategy work is straightforward: one system owns the record, all others read it, and the synchronisation direction is documented before any integration code is written.
Domain-by-domain comparison: pricing, inventory, customers, orders, products
Pricing. In the manufacturer engagements we've seen, the ERP almost always owns pricing. Customer-specific lists, contract pricing, volume breaks, and promotional overrides are encoded in the ERP because that's where the company's financial logic lives. The commerce platform reads price; it does not author price. The exception is promotional pricing that exists only in the digital channel, flash discounts, segment-specific online offers, which can sensibly live in the commerce platform and be reported back to the ERP. Tools like Acumatica's pricing engine and the customer-specific pricing capability in BigCommerce B2B Edition make either pattern technically possible; the right choice is operational, not technical.
Inventory. ERP owns inventory. The commerce platform displays inventory. Real-time availability checks should query the ERP (or a caching layer fed by the ERP) rather than maintaining their own stock counts. The reason is that inventory is committed against orders, work-in-progress, and reservations the commerce platform doesn't see; only the ERP has the complete picture of available-to-promise. Commerce-side inventory tends to drift the moment a phone order is placed.
Customers. This is the most nuanced domain. The ERP owns the customer for billing, credit, and tax purposes, the legal entity, the AR record, the payment terms. The commerce platform owns the customer for behavioural and authentication purposes, the login, the saved cart, the browsing history, the named individual within the buying organization. The two records describe the same customer from different angles. Neither system 'owns' the customer as a whole; both own a domain of customer data. Designing the bridge between them is one of the highest-leverage architectural decisions in any B2B build.
Orders. The order is interesting because it starts in commerce (or in CPQ) and finishes in the ERP. The pattern we recommend: commerce owns the order until it is submitted; the ERP owns the order from submission onwards. Status updates flow back to commerce for display. The commerce platform should never be the authoritative record of order state once fulfillment begins, that creates a class of bugs where the customer sees one thing and operations sees another.
Products. Product information is the domain most often split between systems. The ERP owns the SKU as a transactional object (cost, weight, tax classification, vendor). A PIM or the commerce platform owns the SKU as a marketing object (descriptions, images, categorization, search terms). The two share a primary key but not a record. Manufacturers without a PIM tend to push marketing-side product data into the ERP; that works until the catalogue gets large, at which point a dedicated PIM (or the PIM features inside platforms like Shopware) pays back quickly.
When the ERP should own the record
The ERP should own any record that has financial, legal, or operational consequences beyond the digital channel. Pricing affects margin; inventory affects fulfillment; customer billing affects AR; order-of-record affects revenue recognition. These are not commerce decisions dressed up as data; they are business decisions whose authoritative record belongs in the system that runs the business.
A useful test: if the record needs to be true whether or not the commerce site exists, the ERP should own it. Pricing was true before the website. Inventory was true before the website. Customer billing relationships were true before the website. The website is a new way to read and act on those records, not a new place to author them.
There's a second test. If two channels (web, phone, EDI, sales rep order entry) need to agree on the record, the ERP should own it. Channel parity is one of the strongest arguments for ERP-centric architecture. The companies that put pricing or inventory in the commerce platform tend to discover the limits of that decision the first time a sales rep enters an order in the ERP and the website shows a different number.
When the commerce platform should own the record
The commerce platform should own records that exist only because the digital channel exists. The user account (as distinct from the billing customer) is the clearest example: the named individual logs into the website, has a password, has saved preferences, has a browse and cart history. None of that exists outside the website. Forcing the ERP to model it is awkward and usually unnecessary.
Other commerce-owned records include digital-only product content (long-form descriptions, alternate images, search synonyms), behavioural data (browse history, recommendations, search queries), digital-only promotions, and the in-progress cart or quote before it is submitted. These are records the ERP doesn't need and shouldn't be asked to hold.
There is a third category worth naming: records that the commerce platform owns operationally but synchronises to the ERP for reporting. Newsletter consent, marketing preferences, and channel-specific engagement scores are examples. The commerce platform is the system of record; the ERP receives a copy for reporting and segmentation. Naming the synchronisation direction matters: this is commerce-to-ERP one-way, not bidirectional.
Hybrid patterns and the cost of getting it wrong
Most mid-market manufacturer architectures are hybrid by necessity. Pricing lives in the ERP but contract pricing for net-new web-only customers might originate in commerce. Inventory lives in the ERP but a caching layer in commerce reduces API load. Customer billing lives in the ERP but the user account lives in commerce. These hybrids are fine; they become problems only when the synchronisation direction is ambiguous or undocumented.
The cost of getting it wrong is paid in three currencies. The first is customer experience: a buyer sees one price on the website and gets a different invoice from finance. The second is operational time: a customer service team spends hours per week reconciling records that the architecture didn't design to be reconciled. The third is platform migration cost: when source-of-truth decisions are buried in integration code rather than documented as architectural rules, the next platform change becomes far more expensive than it needs to be.
A useful diagnostic: when something is wrong with a record, can your team identify within thirty seconds which system to fix it in? If the answer is no, sources of truth are not named clearly enough. Across the engagements we've seen, this diagnostic alone surfaces most of the architectural debt manufacturers have accumulated.
Decision matrix: which system owns which record
The defaults below hold for most mid-market manufacturer architectures. Use them as a starting point, then mark exceptions explicitly per domain.
Pricing, ERP owns the record. Commerce reads. Exception: digital-only promotional pricing can be owned by commerce and reported back to the ERP.
Inventory and availability, ERP owns the record. Commerce queries or caches with a documented refresh interval. Exception: none in most B2B contexts; manufacturers running drop-ship or marketplace models may have additional sources to reconcile.
Customer (billing entity), ERP owns the record. Commerce reads. Customer (named user / login), Commerce owns the record. ERP receives the link via a shared customer identifier.
Order (pre-submission), Commerce owns the record. Order (post-submission, including status, fulfillment, invoice), ERP owns the record. Status flows back to commerce one-way.
Product (transactional attributes: cost, weight, tax), ERP owns the record. Product (marketing attributes: descriptions, images, categorization), PIM or commerce owns the record. Both systems share the SKU as a primary key.
Promotions, Commerce owns the record. ERP receives the impact via order-line discount data.
Quotes, Commerce or a dedicated CPQ owns the record until acceptance. On acceptance, the quote becomes an order and the ERP takes ownership.
Use this matrix as a starting brief, then validate each row against your own pricing, fulfillment, and customer logic. The work to validate is roughly half of what a discovery phase produces; the other half is sequencing the build. Acro Commerce's ERP integration and expansion practice exists to do exactly this work, but the matrix is also useful as a self-administered exercise. For manufacturers considering a composable commerce approach, the matrix is the input that decides which composable services are needed and which are not.
Comparison dimensions
{ "domain": "Pricing", "default_owner": "ERP", "rationale": "Customer-specific, contract, volume, and promo pricing logic encode financial decisions that need to be true across all channels.", "exceptions": "Digital-only promotional pricing can be owned by commerce and reported back to the ERP." }
{ "domain": "Inventory and availability", "default_owner": "ERP", "rationale": "Only the ERP has the full picture of committed orders, work-in-progress, and reservations needed for true available-to-promise.", "exceptions": "Caching layers in commerce are acceptable with a documented refresh interval." }
{ "domain": "Customer (billing entity)", "default_owner": "ERP", "rationale": "Legal entity, AR record, credit terms, tax classification \u2014 all live in the system that runs financial operations.", "exceptions": "None in most B2B contexts." }
{ "domain": "Customer (named user / login)", "default_owner": "Commerce", "rationale": "Authentication, saved carts, preferences, and browse history exist only because the digital channel exists.", "exceptions": "Link to the ERP billing entity via a shared customer identifier." }
{ "domain": "Order (pre-submission)", "default_owner": "Commerce", "rationale": "In-progress carts and unaccepted quotes are commerce-channel artefacts that the ERP doesn't need to model.", "exceptions": "CPQ-led quote workflows may live in a separate CPQ system." }
{ "domain": "Order (post-submission)", "default_owner": "ERP", "rationale": "Once submitted, the order has fulfillment, invoice, and revenue recognition implications that belong to the ERP.", "exceptions": "Status updates flow back to commerce one-way for customer-facing display." }
{ "domain": "Product (transactional attributes)", "default_owner": "ERP", "rationale": "Cost, weight, tax classification, and vendor data drive transactional and operational decisions.", "exceptions": "None in most architectures." }
{ "domain": "Product (marketing attributes)", "default_owner": "PIM or commerce", "rationale": "Descriptions, images, categorization, and search terms are content artefacts authored for the digital channel.", "exceptions": "Manufacturers without a PIM may store this in the ERP until catalogue size forces a split." }
{ "domain": "Promotions", "default_owner": "Commerce", "rationale": "Digital-channel promotions are authored, scheduled, and measured in commerce.", "exceptions": "Promotion impact is reported to the ERP via order-line discount data." }
{ "domain": "Quotes", "default_owner": "Commerce or CPQ", "rationale": "Quotes are conversation artefacts that may pass through several revisions before becoming an order.", "exceptions": "On acceptance, the quote becomes an order and the ERP takes ownership." }
Related Articles
ERP-centric B2B commerce: why business logic decides the platform, not the other way around
Frequently Asked Questions
How do I know if my manufacturing business is ready to launch B2B ecommerce?
Readiness has less to do with platform choice and more to do with whether your ERP can answer, cleanly and via API, the questions a commerce site is going to ask it: how is a customer identified, how is a price calculated, how is availability promised, how is a quote turned into an order, who approves what, and how is an order tracked. If those answers exist on paper before platform conversations start, you're ready enough to launch.
What's the most common readiness gap manufacturers miss?
Pricing logic that lives outside the ERP, in spreadsheets, sales rep filing systems, or customer-specific email threads. If your pricing logic isn't encoded in the system that runs your business, putting commerce on top of it just exposes the gap to customers.
Does the ERP brand matter for ecommerce readiness?
Less than people expect. We see strong readiness across Acumatica and other tier-one and tier-two ERPs when the implementation respected the company's operational truth, and weak readiness across the same brands when implementations cut corners on master data and pricing governance. Implementation discipline predicts readiness more reliably than brand.
Should we wait until our ERP data is perfect to start an ecommerce project?
No. Mixed readiness is normal and is not a reason to delay. It's a reason to sequence. A good discovery phase converts a mixed readiness profile into a sequenced plan with a clear list of pre-build actions, most of which the manufacturer can resolve internally without an agency.
How long does a readiness assessment take?
The scorecard itself is twenty-two questions and can be self-administered. A formal Acro Commerce discovery engagement that includes readiness assessment, architecture brief, and platform shortlist typically runs four to six weeks for manufacturers with high readiness, longer where readiness is mixed.
Next step
Get the foundation right before you build.
For readers scoping a platform decision or wanting a full architecture recommendation.