Fiscalidad de un marketplace con Stripe Connect: quién factura, declara el IVA y reconoce el ingreso
Stripe Connect resuelve una parte técnica muy importante de un marketplace: cobrar al cliente, distribuir fondos entre cuentas conectadas, retener comisiones y gestionar reembolsos o disputas.
Pero Stripe no decide quién vende.
Tampoco decide quién debe emitir la factura, declarar el IVA, reconocer el ingreso o responder ante una reclamación del cliente. Eso depende del modelo contractual y de cómo funciona realmente la plataforma.
El error más peligroso es diseñar primero el flujo de pagos y tratar de justificar después la fiscalidad. El orden correcto es el contrario:
Definir quién presta o vende.
Establecer quién contrata con el cliente.
Determinar quién factura y asume el riesgo.
Configurar Stripe para reflejar ese modelo.
Construir la contabilidad y la conciliación.
Dos modelos que no deben confundirse
La mayoría de las plataformas encaja, total o parcialmente, en uno de estos modelos.
Modelo 1: el marketplace actúa como intermediario
La plataforma conecta a un cliente con un profesional, propietario, comercio u otro proveedor independiente. El proveedor realiza la operación principal y la plataforma cobra una comisión por facilitarla.
En una estructura coherente:
El proveedor presta el servicio o vende el producto al cliente.
El proveedor factura al cliente por el importe total de su operación.
La plataforma factura al proveedor su comisión y, en su caso, otros servicios.
El ingreso de la plataforma es la comisión, no todo el dinero cobrado al cliente.
Las cantidades destinadas al proveedor son fondos gestionados o saldos a pagar, no un gasto por una compra propia de la plataforma.
Ejemplo
El cliente paga 121 euros por un servicio. La plataforma retiene una comisión de 20 euros más el IVA que corresponda y transfiere el resto al profesional.
Si la plataforma es un intermediario real, no debería registrar automáticamente 121 euros como cifra de negocio y la transferencia como gasto. Debe reconocer su comisión como ingreso y reflejar correctamente el saldo cobrado por cuenta del proveedor.
La factura del profesional al cliente debe existir aunque Stripe haya cobrado inicialmente en la cuenta de la plataforma.
Modelo 2: la plataforma actúa como proveedor principal
La plataforma vende al cliente el servicio o producto en nombre propio y subcontrata a un tercero para ejecutarlo.
En este modelo:
La plataforma contrata directamente con el cliente.
La plataforma fija o controla las condiciones esenciales de la venta.
La plataforma factura al cliente el importe completo.
La plataforma reconoce como ingreso la venta total.
El profesional o proveedor factura sus servicios a la plataforma.
La plataforma reconoce ese coste y soporta el riesgo comercial frente al cliente.
Ejemplo
El cliente paga 121 euros a una plataforma de servicios vacacionales. La plataforma se compromete a prestar el servicio completo y contrata a un profesional por 70 euros.
La plataforma registra la venta al cliente como ingreso y la factura del profesional como coste. Su margen no es la cantidad que Stripe retiene técnicamente, sino la diferencia económica entre la venta y los costes asociados, una vez tratados correctamente los impuestos.
La comparación que debe quedar por escrito
| Elemento | Marketplace intermediario | Plataforma como proveedor principal |
|---|---|---|
| Vendedor o prestador ante el cliente | Profesional o proveedor | Plataforma |
| Factura principal al cliente | La emite el proveedor | La emite la plataforma |
| Factura de la plataforma | Comisión al proveedor | Venta completa al cliente |
| Ingreso de la plataforma | Comisión y servicios propios | Importe total de la venta |
| Pago al proveedor | Liquidación de fondos | Pago de una factura de coste |
| Riesgo de ejecución | Principalmente el proveedor | Principalmente la plataforma |
| Devoluciones y reclamaciones | Según contrato; normalmente proveedor | Responsabilidad directa de la plataforma |
| IVA | Sobre la comisión o servicio propio | Sobre la operación completa, según su naturaleza |
Esta tabla no se elige por conveniencia contable. Debe reflejar la realidad jurídica y operativa.
Las preguntas que determinan quién vende
Antes de cerrar el modelo, conviene responder sin ambigüedad:
¿Quién aparece como parte contratante en los términos y condiciones?
¿Quién fija el precio final?
¿Quién describe y promete el servicio al cliente?
¿Quién puede aceptar o rechazar la operación?
¿Quién responde si el proveedor no se presenta o presta mal el servicio?
¿Quién decide una devolución?
¿Quién asume el coste de un reembolso o chargeback?
¿Quién emite la factura principal?
¿Quién figura en el checkout, el recibo y el extracto bancario?
¿El proveedor puede contratar directamente con el cliente o la plataforma revende en nombre propio?
Ninguna respuesta aislada decide el resultado. Lo importante es la coherencia del conjunto.
Si los términos dicen que la plataforma es solo intermediaria, pero esta fija unilateralmente el servicio, promete el resultado, factura al cliente y soporta todos los reembolsos, existe una contradicción que debe corregirse.
Qué configura Stripe Connect y qué no configura
Stripe Connect permite diferentes tipos de cargos. Por ejemplo, con los destination charges el cargo se crea en la plataforma y el importe restante se transfiere a una cuenta conectada. Con separate charges and transfers, la plataforma realiza el cargo y puede distribuir después fondos entre una o varias cuentas.
Esa elección afecta a:
Dónde se crea el cargo.
Cómo se transfieren los fondos.
Qué cuenta soporta comisiones de Stripe.
Cómo se gestionan reembolsos y disputas.
Qué información aparece en determinados recibos o extractos.
Pero no transforma por sí sola una comisión en una venta completa ni convierte automáticamente a la plataforma en proveedor fiscal.
La regla básica del IVA sigue siendo que el impuesto lo debe, con carácter general, el sujeto pasivo que realiza la entrega de bienes o prestación de servicios, salvo que una norma atribuya la obligación a otra persona.
El error contable de registrar el payout como una factura
Un payout es un movimiento de fondos. No es necesariamente una venta, una compra ni una factura.
En Stripe pueden coexistir:
Pago del cliente.
Comisión de procesamiento.
Comisión de la plataforma.
Transferencia a una cuenta conectada.
Reembolso parcial o total.
Chargeback o disputa.
Ajustes y reservas.
Conversión de moneda.
Transferencia del saldo disponible al banco.
Si la contabilidad solo importa el extracto bancario, pierde el detalle económico. El ingreso aparece cuando Stripe envía el dinero al banco en lugar de cuando se produce la venta, varios pedidos se agrupan en un único payout y las comisiones quedan mezcladas.
El resultado puede ser una cifra de negocio incorrecta, IVA mal calculado y saldos de proveedores imposibles de conciliar.
Qué datos necesita la contabilidad
La conciliación debería unir cuatro capas:
Pedido o reserva en la plataforma.
Factura o documento fiscal.
Movimiento de Stripe.
Transferencia o liquidación al proveedor.
El registro mínimo por operación debería contener:
| Dato | Función |
| ID de pedido | Identifica la operación comercial |
| ID de Payment Intent o Charge | Une la operación con el cobro |
| Cliente y país | Ayuda a determinar localización e IVA |
| Proveedor conectado | Identifica al prestador o vendedor subyacente |
| Importe bruto | Total pagado por el cliente |
| Impuestos | Separa base y cuota |
| Comisión de plataforma | Determina el ingreso del intermediario |
| Comisión de Stripe | Registra el coste financiero |
| Transferencia al proveedor | Liquida el saldo o paga el coste según el modelo |
| Reembolsos y disputas | Corrige ingresos, impuestos y saldos |
| ID de factura | Acredita el tratamiento fiscal |
| Moneda y tipo de cambio | Evita diferencias de conciliación |
La contabilidad no debería depender de descripciones manuales o de conceptos bancarios genéricos. Debe existir una clave única que conecte todo el recorrido.
¿Quién emite la factura?
La respuesta depende del modelo.
Si la plataforma es intermediaria
Normalmente se necesitan dos documentos:
Factura del proveedor al cliente por la operación principal.
Factura de la plataforma al proveedor por la comisión o los servicios contratados.
La plataforma puede automatizar la emisión material de facturas en nombre del proveedor si existe una estructura legal adecuada, pero eso no cambia necesariamente quién realiza la prestación. La numeración, autorización, datos fiscales y conservación deben estar correctamente organizados.
Si la plataforma vende en nombre propio
La plataforma emite la factura al cliente por el total. El profesional factura a la plataforma por el servicio subcontratado.
En ambos casos deben revisarse las reglas de localización, el tipo de cliente, la naturaleza del servicio o producto y los países implicados. No existe un único tratamiento de IVA válido para todos los marketplaces.
¿Puede una plataforma utilizar los dos modelos?
Sí, pero no de forma improvisada.
Una empresa puede intermediar en una línea de negocio y vender en nombre propio en otra. Por ejemplo:
Marketplace de servicios domésticos: la plataforma conecta al cliente con el profesional y cobra una comisión.
Servicio vacacional gestionado: la plataforma vende un paquete completo y subcontrata a profesionales.
El modelo híbrido exige separar:
Condiciones contractuales.
Flujos de checkout.
Series de facturación.
Cuentas contables.
Reglas de IVA.
Políticas de reembolso.
Informes de Stripe.
Márgenes y métricas de cada línea.
Si se mezcla todo en una sola cuenta de ventas, la dirección deja de saber qué negocio gana dinero y la asesoría pierde la trazabilidad fiscal.
DAC7: informar no significa pagar un impuesto nuevo
Las plataformas digitales que facilitan determinadas actividades pueden quedar sometidas a obligaciones de identificación y comunicación de información sobre vendedores en virtud de DAC7.
DAC7 no crea por sí misma un nuevo impuesto sobre los ingresos de los vendedores. Su objetivo es mejorar la transparencia y el intercambio de información entre administraciones.
Una plataforma potencialmente afectada debe preparar desde el alta del proveedor:
Identidad y datos fiscales.
Residencia fiscal.
Número de identificación fiscal y, cuando proceda, IVA.
Cuenta financiera de cobro.
Contraprestaciones pagadas o abonadas.
Comisiones, tarifas o impuestos retenidos por la plataforma.
Actividad y periodos correspondientes.
Intentar recopilar estos datos al final del año genera cuentas bloqueadas, proveedores sin validar y declaraciones incompletas.
Ocho errores que conviene evitar
Copiar la configuración técnica de otro marketplace. El flujo de Stripe puede parecer igual y el contrato ser completamente distinto.
Registrar como ventas todos los cobros. En un modelo de intermediación puede inflar ingresos e IVA.
Registrar como gasto toda transferencia al proveedor. Una liquidación de fondos no equivale automáticamente a una compra.
Emitir una única factura de comisión sin factura principal al cliente. La operación subyacente queda sin documentar.
No tratar reembolsos y disputas a nivel de pedido. Los abonos terminan en periodos y cuentas incorrectos.
Usar el payout bancario como fuente contable. Agrupa operaciones diferentes y oculta comisiones.
Mezclar intermediación y venta propia. Impide medir márgenes y aplicar correctamente el IVA.
Dejar DAC7 para diciembre. La diligencia debida comienza al incorporar al vendedor.
Cómo diseñar la operativa antes del lanzamiento
Un proceso razonable sería:
Dibujar el flujo contractual y el flujo de dinero por separado.
Elegir el modelo económico de cada línea de negocio.
Revisar términos y condiciones, checkout y política de devoluciones.
Definir quién emite cada factura y cuándo.
Configurar Stripe Connect conforme al modelo decidido.
Crear el plan contable y las cuentas de saldos de proveedores.
Automatizar la relación entre pedidos, cargos, transferencias y facturas.
Preparar el alta fiscal de vendedores y los datos de DAC7.
Probar ventas, cancelaciones, reembolsos parciales y disputas.
Conciliar un mes completo antes de aumentar inversión en captación.
El mejor momento para detectar un fallo no es cuando ya existen miles de operaciones, sino cuando todavía pueden simularse diez pedidos y seguir manualmente cada euro.
Conclusión
Stripe Connect es infraestructura de pagos, no un criterio fiscal.
Un marketplace debe decidir si intermedia por cuenta de terceros o vende en nombre propio. Esa decisión cambia quién factura, qué importe reconoce como ingreso, cómo se declara el IVA, qué representa el pago al proveedor y quién soporta el riesgo frente al cliente.
La tecnología debe reflejar esa realidad. Si el contrato, el checkout, las facturas, Stripe y la contabilidad cuentan historias distintas, el problema no es solo administrativo: la empresa no conoce su margen real y queda expuesta ante clientes, proveedores y administraciones.
¿Estás creando o gestionando un marketplace con Stripe Connect?
En Gestoría Marketplace revisamos el modelo contractual y económico junto con el circuito de pagos, facturación, IVA, contabilidad y DAC7. También diseñamos la conciliación para separar ventas, comisiones, fondos de proveedores, reembolsos y costes de Stripe.
Antes de escalar tráfico, valida quién vende y consigue que cada euro tenga pedido, factura, movimiento y responsable.
