Wholesale operations desk with a storefront tablet, company and location icons, an ERP monitor, and a barcode scanner.

Map the Shopify company to the Acumatica organization customer, its company location to the ERP customer location, and the individual buyer to a contact associated with that location. On the order, preserve all three identities, the buyer’s purchase order number when supplied, and the addresses and commercial values required for fulfillment and invoicing. Establish the direction of authority for each field before synchronizing existing records. Prove the mapping with one customer that has two locations and a buyer who can order for both. The right test ends with a correctly billed and shipped order, a searchable source reference, and one ERP order even after the same Shopify order is processed again.

Shopify and Acumatica B2B projects usually encounter the hardest cases when the records already exist in both systems. A buyer’s email may be shared across branches or changed after onboarding. A headquarters billing address may coexist with a branch ship-to and a one-time delivery address. Two sites can belong to the same account while using different catalogs or payment terms. This guide uses the documented Acumatica 2026 R2 Shopify connector behavior as a concrete reference and identifies design choices to validate for other connector versions, including the Biz-Tech Services Shopify Connector. Acumatica business customer synchronization

How Shopify B2B represents the purchasing business

A Shopify company is the parent for one or more purchasing locations. A location can carry its own shipping and billing addresses, contacts, payment terms, pricing context, checkout settings, and tax attributes. A Shopify customer represents an individual buyer. Their relationship to the company location determines which locations they can order for and what they can do there. Shopify describes separate Ordering only and Location admin permissions. A buyer with access to more than one location selects the purchasing location in the B2B buying experience. Shopify companies and customers and Shopify B2B customer sign-in

Start a discovery session by asking a customer-service representative to describe one customer in ordinary language. Who is the invoiced party? Who places orders? Which addresses are permanent? Can a buyer purchase for multiple sites? Who can see all orders for a site? This conversation often reveals whether an existing spreadsheet calls several different concepts “customer.” Record those distinctions before deciding that the same column should map to the same field everywhere.

For illustration, Harbor Supply has a headquarters and two purchasing sites, North and South. Jordan orders for both. North ships to a receiving dock, while South normally ships to its branch. Headquarters receives both invoices. One organization account can represent Harbor Supply if finance manages it as one debtor, while the two purchasing sites and their contacts retain their own identifiers. If the sites are separate legal customers with different receivable balances and credit decisions, treat that as a different modeling requirement and validate how the selected connector represents it.

Back to TOC

Map a company to the Acumatica organization customer

In the documented Acumatica 2026 R2 native connector, importing the Company entity creates a customer on Customers (AR303000) with the Organization customer category. The business customer guide also describes recording the Shopify company identifier with the store name in the external reference. The store matters because a trading relationship can appear in more than one Shopify store. The external reference supports traceability, and the team should verify how existing records are associated in the selected configuration before bulk processing. Acumatica business customer synchronization

Have finance identify the correct Acumatica account using its approved master data and billing evidence. Compare legal name, approved account ID, billing identity, and the relationship among subsidiaries or franchisees. A familiar display name can be a search clue. It is a poor join key because sales teams can rename companies, and two businesses can share a trading name. An account found by name alone belongs in an exception queue until its association is established.

Document the link with the Shopify store, Shopify company ID, Acumatica tenant or company scope, ERP customer ID, source of approval, and current state. This can be an approved cross-reference or the connector’s supported linkage mechanism. Define how the team can discover the existing link from either system and who can correct it. For a customer already integrated through another channel, reconcile the relationship with that channel first. Adding a storefront should preserve the approved customer master where the business relationship is the same.

Back to TOC

Keep purchasing locations and ship-to addresses distinct

The native business customer import creates a Customer Locations (AR303020) record for each Shopify company location it imports. A customer location is part of the organization relationship. A Shopify inventory or fulfillment location represents where the merchant stocks or fulfills goods, which is a separate concept. Acumatica documents warehouse mapping for Shopify fulfillment locations in the store configuration. Mixing those two meanings of “location” can lead to a correct buyer record paired with the wrong warehouse or billing defaults. Business customer synchronization and Shopify Stores form

