¿Qué son los fondos de desarrollo de mercado (MDF)?
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
Un vendor de software quiere que sus socios realicen campañas, organicen eventos y construyan pipeline. Los socios quieren que alguien más comparta la cuenta. Los fondos de desarrollo de mercado, que suelen abreviarse como MDF, son la respuesta del vendor: un presupuesto que reserva para cofinanciar las actividades de marketing aprobadas que ejecutan los socios.
La idea es sencilla. La ejecución es donde los programas triunfan o fracasan. Este artículo define los MDF, los distingue de los fondos co-op, recorre el ciclo que va de la solicitud al reembolso y aborda las actividades elegibles, cómo deciden los vendors quién recibe dinero, el tratamiento contable, la medición del ROI y los modos de fallo que hacen perder tiempo a ambas partes.
Qué son los MDF
Los MDF son dinero que un vendor entrega a un socio de canal para ayudar a pagar actividades de marketing o de venta que promueven los productos del vendor. Es una forma de reparto de costos. El socio ejecuta la actividad, paga las facturas y el vendor reembolsa la totalidad o una parte del costo elegible una vez que el socio demuestra que el trabajo se realizó.
Dos puntos condicionan todo lo demás.
El dinero sigue siendo del vendor hasta que se paga. La guía de MDF para socios de DigiCert dice con claridad que los fondos MDF pertenecen a DigiCert y que reembolsa las actividades aprobadas a su entera discreción. Es lo habitual. Un socio no es dueño de un saldo de MDF como lo es de un saldo bancario.
El dinero compra algo que el vendor quiere. Los MDF no son un regalo. El vendor espera a cambio pipeline, visibilidad o capacidades medibles, y por eso casi todos los programas vinculan el gasto con registros de oportunidades (deal registrations), listas de leads o informes de campaña. Verá la misma lógica en crecimiento liderado por socios, donde el marketing propio del socio pasa a formar parte del motor go-to-market del vendor.
MDF vs. fondos co-op
La gente usa los términos con laxitud, y algunos vendors emplean "MDF" para ambos. La distinción más clara, como convención general y no como estándar, es la siguiente.
| Fondos co-op | MDF | |
|---|---|---|
| Cómo se originan los fondos | Se acumulan automáticamente, a menudo como porcentaje de lo que el socio compra o vende | Se asignan a discreción del vendor, a menudo por propuesta |
| Quién decide el monto | Una fórmula de las reglas del programa | El equipo de canal o de marketing de socios del vendor |
| Qué premian | El desempeño pasado, por lo que se ganan | El desempeño esperado, por lo que son una inversión |
| Propósito típico | Promoción constante y continua | Campañas específicas que responden a una prioridad del vendor |
| Patrón de planificación | El socio consume lo que ha acumulado | El socio presenta una solicitud y espera la aprobación |
La línea se difumina en los programas reales. La documentación de Oracle para su software de gestión de relaciones con socios define tres tipos de fondos MDF: fijo (se asigna un monto específico), de acumulación (dinero asignado según el desempeño del socio, como unidades vendidas o un porcentaje de los ingresos) y mixto (un monto inicial fijo más un componente de acumulación). Así que un "MDF de acumulación" existe de verdad, y se parece mucho a los fondos co-op.
La guía de niveles y beneficios de HubSpot para 2025 ofrece un buen ejemplo del modelo híbrido. Indica que los MDF estarían disponibles "en un modelo de mérito" de forma continua durante 2025, abiertos a socios de cualquier nivel o ubicación, pero reservados en general para los socios Platinum, Diamond y Elite, mientras que los socios sin nivel y Gold se evalúan caso por caso. La regla práctica: lea el documento del programa, no la etiqueta. Si los fondos se acumulan automáticamente, trátelos como co-op. Si debe solicitarlos y obtener aprobación, trátelos como MDF.
El ciclo de los MDF: de la propuesta al reembolso
Los programas difieren en los detalles, pero siguen un mismo esqueleto. DigiCert y GitLab publican el suyo, y coinciden en gran medida.
| Paso | Qué ocurre | Qué suele fallar aquí |
|---|---|---|
| 1. Plan | El socio y el vendor acuerdan un plan de marketing, normalmente con un gerente de marketing de socios | No hay un plan compartido, así que las solicitudes parecen arbitrarias |
| 2. Solicitud | El socio presenta una propuesta: actividad, fechas, costo, resultados esperados | Se presenta después de gastar el dinero |
| 3. Preaprobación | El vendor aprueba, recorta o rechaza, por escrito | El socio empieza antes de la aprobación |
| 4. Ejecución | El socio realiza la actividad y paga sus propias facturas | La actividad se aparta de lo aprobado |
| 5. Prueba de desempeño (POP) | El socio presenta facturas y evidencias | Evidencia débil o ausente |
| 6. Reembolso | El vendor revisa la reclamación y paga el monto aprobado | Reclamación tardía, así que los fondos se pierden |
Los plazos son estrictos. DigiCert pide a los socios que presenten el formulario de solicitud un mes antes del trimestre en que se planea la actividad, y afirma que busca pagar las reclamaciones aprobadas en un plazo de 60 días desde su presentación. GitLab pide las solicitudes al menos 10 días hábiles antes de que comience la actividad, dice que busca responder en un plazo de 5 días hábiles y exige la reclamación dentro de los 30 días naturales posteriores al fin de la actividad. Ambos datos están tal como se publican; consulte las versiones vigentes.
La preaprobación no es opcional. La página del handbook de MDF de GitLab establece que cualquier actividad que no siga su proceso ni cuente con las aprobaciones correspondientes no es elegible para reembolso, y que, como el programa se basa en propuestas, no garantiza que todos los socios reciban MDF.
Los fondos caducan. DigiCert indica que las asignaciones no utilizadas no pueden trasladarse de un trimestre a otro y deben usarse en el plazo de la solicitud aprobada. GitLab indica que los socios deben completar la actividad dentro del trimestre para el que fue aprobada, y que los fondos no reclamados pueden perderse si la reclamación se presenta fuera de su ventana.
Prueba de desempeño
La POP es la evidencia de que la actividad aprobada realmente ocurrió y logró lo que debía. Los vendors la piden porque los fondos son un reembolso, no un adelanto.
La guía de DigiCert pide una factura o recibo que nombre la actividad, las fechas y la moneda, una imagen del material de marketing o de ventas entregado, y un informe de ROI que muestre resultados como tráfico en el stand, asistencia al evento, tasas de apertura de correos y registros de oportunidades. Añade que una factura generada por el propio socio no basta: se requieren copias de las facturas o recibos de los proveedores que demuestren que el gasto se realizó.
La POP de GitLab depende del tipo de actividad. Una factura generada por el socio más al menos un elemento de prueba, como una invitación, material de apoyo, una foto del stand o una URL de un webinar grabado. Para varios tipos de actividad se exige una lista de leads o de asistentes, con empresa, contacto, cargo, correo electrónico y teléfono. GitLab también indica que devolverá esos leads al socio, para que este pueda registrar las oportunidades resultantes contra la solicitud de MDF. Eso vincula los MDF con el registro de oportunidades (deal registration), que es como los vendors conectan el gasto con los resultados.
Actividades elegibles e inelegibles más habituales
Las actividades elegibles se concentran en la generación de demanda. Según lo que publican DigiCert y GitLab:
| Normalmente elegibles | Normalmente inelegibles |
|---|---|
| Patrocinios y tarifas de stand en eventos del sector | Descuentos sobre los productos del vendor |
| Seminarios y webinars para clientes organizados por el socio | Atenciones o entretenimiento general a clientes |
| Campañas de correo electrónico y de correo directo | Equipos para la operación normal del negocio |
| Publicidad en conjunto (co-branded), anuncios sociales, búsqueda de pago (a veces con aprobación) | Alcohol, efectivo, donaciones benéficas, viajes (varía según el programa) |
| Contenido y material de apoyo que destaque la marca del vendor | Materiales que no mencionan los productos del vendor |
| Incentivos de venta de duración limitada para el propio personal del socio (en DigiCert, preaprobados) | Actividades que promueven soluciones de la competencia |
Se repiten dos patrones. Primero, la marca del vendor debe ser visible: tanto DigiCert como GitLab exigen su logo en el material financiado. Segundo, los MDF no pueden financiar los gastos generales ordinarios del socio. GitLab establece que los MDF no pueden usarse para gastos de capital ni para el costo normal de hacer negocios. Los incentivos de venta financiados por el vendor para los representantes del socio son una zona gris que cada programa maneja de forma distinta; la economía de esos incentivos corresponde a los márgenes, los rebates y los SPIFF, más que a los MDF.
Cómo deciden los vendors a quién financiar
Los vendors no reparten los MDF de manera uniforme. Sus reglas publicadas muestran los filtros.
- Posición en el programa. HubSpot concentra los MDF en sus niveles superiores. DigiCert exige que los socios estén al corriente, sin facturas vencidas.
- Preparación. DigiCert exige un plan de marketing documentado y una capacitación del socio al día. GitLab exige un socio "listo para marketing", con un plan de negocio aprobado, una lista de cuentas prioritarias, una persona que gestione los leads que se le pasan al socio y llamadas periódicas con el gerente de marketing de canal del vendor.
- Retorno esperado. DigiCert indica que la financiación se determina trimestralmente según el compromiso del socio, el retorno de inversión proyectado y la disponibilidad de fondos.
- Reglas de reparto de costos. GitLab indica que cubrirá hasta el 50% del costo total de una actividad y fija un monto mínimo de solicitud; ese mínimo es actualmente de $1,000. Las actividades con varios vendors no reciben financiación completa.
Si usted es un socio, la lección es llegar con un plan, un objetivo y una forma de demostrar resultados. Si es un vendor, los mismos filtros evitan que los fondos terminen en socios que no pueden convertirlos en resultados.
Tratamiento contable
Para el vendor, los MDF no son automáticamente un gasto de marketing. Según la norma ASC 606, la contraprestación pagadera a un cliente se presenta en general como una reducción de los ingresos, a menos que el vendor reciba a cambio un bien o servicio distinto. Cuando un socio de canal es cliente del vendor (por ejemplo, un revendedor que compra producto), los MDF que se le pagan pueden quedar sujetos a esa regla.
Un artículo sobre marketing digital cooperativo de la BYU School of Accountancy explica la prueba. Si el servicio de marketing es distinto según la ASC 606-10-25-19, es decir, si beneficia al vendedor y es identificable por separado de las demás promesas del cliente, el pago se contabiliza como otras compras a proveedores. El artículo añade dos límites: cualquier monto que supere el valor razonable del servicio reduce los ingresos, y si no se puede estimar el valor razonable, la totalidad del pago reduce los ingresos.
Esto tiene consecuencias prácticas. Un vendor que quiera tratar los MDF como gasto necesita evidencia de que recibe algo distinto y de que puede estimar su valor razonable, otra razón más por la que importa la POP. El tratamiento depende de los hechos y del contrato, así que los equipos de finanzas deben confirmarlo con sus auditores en lugar de darlo por sentado.
Cómo medir el retorno de los MDF
Cada vendor tiene una vara de medir distinta, y los puntos de referencia públicos de un "buen ROI de MDF" son escasos. En lugar de citar una cifra, use un método sencillo.
- Defina el resultado antes de la aprobación. Oportunidades creadas, deals registrados, reuniones agendadas o asistentes, según lo que la actividad deba producir.
- Etiquete la actividad. Asigne a cada solicitud aprobada un ID y arrástrelo a través de las listas de leads y los registros de oportunidades, como hace el flujo de devolución de leads de GitLab.
- Compare con el costo. Divida el gasto del vendor entre el pipeline creado y entre los ingresos cerrados, y luego compárelo con los demás canales del vendor y con su costo de adquisición de clientes.
- Mire al socio, no solo a la campaña. Un socio cuyas campañas con MDF rara vez producen deals registrados le está diciendo algo.
- Tenga en cuenta los ciclos de venta. Los deals enterprise pueden cerrarse mucho después de que se pague la reclamación, así que dé seguimiento a las cohortes por trimestre.
Vuelque los resultados en los niveles de socios para que los de mejor desempeño ganen más acceso. El artículo sobre el modelo de ventas por canal muestra dónde encaja esto entre las demás palancas del canal.
Modos de fallo habituales
Fondos sin utilizar. Asignaciones que caducan al cierre del trimestre, reclamaciones presentadas fuera de la ventana o planes que nunca se convierten en solicitudes. Los vendors pierden buena voluntad y los socios pierden dinero que habrían usado.
Prueba deficiente. Facturas ausentes, una factura generada por el socio sin nada que la respalde, ninguna lista de leads, ningún logo en el material. Estas son las razones habituales por las que se rechaza una reclamación, y tanto DigiCert como GitLab detallan lo que necesitan.
Empezar antes de la aprobación. El error autoinfligido más frecuente. Si el gasto se hizo antes de la aprobación, normalmente no es elegible.
Exposición a auditorías y fraude. DigiCert se reserva el derecho de auditar y verificar las reclamaciones, solicitar más documentación y excluir de los MDF durante un periodo a los socios que no cumplan. Los términos de GitLab exigen que los socios actúen de forma ética y legal, y prohíben ofrecer algo de valor de manera indebida para influir en las personas. Las facturas infladas, las evidencias recicladas y las reclamaciones dobles entre vendors son los patrones de fraude que los programas existen para detectar. Los eventos con varios vendors son un lugar habitual de doble financiación, y por eso GitLab limita la financiación cuando participan varios vendors.
Vínculo débil con los resultados. Si la actividad financiada no se asocia con deals registrados, el vendor no puede saber qué funcionó, y el programa se convierte en un presupuesto de patrocinios.
Fricción en el canal. Los MDF pueden alimentar disputas cuando una campaña genera leads que persiguen tanto el equipo de venta directa como un socio. Aquí importan las reglas de interacción (rules of engagement), y el artículo sobre el programa de socios de canal explica cómo los programas las formalizan.
Datos clave: fondos de desarrollo de mercado
- Los MDF son dinero del vendor que cofinancia el marketing de los socios; DigiCert afirma que los fondos MDF pertenecen al vendor y se reembolsan por las actividades aprobadas a su discreción (DigiCert).
- La documentación de gestión de socios de Oracle define tres tipos de fondos MDF: fijo, de acumulación y mixto (Oracle).
- GitLab exige una solicitud preaprobada y una reclamación dentro de los 30 días naturales posteriores al fin de la actividad (GitLab Handbook).
- GitLab indica que cubre hasta el 50% del costo total de una actividad, con una solicitud mínima actual de $1,000 (GitLab Handbook).
- La guía de HubSpot para 2025 describe los MDF como un modelo de mérito, reservado en general para los socios Platinum, Diamond y Elite (HubSpot).
- Según la ASC 606, los pagos a un cliente reducen los ingresos, a menos que compren un servicio distinto (BYU School of Accountancy).
Lecturas relacionadas
Co-Founder & COO