Which error are you looking at?
Get the exact string out of the sync log before you change any configuration. Four documented shapes cover most of what people report after an Acumatica release, and they have completely different owners: one is an Acumatica validation change, one is a Shopify permission change, one is a data-loss symptom with no error at all, and one is not release-related and was always going to happen eventually.
All four observations below come from Acumatica’s own Retail and Commerce community and are keyed to the release the reporter was on. That matters. A behaviour reported on 25R1 is evidence about 25R1, and the correct way to use this table is to match the shape and then verify against your own release rather than assuming the fix transfers.
| Criterion | What you see | What it means | What to do |
|---|---|---|---|
| “At least one option value is duplicated” on template item syncThis is the classic release-note-free change: nothing in your setup moved, and the sync stopped. | Template and matrix items that synced for years now fail. Reported on Shopify Plus with 25R1. | A validation change on the Acumatica side started rejecting attribute values that had duplicate descriptions. Your data did not change; what will accept it did. | Find the attribute with repeated descriptions and make them distinct. Then check every other template item, because the same data pattern is usually widespread. |
| “Access denied for paymentTerms field. Required access: read_payment_terms access scope” | A GraphQL error on payment sync, reported against the 25R1 Shopify connector. | A Shopify API permission problem rather than an Acumatica configuration problem. Shopify gates certain order fields behind approved scopes and the connector app has to hold them. | Fix it on the Shopify app side by granting the scope, then re-authenticate the connection. Nothing in Acumatica will resolve this one. |
| Metafields empty after the upgrade, with no error anywhere | Theme content that depended on Shopify metafields is blank. The connector reports success throughout. | Data loss in a place the connector does not monitor. Reported by more than one user after the 25R1 Shopify connector upgrade. | Restore from your pre-upgrade export. If you do not have one, this is the reason to start taking one before every release. |
| “Sync ID is not found for the record” on price list sync | A whole price list fails to process. Often noticed just after an upgrade and blamed on it. | A stock item on the list has not synced to the store, usually because it was deactivated. Not release-related, and it would have happened anyway. | Find the unsynced item, sync or remove it, and re-run. Then add a pre-flight check for inactive items on price lists. |
Checked against: Acumatica community 30860: 25R1 template sync, “at least one option value is duplicated”, Acumatica community 31039: 25R1 payment sync, access denied for paymentTerms, Acumatica community 32281: Shopify metafield data loss with the 25R1 connector, Acumatica community 22606: “Sync ID is not found for the record”
Did Acumatica break it, or did Shopify?
This is the question that decides who fixes it, and teams lose days to it because both systems changed in the same fortnight. Three checks, in this order, and each one is quick.
Check the direction of the failure first. If products and prices still flow out to the store and only orders or payments fail to come back, look at the storefront side, because outbound and inbound use different permissions. If everything stopped at once, look at authentication.
Then check the app rather than the connector. Shopify has been retiring its older custom app model, and a connection built on legacy credentials fails in a way that looks exactly like a broken connector. The person who set up the Acumatica store record originally is frequently no longer at the company, which is why this one takes so long to find.
Then check whether the thing that broke is yours. A customisation that reads a table the connector does not officially expose, an extension on the commerce graph, or a mapping someone added by hand are all things an upgrade will break without any of it appearing in a release note. If you own a customisation against the Commerce Connector, assume every release is a regression test you have to run.
Direction: does data still flow one way? Outbound working and inbound failing points at storefront permissions rather than at Acumatica.
Authentication: when was the connection last re-authorised, and is it on Shopify’s current app model or on legacy credentials?
Ownership: is the failing behaviour a stock connector entity or something your team or your VAR extended?
Checked against: Acumatica community 32415: Acumatica and Shopify integration issues, Acumatica commerce connectors, product page, read 20 August 2026
Does a certification badge mean the vendor tested this?
No, and the distinction is worth knowing before your next renewal conversation. Every application on the Acumatica Marketplace carries the certification badge, so the badge tells you the vendor is in the programme rather than that any particular behaviour was verified.
"Fulfilled by Acumatica" is a narrower thing again. It is a hand-selected subset requiring a base of mutual customers and a commitment to keep pace with Acumatica releases, and it is billed through Acumatica’s own price list. That means Acumatica takes the money and holds the vendor to an update cadence. It does not mean Acumatica tested the code against your catalogue.
Both audiences misread these badges as capability guarantees, buyers and implementation partners alike. Read them as commercial arrangements, then go and test the behaviour you actually depend on. The test is the evidence; the badge is a purchasing route.
Checked against: Acumatica commerce connectors, product page, read 20 August 2026
What is the standing practice that stops this happening again?
Acumatica ships two feature releases a year, and upgrade dates are known well in advance. That makes this a schedulable piece of work rather than an emergency, and the companies that never have this problem are the ones that treat each release as a small planned project.
Five practices, in the order they pay for themselves. The first two cost almost nothing and catch most of what the community reports.
One caveat on the test tenant. Acumatica licensing counts stores and tenants, so before you assume you can spin up a test store, confirm what your licence allows. Discovering that at upgrade time is worse than discovering it now.
Write down the entities you actually use: which are enabled, which are scheduled, and what each one carries. Most teams cannot produce this list, and without it nobody can tell what an upgrade touched.
Export before every upgrade: product metafields, price lists, customer and company mappings, and your store configuration. The metafield case is the argument for this one on its own.
Keep a fixed regression script of a dozen checks and run it after every release: one contract-priced item, one multi-unit item, one matrix item, one order on terms, one refund, one price list run.
Upgrade a test tenant first and run the script there. This is the whole practice, and it is the one skipped under time pressure.
Read the Retail and Commerce community forum for the fortnight after a release goes generally available. The breaks in the table above were all reported there by somebody before they happened to somebody else.
Checked against: Acumatica Retail and Commerce community forum, Acumatica Licensing Guide, April 2026
When should an upgrade break change your architecture?
Once is an incident. Three times in two years is information, and it is telling you that the thing you depend on is not a supported path.
The signal to watch for is which layer keeps breaking. If the stock connector entities break and get fixed, that is the cost of a native connector and it is usually still the cheapest option you have. If what breaks every time is a customisation you own against the connector, you are paying a maintenance tax at every release and the honest comparison is against an integration layer that sits outside the ERP and has its own version boundary.
That comparison is a real decision with real numbers on both sides, and it belongs on the architecture pages rather than here. What this page can tell you is when to open it: when your regression script fails on the same customisation twice, or when the fix takes longer than the upgrade.
The wider picture
This page answers one narrow question. Acro Commerce covers the strategy around it.
Common questions
- Why did our sync break when nothing in our setup changed?
- Because validation moved rather than data. The clearest documented example is the 25R1 template sync error “at least one option value is duplicated”, reported on Shopify Plus, where attribute values with duplicate descriptions had always existed and the release started rejecting them. This is normal for a connector that ships twice a year, and it is the reason a pre-upgrade regression run on a test tenant is worth more than any amount of post-upgrade troubleshooting.
- Is “Access denied for paymentTerms field” an Acumatica problem?
- No, it is a Shopify access scope problem that surfaced on the 25R1 Shopify payment sync. Shopify gates certain order fields behind approved scopes and the connector app has to hold the read_payment_terms scope. The fix is to grant the scope on the Shopify app and re-authenticate the connection, and nothing you change in Acumatica will resolve it. Scope requirements change on Shopify’s timetable rather than yours, which is why this class of break arrives without warning.
- What should we back up before an Acumatica connector upgrade?
- Product metafields first, because they are where a Shopify storefront keeps everything the standard product model has no room for and there is a reported case of them being lost after the 25R1 connector upgrade with no error raised. Then price lists, customer and company mappings, and the store configuration itself. Losing a metafield breaks the theme without breaking anything the connector monitors, so the connector will report success while your product pages render blank.
- Does “Fulfilled by Acumatica” mean the app was tested by Acumatica?
- No. Every Marketplace application carries the certification badge, and Fulfilled by Acumatica is a narrower hand-selected subset requiring a base of mutual customers and a commitment to stay current, billed through Acumatica’s own price list. It means Acumatica takes the money and holds the vendor to an update cadence. It is a commercial arrangement rather than a statement that the code was tested against your catalogue, and both buyers and implementation partners routinely read it as the second thing.
- How long should we wait before applying an Acumatica release?
- Long enough that the community has reported what broke, which in practice is a few weeks after general availability, and not so long that you are running an unsupported version. The useful discipline is not the delay itself but what you do with it: upgrade a test tenant, run a fixed regression script covering contract pricing, units, matrix items, orders on terms and refunds, and read the Retail and Commerce forum. Check your licence before assuming you can create the test store.
Last updated 2026-08-20. Facts on this page last checked against source 2026-08-20.