For each company location, match the source location ID to the ERP customer location ID under the intended account. Specify the normal ship-to and bill-to, relevant customer price class if used, and the owner who can approve changes. Compare the full address, including suite, receiving instructions, postal code, and country. Use the source and target identifiers to resolve the location even if two locations share an address or staff rename one for convenience.

Shopify can be configured to let a customer use a one-time shipping address. Decide whether that exception is allowed for your trading partners and how the order should carry it. A direct shipment to a project site should not rewrite the permanent master location. Verify whether the deployed connector uses the order’s captured address, its company-location defaults, or an override in the intended scenario. Record the permanent location and actual shipment address as separate facts in the acceptance test. Shopify B2B checkout settings

Back to TOC

Map the buyer as a contact with location access

In Acumatica’s documented native import, a Shopify customer associated with the company becomes a contact in Acumatica. Under the conditions described in the product guide, the same person can also have an Individual customer record. The two records serve different functions. Check whether individual buying, B2B buying, or both are in scope, and test how the connector handles a person who shops in both contexts. Keep the sales order’s customer account tied to the purchasing business when it is a B2B order. Acumatica business customer synchronization

Use a buyer reference that captures the shop and the company contact or customer identity with the company relationship. Store the buyer’s display name and email for permitted operations. Treat those values as attributes that can change. An accounts-payable mailbox may be shared by several people, and a buyer can change employer or lose access to one branch. Validate the location assignment before mapping a contact to the order. Ask who can authorize a new person, a broader location assignment, or a role change.

Where the native export is used, Acumatica documents mapping contact roles to Shopify’s Ordering only or Location admin role. That is a reason to test the policy with a buyer who may order from one location and administer another. Verify storefront access with test accounts and inspect the result after a role change. A successful contact export tells you the record was processed. The access test tells you whether the person can see the correct catalog and place an order for the intended site. Acumatica Customer Locations form

Back to TOC

Build a field map that people can use

Document the map before enabling bulk synchronization. For each field, capture the source object and identifier, target record and field, owner, direction, approved default if any, and the expected outcome when a required value is missing. Add a sample document and an acceptance test. Keep account-level defaults, location-level settings, and transaction values on separate rows so reviewers can see which value is applied and when.

  • Company identity. Shopify company and shop reference to Acumatica Organization customer and its approved linkage. Verify one existing customer maps to one intended business in each configured scope.
  • Purchasing location. Shopify company location identifier to Acumatica customer location under that account. Verify the order resolves the selected location for a buyer who can order for more than one.
  • Buyer and access. Shopify customer or company contact to ERP contact and allowed location relationship. Test role changes and a buyer who also uses a consumer account.
  • Sales order and PO. Shopify order identity to the ERP sales order reference. Store the supplied buyer PO separately from the Shopify order ID and the ERP order number.
  • Address and commercial values. Identify the bill-to, ship-to, source of shipping charges, currency, quantities, price, discount, tax, and terms that the order and invoice must reconcile.
  • Source event and error. Record the shop, external order ID, attempt, current result, and error reason when the process stalls. Include an owner and allowed recovery action.

The field names in a mapping worksheet can describe business meaning before the team has confirmed the exact connector UI. Keep a second column for the implementation field name when it is verified. This is particularly useful when one shop uses the native connector and another uses a customization package or middleware. A shared business contract can cover both while the implementation and evidence remain specific to each route.

Back to TOC

Confirm the connector and plan combination

Shopify’s current plan guidance lists B2B companies, locations, and some other features on Basic, Grow, Advanced, and Plus. It reserves direct catalog assignment to companies and locations and some payment features for Plus. Acumatica’s 2026 R2 native business-customer guide describes its B2B workflow in the context of Shopify Plus and requires the Shopify Connector and Shopify B2B Integration features enabled in Acumatica. Verify the supported combination with the connector provider for the installed build, store plan, and specific feature. Shopify B2B features by plan and Acumatica business customer synchronization

