How Acumatica VARs Should Evaluate a White-Label Development Partner

Published August 2026 by the Envinse Technical Team · 10 minute read · For Acumatica VARs and resellers.

The short version

  • Start with the non-compete question, not the rate card. A cheap partner who later sells to your client costs more than any hourly difference.
  • Verify certification independently. Gold Certified status is checkable in the Acumatica partner directory, not just on a website.
  • Ask for delivery evidence with numbers in it. Screens migrated, weeks to go-live, defects after handoff.
  • Get IP ownership, upgrade support and response times in the agreement before the first engagement, not after the first dispute.
  • Test the handoff. If your engineers cannot extend the build without calling the partner, you did not buy capacity, you bought a dependency.

Choosing a white-label Acumatica development partner is not a procurement exercise. You are not buying hours. You are lending someone your brand, your delivery reputation and, indirectly, your client list. That changes what you should be asking about and in what order.

Most VARs run this evaluation the way they would evaluate any subcontractor: rates, availability, a portfolio review, a reference call. That sequence puts the least important variable first. The rate difference between two competent Acumatica development shops is rarely more than twenty percent. The difference between a partner who protects your client relationship and one who quietly builds a direct book of business from your accounts is your entire business. So evaluate in the order that reflects the real risk.

Step 1: Establish whether the partner competes with the channel

This is the first question and it is not rude to ask it directly. A firm that sells Acumatica implementations directly to end customers and also offers white-label development to VARs has a structural conflict. Every client you introduce becomes a prospect in their pipeline, whether or not anyone intends it that way. Some firms manage that conflict well. Many do not.

What to ask

  • Do you sell Acumatica directly to end customers, and what share of your revenue comes from direct work?
  • Will you sign a non-solicitation clause covering our clients and our staff, and for how long after the engagement ends?
  • Do you ever invoice the end customer directly, in any scenario?
  • Will our client names appear in your marketing, case studies or references, and under what approval process?
  • If our client contacts you directly after the project, what happens?

The answers you want are specific and contractual. "We would never do that" is a sentiment. A non-solicitation clause with a defined term is a commitment. Ask to see the clause language before you disclose a single client name. A partner structured for the channel will have it ready, because every VAR asks.

What a clean answer looks like

A channel-focused partner will tell you plainly that they hold no commercial relationship with the end customer at any stage, that the NDA is mutual and signed before scope is discussed, and that non-solicitation covers both your clients and your employees. Envinse publishes its full terms on the white-label Acumatica development page precisely so partners can hold the agreement up against them before a first conversation.

Step 2: Verify certification rather than accepting it

Acumatica's partner tiers run from Authorized through Certified, Silver and Gold. Gold requires annual recertification and reflects credentials held across the team in functional, technical and industry tracks. It is a meaningful signal, but it is also a claim that appears on a lot of websites without anything behind it.

Check it yourself in the Acumatica partner directory rather than taking the badge at face value. Then go a layer deeper: certification tiers are earned at company level, but code is written by individuals. Ask which specific engineers would be assigned to your work and what certifications those individuals hold. A Gold-tier company that staffs your project with its most junior available developer has met the letter of the claim and none of the intent.

Platform focus is worth more than headcount

A firm running twelve ERP platforms with Acumatica as one line item will carry less platform-specific depth than a smaller shop where Acumatica is the only product. Release cadence familiarity matters here. When a version like 2026 R2 deprecates Classic UI, a partner who tracks the roadmap has already audited their delivery patterns against it. A generalist finds out when a client's screen breaks.

Step 3: Ask for delivery evidence that contains numbers

Portfolios are easy to assemble and hard to verify. What separates real delivery history from a capabilities deck is whether the partner can attach measurable outcomes to their work.

The evidence worth requesting

  • Scope in units. How many screens, how many endpoints, how many entities in the integration.
  • Elapsed time. Weeks from kickoff to go-live, not "a few months".
  • Estimate accuracy. How often fixed-price quotes held, and what happened when they did not.
  • Defects after handoff. How many issues surfaced in the first 30 days, and who paid to fix them.
  • Upgrade survival. How their code behaved across the last two Acumatica releases.
  • Capacity supplied. Developer hours or named specialists provided per month on retainer engagements.

Expect the client names to be redacted. That is correct behaviour for a white-label partner, and a firm that freely names other VARs' clients to win your business will freely name yours to win the next one. What you should still get is the shape of the engagement and the numbers attached to it. If a partner cannot produce a single anonymized case with metrics in it, they either do not measure their delivery or they do not have much of it.

Reference calls with other VARs, not with end clients

