Specialist software procurement for IT resellers and MSPs: sourcing what you don't stock

When a customer asks an IT reseller or MSP for software it doesn’t stock, such as GitLab, JFrog or a niche developer tool, the safest way to say yes is to source it through an authorised partner of that vendor, under an agreement that keeps you as the customer’s supplier. You get a valid, supportable licence and a margin. The customer gets one supplier. The vendor gets a properly registered end user. The risks lie in grey-market licences, unclear customer ownership and missed renewals, and each can be managed.

This guide covers how that works in practice for South African and African resellers.

Authorised channels vs the grey market

What “authorised” means

An authorised channel is one the vendor recognises: the vendor itself, its distributors, or partners it has appointed. Some examples of how vendors define this:

• GitLab. GitLab’s channel programme says Open-track resale partners transact through GitLab authorised distributors active in their region, and deal registration is available to partners once their staff complete the required training.
• JFrog. JFrog’s channel programme has Co-Sell and Reseller tracks, with deal registration and enablement in JFrog’s Partner Center and subscription and renewal management in a partner portal.
• Microsoft. Cloud Solution Provider (CSP) orders require the customer to accept the Microsoft Customer Agreement before the order is placed. Microsoft’s documentation says indirect resellers cannot attest on the customer’s behalf and must work with their indirect provider.

Why the grey market is a false economy

Licences bought outside authorised channels, for example personal card purchases resold to a business, keys from marketplaces or licences issued to a different legal entity, can cause problems such as:

• Invalid entitlement. Many licences are issued to a named customer. GitLab’s quotes, for example, carry a Sold To address that also defines where the licence may be used.
• No vendor support for the reseller relationship, and sometimes not for the customer either.
• Audit exposure. GitLab’s licensing policy includes a right to audit compliance under a written agreement. Other vendors have similar terms.
• Renewal surprises when the vendor will not renew a licence bought the wrong way.

Your customer’s IT and procurement teams increasingly ask for proof of authorised supply, such as a vendor authorisation letter. If you cannot provide it, you may lose the deal anyway.

Deal registration: protecting your opportunity

Deal registration tells the vendor that a particular opportunity belongs to a particular partner. It typically gives the registering partner pricing protection and reduces the chance of a competing partner being quoted on the same deal. The rules differ by vendor, so ask your procurement partner:

1. Who registers the deal? Usually the authorised partner registers it, naming the end customer.
2. What information is needed? Normally the customer’s legal name, address, contact and the expected products and quantities.
3. How long does it last and what happens if the deal slips?
4. Is the registration tied to the partner, so you keep the benefit? Agree this in writing.

End-user registration: why the vendor needs your customer’s details

Most enterprise software vendors need to know who the end user is. This is normal and is not a sign that anyone is trying to take your customer. Typical requirements include:

• The legal entity and address of the customer on the quote or order (GitLab’s Sold To address is an example).
• Agreement acceptance by the customer, such as the Microsoft Customer Agreement for CSP, or the vendor’s subscription terms.
• Technical contacts for licence delivery, activation and support.

What you should expect from a procurement partner is a clear statement of exactly which customer details go to the vendor, why, and who will contact the customer (if anyone). The customer’s personal information, such as contact names and emails, is covered by POPIA, so the partner should handle it as an operator under a written agreement.

NDAs and non-circumvention

Before you share customer details, put an agreement in place. Common elements are:

• Confidentiality of customer identity, pricing and deal information.
• Non-solicitation or non-circumvention: the procurement partner will not approach or sell directly to your customer.
• Exceptions for contact that the vendor requires, such as licence delivery or vendor support.
• Duration that covers renewals, not just the first sale.

The exact wording, scope and enforceability of these clauses should be reviewed by your own legal adviser. We do not offer legal advice, and courts look at restraint-type clauses on their own facts.

Renewals and true-ups

Most of the lifetime value of a software deal is in renewals, and most lost renewals are simply missed dates.

• Track every renewal date and set reminders at 90, 60 and 30 days.
• Understand mid-term changes. GitLab, for example, uses quarterly reconciliation by default for newer subscriptions: users added during a quarter are billed for the remaining quarters of the term.
• Agree who sends the reminders and who talks to the customer. In a reseller-confidential model, the partner reminds you and you talk to the customer.
• Re-quote currency at renewal. Exchange rates move, so quotes should state their rate, date and validity.

Margin: how the commercials usually work

In a typical reseller arrangement, the procurement partner sells to you at an agreed price and you set your own price to the customer. Things to clarify:

• Is your buy price fixed or a discount off list? For example, GitLab Premium has a published list price, but Ultimate is custom-priced and quoted per deal.
• Which currency? USD or ZAR (your choice). Match the currency to how you will invoice your customer to avoid exchange-rate mismatch.
• Payment terms. Vendors often bill annually in advance. Make sure your terms with the customer and your terms with the partner line up.
• Services. If the customer also needs implementation, decide whether you deliver it, the partner delivers it under your brand, or the customer contracts separately.

A checklist for choosing a procurement partner

1. Is the partner authorised by each vendor you need? Ask for evidence, such as a public partner listing or authorisation letter.
2. Will it sign an NDA and non-circumvention agreement before you share customer details?
3. Will it give you confidential quotes you can mark up and present as your own?
4. Does it register deals in a way that protects you?
5. Will it track renewals and remind you, without contacting your customer?
6. Can it invoice locally with VAT, in USD or ZAR (your choice)?
7. Does it understand the products well enough to answer technical licensing questions?

How the Spreeze procurement desk works

You keep the customer. We handle the licensing. Spreeze is an authorised GitLab partner (Open track) and a JFrog partner, and supplies Microsoft products through authorised Microsoft channels, along with other specialist software through authorised channels. Our procurement desk gives resellers and MSPs confidential quotes you can mark up, an NDA before you share customer details if you prefer, and renewal reminders at 90, 60 and 30 days that go to you, not your customer. See the software we source or send us a request.

For your customer’s side of the purchase, our guide to buying foreign software from South Africa explains invoices, VAT and currency. For GitLab specifically, see how GitLab pricing works in South Africa.

GITLAB is a trademark of GitLab Inc. JFrog is a trademark of JFrog Ltd. Microsoft is a trademark of the Microsoft group of companies. Other names are trademarks of their respective owners.