Pricing is one of the first places where a WooCommerce and Acumatica integration becomes more complicated than a simple product sync. A retail store may only need one price per SKU. A B2B store can have a public price, several customer price classes, account-specific agreements, effective dates, promotions, quantity breaks, and different rules for logged-in customers.
The safest approach is to decide which system owns pricing and then make WooCommerce follow that decision consistently. In the QuixWP Acumatica Connector workflow, Acumatica or MYOB Acumatica is treated as the operational pricing source. WooCommerce receives the synchronized base catalogue price, while customer price-class data is stored separately and can override the displayed and cart price for mapped B2B users.
Acumatica pricing is not just one product price
A common integration mistake is to treat an Acumatica item as if it had one number that can be copied into the WooCommerce regular price field. Acumatica supports several pricing layers, and they answer different business questions.
The default item price is a fallback maintained on the item. Sales price records can then define a Base price, a Customer Price Class price, or a Customer-specific price. Acumatica can also apply effective dates and other pricing dimensions depending on configuration. That means the integration needs a precedence model rather than a single field mapping.
- Default item price: a fallback when no applicable sales-price record exists.
- Base price: a general sales price not tied to one customer or price class.
- Customer Price Class: a price for a group of customers that share an agreed price level.
- Customer: a price intended for one specific customer account.
- Promotional, quantity-dependent, warehouse-specific, currency, and UOM rules may add more pricing dimensions in some Acumatica environments.
Choose the pricing source of truth before synchronizing anything
If staff maintain operational prices in Acumatica, WooCommerce should not become a second independent pricing system. Otherwise a merchant can update a price in WordPress, another employee can update Acumatica, and the integration has no reliable rule for deciding which value is correct.
For an Acumatica-led workflow, the clean model is one-way pricing ownership: prices are maintained in Acumatica, synchronized into the connector, and then exposed through WooCommerce. WooCommerce remains responsible for the storefront and checkout experience, but it does not invent a competing B2B price.
- Define Acumatica as the owner of synchronized catalogue and B2B prices.
- Use WooCommerce SKU to match the product or variation to the Acumatica Inventory ID.
- Treat manual WooCommerce price edits as temporary unless the integration explicitly allows them.
- Document how unmapped products and unmapped customers should behave.
- Test pricing ownership before enabling scheduled synchronization.
How base price synchronization works in WooCommerce
The QuixWP connector retrieves a default price for synchronized Acumatica inventory items and also processes sales-price records. Applicable base pricing is stored separately from customer-class pricing in the connector database.
When the WooCommerce catalogue is updated, the synchronized base price becomes the WooCommerce regular price and active price for the matching SKU. The connector also clears the native WooCommerce sale-price field so an old WordPress sale price does not continue overriding Acumatica-controlled pricing.
- WooCommerce products and variations are matched by SKU.
- The synchronized Acumatica base price becomes the WooCommerce regular catalogue price.
- An existing WooCommerce sale price is cleared during the catalogue price update.
- Variable-product price caches are refreshed after synchronized variation prices change.
- If no synchronized Acumatica price exists for a SKU, the connector does not need to manufacture a replacement value.
Customer price classes stay separate from the public base price
Customer price classes are useful for B2B stores because they allow one Acumatica pricing structure to serve groups such as wholesale, trade, dealer, distributor, or other account tiers without creating duplicate WooCommerce products.
During synchronization, the connector reads the Acumatica sales-price records and stores a price code alongside each item-specific class price. Base prices and class prices are kept in separate tables, so importing a wholesale price does not overwrite the public catalogue price for every visitor.
- Each synchronized class price is associated with an Inventory ID and price-class code.
- Class codes are normalized so WooCommerce role mapping can be matched consistently.
- A product can keep its public base price while one or more B2B classes have different values.
- If a mapped class has no price for an item, the connector can fall back to the synchronized base price.
- The store does not need duplicate retail and wholesale product records just to expose different prices.
Mapping WooCommerce users to Acumatica customer price classes
Importing customer price classes is only half of the B2B workflow. WooCommerce also needs a deterministic way to decide which class applies to the logged-in user.
The connector supports role-to-price-class mapping. A WooCommerce role can be mapped to the corresponding Acumatica class code, and roles can also be ignored when they should never trigger customer pricing. This keeps the B2B rule inside normal WordPress user management while Acumatica continues to own the actual price values.
- Example: a WooCommerce wholesale role can map to an Acumatica WHOLESALE price class.
- Different WordPress roles can map to different Acumatica price levels.
- Ignored roles can be excluded from class-price resolution.
- If no class-specific price matches, the base price remains the fallback.
- Role mapping should be tested with real customer accounts before production caching is enabled.
Where the B2B price is applied in WooCommerce
A B2B price needs to be consistent everywhere the customer sees or pays for the product. Changing only the product-page HTML is not enough because WooCommerce may calculate variation ranges and cart totals from different price APIs.
The QuixWP pricing integration resolves the synchronized class price for the current user and applies it through WooCommerce product and variation price filters. It also sets the line-item price before cart totals are calculated. Variation price caches include the current user and price-class context so one customer tier is not intentionally reused as another tier.
- Simple product price output uses the synchronized class price when one matches.
- Variation prices can use the same customer-specific class resolution.
- Available-variation data is updated so the selected variation shows the correct value.
- Cart line items receive the resolved synchronized price before totals are calculated.
- The base price remains available as the fallback when no customer-class override exists.
A practical price precedence rule for B2B WooCommerce
Pricing integrations become easier to reason about when the fallback order is explicit. For the standard class-based workflow, the customer-specific storefront decision can be kept simple.
First, identify the synchronized SKU. Then check whether customer pricing is enabled and whether the logged-in user resolves to an Acumatica price class with a price for that SKU. If it does, use that class price. If it does not, use the synchronized base price. If the integration has no synchronized value, preserve the existing WooCommerce behavior instead of guessing.
- 1. Matching synchronized class price for the logged-in B2B user.
- 2. Synchronized Acumatica base price.
- 3. Existing WooCommerce price only when there is no applicable synchronized value.
- Do not silently choose the cheapest available class price.
- Do not infer a customer tier from order history, email domain, or company name unless that rule was explicitly designed.
Effective dates, expiration dates, and scheduled prices
Acumatica sales-price records can be date-sensitive. The connector checks effective and expiration dates while processing synchronized sales-price rows. A future price is not applied early, and an expired price is not imported as the current storefront value.
This is different from building a complete future-price calendar inside WooCommerce. The connector evaluates what is applicable when synchronization runs. If a business relies on frequent scheduled price changes, the synchronization schedule and Acumatica price-maintenance process need to be aligned so WooCommerce receives the new current price at the right time.
- Expired sales-price rows are ignored as current pricing.
- Rows with a future effective date are not applied before that date.
- Zero or negative price rows are not used as normal synchronized selling prices.
- Scheduled synchronization should run often enough for the business pricing calendar.
- Time-sensitive promotions should be tested around both their start and expiry boundaries.
Do not confuse Acumatica pricing with WooCommerce sale prices
WooCommerce has a familiar regular-price and sale-price model, but Acumatica pricing is broader. A customer price class is not a sale. A negotiated B2B price should not automatically display as a temporary discount simply because it is lower than the public price.
For an Acumatica-led store, it is usually clearer to treat the resolved ERP price as the actual selling price for that customer. If the business also needs strike-through retail pricing, scheduled WooCommerce sales, coupons, or promotional messaging, decide which layer owns that behavior and test the interaction separately.
- A wholesale price is a customer entitlement, not necessarily a promotion.
- WooCommerce coupons can be a separate discount layer and need explicit testing with synchronized B2B prices.
- Native WooCommerce sale prices should not independently override an Acumatica source-of-truth model.
- If the storefront must show both list price and negotiated price, define that presentation requirement during onboarding.
What about customer-specific Acumatica prices?
Acumatica can define a sales price for one customer as well as for a customer price class. That does not mean a WooCommerce integration should automatically treat every Price Code as a WordPress role.
The current QuixWP standard storefront model is designed around customer price classes and role mapping. The connector also has customer lookup capabilities for the wider order workflow, but unique per-account pricing needs an agreed identity mapping and precedence rule before it should override class pricing in the storefront.
- Decide whether an individual-customer price should override the customer price class.
- Use a stable Acumatica customer identifier rather than guessing from a company name.
- Define what happens when a WooCommerce account cannot be matched to an Acumatica customer.
- Review caching and privacy implications when prices differ by individual account.
- Treat complex account-specific pricing as a workflow to validate, not as a side effect of importing sales-price rows.
Quantity breaks, multiple currencies, warehouses, and UOM pricing need explicit scope
Acumatica can support pricing dimensions beyond base and customer price class. Volume-dependent prices, warehouse-specific prices, UOM-specific prices, promotions, and currency rules can all affect which price Acumatica selects for a transaction.
A WooCommerce connector should not pretend those dimensions are automatically equivalent to a single product price. If the business uses them, they need to be included in the compatibility review and tested against the actual cart and order workflow.
- Quantity breaks may require cart-quantity-aware price resolution.
- Multiple currencies need a defined source and conversion or price-list strategy.
- Warehouse-specific prices need to align with the warehouse used for stock and order export.
- UOM-specific pricing needs a clear relationship between WooCommerce quantities and Acumatica units.
- Complex promotional precedence should be tested using real Acumatica examples.
How to test Acumatica B2B pricing before go-live
Pricing should be tested with a matrix, not with one product and one administrator account. Use several SKUs and several customer states so the fallback rules are visible before real customers depend on them.
For every test, record the expected Acumatica value first and then verify the WooCommerce product page, variation selection, cart, checkout, and exported order. A price that looks correct on the product page but changes in the cart is still a failed integration.
- Guest or standard retail user: confirm the synchronized base price.
- Mapped B2B role with a class price: confirm the class-specific price.
- Mapped B2B role without a class price for one SKU: confirm base-price fallback.
- Variable product: verify both price range and selected variation.
- Future and expired Acumatica price rows: verify that they do not become the current price incorrectly.
- Cart and checkout: confirm line prices, tax display, coupons, shipping, and totals.
- Repeat the test after a scheduled synchronization and after clearing or warming relevant caches.
The QuixWP approach to WooCommerce Acumatica pricing sync
QuixWP Acumatica Connector is designed for managed WooCommerce and Acumatica or MYOB Acumatica integrations where the pricing rules are confirmed before production automation is enabled. The standard approach keeps Acumatica as the pricing authority, synchronizes base and customer price-class data, and applies the appropriate class price to mapped WooCommerce users.
That provides a practical B2B foundation without forcing every store into the same pricing model. During onboarding, the compatibility review identifies whether the business only needs base and customer price classes or whether customer-specific pricing, volume breaks, multiple currencies, promotions, warehouse pricing, UOM rules, or other custom requirements need additional implementation work.
- Acumatica remains the operational source of synchronized prices.
- WooCommerce SKUs provide deterministic product matching.
- Base prices and customer price-class prices are stored separately.
- Mapped B2B users can receive their synchronized class price throughout the storefront and cart.
- Base-price fallback protects products that do not have a special price for every class.
- Advanced pricing rules are confirmed during onboarding instead of being silently assumed.
Frequently asked questions
Can WooCommerce sync customer price classes from Acumatica?
Yes. QuixWP Acumatica Connector can synchronize Acumatica sales-price data separately from the base price and apply a matching customer price-class price to mapped WooCommerce users.
What happens if a B2B customer has no class price for a product?
In the standard QuixWP class-pricing flow, the synchronized Acumatica base price is used as the fallback when no matching class-specific price exists for the SKU.
Does an Acumatica customer price class become a WooCommerce sale price?
No. A customer price class is a conditional B2B price, not inherently a promotion. The connector resolves it as the customer selling price rather than treating it as a native WooCommerce sale price.
Can different WooCommerce roles have different Acumatica prices?
Yes. WooCommerce roles can be mapped to Acumatica customer price-class codes so different logged-in B2B groups can receive different synchronized prices.
Does the connector apply B2B prices in the cart as well as on product pages?
Yes. The pricing integration resolves synchronized prices for product and variation display and also applies the resolved price to cart line items before WooCommerce calculates totals.
Can Acumatica future and expired prices be synchronized?
The connector checks effective and expiration dates when processing sales-price rows. Future prices are not applied early and expired rows are not used as the current synchronized price.