Confirm which integration is deployed by checking the implementation documentation, licensed features, store connection, installed customization version, and connector support contact. The native product’s forms and entity rules in the Acumatica documentation are specific to that path. Biz-Tech Services describes its Shopify Connector as supporting B2B company data flows with multiple contacts and locations when B2B mode is enabled. Use the Biz-Tech product documentation and the installed build to establish the exact direction and supported fields for your environment. Biz-Tech Shopify Connector and Biz-Tech connector configuration checklist

Validate the combination with a test store and test tenant under your organization’s policies. Confirm that the app can read the required company and order objects with the approved scopes. If the required order context is absent, investigate whether the order was placed as a B2B order, whether the app can access the data, and whether the connector version ingests it. These three failures call for different fixes. Document the supported feature set as part of the rollout decision, especially if a storefront plan or ERP build may change later.

Back to TOC

Assign ownership by field and event

Agree on the authoritative system for company creation and for each attribute that will be updated. The owner can differ by attribute. Finance may control the organization and credit decisions in Acumatica, while a commerce administrator manages storefront permissions in Shopify. Fulfillment may need a separately approved delivery address on one order. Decide whether each field is imported, exported, available for authorized exceptions, or held for manual review. Bidirectional synchronization needs explicit rules about how simultaneous changes resolve.

For new company requests, determine where the request lands, how staff qualify it, and how they link it to an existing business if appropriate. The creation of a record in Shopify is a commercial intake event. The approval to create or use an AR customer belongs to the organization’s finance and master data process. Reserve a deterministic path to reprocess an approved request without creating a second organization. If the business is known but the selected location is new, review whether it should be added to the existing account or handled as a separate relationship.

At go-live, publish a simple ownership list for finance, sales operations, ecommerce, and fulfillment. Include who can approve a buyer’s access, assign payment terms, change a catalog, add a permanent ship-to, and unblock failed orders. Pair each ownership decision with a verification example. If the wrong system overwrites an address every night, a timestamp alone cannot identify the correct value. An agreed owner and a change history give operations a way to resolve the conflict and prevent it from recurring.

Back to TOC

Preserve the buying context on the sales order

Acumatica’s native documentation describes importing company orders through the Sales Order entity. In the documented workflow, the company is imported first if needed. The sales order on SO301000 then records the organization as Customer, the selected company location as Location, the buyer as Contact, and the shopper’s PO number in Customer Order Nbr. when supplied. The guide describes location-based shipping and billing details and the ordering customer as the shipping contact. Validate special address behavior separately. Acumatica orders for companies

Shopify’s Admin API represents the purchasing entity on an order as either an individual customer or a purchasing company. The purchasing company object exposes the company and location, and its contact field can be absent. An integration design can use the purchasing relationship as an explicit signal for routing, and define what to do if a required buyer association is missing. Ask whether sales operations can verify and resolve a missing contact while keeping the company and location correct. A record should not quietly become consumer business because a contact field is unavailable. Shopify PurchasingEntity and Shopify PurchasingCompany

Record the external order identity separately from any human-facing order number or PO reference. The same purchase order number can appear on more than one shipment or release, and identical display numbers can occur across stores. One reliable model is to key synchronization by the shop and stable Shopify order ID, and retain the ERP order type and order number once created. Use display numbers and PO numbers to help people search, and use stable record IDs to decide whether processing creates a new document or revisits an existing one.

Back to TOC

Carry through prices discounts and quantities

Shopify B2B catalog pricing depends on the purchasing location and its catalog assignments. Current Shopify documentation describes catalog priority for direct location assignments and market assignments. When using the native ERP price-list export, Acumatica documents exporting price lists by customer price class, including applicable quantity rules and volume prices, with eligible Shopify company locations associated with catalogs. Confirm the actual SKU, currency, catalog, quantity break, and customer price class on a test order before accepting the mapping. Shopify B2B catalogs and Acumatica sales price lists

Choose how prices are authored and how the accepted order is represented. An ERP-owned price list may be exported for future purchases. The order captured in Shopify reflects an actual checkout at a point in time. Decide whether and how the ERP imports that order’s accepted line amounts and discounts, when it recalculates, and who approves any differences. Repricing an older order silently during a retry can change an agreed commercial amount. Test a catalog update between initial capture and replay to show what the configured connector actually does.