Ask to speak to another VAR the partner delivers for. That conversation tells you things a client reference never will: whether quotes held, whether the partner stayed invisible on client calls, how scope changes were handled mid-build, and whether the VAR would route their next project to them. If the partner cannot arrange a single VAR reference, ask why.

Step 4: Nail down the commercial terms before the first project

VARs routinely leave these vague on engagement one because the relationship starts well. The cost of that shows up later, usually at the worst moment, when a customization breaks after an upgrade and nobody agreed who pays.

Term What to require Why it matters
IP and source code Written confirmation that deliverables are work for hire and transfer to you or your client on final payment, with no retained license and no resale. You cannot support, extend or migrate code you do not own. This is the single most common gap.
Pre-built components Disclosure of any partner-owned tool or framework used in the build, with licensing agreed before the quote is issued. An undisclosed dependency turns your deliverable into a subscription your client did not agree to.
Upgrade support A commitment to build against published Acumatica coding standards, plus a defined remediation path if their code breaks on a standard platform update. A blanket "it will never break" warranty is not credible. A remediation obligation is.
Response times At least two tiers in writing: new briefs and standard requests inside one business day, production severity 1 measured in hours. Your client's deadlines do not flex. Neither should your partner's turnaround.
Scope changes A defined change process with a written price impact before work continues. Mid-build scope drift is where fixed-price engagements quietly become time and materials.
Branding Your naming conventions in code headers, customization project names, documentation and release notes. Renaming a customization package after delivery is avoidable rework and a disclosure risk.

Step 5: Test the operating model, not just the output

Capacity you cannot integrate into your delivery process is not capacity. Before the first project, work out how the partner actually plugs in.

Will they work inside your project management tool or insist on theirs? Will they attend your stand-ups? Do they write to your documentation template or their own? Who does your project manager message at 4pm when a client escalates? These sound like small operational details, and they are exactly what determines whether the second engagement happens.

There is a meaningful difference between a partner who takes a specification and returns a build, and one who embeds engineers into your team and works under your direction. Both are valid. They suit different situations, and the choice has cost and control implications worth understanding before you commit. We covered that trade-off in detail in white-label development vs staff augmentation for Acumatica VARs.

Step 6: Test the handoff

The handoff is the part most VARs never evaluate and the part that determines whether you built capacity or bought a dependency. A good handoff includes production-ready code, a deployment guide, a customization inventory, upgrade notes and a walkthrough session with your engineers. The test is simple: after handoff, can your team make a small change to the build without calling the partner?

Ask to see a sample documentation package from a previous engagement, redacted. If the partner hesitates, or if what arrives is a two-page summary, you now know what your support desk will be working from at 9am on a Monday when the client calls.

Red flags worth walking away from

  • Reluctance to put non-solicitation in writing. Enthusiasm about your client list is not a substitute.
  • Named client references from other VARs' accounts. If they do it to them, they will do it to you.
  • No fixed price after technical review. A partner who will only work time and materials on a well-defined scope is transferring their estimation risk to you.
  • Vague IP language. "You get the code" without ownership terms in the agreement is not ownership.
  • No named engineers. If you cannot find out who is assigned, you cannot assess whether the certification claim applies to your project.
  • Documentation as an add-on line item. Documentation is part of the deliverable, not an upsell.
  • Direct contact with your client before you authorised it. One instance is a pattern.

A scoring approach that keeps the decision honest

Score each candidate partner across six areas and weight them by the damage a failure would cause. Channel conflict protection carries the heaviest weight, because it is the only category where a failure is unrecoverable. Platform depth and delivery evidence come next, since they predict whether the work lands. Commercial terms, operating fit and handoff quality follow, because those can be renegotiated after a first engagement if the rest holds up.

Run the scoring before you look at rates. Then look at rates, and see whether the difference is large enough to outweigh anything the scoring surfaced. In most evaluations it is not.

Where Envinse fits

Envinse is a US-based Acumatica Gold Certified Service Provider that works only inside the channel. We do not sell Acumatica directly to end customers, we do not invoice your clients, and non-solicitation covering your clients and your staff is standard in the agreement. Deliverables carry your branding, source code transfers to you, and every build ships with the documentation package your team needs to support it without us. Engagement models, contract terms and VAR case studies are on the Acumatica development for VARs page.

If you are running this evaluation now and want a partner to score against the framework above, send us the scope. We respond within 24 hours, and we will share the NDA and non-solicitation language before you disclose a client name.

Schedule a Partnership Intro - We Respond Within 24 Hours

Email: acumatica@envinse.com · Phone: 737-377-3839

Schedule a Partnership Intro →