What Are Market Development Funds (MDF)?
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
A software vendor wants its partners to run campaigns, host events and build pipeline. The partners want somebody else to share the bill. Market development funds, usually shortened to MDF, are the vendor's answer: a budget it sets aside to co-fund approved marketing activity that partners carry out.
The idea is simple. The execution is where programs succeed or fail. This article defines MDF, separates it from co-op funds, walks through the request-to-reimbursement cycle, and covers eligible activities, how vendors decide who gets money, the accounting treatment, ROI measurement and the failure modes that waste both sides' time.
What MDF Is
MDF is money a vendor provides to a channel partner to help pay for marketing or selling activity that promotes the vendor's products. It is a form of cost sharing. The partner runs the activity, pays the bills, and the vendor reimburses all or part of the eligible cost once the partner proves the work happened.
Two points shape everything else.
The money stays the vendor's until it's paid out. DigiCert's partner MDF guide says plainly that MDF funds belong to DigiCert and that it reimburses approved activities at its sole discretion. That is typical. A partner doesn't own an MDF balance in the way it owns a bank balance.
The money buys something the vendor wants. MDF isn't a gift. The vendor expects measurable pipeline, awareness or capability in return, which is why almost every program ties spending to deal registrations, lead lists or campaign reports. You'll see the same logic in partner-led growth, where the partner's own marketing becomes part of the vendor's go-to-market engine.
MDF vs. Co-Op Funds
People use the terms loosely, and some vendors use "MDF" for both. The cleaner distinction, as a general convention rather than a standard, looks like this.
| Co-op funds | MDF | |
|---|---|---|
| How the money arises | Accrues automatically, often as a percentage of what the partner buys or sells | Allocated at the vendor's discretion, often per proposal |
| Who decides the amount | A formula in the program rules | The vendor's channel or partner marketing team |
| What it rewards | Past performance, so it's earned | Expected performance, so it's an investment |
| Typical purpose | Steady, ongoing promotion | Targeted campaigns that serve a vendor priority |
| Planning pattern | Partner draws down what it has accrued | Partner submits a request and waits for approval |
The line blurs in real programs. Oracle's documentation for its partner relationship management software defines three MDF fund types: fixed (a specific amount allocated), accrual (money allocated based on partner performance, such as units sold or a percentage of revenue) and mixed (a fixed starting amount plus an accrual element). So an "accrual MDF" is a real thing, and it looks a lot like co-op.
HubSpot's 2025 tiers and benefits guide offers a useful example of the hybrid. It says MDF would be available "in an earned model" on a rolling basis through 2025, open to partners of any tier or location but held in general for Platinum, Diamond and Elite partners, with Untiered and Gold partners considered case by case. The practical rule: read the program document, not the label. If funds accrue automatically, treat them as co-op. If you must apply and be approved, treat them as MDF.
The MDF Cycle: Proposal to Reimbursement
Programs differ in detail but follow one skeleton. DigiCert and GitLab both publish theirs, and they line up closely.
| Step | What happens | What goes wrong here |
|---|---|---|
| 1. Plan | Partner and vendor agree a marketing plan, usually with a partner marketing manager | No shared plan, so requests feel random |
| 2. Request | Partner submits a proposal: activity, dates, cost, expected results | Submitted after the money is spent |
| 3. Pre-approval | Vendor approves, trims or declines, in writing | Partner starts before approval |
| 4. Execution | Partner runs the activity and pays its own invoices | Activity drifts from what was approved |
| 5. Proof of performance (POP) | Partner submits invoices and evidence | Weak or missing evidence |
| 6. Reimbursement | Vendor reviews the claim and pays the approved amount | Late claim, so funds are forfeited |
Timing is strict. DigiCert asks partners to submit the request form one month before the quarter in which the activity is planned, and says it aims to pay approved claims within 60 days of submission. GitLab asks for requests at least 10 business days before the activity starts, says it aims to respond within 5 business days, and requires a claim within 30 calendar days of the activity ending. Both are as published; check the current versions.
Pre-approval is not optional. GitLab's MDF handbook page states that any activity that doesn't follow its process and have the right approvals isn't eligible for reimbursement, and that because the program is proposal-based it doesn't guarantee every partner will receive MDF.
Funds expire. DigiCert says unused allocations can't be carried from quarter to quarter and must be used in the timeframe in the approved request. GitLab says partners must complete the activity within the quarter it was approved for, and that unclaimed funds may be forfeited if the claim misses its window.
Proof of Performance
POP is the evidence that the approved activity actually happened and did what it was supposed to. Vendors ask for it because the funds are reimbursement, not an advance.
DigiCert's guide asks for an invoice or receipt that names the activity, dates and currency, an image of the marketing or sales deliverable, and an ROI report showing results such as booth traffic, event attendance, email open rates and deal registrations. It adds that a partner-generated invoice alone is not enough: copies of the vendor invoices or receipts that show the expense was incurred are required.
GitLab's POP depends on the activity type. A partner-generated invoice plus at least one proof item, such as an invitation, collateral, a photo of the booth, or a URL to a recorded webinar. For several activity types a lead or attendee list is required, with company, contact, title, email and phone. GitLab also says it will pass those leads back to the partner, so the partner can register resulting deals against the MDF request. That ties MDF to deal registration, which is how vendors connect spend to outcomes.
Typical Eligible and Ineligible Activities
Eligible activities cluster around demand generation. Based on what DigiCert and GitLab publish:
| Usually eligible | Usually ineligible |
|---|---|
| Sponsorships and booth fees at industry events | Discounting the vendor's products |
| Partner-hosted customer seminars and webinars | General customer appreciation or entertainment |
| Email and direct mail campaigns | Equipment for normal business operations |
| Co-branded advertising, social ads, paid search (sometimes with approval) | Alcohol, cash, charitable donations, travel (varies by program) |
| Content and collateral that features the vendor's brand | Materials that don't mention the vendor's products |
| Time-limited sales incentives for the partner's own staff (at DigiCert, pre-approved) | Activities promoting competing solutions |
Two patterns recur. First, the vendor's brand has to be visible: both DigiCert and GitLab require their logo on funded collateral. Second, MDF can't fund the partner's ordinary overhead. GitLab states MDF may not be used for capital expenses or the normal cost of doing business. Vendor-funded sales incentives for partner reps are a gray area handled differently by each program; the economics of those belong with margins, rebates and SPIFFs rather than MDF.
How Vendors Decide Who Gets Funded
Vendors don't hand MDF out evenly. Their published rules show the filters.
- Program standing. HubSpot concentrates MDF in its higher tiers. DigiCert requires partners to be in good standing with no past-due invoices.
- Readiness. DigiCert requires a documented marketing plan and up-to-date partner training. GitLab requires a "marketing ready" partner with an approved business plan, a focus-account list, a person to manage leads passed to the partner and regular calls with the vendor's channel marketing manager.
- Expected return. DigiCert says funding is determined quarterly based on partner engagement, projected return on investment and fund availability.
- Cost-share rules. GitLab says it will cover up to 50% of an activity's total cost and sets a minimum request amount; that minimum is currently $1,000. Activities with multiple vendors don't get full funding.
If you're a partner, the lesson is to arrive with a plan, a target and a way of proving results. If you're a vendor, the same filters keep funds from landing on partners who can't convert them.
Accounting Treatment
For the vendor, MDF isn't automatically a marketing expense. Under ASC 606, consideration payable to a customer is generally presented as a reduction of revenue unless the vendor receives a distinct good or service in exchange. Where a channel partner is the vendor's customer (for example a reseller buying product), MDF paid to it can fall under that rule.
A BYU School of Accountancy article on cooperative digital marketing walks through the test. If the marketing service is distinct under ASC 606-10-25-19, meaning it benefits the seller and is separately identifiable from the customer's other promises, the payment is accounted for like other purchases from suppliers. The article adds two limits: any amount above the service's fair value reduces revenue, and if fair value can't be estimated, the whole payment does.
That has practical consequences. A vendor that wants MDF treated as expense needs evidence that it receives something distinct and can estimate its fair value, which is one more reason POP matters. Treatment depends on the facts and the contract, so finance teams should confirm it with their auditors rather than assume it.
Measuring MDF Return
Every vendor has a different yardstick, and public benchmarks for "good MDF ROI" are thin. Rather than quote a number, use a simple method.
- Define the outcome before approval. Opportunities created, deals registered, meetings booked or attendees, whichever the activity is meant to produce.
- Tag the activity. Give each approved request an ID and carry it through lead lists and deal registrations, as GitLab's lead-return flow does.
- Compare against cost. Divide the vendor's spend by pipeline created and by closed revenue, then compare with the vendor's other channels and its customer acquisition cost.
- Look at the partner, not just the campaign. A partner whose MDF campaigns rarely produce registered deals is telling you something.
- Allow for sales cycles. Enterprise deals can close long after the claim is paid, so track cohorts by quarter.
Tie results back into partner tiering so strong performers earn more access. The channel sales model article shows where this sits among the other channel levers.
Common Failure Modes
Unused funds. Allocations that expire at quarter-end, claims filed outside the window, or plans that never turn into requests. Vendors lose goodwill and partners lose money they'd have used.
Poor proof. Missing invoices, a partner-generated invoice with nothing behind it, no lead list, no logo on the collateral. These are the usual reasons a claim bounces, and DigiCert and GitLab both spell out what they need.
Starting before approval. The most common self-inflicted wound. If the expense came before the approval, it's usually ineligible.
Audit and fraud exposure. DigiCert reserves the right to audit and verify claims, request more documentation and bar non-compliant partners from MDF for a period. GitLab's terms require partners to conduct business ethically and legally and prohibit anything of value offered improperly to influence people. Inflated invoices, recycled evidence and double claims across vendors are the fraud patterns programs exist to catch. Multi-vendor events are a common place for double funding, which is why GitLab limits funding when several vendors are involved.
Weak linkage to outcomes. If funded activity isn't tied to registered deals, the vendor can't tell what worked, and the program turns into a sponsorship budget.
Channel friction. MDF can feed disputes when a campaign generates leads that both direct sales and a partner pursue. Rules of engagement matter here, and the channel partner program article covers how programs formalize them.
Key Facts: Market Development Funds
- MDF is vendor money that co-funds partner marketing; DigiCert states that MDF funds belong to the vendor and are reimbursed for approved activities at its discretion (DigiCert).
- Oracle's partner management documentation defines three MDF fund types: fixed, accrual and mixed (Oracle).
- GitLab requires a pre-approved request, and a claim within 30 calendar days of the activity ending (GitLab Handbook).
- GitLab says it covers up to 50% of an activity's total cost, with a current $1,000 minimum request (GitLab Handbook).
- HubSpot's 2025 guide describes MDF as an earned model, generally held for Platinum, Diamond and Elite partners (HubSpot).
- Under ASC 606, payments to a customer reduce revenue unless they buy a distinct service (BYU School of Accountancy).
Related Reading