Use line-level comparisons, not only a total. A 10-pack at an agreed case price can produce the same total as a single unit with an incorrectly mapped quantity or unit of measure. The warehouse will still pick the wrong stock. Compare SKU, variant, ERP inventory ID, unit of measure, quantity, unit price, discounts, freight and tax in both systems. Add separate samples for a quantity break, a manual draft quote, and an item that is available to one location only if the business uses those scenarios.

Back to TOC

Map payment terms and test the due date

Shopify lets merchants set payment terms by company location and for individual draft orders. Acumatica documents mapping Shopify terms to ERP credit terms on the Customers tab of Shopify Stores (BC201010). In the native company synchronization workflow, Acumatica says the company’s terms can populate the organization customer’s credit terms when the relevant Shopify locations share mapped terms, while differing location terms can prevent that master-level import. The Always Export Credit Terms option can cause the ERP customer’s terms to override Shopify location terms during export. Review its effect before enabling it for customers that negotiate terms by location. Shopify B2B payment terms and Acumatica business customer synchronization

Compare the master setting and the actual sales order and invoice. A terms mapping can look correct on the company yet differ on a specific order due to draft negotiations, payment-method behavior, or differences in how due dates are calculated. Test a straightforward net terms order and a contrasting case used by the business, such as a prepaid order or a draft with an approved exception. Compare the final invoice and receivable due date to the commercial agreement with finance. Record who handles exceptions if the connector cannot represent a terms combination.

Treat a payment term, a payment method, and a payment transaction as different fields. “Net 30” describes when the balance is due. A card, bank transfer, or another method describes how it may be paid. An authorization, capture, or refund is a financial event. Decide what evidence needs to move for each order type. Test settlements and payment application with the configured provider and ERP process before promising financial reconciliation. Acumatica order synchronization

Back to TOC

Decide where billing shipping and tax data come from

Identify the address used for billing, the normal address for the purchasing location, and the actual delivery destination on the order. Include the contact for delivery separately from the named purchaser and the billing recipient. The native orders-for-companies documentation describes deriving shipping and billing details from the selected company location and the shipping contact from the ordering customer. A deployment that allows a one-time address or sends an order to an end customer needs its own test and approved handling. Confirm what appears on the ERP shipment and invoice before enabling those cases. Acumatica orders for companies

Tax and exemption records need an owner in the implementation. Shopify’s company location can carry tax information and exemptions. The required ERP mapping depends on the tax configuration and the connector’s handling of order tax, customer defaults, and exemptions. Capture representative taxable and approved exempt transactions with the correct location and address, then compare actual tax lines and totals before release. If an exemption depends on evidence held elsewhere, store or link that evidence through the organization’s approved process and identify who can update the setting. Shopify companies and customers

Order reconciliation should distinguish address validation from tax validation. A correct address can still yield a different total if freight or a discount was classified differently. A matching tax total can hide an invalid ship-to where rates happen to be the same. Ask the team to verify who receives the invoice, which destination appears on the carrier label, whether the tax breakdown matches the source under the agreed policy, and how the ERP warehouse was chosen. Sign off each fact separately.

Back to TOC

Handle existing accounts before the first sync

Export or inspect an approved subset of active organizations and locations in both systems. Normalize formatting for the comparison, then match identities using authoritative references. Separate confirmed one-to-one links, plausible candidates that need approval, and truly new records. Keep a list of company records that may correspond to accounts in another Acumatica tenant or company. The same source identity can require different treatment when deployments or trading relationships differ.

Do not apply the connector’s individual customer matching logic to companies by assumption. Acumatica’s native Customer entity reference describes a matching rule based on email, or phone when email is absent. Its business synchronization guide separately describes the Company entity and related organization, location, and contact records. Test and document how the deployed Company route identifies a previously linked account, what it does when no link exists, and whether it can safely bind to an existing record. Acumatica Customer entity mapping and Acumatica customer synchronization overview

