Start from the assumption that you keep it
Most commerce projects attached to an ERP deal are yours to keep, and any framework that does not say so first is a referral funnel with a table in it. A large share of them are a native connector, a themed storefront, a catalogue data exercise and a fortnight of order flow testing. You own the ERP relationship, you know the item master, you know how their orders post, and you know which of their processes are held together with a spreadsheet. A specialist arriving cold spends three weeks learning what you already know.
On that project you are the better provider, and bringing anyone else in dilutes your margin and adds a coordination cost in exchange for nothing. The client also gets a worse outcome, because the ERP context that makes the project work is in your head and not in a requirements document.
The decision is only live when the project has something in it you have not done before and cannot afford to learn on. That is a much smaller set than the market wants you to believe, and it is the set the rest of this page is about.
What does each option actually cost you?
Four axes decide this, and partners consistently weight the first one too heavily and the fourth one not enough. Read the table down the columns first to see each option whole, then across the rows to compare.
On the margin row, we are describing shape rather than figures. Referral fees in this channel are typically a one-time percentage of first-year fees, subcontract margin is a markup on delivered hours that recurs for as long as the work runs, and both vary enough between firms that a published number would be misleading. Ask two peers what they see rather than trusting any figure on a webpage, including this one.
| Criterion | Keep it | Subcontract it | Refer it |
|---|---|---|---|
| Margin | Highest. Full services margin, and the utilisation stays inside your own team. | A markup on delivered hours, recurring while the work runs. Real money, and smaller than partners expect once management time is counted. | A one-time fee, usually a percentage of first-year fees. Treat it as a rounding error rather than a revenue line. |
| Cash flow and who invoices | You invoice, you collect, you carry the work in progress. | You invoice the client and pay the subcontractor, so you carry the float and the bad debt risk on someone else’s labour. | They invoice. You carry nothing. |
| Delivery risk | Yours, and bounded by what you already know how to build. | Yours in full. A subcontractor’s over-run is your over-run and your client never hears their name. | Theirs. This is the entire point of referring. |
| Warranty and defect liability | Yours. Price a maintenance period into the quote or you have sold a warranty for free. | Yours to the client, theirs to you, and the gap between those two contracts is where the money is lost. Match the terms or do not sign. | Theirs, provided the client contracted with them directly. Check that this is actually true before you rely on it. |
| Relationship exposure at renewalThis is the row that decides it in practice, and it is the row least often on the spreadsheet. | You are the only supplier. A good outcome is entirely yours and so is a bad one. | Highest exposure of the three. The client sees one supplier, so a subcontractor failure arrives at your ERP renewal wearing your name. | Lower, and not zero. You recommended them, and clients remember recommendations. |
| What happens when it slips | You reprioritise your own people, which costs you an ERP deliverable somewhere else. | You manage someone else’s schedule with none of the authority, and you absorb the difference. | You are the client’s ally in a difficult conversation rather than a party to it. That position has value. |
| What you learn | Everything, at your own expense, on a live client. | A useful amount, if you insist on shared code review and joint design sessions. Write that into the subcontract or it will not happen. | Almost nothing. |
Which column usually decides it?
Relationship exposure. The asset in this business is the ERP renewal and the position it gives you inside the account, and every other number on the table is small next to it.
That reframes the subcontract option in a way partners often resist. Subcontracting looks like the commercially clever middle path, because you keep the client and take a margin on someone else’s work. What you have actually done is accept full delivery risk on work you cannot supervise in detail, in a discipline where you cannot tell a good week from a bad one until the demo. If the subcontractor misses, the client does not know they exist. They know you missed.
So subcontract when you can genuinely supervise: you have someone who can read the code, you have run this shape of build before, and the failure mode is a schedule slip rather than an architecture you cannot assess. Refer when the risk is architectural, because the thing you cannot supervise is exactly the thing that will go wrong.
One more consideration that is not on the table. Referring well is a relationship asset in its own right. A partner who says "this one is outside what we do, here is who does it, and I will stay in the room" is trusted the next time they say "this one is ours". Partners who keep everything eventually get one project badly wrong, and the client’s conclusion is not that the project was hard.
A four-question test you can run in a meeting
Answer these about the specific project rather than about your firm in general. Two or more answers on the right side means the keep option is doing more work than it can carry.
The fourth question is the one people skip and the one that predicts over-runs best. Novel work expands. Work you have done twice does not.
Does the price on the storefront have to be calculated per request rather than copied from a stored field? If yes, you are building and operating a pricing service with a cache and a failure behaviour, which is a practice rather than a project.
Has a named customer mandated punchout, EDI or a hosted catalogue with a date attached? If yes, the testing calendar belongs to someone else’s procurement team and a missed date has a revenue number on it.
Would a three-month slip on this project put the ERP renewal at risk? If yes, the relationship exposure column has already answered the question.
Have you delivered this exact shape of work before, with the same platform and the same pricing model? If not, price the learning honestly and decide whether the client should pay for it.
When is referring the wrong answer?
When the project is smaller than the specialist’s minimum engagement. A client with a 900 item catalogue, list pricing, one warehouse and card payment does not need an architecture practice, and referring them produces a quote that frightens them out of the project entirely. Keep it, scope it down, and switch on the native connector.
When the requirement is unclear rather than hard. Referring an ambiguous requirement converts your discovery problem into someone else’s discovery invoice, and the client pays twice. Do the discovery, then decide.
When the client’s real constraint is budget rather than capability. A referral does not make a project cheaper. If the honest answer is that the client cannot afford what they are describing, say that, and offer the version they can afford. That conversation keeps more accounts than any referral network does.
And when you are referring to avoid a conversation. If you are handing off because you do not want to tell the client their platform choice was wrong, the referral will not spare you that conversation. It will just delay it until someone else has been paid to have it.
Common questions
- What percentage of commerce projects should a VAR keep?
- Most of them, and we are not going to invent a percentage. The test is structural rather than statistical: if the price on the page can be copied from a stored ERP field, the availability figure is honest at company or single-warehouse level, and no customer has mandated punchout or EDI, the work is inside a competent ERP partner’s reach. Each of those three turning the other way moves the project toward middleware and toward a specialist.
- Is subcontracting safer than referring?
- It is more profitable and less safe. Subcontracting keeps the client relationship and the margin, and it also keeps the full delivery risk, because the client sees one supplier and a subcontractor’s over-run arrives at your renewal wearing your name. Subcontract when you can supervise the work in detail and the likely failure is a schedule slip. Refer when the likely failure is architectural, because that is precisely what you cannot supervise.
- What referral fee is normal in this channel?
- It is normally a one-time percentage of first-year fees rather than a recurring share, and the range varies enough between firms that publishing a number would mislead you. We know figures internally and they are not ours to publish. Ask two peers in your own channel what they see, and treat the fee as a courtesy rather than as a revenue line, because a referral you took for the fee will be a referral you regret.
- How do I keep the client relationship if I subcontract?
- Draw the boundary by system rather than by task, before the client meets anyone. You own everything inside Acumatica or Cin7, including item master, pricing configuration, order types and workflow, and the subcontractor owns the storefront and the integration and raises ERP requests through you. Put that in the statement of work with a named escalation contact per system, and agree in advance what happens if the client asks the subcontractor for ERP work.
- What should be in a subcontract agreement that usually is not?
- Matched warranty terms, first. If you owe the client 12 months on defects and the subcontractor owes you 90 days, you have bought nine months of free warranty. Then a code and credentials escrow so you can take over if the relationship ends, a non-solicit that runs both ways, a named technical lead who cannot be swapped without notice, and a clause requiring joint design review before build so you find out about an architecture you dislike while it is still cheap.
- Can I refer the hard part and keep the rest?
- Often yes, and it is underused. A common split is that the specialist builds and operates the pricing or punchout layer while you deliver the storefront, the catalogue and the ERP configuration. It keeps most of the revenue and most of the client contact with you, and it moves only the piece with the architectural risk. It works when the interface between the two is defined early and in writing, and it fails when the split is agreed verbally and discovered in integration testing.
Last updated 2026-08-20. Facts on this page last checked against source 2026-08-20.