Why does the three-way triangle fail?
Because everyone is telling the truth. The VAR checks Acumatica and finds no failed records, which is true, since the records never arrived. The agency checks the storefront and finds the orders present and marked as sent, which is also true. The platform confirms its API was up, which is true as well. Each party has evidence that is correct inside its own boundary, and nobody owns the boundary itself.
The second reason is commercial. Triage is unpaid work in most of these arrangements. Every party has an incentive to spend 20 minutes proving it is not theirs rather than two hours finding out whose it is, and 20 minutes times three parties times two rounds is most of a working day with the client watching.
The third reason is access. The party most likely to find the fault often cannot see the evidence. An agency that cannot read the ERP’s integration logs is guessing, and a VAR who cannot see the platform’s API responses is guessing too. Access is cheaper to arrange in week one than during an incident, and it is almost never arranged in week one.
What will the platform and the ERP vendor actually do for you?
Less than clients assume, and both of them publish this. Shopify’s help centre says that if you need help with an app or sales channel built by a third-party developer, you contact the developer directly. That covers every ERP connector that is not Shopify’s own code, which is most of them.
Acumatica’s published position is that support runs through the partner who sold the system. Its Direct Support page says you can get support the same way you purchased Acumatica, through a local partner, and describes Direct Support as complementing the support programme you may already have with your Acumatica partner, with training, consulting and implementation explicitly not included. Acumatica’s support overview does say customers and partners both have direct access, so the client can raise a ticket. What they cannot do is raise a ticket that makes Acumatica triage a third-party integration.
Put those two together and the position is clear. Neither vendor will own an integration defect. The only parties who can are the VAR, the agency, and whoever built or resold the connector, and if none of them has been made responsible in writing then nobody has been.
Checked against: Shopify Help Centre, app support: "If you need help with an app or sales channel that was built by a third-party developer, then contact the developer directly." Read 20 August 2026, Acumatica Direct Support: support is available through a local partner, and Direct Support complements an existing partner support programme; training, consulting and implementation are not included. Read 20 August 2026, Acumatica support overview: a multi-layered model across the VAR network, direct support and the community. Read 20 August 2026
How do you assign ownership by symptom rather than by system?
System boundaries do not help during an incident, because the client does not experience a system, they experience a symptom. Assign a first responder per symptom instead. The first responder is not the party at fault, they are the party who looks first and produces evidence within an agreed window, and they get paid for that whether or not the fault is theirs.
The table is the version to put in an appendix. Six symptoms cover the large majority of production incidents on an ERP-connected storefront.
| Criterion | First responder | Evidence produced within the response window |
|---|---|---|
| An order exists on the storefront and not in the ERP | Whoever operates the integration layer, which on a native connector build is the VAR. | The sync record for that order: prepared or not, processed or not, error text, and the timestamp of the last successful batch. |
| The price shown on the page disagrees with the invoiceThis symptom is a design gap far more often than a defect, which is why the source of the published price belongs in the go-live documentation. | The VAR, because the answer is almost always in ERP pricing configuration rather than on the storefront. | The effective price for that customer and item at the time of the order, and which stored field the storefront was published from. |
| Stock oversells or shows a quantity nobody recognises | The VAR, then the agency if the ERP figure is correct. | The ERP availability calculation for the item, the last quantity pushed, the push timestamp, and whether any storefront-side buffer is configured. |
| A customer cannot sign in or sees the wrong company | The agency, since account and company records live on the storefront. | The customer record on both sides, the mapping key used, and whether a duplicate exists. |
| The queue is backing up and everything is late | Whoever operates the integration layer. | Queue depth over the last 24 hours, throughput per hour, and any rate limit responses received. |
| Something broke immediately after an ERP or platform release | The VAR for an ERP release, the agency for a platform release. The party whose system changed looks first. | The release version before and after, the change log, and the first failing record with its timestamp. |
Language you can lift into a statement of work
These are drafting notes rather than legal advice, and your own counsel should see them before they go into a contract. They are written to be short enough that a client will actually read them.
The clause that earns its place fastest is the first one. Most support arguments are not about who is at fault, they are about who has to spend the first hour, and paying for that hour removes the argument entirely.
Triage responsibility. "For each symptom listed in Appendix A, the named first responder will investigate and produce the specified evidence within the response window, regardless of which party is ultimately responsible for the defect. Triage time is chargeable at the standard rate and is not conditional on fault."
Defect definitions. "An Integration Defect is a failure of data to move between systems as described in the field mapping document. A Configuration Defect is a system behaving as configured where the configuration does not match the agreed design. A Data Defect is a record that does not conform to the agreed data standard. Each category has a different owner and a different remedy."
Log and environment access. "Each party will maintain read access for the other parties to the logs, sync records and error queues of the systems it operates, for the duration of the support term. Access will be provisioned within five business days of go-live."
Correlation. "Every transaction crossing a system boundary will carry a shared correlation identifier, recorded on both sides and retained for no less than 30 days."
Third-party components. "Where a component is supplied by a third party, including any Marketplace or App Store application, the party that recommended or installed the component is responsible for managing the vendor relationship during an incident, including raising and pursuing vendor support tickets."
Release change control. "Neither party will apply a major release to a production system without 10 business days’ notice to the other parties and a joint regression test of the interfaces listed in the field mapping document."
Escalation. "If no party has accepted ownership within the escalation window, the parties will convene a joint call at their own cost. No party will decline to attend on the basis that the defect has not been proven to be theirs."
What should you instrument so the argument is about evidence?
Six things, all cheap at build time and all impossible to add retrospectively during an incident. A partner who has these can end most disputes in ten minutes with a screenshot.
Do not skip the daily reconciliation count on the grounds that errors are already alerted. The failure that hurts is not the one that throws an error, it is the order that was never picked up in the first place, and only a count of both sides finds that.
A shared correlation identifier on every transaction, written on both sides.
A daily reconciliation count: orders created on the storefront versus orders posted in the ERP, with the difference alerted rather than reported.
Queue depth and age of the oldest unprocessed item, with a threshold that pages someone.
Retained request and response payloads for a defined window, with a documented retention period so the privacy conversation happens once.
A single status channel that all three parties are in, created before go-live and used for nothing else.
A record of every release applied to either system, with dates, so "it started on Tuesday" becomes a checkable statement.
What happens to the boundary at an ERP upgrade?
This is where a working support model quietly stops working. An ERP major release changes behaviour under an integration that nobody re-tested, and the first evidence is a customer complaint rather than an alert.
Acumatica’s programme structure helps and does not solve it. Marketplace applications carry an Always Current commitment, which Acumatica’s community describes as re-certification within 90 days of a major release, and the Fulfilled by Acumatica programme describes monthly updates and semi-annual upgrades. That covers the certified application. It does not cover the field mappings you built, the customizations around them, or the storefront behaviour that depends on both.
So put the regression test in the calendar rather than in the contract only. A short scripted pass over the interfaces in the field mapping document, run in a sandbox before every major release on either side, is the cheapest insurance in this whole arrangement. Name who runs it and when, because a test that belongs to everyone belongs to nobody.
Checked against: Acumatica community 34096: Always Current commitment with re-certification within 90 days of a major release, as part of ADN Level 2
Common questions
- Who is responsible when a third-party connector from the Acumatica Marketplace fails?
- The connector vendor owns the defect in their code, and someone in your arrangement has to own the vendor relationship during the incident. Make that the party who recommended or installed the component, and write it down, because the alternative is a client raising their own ticket into a support queue that does not know their configuration. Note that neither Acumatica nor the commerce platform will triage an integration for you: Shopify directs users to the third-party developer, and Acumatica’s support runs through the partner.
- What if the client bought the connector directly and we were not told?
- It happens more often since Fulfilled by Acumatica applications sit on Acumatica’s own price list and can be bundled with the ERP purchase, so a connector decision can be made in a licensing conversation you were not part of. The practical protection is a clause in your support agreement requiring notice before any Marketplace application is added to production, plus a right to re-test the interfaces at the client’s cost. Ask for it at signing, when it costs nothing.
- What response time is reasonable for an integration outage?
- Set it by business impact rather than by severity labels. Orders not reaching the ERP is a revenue-stopping fault and deserves a same-business-day response with evidence, not a fix. A price display defect affecting one customer is next business day. What matters more than the number is that the response window applies to producing evidence rather than to producing a fix, because a fix time nobody can commit to gets ignored and an evidence time can actually be met.
- Should the VAR or the agency operate the integration?
- Whoever operates the system the integration runs inside. On a native Acumatica connector build the integration runs inside Acumatica, so the VAR operates it and should be resourced and paid to do so. On a middleware build the middleware owner operates it. The failure mode to avoid is a native connector configured by an agency who then has no ERP access to support it, because that arrangement produces an incident nobody can investigate.
- How do we handle an incident when nobody will accept ownership?
- That is what the escalation clause is for: if no party has accepted ownership within the agreed window, all parties join a call at their own cost and nobody may decline on the grounds that the fault has not been proven to be theirs. Run it with the shared correlation identifier and the daily reconciliation count on screen. Almost every stand-off ends within ten minutes once both sides are looking at the same transaction record.
- Does a Fulfilled by Acumatica badge change who supports the connector?
- It changes who bills for it, not who investigates your integration. Fulfilled by Acumatica means the application is sold on Acumatica’s price list and the vendor has committed to the Always Current update cadence. The vendor still supports their own software, and nobody in that arrangement is responsible for the field mappings and configuration you built around it. Keep the triage table and the correlation identifier regardless of what badge the connector carries.
Last updated 2026-08-20. Facts on this page last checked against source 2026-08-20.