For a true duplicate, pause automated updates to the affected pair while the master data owner reviews the relationship. Identify the account with open receivables, historical transactions, approved terms, and current customer identifiers. Decide whether and how the duplicate can be reconciled under the organization’s rules. A master data cleanup may require corrections or a deliberate remapping, and historical orders should remain traceable to their original source. After the correction, use a sample order and a replay to prove that the connector no longer creates or selects the wrong account.

Back to TOC

Plan changes to buyers and locations

An integration should account for changes after onboarding. Test a location rename, an address correction, a buyer email change, a transfer between branches, a role reduction, and a buyer who leaves. For each, note which record should update, who approves the update, and what happens to orders already placed. Maintain a searchable link to historical orders even after a location is retired. Where future checkout must be restricted, verify the storefront access itself after the change.

The native connector guide documents asymmetries for deletion and deactivation. For example, a Shopify customer removed from a synchronized company can cause the corresponding Acumatica contact to become inactive on a subsequent synchronization. The same guide says an ERP contact or location that is deactivated or deleted does not update the corresponding Shopify record through the documented export. Confirm the installed build and use a separate controlled revocation procedure where synchronization cannot enforce it. Acumatica business customer synchronization

Coordinate changes that affect trading terms. A permanent ship-to edit can change how new orders are fulfilled and taxed. A role change can make order history visible to a different person. A price class or catalog reassignment can affect future checkout for multiple locations. Test a new order and compare an older order after each change. Establish which facts should be preserved on historical documents and which values are recalculated by the configured system when a new order is created.

Back to TOC

Route ambiguous orders to an exception queue

Define the policy for incomplete or inconsistent buying context. Common examples include a recognized company with no location mapping, a location under the wrong ERP customer, a buyer with a missing contact reference, or an order that appears to use retail context even though the buyer is known. Keep the source order, error type, identities that could be read, and an owner in the queue. Use the smallest information set needed for troubleshooting and give staff a link to the protected source record.

An approved generic account can be appropriate for a genuinely generic retail or guest workflow. A named B2B order may need the organization’s credit terms, pricing, billing, customer PO, or order history. Keep the fallback rule narrow enough that a malformed company order cannot inadvertently pass through it. Test that the team can detect both false routing directions. A retail checkout by a buyer with a company association can still be retail when the purchasing context shows it, while a company order should continue to the company workflow.

Set response expectations for the queue. A pricing error that prevents order confirmation may require a different owner and time frame from a missing buyer contact on a fulfilled historical order. When someone repairs a mapping, record which pending orders can now be processed and confirm that the repair applies to the intended customer scope. An order already billed incorrectly needs a separate finance decision. Give operations a way to see unresolved exceptions so an apparently healthy daily import does not hide missing orders.

Back to TOC

Prove one Shopify order creates one ERP order

Build a replay test around the source shop and stable order identifier. Import one controlled B2B order and record the ERP order type and number that result. Process the same source order again using the normal recovery or resynchronization path. Verify the outcome is a safe retry, an allowed update, or a clear hold depending on the existing document state. It should leave a single intended sales order and avoid duplicating customer, contact, or payment records. Use the connector’s documented status and retry controls, and compare the resulting records directly.

Test the failure window that matters most. For example, simulate or use a test case where the ERP record is created but the integration does not receive a success result. The next attempt should be able to find the existing order by its link or handle the case as a controlled exception. Repeat with two nearby orders sharing a PO reference, and with a second Shopify store using a similar visible order number. These cases show whether routing uses stable identifiers or a convenient but ambiguous display value.

Also test legitimate updates. An order that changes before fulfillment can require a different result from an update after an invoice is released. Document which fields may update at each point in the lifecycle and who approves changes. In the native path, Acumatica describes separate preparation, processing, and automated synchronization options. Establish when retries or updates occur in your configuration and where an operator can see the latest status. Acumatica scheduled synchronization

Back to TOC

Walk through an illustrative two-location order

