Which Acumatica contact becomes the BigCommerce company admin?
The main contact, not the primary contact, except that the primary contact’s name is used. That mismatch is the first item in a list a user posted in Acumatica community thread 24685, running on 23R1: “the main contact rather than the primary contact (except for the primary contact name) is used as the first admin info in BigC”.
For an Acumatica user this is genuinely confusing, because main contact and primary contact are different records maintained by different people for different reasons, and neither of them is necessarily the person who should administer your customer’s A company account is a customer record that holds several people, each with their own login and their own permissions. One buyer might place orders, another might only approve them, a third might only look up past invoices. on your website. The person who signs off invoices and the person who manages who can log in and order are frequently not the same person.
The same thread reports that the second phone number on the main contact syncs rather than the first. Nothing about that is dangerous, and it is exactly the kind of small wrongness that makes a sales team distrust the whole dataset when they see it in the wild.
Checked against: Community 24685: BigCommerce B2B customer syncing issues, on Acumatica 23R1
What happens when Acumatica and BigCommerce disagree about a contact?
BigCommerce wins on the fields that matter most, which is the opposite of what most ERP-run businesses assume. From the same thread: “if you modify the main contact email address or primary contact name in Acumatica, those changes get overwritten by what is in BigC B2B”. If your customer service team corrects an email in the ERP, that correction can be undone by the storefront.
The mirror image is just as awkward. The connector “will not notice that a customer needs to be resynced if you only modify contact data (for contacts other than the main contact)”. So edits to the main contact flow the wrong way, and edits to everyone else do not flow at all until something else triggers a resync.
Decide your The source of truth is the system that gets to be right when two systems disagree. For price, stock and customer terms in an ERP-run business, that is almost always the ERP. per field before you configure anything, and then verify the connector agrees with your decision. This is the single most common place where a documented intention and an actual sync behaviour diverge, and where nobody notices for months because both systems look fine on their own.
Checked against: Community 24685: overwriting and missed resyncs
Why can’t the customer delete their first admin?
Because that admin record is how the connector holds the link between the Acumatica customer and the BigCommerce B2B company. The thread flags exactly this risk: “the possibility of a customer deleting the first admin in their company in BigCommerce B2B since that is how the connector is connecting the customer”.
Read that as an operational hazard rather than a bug. Your customer’s buying team changes. Somebody leaves, their successor tidies up the user list, and the tidy-up quietly breaks the association between their company and their account in your ERP. Nobody at either end is doing anything unreasonable.
Two things follow. Whoever supports the storefront needs to know that removing the first admin is not a routine action, which means it needs to be in your customer-facing help and in your support team’s runbook. And you need a way to detect a broken link, because the symptom will present as an order that will not import or pricing that stops applying, weeks later, rather than as an alert.
Checked against: Community 24685: deleting the first admin severs the link
The six behaviours, and what each one asks you to build
All six come from one Acumatica community thread on 23R1. We are listing what each one costs in project terms, because the individual behaviours are manageable and the accumulation is what turns a connector project into a customization project.
| Criterion | Reported behaviour | What you have to do about it |
|---|---|---|
| First admin | Main contact is used, except the primary contact’s name. | Data hygiene on the contact records before go-live, and a rule your team understands about which contact record governs the website. |
| Phone number | The second phone number on the main contact syncs, not the first. | Either accept it or normalize the phone fields across your customer base. Cosmetic, and it damages trust in the data. |
| Edit direction | Acumatica edits to main contact email and primary contact name are overwritten by BigCommerce values. | A decided and documented source of truth per field, plus a process that stops your service team making edits that will be undone. |
| Change detection | Edits to contacts other than the main contact do not trigger a resync. | A periodic full resync, or an external trigger, if contact accuracy matters to your buying experience. |
| Duplicates | Unusual situations routinely produce duplicate contacts in Acumatica. | A de-duplication routine and someone who owns it. This is ongoing work, not a project task. |
| First admin deletion | Deleting the first admin in BigCommerce severs the customer to company link. | Customer-facing guidance, a support runbook, and monitoring that detects a broken link before an order fails. |
Checked against: Community 24685: the full list, reported on Acumatica 23R1
Has any of this changed since 23R1?
Some of it may have. Acumatica’s 2026 R1 release page lists BigCommerce B2B Edition import among its retail and commerce features, describing importing and synchronizing company accounts, additional B2B customer details, and orders. That is the right area of the product and it is a reason to re-test rather than a reason to assume the list above is obsolete.
What we can say with confidence is that the thread is from 23R1 and the behaviours in it were reported by a user running the connector in anger, not inferred from documentation. What we cannot say is which of the six survive on 2026 R1, because we have not tested them.
If you are scoping a BigCommerce B2B project on Acumatica right now, use this list as a test plan. Six tests, an afternoon, and you will know which of them are your problem on your release instead of arguing about it in month four.
Checked against: Acumatica 2026 R1 release page: BigCommerce B2B Edition import, Community 24685: the 23R1 baseline
Common questions
- Which Acumatica contact becomes the BigCommerce B2B company admin?
- On Acumatica 23R1, per community thread 24685, the connector used the main contact’s details as the first admin in BigCommerce B2B, while taking the name from the primary contact. Those are two different records in Acumatica, so the resulting admin can be a blend of two people. Clean up which contact is which before go-live, because correcting it afterwards means touching live customer logins.
- Why do our Acumatica contact edits keep reverting?
- Because for some fields BigCommerce is winning. The 23R1 behaviour reported in community thread 24685 is that modifying the main contact email address or the primary contact name in Acumatica gets overwritten by whatever BigCommerce B2B holds. If your customer service team maintains contacts in the ERP, either change the process or change the direction of the sync, but do not leave both systems editable for the same field.
- Why are duplicate contacts appearing in Acumatica?
- The user in Acumatica community thread 24685 put it bluntly: any weird situation frequently causes the connector to create a duplicate contact in Acumatica. Guest checkouts, self-registrations that match an existing customer, and email changes are all common triggers for this class of problem across connectors. Plan for a de-duplication routine with a named owner rather than treating duplicates as a defect that will be fixed.
- What happens if a customer deletes their first admin user?
- The link between the Acumatica customer and the BigCommerce B2B company can be severed, because that admin record is how the connector holds the association. The practical consequences show up later as orders that will not import or account-specific pricing that stops applying. Put this in your support runbook and in whatever guidance your customers get, and monitor for companies with no linked customer.
- Is this still true on the current Acumatica release?
- We do not know, and we would rather say that than pretend. The behaviours above were reported on Acumatica 23R1 in community thread 24685. Acumatica’s 2026 R1 release notes list BigCommerce B2B Edition import work covering company accounts, B2B customer details and orders, which touches this exact area. Run the six checks on your own release before you design around any of them.
Last updated 2026-08-20. Facts on this page last checked against source 2026-08-20.