Harbor Supply has one ERP organization customer with separate North and South locations. Jordan has Shopify ordering access to both. Finance has approved headquarters as bill-to. North’s preferred ship-to is a receiving dock, and South has a negotiated catalog for a smaller minimum quantity. These are sample facts for testing. A real configuration must establish which fields are supported and how it represents differences in location terms and catalogs.

In the test, Jordan buys 10 cases for North using the B2B account and enters PO HS-441. Record the Shopify shop, company, North location, buyer, order ID, PO reference, and captured line values before processing. In the resulting ERP order, confirm the customer is Harbor Supply, the location is North, the contact is Jordan, and the PO is HS-441. Verify the billing address, North’s ship-to, the planned source warehouse, and the quantity in cases. Compare the actual checkout price, freight and tax to the ERP order before shipping.

Repeat with an order for South using the same buyer and, for the retry test, a PO reference that is intentionally reused. Check that the new order belongs to South and uses the intended commercial context. Replay North’s original order through the recovery process and verify that the existing ERP order is found without creating another. Then remove the test buyer’s access to North through the approved procedure and confirm the buyer can still order for South. Save the source references, resulting record IDs, and evidence of the negative access check as part of the acceptance decision.

Back to TOC

Reconcile orders through fulfillment and invoicing

Use a reconciliation view that starts from Shopify order IDs in the scope of the rollout and matches them to Acumatica order numbers. Include store, B2B classification, company and location, amount, currency, latest processing state, and age of any exception. Include a count of source orders missing a valid ERP link. Compare eligible orders over a defined time window so you can distinguish timing differences from records that never arrived. Keep manually resolved cases visible until the link and subsequent ERP records are confirmed.

Finance should select samples and compare the ERP order, shipment, and invoice. Confirm which account owns the receivable, which customer PO appears on the invoice, which delivery address appears on the shipment, and whether quantities, pricing, freight, discounts, tax, currency, and payment state reconcile. Where the business uses multiple shipments, partial payments, or multiple storefronts, test them explicitly. Review which fields are exported back to Shopify and when the customer sees them.

Have operations record how long it takes to clear an exception and what causes the most rework. Useful measures include the share of eligible orders linked to one intended ERP order, missing or ambiguous locations, aged processing failures, and mismatches found at invoice review. Keep the numerator and denominator tied to the same population and period. A team that knows which cases are outside scope can make a better rollout decision than one relying on a single “successful sync” count.

Back to TOC

Decide which source event makes an order ready

Agree on the point at which commerce hands an order to the ERP. Some B2B locations submit draft orders for review. Shopify supports that setting at the location level. A draft may still be awaiting revised quantities, a negotiated price, or an approved shipping address. For a process that sends only confirmed orders to fulfillment, document the point at which the draft becomes eligible and how the connector identifies that state. If sales uses ERP-created orders or quotes in addition to storefront checkout, give that path a separate eligibility rule and test its supported direction. Shopify B2B checkout settings

Run the draft case in both directions of the business decision. In one case, a reviewer confirms the draft after changing one commercial value. Compare the confirmed Shopify order to the ERP record and prove which price and terms moved. In the other, the draft remains pending or is declined. Confirm that it does not create a fulfillable sales order. If the deployment imports a draft into a separate ERP work queue, confirm the expected status and who can turn it into a shipment. Document how a second delivery of the confirmation is handled.

Keep business status and integration status visible together. An eligible order can have a failed sync, and a synchronized order can still be held for credit or another approved check. The support team needs to know which system and owner can advance each state. Provide a route for orders that have been placed correctly but are not yet eligible, so staff do not manually duplicate them while waiting.

Back to TOC

Keep an acceptance packet for each connector path

Give the pilot a simple acceptance packet that can be reviewed without a live demonstration. Start with the app or package name and version, ERP build, Shopify shop and plan, enabled entities, and tested sync direction. Attach the approved field map. Include each scenario’s source company, location, buyer role, order reference, resulting ERP customer and order reference, and the outcome of replay. Keep sensitive data inside authorized systems and use masked examples in any shared report.

For each representative order, record what was expected and what was observed at four points. At checkout, confirm the purchasing context and accepted values. At import, confirm the account, customer location, contact, order type, and reference. At shipment, confirm destination, inventory quantities, and source warehouse. At invoice review, confirm the billed party, terms, currency, and values finance reconciles. If a workflow ends before invoicing during a first pilot, say where it stopped and keep the remaining checks open.

Use the packet again when an ERP upgrade, storefront plan change, or connector update changes the integration. A regression check should include the cases most likely to break silently, such as a buyer with two locations, a PO reused by two orders, a one-time address, and a B2B order mixed into a consumer store. Keep the ERP and commerce acceptance owners visible. If one case requires custom mapping or manual review, identify the owner and the decision threshold that will trigger a future change. The packet gives the next reviewer a way to reproduce the result with the same evidence.

Back to TOC

Roll out the map in stages

Begin in a controlled environment with a small set of approved customers. Include at least one organization with two locations and one buyer with different roles across sites. Add a retail order if the store also serves consumers. Review the mappings with AR, ecommerce, sales operations, and fulfillment. Test the path all the way to the invoice, and confirm the exact connector version and Shopify plan used for the test. Document any scenario that remains manual or has a dependency.

Before activating an automated schedule, agree on an order cutoff, a backfill policy, and a way to pause processing if the queue contains unexpected duplicates or wrong-customer orders. Acumatica’s native Shopify order guidance describes a store-level earliest order date setting and its effect on related synchronization. Verify the relevant filter and start date on the deployed connector rather than assuming the same field exists in another integration. Reconcile the first run against a list of expected source orders and check the customer records it touched. Acumatica order synchronization

Expand by customer segment or store only when the prior group meets the agreed acceptance criteria. An operations lead should be able to identify a failed order, determine whether an existing ERP record exists, fix the issue through the approved owner, and safely replay the order. A controller should be able to trace the billed party and terms. The warehouse should be able to verify the destination and item quantities. Use those three observations to decide whether the rollout is ready. For a connector fit review, bring one representative multi-location account, one sample order, and your current ownership and exception rules. Biz-Tech Shopify data flow guide

Back to TOC

Frequently Asked Questions

Does a Shopify company map to a single Acumatica customer

That is the documented native Company import pattern. The ERP organization can have multiple customer locations and contacts. Confirm separate legal customers, franchise arrangements, and existing account links with finance before choosing the map.

Where should the Shopify company location go

Map it to an Acumatica customer location under the correct organization in the documented native workflow. Keep the purchasing location separate from any fulfillment warehouse and from a one-time order address.

Can one buyer place orders for two locations

Shopify supports buyers assigned to multiple company locations. Test checkout for each location with the same buyer and check that the ERP sales order carries the selected location and correct contact.

Can a buyer email be the B2B account key

Use stable identifiers and a verified company relationship for the business account. Email can help staff find a person. It may change or be shared and does not establish which company or location placed the order.

Does Shopify B2B always require Plus

Shopify currently lists core B2B features on several plans and reserves some capabilities for Plus. Acumatica’s native B2B guide describes a Plus path. Check the supported plan, connector version, and specific feature together. Shopify B2B features by plan

What happens if two company locations have different terms

In the documented native company sync, differing location terms can cause the ERP customer master terms import to be skipped. Review the order and invoice terms separately, and test who owns terms before turning on export overrides.

Is the purchase order number a safe duplicate key

Use a source shop and stable order identifier for retry and deduplication. Retain the PO number for commercial reference and search. More than one order can reference the same purchase order.

What if the ERP has a matching organization already

Confirm the match using approved account references, then link it using the deployed connector’s supported method. Test that the next company sync and a sample order use the existing account and location.

How do I test updates without losing history

Use one buyer and two locations in a controlled environment. Change a permitted attribute, place a new order, and verify that the old order still reflects its captured context. Test access revocation separately.

What should a pilot demonstrate before expansion

It should demonstrate correct company, location, buyer, commercial values, a traceable source link, safe replay, and reconciliation through shipping and invoicing. A named owner should be able to resolve a representative exception.

Back to TOC

Sources

Back to TOC

Privacy Preference Center